Re: Different multiply operator for pointers and integers

[Nick Ing-Simmons <nick at ing-simmons dot net>]

Richard Henderson <rth@redhat.com> writes:
>On Fri, Dec 17, 2004 at 04:12:01PM +0100, Laura Tosoratto wrote:
>> 3)When an address calculation is performed  (i.e.  for a[i])  I want to 
>> use the mult_a operator (at RTL level)
>> instead of the mult_i:
>> @a[i] = &a + i mult_a sizeof(a[i])
>> because I want to leave unchanged the upper 32 bits of the address (the 
>> remote part).
>> A typical situation is:
>> b = a[i+X_PLUS]
>> that means that I want to read variable a[i] on the remote node at 
>> coordinates x+1 from the local node (machine has SIMD architecture)
>> and store it in the local variable b. X_PLUS is a pure remote address 
>> (its lower 32 bits are zero).
>
>Why a mult_a operator then?  You don't perform multiplication on
>pointers.  You perform multiplication on integers and then add
>an integer to a pointer.
>
>As for a special plus_a operator, I'm certain that you could not
>reliably do this in gcc.  However...
>
>In what situation do you expect the low half of an object to be
>located at the highest address on a node, and the upper half of
>the same object to be located at the lowest address on a node?
>
>This would be a highly surprising bit of memory management, it
>seems to me.  That sort of thing in my experience only gets used
>on 8- and 16-bit microcontrolers in which we want to use, say, a
>signed 4-bit displacement from the zero register, or some really
>quirky addressing mode like that.
>
>If you never have such an object placement, then you *don't care*
>what the wrapping characteristics of pointer arithmetic are.  
>Plain old 64-bit integer arithmetic is fine.
>
>So why, exactly, do you want to do anything special with pointer
>arithmetic at all?  My guess is that your goals are not clear.

It seems that Laura's address multiply operataes on a 32-bit 
"subreg" of the 64-bit address.

So I think plain-old 32-bit integer arithmetic is fine.

64-bit would be wrong as 

   0x100000001 * 4 would be 0x400000004

and that has changed "nodes" 

But 32-bit on low half 

   0x1:0x00000001 * 4 would be 0x1:0x00000004

Is fine.

As usual with weird machines the trick is not to lie to the 
compiler. These addresses are NOT flat - they are akin
to 8086 segment register/address register pairs.
They are going to cause the same pain. Things like 
adr * 4 being turned into adr << 2 won't work right
and will need to be back-recognised and turn back into multiply.

So some kind of PDIMODE is 

>
>
>r~