Haskell Int{8,16,32...} types, config.h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I decided to look in the generated "config.h" file to see what was
there. Some of it seems like it could be improved.
/* first of all get constants for Int8, Int16, Int32, etc ... */
#if SIZEOF_CHAR == 1
# define INT8_TYPE char
#else
# error "can't find type matching int8"
#endif
#if SIZEOF_SHORT == 2
# define INT16_TYPE short
#else
# error "can't find type matching int16"
#endif
and so on.
These are not as portable as they could be. A C standard defines headers
that have int8_t, uint8_t, int16_t, uint16_t, and so on. These types are
guaranteed by the standard, no matter what sizes "short", "int", and so
on are. This is potentially more portable across architectures, but
potentially less portable across compilers: C99 defines these headers
(both
Hi,
These are not as portable as they could be. The idea is that they as portable as possible, and they are generated by directly testing code - generating a type and prodding sizeof it. The hope is that even a really broken setup can't lie about those sort of things :)
A C standard defines headers that have int8_t, uint8_t, int16_t, uint16_t, and so on. These types are guaranteed by the standard, no matter what sizes "short", "int", and so on are. Yes, but the reason we need to do these hacks is precisely because the standard is badly implemented. I think this these types are defined on Linux/glibc, rather than in standard C, but may well be wrong.
As for the rest of the things, I'm not really sure - I guess only Tom will know exactly why this was done the way it was - and might relate to Autoconf, and hence is a good reason to change it :) Thanks Neil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
These are not as portable as they could be. The idea is that they as portable as possible, and they are generated by directly testing code - generating a type and prodding sizeof it. The hope is that even a really broken setup can't lie about those sort of things :)
True, I tend to trust standards a little much I guess. :) (Are there really compilers that define something as straightforward as those types wrongly?!) Anyhow, if those types give the correct sizeof values, they should work, although it might not be worth adding that complexity for the sake of machines we may never see (The C standard says 'char' is always 1 byte, but maybe short is 4 bytes, int 4 or 8 bytes, long 8 or 16 bytes, and long long 16 bytes; or who knows what setup some machine could have.) Regards, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0maqHgcxvIWYTTURAu2/AKCAP8FjsAzEYemZeXLSiJXwEOix+wCgtADB NCVtnx2bgg5Slop8calh8z4= =yDBh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote:
Anyhow, if those types give the correct sizeof values, they should work, although it might not be worth adding that complexity for the sake of machines we may never see (The C standard says 'char' is always 1 byte, but maybe short is 4 bytes, int 4 or 8 bytes, long 8 or 16 bytes, and long long 16 bytes; or who knows what setup some machine could have.)
Actually, I think I heard of a machine that couldn't do 16-bit operations with any kind of reasonable efficiency so 'short' was made 32 bits. And if you can't rely on int16_t to be 16 bits, you certainly never know when some crazy compiler will have "short" be some other size (along with "int" and the rest). Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0m85HgcxvIWYTTURAtyMAJ9/0S9YKFr/4CEPNcIMVQOc354ZCgCglotH gJC3Dzmki3fT8fvrQflGl+w= =aAGY -----END PGP SIGNATURE-----
Hi All, Sorry for the late reply, I've just moved house and no internet yet :-) I avoided stdint.h principally because it's C99 and not ANSI C. However, there might well be a case for lifting that restriction now, we've already gots lots of other non-portable bits (libffi, libgmp etc.) and almost every C compiler does support C99 ... Thus I suppose the principal reason is that it started that way and no one has been bothered to change it ;-) So yes, might be worth changing in the fullness :-) As a further note in libffi, it does seem to be causing a lot of problems, perhaps having it as a required dependency is not a good idea! It wouldn't be too hard to revert to using non libffi primitives (it just means regenerating the wrappers from the Haskell, which is much easier now they're all in one place). Perhaps we should consider this. Cheers Tom Isaac wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I decided to look in the generated "config.h" file to see what was there. Some of it seems like it could be improved.
/* first of all get constants for Int8, Int16, Int32, etc ... */ #if SIZEOF_CHAR == 1 # define INT8_TYPE char #else # error "can't find type matching int8" #endif
#if SIZEOF_SHORT == 2 # define INT16_TYPE short #else # error "can't find type matching int16" #endif
and so on.
These are not as portable as they could be. A C standard defines headers that have int8_t, uint8_t, int16_t, uint16_t, and so on. These types are guaranteed by the standard, no matter what sizes "short", "int", and so on are. This is potentially more portable across architectures, but potentially less portable across compilers: C99 defines these headers (both
and , but inttypes.h is a superset including stuff we don't need to include). GCC has supported these headers since a long time, but I don't know about other compilers. Using these would also require getting rid of the hack of using macros and attaching "unsigned" to get the unsigned version -- rather, the uintN_t version can be used. If the headers are not available enough yet among C compilers, the configuration could still use them "if possible". Furthermore, since the only use (according to grep ;-)) of testing to find out the size of various C types is in these #if SIZEOF_SHORT, etc., all those configuration tests would not need to be done if stdint.h or inttypes.h was available. If we need to know the exact sizes of floating-point types, however, we are out of luck using this route -- these are "int" headers only. Do we need to do anything with floating-point types but distinguish "float" and "double"? It seems both C and Haskell only offer those two named types (well, C also has "long double" which we already ignore), and Haskell numeric literals are always Integer or Rational, not fundamentally floating-point, so the size of the floating-point types shouldn't affect the bytecode(?) (and sizeof(float) and sizeof(double) can be used if the size of memory to allocate is needed in some place in the interpreter, and various weird properties of floats and doubles can be found in the C89
, or perhaps other places, if needed) Regards, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE0l87HgcxvIWYTTURAuCfAJ4gcFIHZWZWJvVs2HATQb7dNRRghACfWYi+ cHmpGdme96q5ENSYD7zE/cE= =QLC+ -----END PGP SIGNATURE----- _______________________________________________ Yhc mailing list Yhc@haskell.org http://www.haskell.org/mailman/listinfo/yhc
On 8/4/06, Thomas Shackell
As a further note in libffi, it does seem to be causing a lot of problems, perhaps having it as a required dependency is not a good idea! It wouldn't be too hard to revert to using non libffi primitives (it just means regenerating the wrappers from the Haskell, which is much easier now they're all in one place). Perhaps we should consider this.
Although libffi is causing some problems at the moment that's because it's highly platform specific and therefore it's hard to get it right if you don't have access to a machine of the correct type. x86 and amd64 versions of Linux should work fine at the moment, as should Windows (not 64 bit) and PPC versions of MacOS. I'm hopeful that I'll be able to get PPC versions of Linux working too, and once Greg comes back from holiday x86 versions of MacOS should start working too. Yhc needs libffi support, and it's much better and cleaner to have it completely integrated with the core. Libffi support has greatly improved over the past few weeks, and it will continue to get better. As it's required at the moment it's getting a lot of work and testing, if it wasn't then it would no doubt become neglegeted and not work on anywhere near as many platforms - a very bad thing IMHO. Andrew
Yhc needs libffi support, and it's much better and cleaner to have it completely integrated with the core.
I wouldn't say it "needs" it, it would be possible to manage without it, though it's certainly very nice to have it.
Libffi support has greatly improved over the past few weeks, and it will continue to get better. As it's required at the moment it's getting a lot of work and testing, if it wasn't then it would no doubt become neglegeted and not work on anywhere near as many platforms - a very bad thing IMHO.
There is definitely a certain logic to this and if you're happy to get it working then that's great. I simply saying that I'm not absolutely wedded to using it for the core if that turns out to be a problem. But since you're saying "no problem" I'm happy to leave it as it is :-) Thanks Tom
participants (4)
-
Andrew Wilkinson -
Isaac -
Neil Mitchell -
Thomas Shackell