Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #75726 > unrolled thread

memset extensions

Back to article view | Back to comp.lang.c

Contents

  memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 11:05 +0100
    Re: memset extensions Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-11-11 11:08 +0100
      Re: memset extensions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-11 04:56 -0800
    Re: memset extensions Philipp Klaus Krause <pkk@spth.de> - 2015-11-11 13:39 +0100
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 17:34 +0100
        Re: memset extensions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 17:22 +0000
          Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 21:19 +0100
            Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 12:51 -0800
            Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 16:01 -0500
              Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 22:03 +0100
                Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 13:19 -0800
                  Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 22:45 +0100
                    Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 16:51 -0500
                      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 23:01 +0100
                        Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 17:29 -0500
                          Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 23:36 +0100
                    Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 15:00 -0800
                Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 16:48 -0500
            Re: memset extensions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 22:15 +0000
    Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 08:05 -0500
    Re: memset extensions Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-11 08:31 -0500
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 17:34 +0100
    Re: memset extensions Les Cargill <lcargill99@comcast.com> - 2015-11-11 08:30 -0600
      Re: memset extensions Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-11 09:48 -0500
      Re: memset extensions gwowen <gwowen@gmail.com> - 2015-11-11 07:55 -0800
      Re: memset extensions James Kuyper <jameskuyper@verizon.net> - 2015-11-11 11:24 -0500
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 17:32 +0100
        Re: memset extensions Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-11 11:44 -0500
        Re: memset extensions raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:53 +0000
          Re: memset extensions supercat@casperkitty.com - 2015-11-17 15:37 -0800
            Re: memset extensions raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:27 +0000
              Re: memset extensions supercat@casperkitty.com - 2015-11-20 08:45 -0800
    Re: memset extensions supercat@casperkitty.com - 2015-11-11 08:25 -0800
    Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 09:09 -0800
      Re: memset extensions supercat@casperkitty.com - 2015-11-11 09:18 -0800
        Re: memset extensions Keith Thompson <kst-u@mib.org> - 2015-11-11 10:57 -0800
      Re: memset extensions jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-11 21:17 +0100

Page 2 of 2 — ← Prev page 1 [2]

#75737

On 11/11/2015 5:05 AM, jacobnavia wrote:
> void *memset(void *srcPtr,unsigned char value,size_t size);

     Note that this conflicts with the memset() of <string.h>.

> I want to add extensions to it:
>
> void memset16( void *srcPtr, int16_t  value, size_t size);
> void memset32( void *srcPtr, int32_t  value, size_t size);
> void memset64( void *srcPtr, int64_t  value, size_t size);
> void memset128(void *srcPtr, int128_t value, size_t size);
>
> Are the names OK? Or it would be better to just

     I'd suggest something like `destPtr' instead of `srcPtr',
as the latter connotes (to an English speaker) a "source" rather
than a "destination" or "target."

     I'd also suggest removing an ambiguity by changing `size' to
`byteCount' or `elementCount' (whichever one it's supposed to be).

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#75764

Le 11/11/2015 14:31, Eric Sosman a écrit :
> On 11/11/2015 5:05 AM, jacobnavia wrote:
>> void *memset(void *srcPtr,unsigned char value,size_t size);
>
>      Note that this conflicts with the memset() of <string.h>.
>
>> I want to add extensions to it:
>>
>> void memset16( void *srcPtr, int16_t  value, size_t size);
>> void memset32( void *srcPtr, int32_t  value, size_t size);
>> void memset64( void *srcPtr, int64_t  value, size_t size);
>> void memset128(void *srcPtr, int128_t value, size_t size);
>>
>> Are the names OK? Or it would be better to just
>
>      I'd suggest something like `destPtr' instead of `srcPtr',
> as the latter connotes (to an English speaker) a "source" rather
> than a "destination" or "target."
>
>      I'd also suggest removing an ambiguity by changing `size' to
> `byteCount' or `elementCount' (whichever one it's supposed to be).
>


Yes, that was a badly choosen name. Thanks

[toc] | [prev] | [next] | [standalone]

#75741

jacobnavia wrote:
> void *memset(void *srcPtr,unsigned char value,size_t size);
>
> I want to add extensions to it:
>
> void memset16( void *srcPtr, int16_t  value, size_t size);
> void memset32( void *srcPtr, int32_t  value, size_t size);
> void memset64( void *srcPtr, int64_t  value, size_t size);
> void memset128(void *srcPtr, int128_t value, size_t size);
>
> Are the names OK? Or it would be better to just
>
> void memsetShort(...);
> void memsetInt(...);
> void memsetLongLong(...);
> void memset128(...);
>
> Microsoft has this functions as RTLFillMemory. I do not know if other
> compilers support anything like this.
>
> What do you think?


