anti-aliasing

[SM Ryan]

Re: anti-aliasing

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:

# I seem to be a bit fuzzy as to how one would write code that would
# detect that it was running on *your* machine, rather than

The genitive is not the same as the possessive. Learn to speaking
english good. If you are using a Macintosh OS 10.4, then you are
using my machine.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
You face forward, or you face the possibility of shock and damage.

[Serve Laurijssen]

Re: anti-aliasing


"Malcolm McLean" <regniztar@btin ternet.comwrote in message
news:vuydnR2erK r-3FLYnZ2dnUVZ8qm inZ2d@bt.com...

After a call to memsame() fails, the pointers have an implicit restrict.
So effectively what we are doing is binding the restrict at run time
rather than at ccompile time.

Can you give an example on how you envision that it should work in real
code?
Either I'm missing something here or it just isnt possible what you want.

A compiler cant optimize at runtime, or well C compilers cant :)
The only thing I can see how the function could work is like

void foo(char *p1, char *p2)
{
if (memsame(p1,p2) )
memmove();
else
memcpy();
}

but then you provide the optimization which can be handled more gracefully
by

void foo(char *p1, char *p2) { memmove(); }
void kungfoo(char * restrict p1, char * restrict p2) { memcpy(); }

And the compiler also knows it can do the usual aliasing optimizations on
the restrict version.
I really dont see a use for such a function.

[Malcolm McLean]

Re: anti-aliasing


"Serve Laurijssen" <ser@n.tkwrot e in message

>
"Malcolm McLean" <regniztar@btin ternet.comwrote in message
news:vuydnR2erK r-3FLYnZ2dnUVZ8qm inZ2d@bt.com...

>After a call to memsame() fails, the pointers have an implicit restrict.
>So effectively what we are doing is binding the restrict at run time
>rather than at ccompile time.

>
Can you give an example on how you envision that it should work in real
code?
Either I'm missing something here or it just isnt possible what you want.
>
A compiler cant optimize at runtime, or well C compilers cant :)
The only thing I can see how the function could work is like
>
void foo(char *p1, char *p2)
{
if (memsame(p1,p2) )
memmove();
else
memcpy();
}
>
>

That is exactly how it is. A modern memcpy() is probably written just like
that to allow aliases and efficinet copying of non-aliases. It can't be done
portably in A|NSI C, because of the pointers to different objects not
comparing rule.

but then you provide the optimization which can be handled more gracefully
by
>
void foo(char *p1, char *p2) { memmove(); }
void kungfoo(char * restrict p1, char * restrict p2) { memcpy(); }
>
And the compiler also knows it can do the usual aliasing optimizations on
the restrict version.
I really dont see a use for such a function.
>

The problem is we've got this.

high_level_func tion(MYTYPE *ptr1, MYTYPE *ptr2)
{
kungfoo(ptr1, ptr2);
}

sorry, says the compiler. Make that high_level_func tion(restrict MYTYPE
*ptr1, restrict MYTYPE *ptr2).

Then every caller of high_level_func tion must ensure that parameters are
restricted. However that can be hard to arrange. So the whole program grinds
up in a mass of difficulties.

This way, we go

high_level_func tion(MYTYPE *ptr1, MYTYPE *ptr2)
{
if(memsame(ptr1 , sizeof *ptr1, ptr2, sizeof ptr2))
foo()
else
kungfoo();
}

So we are handling the problem at runtime rather than compile time, which
isn't in itself ideal, but it buys us an escape from restrict poisoning.

[Christopher Layne]

Re: anti-aliasing

SM Ryan wrote:

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:
>
# I seem to be a bit fuzzy as to how one would write code that would
# detect that it was running on *your* machine, rather than
>
The genitive is not the same as the possessive. Learn to speaking
english good. If you are using a Macintosh OS 10.4, then you are
using my machine.

Really - and our current use and allocation of dynamic memory is exactly the
same?

[Christopher Layne]

Re: anti-aliasing

Malcolm McLean wrote:

>void foo(char *p1, char *p2)
>{
> if (memsame(p1,p2) )
> memmove();
> else
> memcpy();
>}
>>
>>

That is exactly how it is. A modern memcpy() is probably written just like
that to allow aliases and efficinet copying of non-aliases. It can't be done
portably in A|NSI C, because of the pointers to different objects not
comparing rule.

google: opensolaris, memcpy.s

[Malcolm McLean]

Re: anti-aliasing

"Christophe r Layne" <clayne@com.ano dizedwrote in message

>

>That is exactly how it is. A modern memcpy() is probably written just
>like
>that to allow aliases and efficinet copying of non-aliases. It can't be
>done
>portably in A|NSI C, because of the pointers to different objects not
>comparing rule.

>
google: opensolaris, memcpy.s
>

That one isn't. It will break if passed two buffers that overlap within the
same word.

