Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: ocaml for cray? #2493

Closed
vicuna opened this issue Jun 14, 2000 · 3 comments
Closed

Re: ocaml for cray? #2493

vicuna opened this issue Jun 14, 2000 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 14, 2000

Original bug ID: 141
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,

Thank you for your message to the Caml mailing list.

However your message seems to be a bug report; hence I send it to the
relevant mailing list

caml-bugs@inria.fr

Thank again for your interest in Caml.

PS: My machine is an alpha station, it is thus a 64 bits processor and
sure Caml Light and Objective Caml is running on it for years now ...

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

There is an interesting bit of o'caml software called unison.
So I tried to compile ocaml on our J90. After some messing
around (configure only knows about ymp) I got to a message
that said "shorts are 8 bytes, ints are 8 bytes, I give up".

Any chance of ocaml on 64 bit machines?

Bob

@vicuna
Copy link
Author

vicuna commented Jun 15, 2000

Comment author: administrator

There is an interesting bit of o'caml software called unison.
So I tried to compile ocaml on our J90. After some messing
around (configure only knows about ymp) I got to a message
that said "shorts are 8 bytes, ints are 8 bytes, I give up".
Any chance of ocaml on 64 bit machines?

OCaml works fine on 64-bit processors: Alpha/Tru64 Unix, Alpha/Linux,
Cray T3E in particular. However, it needs the C compiler to
provide at least one integer type that is exactly 32 bit wide.
The configuration tries to find one such type among {short, int, long},
and so far this worked on all architectures that we've encountered.

If it is really the case that the C compiler of the J90 takes
sizeof(short) = sizeof(int) = 8, then you could either 1) look for
compiler options that select more reasonable sizes, or 2) see if the
compiler provides other integer types that would be 32-bit wide
(e.g. int32, int32_t, whatever). In case 2), please write back with
details and we'll try to tell you what to patch in the sources.

Regards,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jun 19, 2000

Comment author: administrator

I've looked hard in man pages and C ref manual and I'm pretty sure
there is no way to define a 32 bit int.

Does the system have an include file called intttypes.h or stdint.h?
In ISO C9X, these header files define a bunch of types for fixed-size
integers, e.g. int32_t and uint32_t for 32-bit integers. (Few Unix
systems provide these includes, though, because C9X is still a draft.)

So I guess it is a case of defining the quantity as
struct { unsigned uint32:32 }
and then always referencing the value as whatever.uint32. Does
that sound like it will work?

I'm afraid it won't, because the compiler will pad the structure to
the size of an int (8 bytes), and you won't get the intended behavior
for arrays of int32...

Regards,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jun 19, 2000

Comment author: administrator

Weird architecture: no 32-bit integer type!

@vicuna vicuna closed this as completed Jun 19, 2000
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant