It has occurred to me this morning that there is an alternative approach
to the arithmetic issue.
It seems to me that we have all missed the real issue here. The
primitive hardware operations do not throw exceptions. Perhaps we should
not be so quick to insist that the language should obscure the
information that is available from the hardware.
Let me talk about '+' for a moment -- variations are feasible for other
operators.
Assuming a native code compiler, we can define in the language a notion
of abstract condition codes. Note that the particular one I am giving
can be implemented on every CPU I know about:
(defstruct ConditionCodes
sign : bool
overflow : bool
carry : bool
zero : bool)
We could then define the primitive addition operator as follows:
prim_+u32: uint32 x uint32 -> uint32 x ConditionCodes
>From this, constructing modular_+u32 and checked_+u32 are matters for an
arithmetic library, and can be done without loss of efficiency.
Note that this won't work portably in C with any efficiency, but it can
be done pretty straightforwardly in GCC using inline procedures with
inline assembly language in the runtime library.
I recognize that the language must still take some position on the
canonical binding of '+'. I merely wanted to point out that we may have
been framing our thinking about the underlying support incorrectly.
Indeed, one advantage of this is that we can define the semantics of
these primitive operations within the language, and end up having the
ability to get nearly all the way to assembly language in the compiler
before stepping down to the hardware machine model in a native code
compiler.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
