Dossy, Your last question/point would seem to be reasonable, and in most cases the compilers DO the correct thing, but here too one needs to know and understand what the 'defaults' are for the compiler switches. If and only if, all of the compiler switches are correctly "switched", :), then the correct resultant executable/binary will result. This was one of the tough issues with Alpha as it supported everything, but sorting out the compiler switches was tedious at best.
Regards, Robert ----- Original Message ----- From: "Dossy Shiobara" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, February 01, 2005 12:07 AM Subject: Re: [AOLSERVER] Is AOLserver/Tcl 64-bit capable? > On 2005.01.31, Robert Garron <[EMAIL PROTECTED]> wrote: > > So, the best solution is to understand what the test does, understand > > the details of the chip architecture, and then to recode it for the > > SPARC chip, not to jump around it. > > You spent a whole lot of time explaining endianness when a link to > Wikipedia might have saved you a lot of time: > > http://en.wikipedia.org/wiki/Endianness > > > P.S. Obviously, if the bits and bytes are reordered, the time calculation > > will surely suffer some inaccuracy :). > > I'm guessing that the problem has to do with the differences between > ILP32 and LP64 systems. Here's a great page that talks about the > various architectures: > > http://www.unix.org/version2/whatsnew/lp64_wp.html > > This chart might make things slightly more interesting (taken from that > page): > > Datatype LP64 ILP64 LLP64 ILP32 LP32 > ---------- ---- ----- ----- ----- ---- > char 8 8 8 8 8 > short 16 16 16 16 16 > int 32 64 32 32 16 > long 64 64 32 32 32 > long long 64 > pointer 64 64 64 32 32 > > So, IA32 is ILP32 as well as 32-bit SPARC. I'm assuming that IA64 and > EM64T, along with AMD64 and 64-bit SPARC are LP64. (I'm guessing DEC > Alpha is also LP64.) > > The question is: what problems will we face when performing math on > 64-bit longs with 32-bit int's on LP64 platforms? Quoting that page > again: > > | A change in the width of one or more of the C datatypes affects > | programs in obvious and not so obvious ways. There are two basic > | sets of issues: (1) data objects defined with one of the 64-bit > | datatypes will be different in size from those declared in an > | identical way on a 16 or 32-bit system, and (2) assumptions (not > | those specified within the C standard, but used anyway by the > | developers of particular pieces of code) about the relationships > | between the fundamental datatypes may no longer be valid. Programs > | depending on those relationships often cease to work properly. > > Shouldn't modern-day compilers do the Right Thing(tm) when producing > 64-bit builds when promoting 32-bit ints to 64-bit longs when doing math > with mixed int and long values? Isn't that test comparing sizeof int > and long no longer relevant, then? > > -- Dossy > > -- > Dossy Shiobara mail: [EMAIL PROTECTED] > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
