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.
