[bitc-dev] C interfacing vs. portability
Jonathan S. Shapiro
shap at eros-os.com
Thu Feb 26 18:34:17 EST 2009
On Thu, Feb 26, 2009 at 6:02 PM, Aleksi Nurmi <aleksi.nurmi at helsinki.fi> wrote:
> 2009/2/27 Jonathan S. Shapiro <shap at eros-os.com>:
>> For example, there are LOTS of procedures out there that accept or
>> return an argument of type size_t, which is a platform-specific
>> typedef. How should these be typed in BitC?
> I believe size_t being a typedef was just an implementation choice,
> and it should be handled like C primitive types for maximum
Yes. Unfortunately this solution won't scale. There are a depressing
number of types like this in the world. size_t, off_t, ssize_t,
> On a related note, I have a few questions concerning primitive types:
> - Is it safe to assume that sizeof(Foo*) == sizeof(void*) or is it
> just that sizeof(Foo*) <= sizeof(void*)?
This is safe in all realistic hardware implementations. There are
examples of machines that distinguished pointer registers from data
registers, but type-sensitive pointer registers, so far as I know,
have never been implemented.
> - Should BitC have C-like types to avoid making unnecessary
> representation choices? ("I just want a fast and large enough integer,
No. BitC needs them mainly because we need to be compatible with the
layout constraints of hardware and cache structures.
> - Are BitC programmers stuck with the assumption that data types are
> 8/16/32/64 bits wide?
No. BigNum is straightforwardly implemented.
>I understand that a programmer can create abstractions himself, but a
> good collection of standard types is very important for libraries. If
> each library defined its own basic types, the user has to do a lot of
> unnecessary conversions.
I agree completely. One area that we need to work on very soon is the
core library. So far we have mainly been focused on getting the core
language semantics stabilized, but the library is a very important
next step. One reason that capsules are on the r1 language feature
list is that we can't build a good I/O library without support for
existential types: "stream" is an existential type.
> I guess I'm trying to say that there were lots of reasons why C chose
> abstract primitive types, and I would like an explanation why BitC did
> not. I do like the fact that representation is clearly visible, but it
> hinders portability.
Quite the contrary. It is the C approach that hinders portability,
because whenever the representable range actually matters there isn't
any good choice. BitC has instead followed the approach taken by Java,
C#, and other more recent languages in this regard. The only
difference between BitC int32 and Java int is that we put the size
into the type name.
More information about the bitc-dev