Re: what does "32-bit integer" mean?

From: John Max Skaller (skaller@maxtal.com.au)
Date: Sat Apr 29 2000 - 01:24:33 MET DST

  • Next message: John Max Skaller: "Re: what does "32-bit integer" mean?"

    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