Re: [gtk-list] Re: ItemFactory anyone?

[Shaw Terwilliger <sterwill postman abisource com>]

Jan Kratochvil wrote:
>   At first I should say that I'm in no way an Alpha expert or multi-platform geek
> (only x86 unfortunately, only some shared access to Linux/Sparc). But:

I'm not really an expert either, but I've got one here for
portability testing, and stuffing a pointer in an Item 
Factory int already bit me.  I ended up dumping the
factory and doing the menus by hand.  :)

>   a) I expect that guint/gint maps to "unsigned int"/"int" on all platforms.

Probably true... but an unsigned int is 32-bits on the Alpha.

>   b) I somewhere heard that GCC relies on the fact that (void *) fits in an "int"
>      datatype anyway.

I don't think ANSI C ever guarantees this.  GCC gives 
a warning (not an error) when you cast (void *) into 
(unsigned int), but it allows you to proceed, and if you
do the cast explicitly, I don't think it even whines about it.

>   c) Alpha really should have int/gint 64-bits wide. It's pure 64-bit CPU/system
>      so why it would mess with anything smaller?

Why not make sizeof(char) == 4 too?  :)

>From the Alpha Architecture Handbook:

http://ftp.digital.com/pub/Digital/info/semiconductor/literature/alphaahb.pdf

Section 2.1 says:

byte = 8 bits
word = 2 contiguous bytes
longword = 4 contiguous bytes
quadword = 8 contiguous bytes

The Alpha also supports some Vax types I won't get in to.
Section 2.2.7 gets into longword integer storage, which would
be 4 contiguous bytes (32-bits).  This is what GCC allocates 
when you use "unsigned int foo = 0;"

Also, the Alpha requires access to be byte aligned by the
size of the you're accessing.  For examples, loads and stores
of 32-bit quantities must lie on 32-bit (4 byte) boundaries.
Access to 64-bit quantities must lie on 64-bit (8 byte)
boundaries.  Single byte (char) should be byte aligned.  
 
-- 
Shaw Terwilliger