[builder-ac-amd64@pld-linux.org: ERRORS: scorched3d.spec]

[Paweł Sikora]

On Tuesday 13 of April 2004 21:35, Jakub Bogusz wrote:
> On Tue, Apr 13, 2004 at 08:50:18PM +0200, Paweł Sikora wrote:
> > On Tuesday 13 of April 2004 20:05, Jakub Bogusz wrote:
> > >     dReal *tmprow = (dReal*) ((char*)((((((int)(__builtin_alloca ((n *
> > > sizeof(dReal))+(16 -1)))))-1)|(16 -1))+1)); ^^^
> > >
> > > Co się stanie z 64-bitowym wskaźnikiem po zrzutowaniu na 32-bitowego
> > > inta i rozszerzeniu z powrotem do 64-bitowego wskaźnika, łatwo
> > > przewidzieć.
> >
> > glowy nie dam, ale w standardzie C stoi bodajze, ze:
> >
> > *int ma rozmiar naturalnego slowa maszynowego*
> > i zachowany jest porzadek sizeof(short) <= sizeof(int) <= sizeof(long).
> >
> > czyli...
> >
> > w przypadku arch. 32 bitowej jest to np.:
> > short(16) <= int(32) <= long(32).
> >
> > w przypadku arch. 64 bitowej powinno byc IMO:
> > short(...) <= int(64) <= long(64...)
>
> Tak być nie musi i nie jest.
> Nie byłoby wtedy typu 16- lub 32-bitowego wśród standardowych.

zerknijmy tu: http://www.opengroup.org/public/tech/aspen/lp64_wp.htm 

"C language standards specify a set of *relationships between* the various
 data types but deliberately *do not define actual sizes*.
 Ignoring the non-standard types for a moment, all three 64-bit pointer
 models satisfy the rules as specified."

Datatype  LP64 ILP64 LLP64 ILP32 LP32
char         8    8    8    8    8
short       16   16   16   16   16
_int32           32
int         32   64   32   32   16
long        64   64   32   32   32
long long             64
pointer     64   64   64   32   32

> Różnicą w stosunku do 32-bitowych architektur jest rozmiar longa
> i wskaźnika (a tym samym typów definiowanych w rodzaju size_t
> i pokrewnych), przynajmniej na alphie, amd64, sparc64... ppc64
> i ia64 prawie na pewno też.

roznica IMO jest taka, ze jedziemy na protezie LP64 by 32-bitowe
nieprzenosne (sztywno zakladajace, ze int to 4 bajty) zrodla
sie nie posypaly po kompilacji na x86_64. jest tylko kwestia
czasu przejscie na natywne (dla procesorow) ILP64.

nasz przykladowy fragment kodu powinien nosic miano
"jak wydymac kompatybilnosc LP64" :-D
warto zauwazyc, ze przy natywnym sprzetowo ILP64 nic by sie nie stalo.

dReal *tmprow = (dReal*) ((char*)((((((int)(
                 __builtin_alloca(
                    (n *sizeof(dReal))
                   +(16 -1)))))-1)|(16 -1))+1));

no to chyba EOT. juz wiem wszystko :)

-- 
If you think of MS-DOS as mono, and Windows as stereo,
  then Linux is Dolby Digital and all the music is free...