64 windows caml

64 windows caml

[Niall Dalton]

Hi,

Is support for native code compilation on Window planned anytime soon?

Regards,
Niall

Re: 64 bit windows

[Niall Dalton]

Hello,

I wrote rather in haste yesterday, so perhaps my message was less than 
understandable, apologies!

I'm wondering if there is any plan for native code compilation on 64 bit 
windows using the Visual Studio toolchain? Microsoft do ship a 64 bit 
assembler with it (at least in VC2005 beta and the DDK). However, they 
have defined 'long' as 32 bits rather than the more usual 64 bits on a 
64 bit OS. Are there any other particular 'gotchas' preventing a 
straightforward port?

Thanks,
Niall

Re: [Caml-list] Re: 64 bit windows

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

On Wed, 2005-09-07 at 15:36 +0100, Niall Dalton wrote:
> Hello,
> 
> I wrote rather in haste yesterday, so perhaps my message was less than 
> understandable, apologies!
> 
> I'm wondering if there is any plan for native code compilation on 64 bit 
> windows using the Visual Studio toolchain? Microsoft do ship a 64 bit 
> assembler with it (at least in VC2005 beta and the DDK). However, they 
> have defined 'long' as 32 bits rather than the more usual 64 bits on a 
> 64 bit OS. Are there any other particular 'gotchas' preventing a 
> straightforward port?

Actually MS decision is vastly more sensible than the gnu choice:
it leaves all the ints the same size on win32 and win64,
so all strictly conforming code will continue to work the same 
way, right up to integer overflow, bit masks, etc.

The real 'gotcha' is the Unix programmers that decided
it was OK to use 32 bit ints as addresses .. their code
will break under both models.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Re: 64 bit windows

[Ville-Pertti Keinonen]

On Thu, 2005-09-08 at 06:51 +1000, skaller wrote:

> Actually MS decision is vastly more sensible than the gnu choice:

It's not a GNU choice, it's what almost every vendor of 64-bit systems
has used for more than a decade.

It's nice to have a standard integer type for 64-bit values; C99 still
isn't sufficiently established and C++ has no suitable standard types
other than long.

The Microsoft decision is only sensible in the context where Microsoft
makes their decisions (only Windows matters, incompatibility with the
rest of the world is good).

> The real 'gotcha' is the Unix programmers that decided
> it was OK to use 32 bit ints as addresses .. their code
> will break under both models.

It's also sometimes necessary to represent pointers as integers.  I've
seen more code that uses long for this purpose than int, often with
assertions to ensure that sizeof(long) == sizeof(void *).

All of my Unix C code works just by recompiling for amd64.  On an LLP64
system, many things would break (garbage collectors and such where
representing pointers as integers is necessary).

Personally, I'm very happy that DEC, SGI, Sun, IBM, HP and Apple have
all went with LP64.