It sounds like a complete waste of time. But if you insist:

#define memset16(a,b,c) memset(a,b,(c*2))

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#75746

On 11/11/2015 9:30 AM, Les Cargill wrote:
> jacobnavia wrote:
>> void *memset(void *srcPtr,unsigned char value,size_t size);
>>
>> I want to add extensions to it:
>>
>> void memset16( void *srcPtr, int16_t  value, size_t size);
>> void memset32( void *srcPtr, int32_t  value, size_t size);
>> void memset64( void *srcPtr, int64_t  value, size_t size);
>> void memset128(void *srcPtr, int128_t value, size_t size);
>>
>> Are the names OK? Or it would be better to just
>>
>> void memsetShort(...);
>> void memsetInt(...);
>> void memsetLongLong(...);
>> void memset128(...);
>>
>> Microsoft has this functions as RTLFillMemory. I do not know if other
>> compilers support anything like this.
>>
>> What do you think?
>
>
> It sounds like a complete waste of time. But if you insist:
>
> #define memset16(a,b,c) memset(a,b,(c*2))

	int16_t array[10];
	memset16(array, 12345, 10);
	assert(array[0] == 12345);  // Oops!

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#75755

On Wednesday, November 11, 2015 at 2:26:33 PM UTC, Les Cargill wrote:

> It sounds like a complete waste of time. But if you insist:
> 
> #define memset16(a,b,c) memset(a,b,(c*2))

That doesn't work.

[toc] | [prev] | [next] | [standalone]

#75759

On 11/11/2015 09:30 AM, Les Cargill wrote:
> jacobnavia wrote:
>> void *memset(void *srcPtr,unsigned char value,size_t size);
>>
>> I want to add extensions to it:
>>
>> void memset16( void *srcPtr, int16_t  value, size_t size);
>> void memset32( void *srcPtr, int32_t  value, size_t size);
>> void memset64( void *srcPtr, int64_t  value, size_t size);
>> void memset128(void *srcPtr, int128_t value, size_t size);
>>
>> Are the names OK? Or it would be better to just
>>
>> void memsetShort(...);
>> void memsetInt(...);
>> void memsetLongLong(...);
>> void memset128(...);
>>
>> Microsoft has this functions as RTLFillMemory. I do not know if other
>> compilers support anything like this.
>>
>> What do you think?
> 
> 
> It sounds like a complete waste of time. But if you insist:
> 
> #define memset16(a,b,c) memset(a,b,(c*2))

He hasn't specified what these functions do, but I doubt that
memset(a,b,(c*2)) is the intended behavior. My best guess is something
like the following:

    void memset16( void *srcPtr, int16_t  value, size_t size)
    {
        int16_t *destPtr = srcPtr;
        while(size--)
           *destPtr++ = value;
   }

[toc] | [prev] | [next] | [standalone]

#75762

Le 11/11/2015 15:30, Les Cargill a écrit :

>
>
> It sounds like a complete waste of time. But if you insist:
>
> #define memset16(a,b,c) memset(a,b,(c*2))
>

The motivation is to use the native instructions of the x86 processor to 
fill in the array.

And besides, you can't fill a int16_t array with memset unless all your 
values fit into a char...

[toc] | [prev] | [next] | [standalone]

#75767

On 11/11/2015 11:32 AM, jacobnavia wrote:
> Le 11/11/2015 15:30, Les Cargill a écrit :
>
>>
>>
>> It sounds like a complete waste of time. But if you insist:
>>
>> #define memset16(a,b,c) memset(a,b,(c*2))
>>
>
> The motivation is to use the native instructions of the x86 processor to
> fill in the array.
>
> And besides, you can't fill a int16_t array with memset unless all your
> values fit into a char...

     Not even then.

	int16_t array[10];
	memset(array, 42, sizeof array);
	assert(array[0] == 42);  // Oops!

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#76315

jacobnavia <jacob@jacob.remcomp.fr> wrote:

> Le 11/11/2015 15:30, Les Cargill a écrit :
> 
> > It sounds like a complete waste of time. But if you insist:
> >
> > #define memset16(a,b,c) memset(a,b,(c*2))
> 
> The motivation is to use the native instructions of the x86 processor to 
> fill in the array.

Problem: that's a moving target. And in any case, you definitely
shouldn't tie the definition of the language to a single processor, so
if you intend for these extensions to be widely used, you can't assume
only, or even all of, what x86 has, let alone what it has today.

How about this?

  memfill(void *dest, void *source, size_t len, size_t num);

