[bitc-dev] C interfacing vs. portability
rick.richardson at gmail.com
Thu Feb 26 19:05:46 EST 2009
After thinking through portability problems I've had in the past, I
think option one as you describe it best, provided that those modules
are per-platform .
> (+ x:int32 y:word)
> will compile on a 32-bit platform but not on a 64-bit platform.
I would think that this would be expected operation. I would like to
be notified when I inadvertently mix paradigms as such. Since that is
almost always the cause of overflow/misalignment problems.
If "word" is a type in its own right, the compiler will complain about
> this usage. This is why we made word a distinct type for vector sizes.
I think it should be aliased. I don't see why everything shouldn't be
defined in terms of BitC's core types. It means that there will have
to be a module specific to each platform, but that's minor compared to
everything else that must be done to ensure portability between
> Introducing typealias raises some challenges related to name spaces.
> These challenges are surmountable, but I'm really trying not to make
> major language changes at this point. Adding new types for things like
> c_int is very easy.
So would it be wrong to put them in (something like)Prelude with the
option to hide them if the user wished to override for some reason?
I think aliasing word et all to the local platform int# is a great
compromise between performance and portability. Adding the rest of the
oddball type aliases that people have come up with will be a job for
the user of that C module.
More information about the bitc-dev