That is legitimate, because memcpy() is defined as UB if passed aliased
types, but other memcpy()s, for instance the Iris one I used a while back
for RISC processors, do cut the user some slack on this and will handle
overlapping arguments, so memcpy() is effectively the same function as
memmove(). As a general rule that is the better approach, hence the
qualification, "modern" memcpy().

[Arthur J. O'Dwyer]

Re: anti-aliasing


On Sun, 11 Feb 2007, Malcolm McLean wrote:

"Arthur J. O'Dwyer" <ajonospam@andr ew.cmu.eduwrote

>>
> There is no "fast no-alias version" of strcpy. The strcpy function
>by definition /is/ "fast no-alias"; trying to strcpy overlapping objects
>results in undefined behavior. Therefore, as I originally said, the
>programmer is complicating and pessimizing his code by adding that
>"memsame" call. The compiler certainly is not helped by it.
> All you're doing is adding another assertion. Adding assertions may be
>an admirable goal, but you could probably assert further up the call stack
>for better effect.
>>
> Maybe if you post an example of code that would /benefit/ from this
>new function, the advantages will become clearer.
>>

If you want to be fussy about it, stcpy does have an implict restrict.

No, if I wanted to be fussy, I'd ask what you meant by "stcpy".

So try this real function I wrote the other day.
>
int rectangle(unsig ned char *rgba, int width, int height, double x1, double
y1, double x2, double y2, unsigned char *col)
{

[...]

for(i=(int)y1;i <= (int) y2; i++)
for(ii = (int) x1; ii<= (int) x2; ii++)
{
offset = (i * width + ii) * 4;
rgba[ offset ] = ((int) col[0] * col[3] + rgba[offset] * (255 -
col[3]))/255;
rgba[ offset + 1] = (((int) col[1]) * col[3] + rgba[offset+1] * (255 -
col[3])) / 255;
rgba[ offset + 2] = (((int) col[2]) * col[3] + rgba[offset+2] * (255 -
col[3])) / 255;
}
>
return 0;
}
>
Fortunately it is not a bottleneck function, but it could easily be. The
problem for the compiler is that col - the rectangle colour - could easily
be an alias for the draw space. So it has got to either take risks or read
the colour from memory on each pixel.
So add a "memsame" at the front of the function, and the compiler can
optimise the code.

Add 'restrict' at the front of each pointer variable, and the compiler
can optimize the code, without needing to use anything not already present
in the existing C99 standard.

'restrict' does not suffer from the "poisoning" problem ("const
poisoning"); there's no need to propagate it up the call chain.

If you're really paranoid about some halfway-conforming compiler
requiring you to cast 'restrict', you could always write

void im_scared(unsig ned char *p, unsigned char *q) {
unsigned char * restrict real_p = p;
unsigned char * restrict real_q = q;
...and now deal with real_p and real_q...
}

But, as I said, that's not necessary in C99.

-Arthur

[Arthur J. O'Dwyer]

Re: anti-aliasing


On Mon, 12 Feb 2007, Arthur J. O'Dwyer wrote:

>
'restrict' does not suffer from the "poisoning" problem ("const
poisoning"); there's no need to propagate it up the call chain.

...And by "up", I meant "down". (Brain fart.) I can't think of
anything that propagates /up/ the call chain in C.
(Except non-constness. ;)

If you're really paranoid about some halfway-conforming compiler
requiring you to cast 'restrict', you could always write
>
void im_scared(unsig ned char *p, unsigned char *q) {
unsigned char * restrict real_p = p;
unsigned char * restrict real_q = q;
...and now deal with real_p and real_q...
}

However, that seems to be a pessimization on both compilers I tried
(GCC and Green Hills) --- you get worse code that way than if you'd
simply omitted 'restrict' in the first place. (GCC 3.3.5 seems to
ignore 'restrict' qualifiers anyway, as far as I can tell, so it
doesn't give you better code from any of these contortions.)

-Arthur

[Malcolm McLean]

Re: anti-aliasing


"Arthur J. O'Dwyer" <ajonospam@andr ew.cmu.eduwrote in message

On Mon, 12 Feb 2007, Arthur J. O'Dwyer wrote:

>>
> 'restrict' does not suffer from the "poisoning" problem ("const
>poisoning"); there's no need to propagate it up the call chain.

>
...And by "up", I meant "down". (Brain fart.) I can't think of
anything that propagates /up/ the call chain in C.
(Except non-constness. ;)
>

That's the whole point.
restrict poisioning is like const poisoning, but much worse, because you
poison two variables at each stage.

[Flash Gordon]

Re: anti-aliasing

Malcolm McLean wrote, On 12/02/07 10:31:

"Christophe r Layne" <clayne@com.ano dizedwrote in message

>>That is exactly how it is. A modern memcpy() is probably written just
>>like
>>that to allow aliases and efficinet copying of non-aliases. It can't be
>>done
>>portably in A|NSI C, because of the pointers to different objects not
>>comparing rule.

>google: opensolaris, memcpy.s
>>

That one isn't. It will break if passed two buffers that overlap within the
same word.

Ah, so a memcpy that does not meet your expectations is not a valid
counter-example to your expectations of how memcpy is written?

That is legitimate, because memcpy() is defined as UB if passed aliased
types, but other memcpy()s, for instance the Iris one I used a while back
for RISC processors, do cut the user some slack on this and will handle
overlapping arguments, so memcpy() is effectively the same function as
memmove(). As a general rule that is the better approach, hence the
qualification, "modern" memcpy().

As a general rule of thumb I will use memmove if there is is a
possibility of overlap (or if I'm being lazy) and memcpy if I want
efficiency so I would say that making memcpy as efficient as possible
and only having the overhead of the check in memmove is a better
approach as a general rule.

Both memcpy and memmove are provided for good reasons.
--
Flash Gordon

[Malcolm McLean]

Re: anti-aliasing


"Flash Gordon" <spam@flash-gordon.me.ukwro te in message

>
As a general rule of thumb I will use memmove if there is is a possibility
of overlap (or if I'm being lazy) and memcpy if I want efficiency so I
would say that making memcpy as efficient as possible and only having the
overhead of the check in memmove is a better approach as a general rule.
>
Both memcpy and memmove are provided for good reasons.
>

It depends what the consequences are of you accidentally using a memcpy()
when you meant to use memmove(). If nothing too dire suggests itself, then
it is better to have that little bit extra efficiency and omit the check.

[Flash Gordon]

Re: anti-aliasing

Malcolm McLean wrote, On 12/02/07 23:18:

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message

>As a general rule of thumb I will use memmove if there is is a possibility
>of overlap (or if I'm being lazy) and memcpy if I want efficiency so I
>would say that making memcpy as efficient as possible and only having the
>overhead of the check in memmove is a better approach as a general rule.
>>
>Both memcpy and memmove are provided for good reasons.
>>

It depends what the consequences are of you accidentally using a memcpy()
when you meant to use memmove(). If nothing too dire suggests itself, then
it is better to have that little bit extra efficiency and omit the check.

If you use the correct function for your parameters the program works,
if you use the wrong one all bets are off with the most likely results
(unless using the DS9K) being an incorrect result or a crash.

If you do
ptr = malloc(10000);
instead of
tmpptr = realloc(ptr,100 00);
if (...

Then your program will probably crash. If you do
tmpptr = realloc(ptr,100 00);
without knowing if ptr is initialised there is a fair chance your
program will crash at some point.

The difference is that if you are not comfortable you can use memcpy
correctly you always have the option of banning it from your code and
sticking to memmove. Personally I prefer to know where my pointers point
which makes it trivially easy to know if it is safe to use memcpy and I
would not trust software using either function from someone who did not
know is memcpy would be safe in any place where they used either
function. After all, if they don't know if it is possible for the
regions to overlap how can they know what behaviour they want if they
do? The required behaviour is not always that of memmove!
--
Flash Gordon

[Christopher Layne]

Re: anti-aliasing

Flash Gordon wrote:

As a general rule of thumb I will use memmove if there is is a
possibility of overlap (or if I'm being lazy) and memcpy if I want
efficiency so I would say that making memcpy as efficient as possible
and only having the overhead of the check in memmove is a better
approach as a general rule.
>
Both memcpy and memmove are provided for good reasons.

Exactly!

[Christopher Layne]

Re: anti-aliasing

Malcolm McLean wrote:

It depends what the consequences are of you accidentally using a memcpy()
when you meant to use memmove(). If nothing too dire suggests itself, then
it is better to have that little bit extra efficiency and omit the check.

This is part of the "have the library hand-hold the programmer" school of
thought. How about, verify you aren't going to overlap and use memcpy in that
case, or memmove if not?

[Arthur J. O'Dwyer]

Re: anti-aliasing


On Mon, 12 Feb 2007, Malcolm McLean wrote:

"Arthur J. O'Dwyer" <ajonospam@andr ew.cmu.eduwrote in message

>On Mon, 12 Feb 2007, Arthur J. O'Dwyer wrote:

>>>
>> 'restrict' does not suffer from the "poisoning" problem ("const
>>poisoning") ; there's no need to propagate it up the call chain.

>>
> ...And by "up", I meant "down". (Brain fart.) I can't think of
>anything that propagates /up/ the call chain in C.
>(Except non-constness. ;)

>
That's the whole point.
restrict poisioning is like const poisoning, but much worse, because you
poison two variables at each stage.

"restrict poisoning" does not exist. (I said that already, in the
post you quoted above.)

You are solving a non-problem because you do not understand C typing
rules.

-Arthur