Xavier Leroy wrote:
> We could easily specify Caml's integers as twos complement, with
> division that rounds towards zero, signed modulus, etc, etc --- all the
> guarantees that C doesn't give us ---,
That would be good I think.
> then check those properties
> during configuration and refuse to compile OCaml on machines that do
> not meet those properties. Given that all modern machines meet them,
> that would not be a limitation in practice.
Given that it is usually possible to implement the desired
semantics, such a limitation could also be removed with some
additional effort if necessary.
> > I am a member of the C committee.
> > The issues here are important and non-trivial.
> > I write algorithms that depend on it :-)
> > I point them out only as a service to the ocaml community
> > (myself included of course :-)
>
> Thanks. But as a member of the C committee, you could make all of us
> (not just Caml users, but C programmers as well) a HUGE service
> by pushing forward a C standard that fully specifies signed integer
> arithmetic, e.g. like Java does. (While you're at it, please standardize
> IEEE floats as well.)
The C9X rules are firmer but not yet deterministic.
> The situation is much better on the native compiler front: since we
> know exactly which processors are supported, we can actually guarantee
> twos complement, division that rounds towards zero, signed modulus,
> etc, etc, just because all the supported processors implement those
> properties.
>
> The limiting factor is the bytecode interpreter, at least as long as
> we want it to work on any system with an ANSI-compliant C compiler.
That makes sense. However, it may make sense to specify
the desired semantics anyway, and state that the bytecode interpreter
is not conformant on certain systems.
By the way, I think for 'native' int, the semantics
can be loose: the idea being to 'do what the machine does',
the purpose here is already machine specific.
Perhaps by way of explanation: I feel that the ocaml team
and myself share a goal: to be able to write code about which
various properties are easily deduced. Reasoning about bitwise
operations use together with integral ones on special 'portable
register' types such as int32 would be enhanced by a strictly
deterministic semantics.
So I mentioned this 'flaw' in the manual not to whinge,
but to show how easily a common goal might be met. Many applications
needing to perform encoding/decoding functions would benefit I think,
from knowing either that they're 'portable across all ocaml platforms'
or at least having a rule to know on _which_ the language will
model desired behaviour.
In particular, many operations are easily specified with
unsigned types like 'uint32' which can only be translated to
signed types with a deterministic semantics.
From what you have said, all existing, known, ocaml ports
meet the twos complement specification anyhow, so not much is lost
by making that a requirement. :-)
-- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net
This archive was generated by hypermail 2b29 : Mon May 01 2000 - 19:14:08 MET DST