fills memory at /dest/ with /num/ copies of the first /len/ bytes found
at /source/. In essence, it does this:

  memfill(void *dest, void *source, size_t len, size_t num)
  {
    unsigned char *d=dest;

    for (size_t n=0; n<num; n++) {
      unsigned char *s=source;

      for (size_t l=0; l<len; l++)
        *d++ = *s++;
    }
  }

Since it's a library function, this can easily be replaced inline with
special-case functions when the implementation detects that it's being
called with /len/ equal to one of your special values - and this has the
advantage that it can _also_ be special-cased for values none of us has
thought of yet, instead of being only allowed special-casing for the
handful of functions now in your proposal. _And_ it'll work, even if
less efficiently, for other values.

Return value as you please; memset() returns dest, which is useless.
Returning the value of dest after the copying would be more useful, but
inconsistent. I have no objection either way.

Richard

[toc] | [prev] | [next] | [standalone]

#76328

On Tuesday, November 17, 2015 at 4:53:29 PM UTC-6, Richard Bos wrote:
> How about this?
> 
>   memfill(void *dest, void *source, size_t len, size_t num);

Any restrictions on the relative locations of source and dest?  My
inclination would be to apply "restrict" qualifiers on source and dest
*but* specify that if source==dest, the function must behave as though
it is reading from as well as writing to *dest, and it may arbitrarily
write or refrain from writing the portion of dest which would be copied
to itself [IMHO, memcpy should be defined in similar fashion so as to
facilitate certain kinds of array-permutation code].  Note that a compiler
wouldn't to generate code that checked whether the pointers were equal--
it would merely have to *refrain* from drawing any inferences about whether
they are or not].

[toc] | [prev] | [next] | [standalone]

#76621

supercat@casperkitty.com wrote:

> On Tuesday, November 17, 2015 at 4:53:29 PM UTC-6, Richard Bos wrote:
> > How about this?
> > 
> >   memfill(void *dest, void *source, size_t len, size_t num);
> 
> Any restrictions on the relative locations of source and dest?

Take your pick; either use the memcpy() or the memmove() setup.

>  My inclination would be to apply "restrict" qualifiers on source and dest
> *but* specify that if source==dest, the function must behave as though
> it is reading from as well as writing to *dest,

Premature optimisation is the root of much computing evil. No. Besides,
you can't apply restrict _and_ allow certain overlap; the two are
contradictory.

> [IMHO, memcpy should be defined in similar fashion so as to
> facilitate certain kinds of array-permutation code].

Thus denying potential optimisation to others for an ephemeral one for
yourself. No, thanks, I'd rather not.

Richard

[toc] | [prev] | [next] | [standalone]

#76647

On Friday, November 20, 2015 at 5:28:08 AM UTC-6, Richard Bos wrote:
> Premature optimisation is the root of much computing evil. No. Besides,
> you can't apply restrict _and_ allow certain overlap; the two are
> contradictory.

Restrict does not forbid passing identical pointers; what it forbids is
accessing the same object via a restrict pointer and anything other than a
pointer derived from it, except in cases where the object is unmodified
during the lifetime of the restrict pointer.  There would be nothing
contradictory about the definition of the function as I specified it
doesn't actually have to generate any machine code.  

> Thus denying potential optimisation to others for an ephemeral one for
> yourself. No, thanks, I'd rather not.

Suppose one needs a function which can swap two objects in memory which might
be equal but are known not to overlap otherwise; the case where objects are
equal is expected to be sufficiently rare that the performance of that case
is not abysmally worse than the disjoint case.  Is there any way one could
write such a function which could be optimized to code equivalent to what
would be possible if memcpy were as I described?

Note that writing the function as:

    void swap(void *p1, void *p2, void *temp, size_t size)
    {
      if (p1 == p2) return;
      memcpy(temp, p1, size);
      memcpy(p1, p2, size);
      memcpy(p2, temp, size);
    }

would require a compiler to generate extra code that an optimizer might in
many cases be forbidden from eliminating (since passing null to p1 and p2
would be defined behavior), but in the only situations where imposing the
requirements on memcpy() would impede otherwise-useful optimizations (as
opposed to code-breaking "optimizations"), those optimizations could be
re-allowed by adding, either before or after the memcpy call:

    +sizeof ((*)int[p1!=p2])

Since the size of the pointer would be independent of the value of the
subscript, a compiler would be under no obligation to evaluate the subscript,
but if p1==p2 the sizeof expression would yield Undefined Behavior since the
compiler would be allowed to evaluate it if it so chose.

[toc] | [prev] | [next] | [standalone]

#75760

On Wednesday, November 11, 2015 at 4:06:03 AM UTC-6, jacobnavia wrote:
> Are the names OK? Or it would be better to just
> 
> void memsetShort(...);
> void memsetInt(...);
> void memsetLongLong(...);
> void memset128(...);

