On Thu, Feb 26, 2009 at 9:41 PM, Aleksi Nurmi <[email protected]> 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. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
