Would it be bad to rely on the C (Posix?) standard: <types.h> and the int32_t int64_t etc. And define a set of rules: If the compiler is 64 bit, then the integral in BitC maps to int64_t, if 32 bit int32_t etc. Real/float/double same way.. but also allow overrides if necessary.
On Thu, Feb 26, 2009 at 10:53 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Feb 26, 2009 at 10:18 AM, Rodrigo Kumpera <[email protected]> wrote: >> >> Usually is enough to have a native size integer type that works with 32 bits >> integers and do >> implicit widening of them on 64 bits archs. This is safe since BitC doesn't >> support 16bits targets. > > BitC does not and will not do implicit widening. This would break the > ability to do type inference. The closest we can get here is to use > three-variable arithmetic type classes. One effect of that is to make > arithmetic behavior imprecise. A second is to severely multiply the > number of type class instances (8 integer types ^ 3 positions is 512 > instances *for each arithmetic operator*). That's probably not > practical. > >> Most 64bits targets handle mixed 32-64 bits math just fine. > > This is not true. It is merely that you have not had occasion to be > bitten in the ass by this because you have not written critical > programs. A single underspecified arithmetic operation of this form > cost Ariane an entire satellite launch at one point. We have made a > conscious design decision in BitC to encourage more rigorously > specified integer arithmetic. Conversions are possible, but must be > done explicitly. > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