Even in platforms where `short` and `int16_t` have the same representation,
they are not interchangeable.  According to the rules regarding reads and
writes of different types, given:

    short x=1234;
    void *p1 = &x;
    int16_t *p2 = p1;
    p2++;

or

    int16_t x=1234;
    void *p1 = &x;
    short *p2 = p1;
    p++;

a compiler may silently decide to do anything it likes, since both snippets
write memory as one type and read it as another, and nothing in the Standard
requires that any of the "normal" integer types be recognized as equivalent
to any "fixed-sized" types for purposes of those rules.

Consequently, the forms using "short", "long", etc. will not be redundant
with the forms involving fixed-sized values unless or until the Standard
provides a means of saying that code will need to read a pointer as a
different type from what was written, and at least in that particular
situation the cost of jumping through the hoops necessary to conform to
the C89 rules would exceed any realistic useful optimization a compiler
could hope to achieve by declaring it Undefined Behavior.

[toc] | [prev] | [next] | [standalone]

#75776

jacobnavia <jacob@jacob.remcomp.fr> writes:
> void *memset(void *srcPtr,unsigned char value,size_t size);

The actual declaration of memset is:

    void *memset(void *s, int c, size_t n);

The second argument is converted to unsigned char.  (It would make
more sense for the argument to be of type unsigned char, but memset()
probably predates both the unsigned char and prototypes.)

> I want to add extensions to it:
>
> void memset16( void *srcPtr, int16_t  value, size_t size);
> void memset32( void *srcPtr, int32_t  value, size_t size);
> void memset64( void *srcPtr, int64_t  value, size_t size);
> void memset128(void *srcPtr, int128_t value, size_t size);

Others have commented on the names.  I suggest that the second
parameter should be of an unsigned type.

If you're suggesting that these be added to the standard, none of the
[u]intN_t types are required.  Because of that, it would probably be
more consistent to use unsigned short, unsigned int, unsigned long,
unsigned long long.  (And int128_t is very likely not to exist.)

If this is only for your own implementation, then the uintN_t types
are probably ok.

The behavior should be undefined if the target isn't properly
aligned.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#75778

On Wednesday, November 11, 2015 at 11:09:17 AM UTC-6, Keith Thompson wrote:
> If you're suggesting that these be added to the standard, none of the
> [u]intN_t types are required.  Because of that, it would probably be
> more consistent to use unsigned short, unsigned int, unsigned long,
> unsigned long long.  (And int128_t is very likely not to exist.)

The Standard could specify that the headers should include the appropriate
memset versions for the uintN_t types that it defines, rather than having
an explicit list of names, so if a particular platform implements uint24_t,
then it should have a "memset24()" function, but a platform without such
a type would not be expected to have that function.

If the Standard doesn't specify versions of memset for the fixed-sized types
how should code initialize an array of e.g. "uint32_t", given that even on
platforms where UINT_MAX is 4294967295, writing a storage as type "unsigned
int" and reading as type "uint32_t" invokes Undefined Behavior.

[toc] | [prev] | [next] | [standalone]

#75783

supercat@casperkitty.com writes:
> On Wednesday, November 11, 2015 at 11:09:17 AM UTC-6, Keith Thompson wrote:
>> If you're suggesting that these be added to the standard, none of the
>> [u]intN_t types are required.  Because of that, it would probably be
>> more consistent to use unsigned short, unsigned int, unsigned long,
>> unsigned long long.  (And int128_t is very likely not to exist.)
>
> The Standard could specify that the headers should include the appropriate
> memset versions for the uintN_t types that it defines, rather than having
> an explicit list of names, so if a particular platform implements uint24_t,
> then it should have a "memset24()" function, but a platform without such
> a type would not be expected to have that function.
>
> If the Standard doesn't specify versions of memset for the fixed-sized types
> how should code initialize an array of e.g. "uint32_t", given that even on
> platforms where UINT_MAX is 4294967295, writing a storage as type "unsigned
> int" and reading as type "uint32_t" invokes Undefined Behavior.

Perhaps the effective type rules could be updated to specify that the
new memset*() functions don't violate them.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#75785

Le 11/11/2015 18:09, Keith Thompson a écrit :
> If you're suggesting that these be added to the standard, none of the
> [u]intN_t types are required.  Because of that, it would probably be
> more consistent to use unsigned short, unsigned int, unsigned long,
> unsigned long long.  (And int128_t is very likely not to exist.)

Yes, I think unsigned types would be better. Thanks

P.S. lcc-win has 128 bit integers since at least 5 years.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web