Nick Glencross wrote: > Jarkko Hietaniemi wrote: > > >>>Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6 >>>
> Ok, so intsize=4, which is why my md5 test tried to run. I'd be really > grateful if some could run my instrumented MD5.imc from a previous post > on this platform. > > So what I'm confused about is why intsize=4 when you say the Parrot core > is 64 bit. Weelll... I did not say *quite* that. What I said that so far the Parrot's core seems to have worked well in systems with _some_ 64-bit integer types available. So the Parrot core has been 64-bit _safe_, which doesn't mean it has been _using_ 64-bit integers explicitly (e.g. in Tru64 it has been using 64-bit longs implicitly). > Isn't one of the points of a 64-bit processor to have larger > ints (often accompanied by larger address space)? So if ints are just 4 The 64-bit type can be int, long, long long, quad_t, int64_t, ... > bytes, what would trip things up on Tru64? > > There are a few reasons why I'm keen to get this resolved. 1) My > assumption that intsize!=4 for 64-bit processors is broken, which is why Please do not assume such things. The only thing C promises in this regard is that sizeof(int) <= sizeof(long). 4 <= 8, or 8 <= 8 (or 4 <= 4 in the 32-bit world.) See e.g. http://www.unix.org/version2/whatsnew/lp64_wp.html > the test is seen to fail. 2) I would like the library to work on all > platforms. 3) I'm curious to know why it doesn't work, as it was > expected to work on different endianess and word size. 4) the md5 > library has been, and hopefully will continue to be, a good way to shake > problems out of the parrot core. > > Thanks all, > > Nick > -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
