Pointers Extend Unsigned Question

Pointers Extend Unsigned Question

[Donn Terry]

Particularly to Jeff or either Richard, but if anyone else can 
contribute, please do.  (It's a simple yes/no question, once explained.)
This is "before I go on a wild goose chase".

Alpha 32 is (as far as I can find with a grep) the only architecture
where POINTERS_EXTEND_UNSIGNED is true.  (At least that anyone
will admit to.)  On Alpha32, POINTERS_EXTEND_UNSIGNED is
defined to be 0 (both for Windows and VMS variants, altho I
know very little about the latter.)

For most purposes Alpha32 works.  On NT, user space pointers
are (except in rare circumstances, which may never have been
hit) by definition in the low half of the address
space, so sign extension is in practice not an issue,
most of the time.  (No comment on VMS).

Anyway, I'm running into a problem reflected (but NOT exclusively)
in the following RTL, selected more or less at random from
a lot of samples.  This is something I haven't touched (yet).

    (insn 7 6 8 (set (reg:DI 70)
            (const_int -1 [0xffffffffffffffff])) -1 (nil)
        (nil))

    (insn 8 7 9 (set (reg/i:DI 0 $0)
            (and:DI (reg:DI 70)
                (const_int 4294967295 [0xffffffff]))) -1 (nil)
        (nil))

    (insn 9 8 10 (use (reg/i:DI 0 $0)) -1 (nil)
        (nil))

This is an extract of a trivial function returning a pointer,
where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
"don't do that": it's from gcc/calls.c!)

Note that $0 (the return value) is masked (NOT extended) to
32 bits, so the sign information is lost.  This sort of thing
is not at all rare, by any means.  (I've been looking at
LOTS of RTL of late.)

I can interpret the semantics of POINTERS_EXTEND_UNSIGNED in
two ways: it's supposed to be occurring "under the covers"
and not reflected in the RTL, or that the RTL above is incorrect,
and insn 8 should be an extend (optimized to nothing, I'd hope).

Is the above RTL consistent with the intent of POINTERS_EXTEND_UNSIGNED
or not?  (Given an answer to that, I can plan my attack on the
problem.)

My best guess is that the RTL above is not what was intended, but
it would be wise to have confirmation before I go after the
problem. (A response confirming this, or not, would be most
appreciated.)

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question

[Joern Rennecke]

> This is an extract of a trivial function returning a pointer,
> where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
> "don't do that": it's from gcc/calls.c!)

If the value is compared against (ptr) (HOST_WIDE_INT) -1 ,
and the compiler does the extensions consistently, this should
work regardless of whether it zero extends or sign extends.

Re: Pointers Extend Unsigned Question

[Donn Terry]

It definitely isn't handling the issue consistently, but looking
at the code where it's tripping up, it seems that the intent THERE is
that the RTL should contain sign extensions, but it's unclear
from any documentation what the intent really is.  (It could
be handled "under the covers" as well in both places (??), but it
would be uglier, I think.)

The path to the actual failure is long and VERY obscure, and
since it occurs in the "keep trying until you find something
you like" code in combine.c, it never makes it to a file where
it would be relatively easy to see (until the difference is so
great that it's unrecognizable... a split and a couple of folds
occur after the actual problem).

I have all the ugly details, and can send them, but knowing the
authors' intent would be very useful.

Donn


Joern Rennecke wrote:
> 
> > This is an extract of a trivial function returning a pointer,
> > where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
> > "don't do that": it's from gcc/calls.c!)
> 
> If the value is compared against (ptr) (HOST_WIDE_INT) -1 ,
> and the compiler does the extensions consistently, this should
> work regardless of whether it zero extends or sign extends.

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question

[Richard Henderson]

On Thu, Apr 29, 1999 at 09:34:37AM -0600, Donn Terry wrote:
> Alpha 32 is (as far as I can find with a grep) the only architecture
> where POINTERS_EXTEND_UNSIGNED is true.

The only other target I can think of where this should be a problem
is a mips3 target running in 64-bit mode with 32-bit pointers.  I
don't know if anyone actually uses such a configuration in practice.
I suspect that normally the chip is simply put into 32-bit mode.

> For most purposes Alpha32 works.  On NT, user space pointers
> are (except in rare circumstances, which may never have been
> hit) by definition in the low half of the address
> space, so sign extension is in practice not an issue,
> most of the time.  (No comment on VMS).

I suspect that simply not having told the compiler that pointers
are unsigned will solve the problem.  Something like this?

Thoughts?


r~


Index: stor-layout.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/stor-layout.c,v
retrieving revision 1.25
diff -c -p -d -r1.25 stor-layout.c
*** stor-layout.c	1999/03/11 13:56:20	1.25
--- stor-layout.c	1999/04/29 20:33:51
*************** layout_type (type)
*** 795,801 ****
--- 795,805 ----
        TYPE_MODE (type) = ptr_mode;
        TYPE_SIZE (type) = bitsize_int (POINTER_SIZE, 0L);
        TYPE_SIZE_UNIT (type) = size_int (POINTER_SIZE / BITS_PER_UNIT);
+ #if defined(POINTERS_EXTEND_UNSIGNED)
+       TREE_UNSIGNED (type) = ! POINTERS_EXTEND_UNSIGNED;
+ #else
        TREE_UNSIGNED (type) = 1;
+ #endif
        TYPE_PRECISION (type) = POINTER_SIZE;
        break;
  

Re: Pointers Extend Unsigned Question

[Donn Terry]

Richard Henderson wrote:
> 
> On Thu, Apr 29, 1999 at 09:34:37AM -0600, Donn Terry wrote:
> > Alpha 32 is (as far as I can find with a grep) the only architecture
> > where POINTERS_EXTEND_UNSIGNED is true.
> 
> The only other target I can think of where this should be a problem
> is a mips3 target running in 64-bit mode with 32-bit pointers.  I
> don't know if anyone actually uses such a configuration in practice.
> I suspect that normally the chip is simply put into 32-bit mode.

Had *I* a choice, I'd choose putting a chip into 32 bit mode,
but that's me :-).


> > For most purposes Alpha32 works.  On NT, user space pointers
> > are (except in rare circumstances, which may never have been
> > hit) by definition in the low half of the address
> > space, so sign extension is in practice not an issue,
> > most of the time.  (No comment on VMS).
> 
> I suspect that simply not having told the compiler that pointers
> are unsigned will solve the problem.  Something like this?
> 
> Thoughts?

That was one of the directions I was planning to explore, pending
some indication of original intent.  For the moment, I'll take this as 
an indication that the RTL was wrong (which is what the change you
suggest below implies) and see what happens.

If there's disagreement, PLEASE let me know as soon as possible.
(If I run into any more problems like this, I'm going to continue
in the same direction.)

Thanks!

Donn

> 
> r~
> 
> Index: stor-layout.c
> ===================================================================
> RCS file: /egcs/carton/cvsfiles/egcs/gcc/stor-layout.c,v
> retrieving revision 1.25
> diff -c -p -d -r1.25 stor-layout.c
> *** stor-layout.c       1999/03/11 13:56:20     1.25
> --- stor-layout.c       1999/04/29 20:33:51
> *************** layout_type (type)
> *** 795,801 ****
> --- 795,805 ----
>         TYPE_MODE (type) = ptr_mode;
>         TYPE_SIZE (type) = bitsize_int (POINTER_SIZE, 0L);
>         TYPE_SIZE_UNIT (type) = size_int (POINTER_SIZE / BITS_PER_UNIT);
> + #if defined(POINTERS_EXTEND_UNSIGNED)
> +       TREE_UNSIGNED (type) = ! POINTERS_EXTEND_UNSIGNED;
> + #else
>         TREE_UNSIGNED (type) = 1;
> + #endif
>         TYPE_PRECISION (type) = POINTER_SIZE;
>         break;
> 

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question

[Jim Wilson]

	The only other target I can think of where this should be a problem
	is a mips3 target running in 64-bit mode with 32-bit pointers.  I
	don't know if anyone actually uses such a configuration in practice.
	I suspect that normally the chip is simply put into 32-bit mode.

The default irix6 ABI (n32) uses 32-bit pointers in 64-bit mode.

The mips backend however always sign extends 4-byte values, regardless of
type, so we shouldn't see this problem for a mips target.  This happens
primarily via TRULY_NOOP_TRUNCATION and the truncate patterns in the md file.

The alpha port doesn't use TRULY_NOOP_TRUNCATION.  It uses different
mechanisms to get a similar effect.  The alpha way is probably better in some
ways.  My recollection though is that the 32-bit alpha port wasn't stable until
after most of the intial irix6 porting work was done, so I ended up using
different methods than what Kenner invented for the 32-bit alpha port.

Jim

Re: Pointers Extend Unsigned Question

[Jeffrey A Law]

  In message < 19990429133715.C4270@cygnus.com >you write:
  > The only other target I can think of where this should be a problem
  > is a mips3 target running in 64-bit mode with 32-bit pointers.  I
  > don't know if anyone actually uses such a configuration in practice.
  > I suspect that normally the chip is simply put into 32-bit mode.
There is such a target.  The mips chip found in the psII.  It's a mips3
variant that runs in 64bit mode, but pointers are only 32bits.

jeff

Re: Pointers Extend Unsigned Question

[Donn Terry]

It definitely isn't handling the issue consistently, but looking
at the code where it's tripping up, it seems that the intent THERE is
that the RTL should contain sign extensions, but it's unclear
from any documentation what the intent really is.  (It could
be handled "under the covers" as well in both places (??), but it
would be uglier, I think.)

The path to the actual failure is long and VERY obscure, and
since it occurs in the "keep trying until you find something
you like" code in combine.c, it never makes it to a file where
it would be relatively easy to see (until the difference is so
great that it's unrecognizable... a split and a couple of folds
occur after the actual problem).

I have all the ugly details, and can send them, but knowing the
authors' intent would be very useful.

Donn


Joern Rennecke wrote:
> 
> > This is an extract of a trivial function returning a pointer,
> > where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
> > "don't do that": it's from gcc/calls.c!)
> 
> If the value is compared against (ptr) (HOST_WIDE_INT) -1 ,
> and the compiler does the extensions consistently, this should
> work regardless of whether it zero extends or sign extends.

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question

[Jim Wilson]

	The only other target I can think of where this should be a problem
	is a mips3 target running in 64-bit mode with 32-bit pointers.  I
	don't know if anyone actually uses such a configuration in practice.
	I suspect that normally the chip is simply put into 32-bit mode.

The default irix6 ABI (n32) uses 32-bit pointers in 64-bit mode.

The mips backend however always sign extends 4-byte values, regardless of
type, so we shouldn't see this problem for a mips target.  This happens
primarily via TRULY_NOOP_TRUNCATION and the truncate patterns in the md file.

The alpha port doesn't use TRULY_NOOP_TRUNCATION.  It uses different
mechanisms to get a similar effect.  The alpha way is probably better in some
ways.  My recollection though is that the 32-bit alpha port wasn't stable until
after most of the intial irix6 porting work was done, so I ended up using
different methods than what Kenner invented for the 32-bit alpha port.

Jim

Pointers Extend Unsigned Question

[Donn Terry]

Particularly to Jeff or either Richard, but if anyone else can 
contribute, please do.  (It's a simple yes/no question, once explained.)
This is "before I go on a wild goose chase".

Alpha 32 is (as far as I can find with a grep) the only architecture
where POINTERS_EXTEND_UNSIGNED is true.  (At least that anyone
will admit to.)  On Alpha32, POINTERS_EXTEND_UNSIGNED is
defined to be 0 (both for Windows and VMS variants, altho I
know very little about the latter.)

For most purposes Alpha32 works.  On NT, user space pointers
are (except in rare circumstances, which may never have been
hit) by definition in the low half of the address
space, so sign extension is in practice not an issue,
most of the time.  (No comment on VMS).

Anyway, I'm running into a problem reflected (but NOT exclusively)
in the following RTL, selected more or less at random from
a lot of samples.  This is something I haven't touched (yet).

    (insn 7 6 8 (set (reg:DI 70)
            (const_int -1 [0xffffffffffffffff])) -1 (nil)
        (nil))

    (insn 8 7 9 (set (reg/i:DI 0 $0)
            (and:DI (reg:DI 70)
                (const_int 4294967295 [0xffffffff]))) -1 (nil)
        (nil))

    (insn 9 8 10 (use (reg/i:DI 0 $0)) -1 (nil)
        (nil))

This is an extract of a trivial function returning a pointer,
where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
"don't do that": it's from gcc/calls.c!)

Note that $0 (the return value) is masked (NOT extended) to
32 bits, so the sign information is lost.  This sort of thing
is not at all rare, by any means.  (I've been looking at
LOTS of RTL of late.)

I can interpret the semantics of POINTERS_EXTEND_UNSIGNED in
two ways: it's supposed to be occurring "under the covers"
and not reflected in the RTL, or that the RTL above is incorrect,
and insn 8 should be an extend (optimized to nothing, I'd hope).

Is the above RTL consistent with the intent of POINTERS_EXTEND_UNSIGNED
or not?  (Given an answer to that, I can plan my attack on the
problem.)

My best guess is that the RTL above is not what was intended, but
it would be wise to have confirmation before I go after the
problem. (A response confirming this, or not, would be most
appreciated.)

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question

[Richard Henderson]

On Thu, Apr 29, 1999 at 09:34:37AM -0600, Donn Terry wrote:
> Alpha 32 is (as far as I can find with a grep) the only architecture
> where POINTERS_EXTEND_UNSIGNED is true.

The only other target I can think of where this should be a problem
is a mips3 target running in 64-bit mode with 32-bit pointers.  I
don't know if anyone actually uses such a configuration in practice.
I suspect that normally the chip is simply put into 32-bit mode.

> For most purposes Alpha32 works.  On NT, user space pointers
> are (except in rare circumstances, which may never have been
> hit) by definition in the low half of the address
> space, so sign extension is in practice not an issue,
> most of the time.  (No comment on VMS).

I suspect that simply not having told the compiler that pointers
are unsigned will solve the problem.  Something like this?

Thoughts?


r~


Index: stor-layout.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/stor-layout.c,v
retrieving revision 1.25
diff -c -p -d -r1.25 stor-layout.c
*** stor-layout.c	1999/03/11 13:56:20	1.25
--- stor-layout.c	1999/04/29 20:33:51
*************** layout_type (type)
*** 795,801 ****
--- 795,805 ----
        TYPE_MODE (type) = ptr_mode;
        TYPE_SIZE (type) = bitsize_int (POINTER_SIZE, 0L);
        TYPE_SIZE_UNIT (type) = size_int (POINTER_SIZE / BITS_PER_UNIT);
+ #if defined(POINTERS_EXTEND_UNSIGNED)
+       TREE_UNSIGNED (type) = ! POINTERS_EXTEND_UNSIGNED;
+ #else
        TREE_UNSIGNED (type) = 1;
+ #endif
        TYPE_PRECISION (type) = POINTER_SIZE;
        break;
  

Re: Pointers Extend Unsigned Question

[Joern Rennecke]

> This is an extract of a trivial function returning a pointer,
> where the value is (ptr) (HOST_WIDE_INT) -1.  (Don't say
> "don't do that": it's from gcc/calls.c!)

If the value is compared against (ptr) (HOST_WIDE_INT) -1 ,
and the compiler does the extensions consistently, this should
work regardless of whether it zero extends or sign extends.

Re: Pointers Extend Unsigned Question

[Jeffrey A Law]

  In message < 19990429133715.C4270@cygnus.com >you write:
  > The only other target I can think of where this should be a problem
  > is a mips3 target running in 64-bit mode with 32-bit pointers.  I
  > don't know if anyone actually uses such a configuration in practice.
  > I suspect that normally the chip is simply put into 32-bit mode.
There is such a target.  The mips chip found in the psII.  It's a mips3
variant that runs in 64bit mode, but pointers are only 32bits.

jeff

Re: Pointers Extend Unsigned Question

[Donn Terry]

Richard Henderson wrote:
> 
> On Thu, Apr 29, 1999 at 09:34:37AM -0600, Donn Terry wrote:
> > Alpha 32 is (as far as I can find with a grep) the only architecture
> > where POINTERS_EXTEND_UNSIGNED is true.
> 
> The only other target I can think of where this should be a problem
> is a mips3 target running in 64-bit mode with 32-bit pointers.  I
> don't know if anyone actually uses such a configuration in practice.
> I suspect that normally the chip is simply put into 32-bit mode.

Had *I* a choice, I'd choose putting a chip into 32 bit mode,
but that's me :-).


> > For most purposes Alpha32 works.  On NT, user space pointers
> > are (except in rare circumstances, which may never have been
> > hit) by definition in the low half of the address
> > space, so sign extension is in practice not an issue,
> > most of the time.  (No comment on VMS).
> 
> I suspect that simply not having told the compiler that pointers
> are unsigned will solve the problem.  Something like this?
> 
> Thoughts?

That was one of the directions I was planning to explore, pending
some indication of original intent.  For the moment, I'll take this as 
an indication that the RTL was wrong (which is what the change you
suggest below implies) and see what happens.

If there's disagreement, PLEASE let me know as soon as possible.
(If I run into any more problems like this, I'm going to continue
in the same direction.)

Thanks!

Donn

> 
> r~
> 
> Index: stor-layout.c
> ===================================================================
> RCS file: /egcs/carton/cvsfiles/egcs/gcc/stor-layout.c,v
> retrieving revision 1.25
> diff -c -p -d -r1.25 stor-layout.c
> *** stor-layout.c       1999/03/11 13:56:20     1.25
> --- stor-layout.c       1999/04/29 20:33:51
> *************** layout_type (type)
> *** 795,801 ****
> --- 795,805 ----
>         TYPE_MODE (type) = ptr_mode;
>         TYPE_SIZE (type) = bitsize_int (POINTER_SIZE, 0L);
>         TYPE_SIZE_UNIT (type) = size_int (POINTER_SIZE / BITS_PER_UNIT);
> + #if defined(POINTERS_EXTEND_UNSIGNED)
> +       TREE_UNSIGNED (type) = ! POINTERS_EXTEND_UNSIGNED;
> + #else
>         TREE_UNSIGNED (type) = 1;
> + #endif
>         TYPE_PRECISION (type) = POINTER_SIZE;
>         break;
> 

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question -- Alpha

[Donn Terry]

This discussion went off the main list a few days ago, but I felt that
the attached message belonged in the main list (and more importantly
the archives) so I'm attaching it.  If you're not interested in
arcanae of the Alpha, you can quit reading here.

As I have already said directly to him, thanks very much to 
Steven Hobbs for a very clearcut summary of what's going on here.
(The keeper of the VMS port, if there is one, may want to take
this information into account.)

He has kindly given his permission to pass this on, and says:

   You can also give out my e-mail address, steven.hobbs@compaq.com, to
   anyone who has questions about how compilers interact with the
   architecture and calling standard.

The upshot of all this is a patch that I'll be submitting here in a
few minutes.

Donn
-----------------------------------------------------------------
Donn:

I have been forwarded the questions you sent about how
Alpha handles 32 bit and 64 bit pointers and data.  Feel free to ask
me other questions about the Alpha architecture and the various Alpha
calling standards.  I am a compiler developer and I am a member of the
Alpha Architecture Committee and the Alpha Calling Standard Committee.
My e-mail address is steven.hobbs@compaq.com.

In regard to pointer and data type sizes, here is a table of the sizes
supported by the Alpha C compilers that use a Compaq developed code
generator:


                   Open VMS        Tru64 Unix           NT

char                     8               8               8
short                   16              16              16
int                     32              32              32
long                    32              64              32

pointer         default  32     default  64             32
                optional 64     optional 32

float                   32              32              32
double                  64              64              64

long double     default 128     versions 1-4  64        64
                optional 64     versions 5-N 128

In the case of the "optional" sizes, a compile-time switch and/or a
source language pragma are necessary to create values of the
non-default size.

The Alpha Architecture and the Alpha Calling Standard specify that all
32-bit values are sign extended when they are placed in 64-bit integer
registers.  This means that 32-bit signed integers, 32-bit unsigned
integers and 32-bit pointers are all sign extended in the same manner.
This rule is useful when converting programs from a 32-bit environment
where there might be type mismatches between 32-bit signed integers,
32-bit unsigned integers and 32-bit pointers because Alpha does the
same thing when these 32-bit types mismatch as when these types match.

Of course any sign extension convention will work if types are never
mismatched.  With the Alpha conventions, 32-bit programmers are never
surprised by what happens with 32-bit mismatches because they do not
see any behavior differences between the 32-bit types.  Some 64-bit
programmers might be surprised by what happens when they have a
mismatch between 32-bit unsigned integer and 64-bit unsigned integer.
However, there many more 32-bit programmers, and the 64-bit
programmers are usually much more careful in eliminating type
mismatches.

When an Alpha system is supporting a 32-bit address space, addresses

        0x00000000-0x7fffffff are mapped to
                0x0000000000000000-0x000000007fffffff

and

        0x80000000-0xffffffff are mapped to
                0xffffffff80000000-0xffffffffffffffff

It is not possible to have an object whose address starts at or below
0x7fffffff and ends above this address.  There is a discontinuity
between 0x7fffffff and 0x80000000 in the 32-bit address space.

On VMS (both VAX and Alpha) there are user address spaces, called P0
and P1, allocated between 0x0 - 0x7fffffff.  On VMS (both VAX and
Alpha) there are system address spaces, called S0 and S1, allocated
between 0x80000000 - 0xffffffff (on VAX and 32-bit Alpha) and between
0xffffffff80000000 - 0xffffffffffffffff (64-bit Alpha).  On VMS (Alpha
only) there is a 64-bit user space, called P2, allocated from
0x100000000 up through larger addresses (but probably ending before
0x3ffffffffff).  The Digital C compiler is consistent about sign
extending 32-bit addresses so that references to addresses in S0 and
S1 space will always work correctly.

On Tru64 Unix, 64-bit addresses are the default and "ld" usually
places user code and data above 0x100000000.  There is a -taso switch
that causes "ld" to limit program size to *31* bits of address space
and to load data between 0 and 0x7fffffff.  It turns out that the
original Digital C compiler, adapted from MIPS Ultrix, was not very
careful about always sign extending addresses.  Therefore code
compiled by this older compiler cannot work in a 32-bit address space
so it was decided that Digital Unix (now Tru64 Unix) would limit its
32-bit pointers to a 31-bit address space.

On NT, normal user programs are limited to 32-bit addresses between 0
- 0x7fffffff.  The operating system uses 32-bit addresses between
0xc0000000 - 0xffffffff.  There is an extended user address space
between 0x80000000 - 0xbfffffff.  In order for system space and
extended user space to work correctly, the compiler must be careful to
always sign extend 32-bit addresses.

If you find places where gcc is zero extending a 32-bit pointer into a
64-bit address then I would suggest that this be considered a bug.
Things will work much smoother if every Alpha compiler always sign
extends when converting pointers from 32-bits to 64-bits.

If you have any questions then please use steven.hobbs@compaq.com as
an e-mail address.  I am happy to give you any information you might
need.

--Steven Hobbs

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: Pointers Extend Unsigned Question -- Alpha

[Donn Terry]

This discussion went off the main list a few days ago, but I felt that
the attached message belonged in the main list (and more importantly
the archives) so I'm attaching it.  If you're not interested in
arcanae of the Alpha, you can quit reading here.

As I have already said directly to him, thanks very much to 
Steven Hobbs for a very clearcut summary of what's going on here.
(The keeper of the VMS port, if there is one, may want to take
this information into account.)

He has kindly given his permission to pass this on, and says:

   You can also give out my e-mail address, steven.hobbs@compaq.com, to
   anyone who has questions about how compilers interact with the
   architecture and calling standard.

The upshot of all this is a patch that I'll be submitting here in a
few minutes.

Donn
-----------------------------------------------------------------
Donn:

I have been forwarded the questions you sent about how
Alpha handles 32 bit and 64 bit pointers and data.  Feel free to ask
me other questions about the Alpha architecture and the various Alpha
calling standards.  I am a compiler developer and I am a member of the
Alpha Architecture Committee and the Alpha Calling Standard Committee.
My e-mail address is steven.hobbs@compaq.com.

In regard to pointer and data type sizes, here is a table of the sizes
supported by the Alpha C compilers that use a Compaq developed code
generator:


                   Open VMS        Tru64 Unix           NT

char                     8               8               8
short                   16              16              16
int                     32              32              32
long                    32              64              32

pointer         default  32     default  64             32
                optional 64     optional 32

float                   32              32              32
double                  64              64              64

long double     default 128     versions 1-4  64        64
                optional 64     versions 5-N 128

In the case of the "optional" sizes, a compile-time switch and/or a
source language pragma are necessary to create values of the
non-default size.

The Alpha Architecture and the Alpha Calling Standard specify that all
32-bit values are sign extended when they are placed in 64-bit integer
registers.  This means that 32-bit signed integers, 32-bit unsigned
integers and 32-bit pointers are all sign extended in the same manner.
This rule is useful when converting programs from a 32-bit environment
where there might be type mismatches between 32-bit signed integers,
32-bit unsigned integers and 32-bit pointers because Alpha does the
same thing when these 32-bit types mismatch as when these types match.

Of course any sign extension convention will work if types are never
mismatched.  With the Alpha conventions, 32-bit programmers are never
surprised by what happens with 32-bit mismatches because they do not
see any behavior differences between the 32-bit types.  Some 64-bit
programmers might be surprised by what happens when they have a
mismatch between 32-bit unsigned integer and 64-bit unsigned integer.
However, there many more 32-bit programmers, and the 64-bit
programmers are usually much more careful in eliminating type
mismatches.

When an Alpha system is supporting a 32-bit address space, addresses

        0x00000000-0x7fffffff are mapped to
                0x0000000000000000-0x000000007fffffff

and

        0x80000000-0xffffffff are mapped to
                0xffffffff80000000-0xffffffffffffffff

It is not possible to have an object whose address starts at or below
0x7fffffff and ends above this address.  There is a discontinuity
between 0x7fffffff and 0x80000000 in the 32-bit address space.

On VMS (both VAX and Alpha) there are user address spaces, called P0
and P1, allocated between 0x0 - 0x7fffffff.  On VMS (both VAX and
Alpha) there are system address spaces, called S0 and S1, allocated
between 0x80000000 - 0xffffffff (on VAX and 32-bit Alpha) and between
0xffffffff80000000 - 0xffffffffffffffff (64-bit Alpha).  On VMS (Alpha
only) there is a 64-bit user space, called P2, allocated from
0x100000000 up through larger addresses (but probably ending before
0x3ffffffffff).  The Digital C compiler is consistent about sign
extending 32-bit addresses so that references to addresses in S0 and
S1 space will always work correctly.

On Tru64 Unix, 64-bit addresses are the default and "ld" usually
places user code and data above 0x100000000.  There is a -taso switch
that causes "ld" to limit program size to *31* bits of address space
and to load data between 0 and 0x7fffffff.  It turns out that the
original Digital C compiler, adapted from MIPS Ultrix, was not very
careful about always sign extending addresses.  Therefore code
compiled by this older compiler cannot work in a 32-bit address space
so it was decided that Digital Unix (now Tru64 Unix) would limit its
32-bit pointers to a 31-bit address space.

On NT, normal user programs are limited to 32-bit addresses between 0
- 0x7fffffff.  The operating system uses 32-bit addresses between
0xc0000000 - 0xffffffff.  There is an extended user address space
between 0x80000000 - 0xbfffffff.  In order for system space and
extended user space to work correctly, the compiler must be careful to
always sign extend 32-bit addresses.

If you find places where gcc is zero extending a 32-bit pointer into a
64-bit address then I would suggest that this be considered a bug.
Things will work much smoother if every Alpha compiler always sign
extends when converting pointers from 32-bits to 64-bits.

If you have any questions then please use steven.hobbs@compaq.com as
an e-mail address.  I am happy to give you any information you might
need.

--Steven Hobbs

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================