[bitc-dev] C interfacing vs. portability

[Jonathan S. Shapiro]

On Thu, Feb 26, 2009 at 9:41 PM, Aleksi Nurmi <aleksi.nurmi at helsinki.fi> wrote:
> I'm not yet entirely convinced that C wouldn't be more portable - or
> portably performant...

Given signed and unsigned register-width types, which we are about to
introduce, we can make BitC equally performant. The problem is that
this performance comes at a cost of correctness. Look at it this way:
if you had known the representable range that was actually required,
you could have said so and incurred no computational cost. If you
*don't* know the required representational range, how does the
language help you by supporting your desire to ignore the issue?

There is one possible justification that I can see for "register width
int", which is basically: "I don't know the required range, but if it
can't be represented on the machine I'm hosed anyway, so what the
hell." That's at least a case where the throwing up of hands was
justified by an appeal that a pre-existing problem wasn't made any
worse.

> Mapping C types to BitC exact-width types portably may be cumbersome
> due to their mismatch. The C integer converts to what? Theoretically
> bignum is the only portable solution, unless there are additional
> assumptions or checks for machines with unexpectedly high/small
> integer range.

The C int will be defined in a target-dependent library. The place
where things get dicey is in type checking and promotions.