[Openmcl-devel] Windows versions of CCL available for smoke-testing

[Gary Byers]

On Thu, 9 Oct 2008, Brian Mastenbrook wrote:

>
> On Oct 9, 2008, at 12:59 PM, Gary Byers wrote:
>
>> On Thu, 9 Oct 2008, Brian Mastenbrook wrote:
>> 
>>> Very cool. Is this fully relocatable? This is probably less of an issue on 
>>> Win64, of course.
>> 
>> We don't do relocation correctly on ia32 yet
>> 
>> <http://trac.clozure.com/openmcl/ticket/331>
>> 
>> (This would affect 32-bit Darwin and Linux as well as 32-bit Windows.)
>
> Interesting. Does this include things like NIL & friends?

No.

>
>> AFAIK (and as far as I remember), it's worked correctly.  The fact that
>> 'long' is only 32 bits on win64 has sometimes meant that "correctly" and
>> "as expected" aren't quite the same thing.
>
> This is what uint64_t and intptr_t are for, right? Most problematic uses of 
> "long" that I've run into should in fact be intptr_t.

Yes, that it what things like that are for.

Given something like:

typedef uint64_t natural;

...

natural bits_in_last_word, nbits_in_word;

...

natural mask = ~((1L<<(nbits_in_word-bits_in_last_word))-1L);

I found it surprising that both the shift and subtraction were done in
32-bit aritmetic and the result was then sign-extended (IIRC, it was
sign-, not 0-extended) to 64 bits.  (Conditionally) changing the 1L's
to 1LL's avoided the unexpected truncation of intermediate arithmetic
results.

If I was more of a C weenie than I am, I probably shouldn't have been
surprised by that.  Inscrutable C arithmetic rules and the fact that
1L is a 64-bit constant on other 64-bit platforms but a 32-bit constant
on win64 made the fact that 'mask' only ever had <= 32 significant bits
set hard to spot. I'm perfectly willing to believe that gcc's behavior
here was correct, but I doubt if I'm the only person who would find it
useless and unintuitive.  (I'd also be willing to believe that it's
a bug, but I find it very difficult to distinguish between C compiler
bugs and "correct but useless C compiler behavior".)

As practical advice, I think that it's fair to say that the fact that
'long' is 32 bits wide on win64 will likely introduce surprising
effects.


>
> --
> Brian Mastenbrook
> brian at mastenbrook.net
> http://brian.mastenbrook.net/
>