[9fans] Arithmetic on Plan 9 - Plan9

This is a discussion on [9fans] Arithmetic on Plan 9 - Plan9 ; Hello, I'm working on KerGIS, a BSD licenced revival of CERL GRASS, in order to make it compile and run on Plan 9 too---at the moment, it compiles and runs on any POSIX Unix flavour. Even if a huge amount ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [9fans] Arithmetic on Plan 9

  1. [9fans] Arithmetic on Plan 9

    Hello,

    I'm working on KerGIS, a BSD licenced revival of CERL GRASS, in order to
    make it compile and run on Plan 9 too---at the moment, it compiles and
    runs on any POSIX Unix flavour.

    Even if a huge amount of work has already been done for cleaning,
    reorganizing and extending the original sources, confrontation with Plan
    9 shows that it is far from being, if not ideal, even sensible in some
    area.

    The first step---for Plan 9---will be a compilation using APE, and the
    development of a graphical visualization using Plan 9 libdraw.

    But I need too, for Plan 9 and others, to isolate correctly arithmetic
    operations (I include not only integers but floats too in this
    expression) in order to identify correctly the domain of definition of
    the algorithms.

    AFAIK, ISO C for examples does not mandate anything about integer
    overflows (may silently wraps). C99 has added some support for IEEE754,
    but the handling of "exceptions"---that may or may not be faults---is
    still fuzzy for me.

    Calculus is, if I'm not mistaken, a typical "userland" stuff. But it
    involves, obviously the machine---MMIX[1] for example has distinct
    instructions for not signaling integer arithmetic and signaling i.e.
    unsigned integers operations silently wrap while signed overflow---, the
    language and the compiler---is C enough to access all the capabilities
    of the hardware or is assembly required---, and the operating
    system---for the policy on notes.

    So some questions (hoping at least some of them make sense):

    1) Is there a Plan 9 policy concerning the "notes" (exceptions) on
    arithmetic operations, both integer and float?

    2) Concerning float, if the FPU is a (from the ISA point of
    view) separate entity, are registers put in a known state on process
    entry?

    3) Is there some high level arithmetic homogeneous behavior between
    machines---a IEEE754 behavior even on machines lacking a compliant FPU,
    or lacking a FPU?

    4) Is there a way, via C, to handle extended precision on IEEE754, or is
    assembly required (even if the assembler does not provide directly the
    symbolic opcodes, embedding directly the values is possible)?

    I just discover libgeometry and arith(2) etc. so I suspect reading these
    sources will help.

    But if somebody has a résumé or pointers, it will be greatly
    appreciated.

    TIA,
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

  2. [9fans] Re: Arithmetic on Plan 9

    [I forgot the references]:

    On Wed, Jul 25, 2007 at 05:51:55PM +0200, tlaronde wrote:
    > involves, obviously the machine---MMIX[1] for example has distinct


    MMIX is the mythical RISC machine described by Donald E. Knuth in:

    1 The Art of Computer Programming, Volume 1, Fascicle 1: MMIX, A RISC
    Computer for the New Millenium, Addison-Wesley, 2005.

    and

    2 MMIXware, A RISC Computer for the Third Millennium, Springer, Lecture
    Notes in Computer Science n°1750, 1999.
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

  3. Re: [9fans] Arithmetic on Plan 9

    i may not be qualified to answer all those questions for you, but i'll
    try my best. i was dealing with FP exceptions last week and
    consequently may have some of the answers:

    > 1) Is there a Plan 9 policy concerning the "notes" (exceptions) on
    > arithmetic operations, both integer and float?


    i don't think there's anything about integers, but float exception
    behaviour can be controlled via the getfcr/setfcr routines described
    in getfcr(2). that man page will also tell you how to figure out
    whether a particular machine supports those.

    in my particular case the code I was porting defined NaN as a constant
    and threw an exception whenever it ran. one particular quirk that i
    observed was that an exception was thrown regardless of whether I
    defined a silent or a non-silent NaN... my "solution" was simply to
    turn off FPINVAL via setfcr(). if you're porting via ape, as i was
    doing, the best solution is to get the little bits of assembly that
    constitute the *fcr routines, compile them with 8a and link them
    against the

    > 2) Concerning float, if the FPU is a (from the ISA point of
    > view) separate entity, are registers put in a known state on process
    > entry?


    yes. here are the floating point registers of a brand spanking new process:

    parr% acid /bin/links
    /bin/links:386 plan 9 executable

    /sys/lib/acid/port
    /sys/lib/acid/386
    acid: new()
    18031: system call _main SUBL $0xc,SP
    18031: breakpoint main+0x3 MOVL $_IO_stream+0x40(SB),AX
    acid: fpr()
    F0 0
    F1 0
    F2 0
    F3 0
    F4 0
    F5 0
    F6 0
    F7 0
    control 0x0000
    status 0x0000
    tag 0x0000
    ip offset 0x00000000
    cs selector 0x0000
    opcode 0x81f3
    data operand offset 0x0000
    operand selector 0x0000


    > 3) Is there some high level arithmetic homogeneous behavior between
    > machines---a IEEE754 behavior even on machines lacking a compliant FPU,
    > or lacking a FPU?


    i believe the answer is No.

    > 4) Is there a way, via C, to handle extended precision on IEEE754, or is
    > assembly required (even if the assembler does not provide directly the
    > symbolic opcodes, embedding directly the values is possible)?
    >



    not sure if that's what you're asking exactly, but from getfcr(2):

    Precision is
    controlled by installing in fcr, under mask FPPMASK, one of
    the values FPPEXT (extended precision), FPPSGL (single pre-
    cision), and FPPDBL (double precision).

    hope that helps.

  4. Re: [9fans] Arithmetic on Plan 9

    On Wed, Jul 25, 2007 at 10:25:28AM -0600, andrey mirtchovski wrote:
    > [good stuff]
    >
    > hope that helps.


    Yes, definitively. Thank you very much!

    It's almost clear that I need for KerGIS to orthogonalize things, so
    that in the libgis are indeed system dependant (POSIX or Plan 9)
    facilities and only these, and in a libarithm sys dep and machine
    dependant arithmetic.

    All the rest should be userland computation and almost usable as
    is---minus the idiosynchrasies about C and libc [headers].


    Thanks once more,
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

  5. Re: [9fans] Arithmetic on Plan 9

    On Wed, Jul 25, 2007 at 10:25:28AM -0600, andrey mirtchovski wrote:
    >[...]
    > in my particular case the code I was porting defined NaN as a constant
    > and threw an exception whenever it ran. one particular quirk that i
    > observed was that an exception was thrown regardless of whether I
    > defined a silent or a non-silent NaN... my "solution" was simply to
    > turn off FPINVAL via setfcr(). if you're porting via ape, as i was
    > doing, the best solution is to get the little bits of assembly that
    > constitute the *fcr routines, compile them with 8a and link them
    > against the


    Perhaps a hint on this. In The Intel documentation (Intel64 and IA32
    Architectures Software Developer's Manual, Volume 1, §4.8.3.4):

    ------quote
    SNaNs are typically used to trap or invoke an exception handler.
    They must be inserted by software; that is, the processor never
    generates an SNaN as a result of a loating-point operation.
    ------endquote

    As a result, on x87, the invalid operations all cause an exception, and
    it is the responsability of software to create/insert NaNs, whether
    sNaN or qNAN.

    And furthermore (§4.8.3.6):

    ------quote
    ˇ If one of the source operands is an SNaN and the floating-point
    invalid-operating exception is not masked (see Section 4.9.1.1,
    "Invalid Operation Exception (#I)"), the a floating-point
    invalid-operation exception is signaled and no result is stored in
    the destination operand.

    ˇ If either or both of the source operands are NaNs and floating-point
    invalid- operation exception is masked, the result is as shown in
    Table 4-7. When an SNaN is converted to a QNaN, the conversion is
    handled by setting the most- significant fraction bit of the SNaN
    to 1. Also, when one of the source operands is an SNaN, the
    floating-point invalid-operation exception flag it set. Note that
    for some combinations of source operands, the result is different
    for x87 FPU operations and for SSE/SSE2/SSE3 operations.

    ˇ When neither of the source operands is a NaN, but the operation
    generates a floating-point invalid-operation exception (see Tables
    8-10 and 11-1), the result is commonly an SNaN source operand
    converted to a QNaN or the QNaN floating- point indefinite value.
    ------endquote

    So masking the floating-point invalid-operation, even in case of QNaN,
    if I understand correctly, was indeed required to shut up the exception.


    Note: I have the documentation for Plan 9 in hardcopy (from Vita Nuova),
    and I just found some information about IEEE support in the paper called:
    "The Various Ports".

    To summarize: for Motorola MC68020 and x86, there is IEEE754 hardware
    support and there is full IEEE support.

    For chips where there is a FPU but only a partial support, in hardware,
    for IEEE754, there is emulation, but not a complete one: "we implement
    non trapping-underflow as truncation to zero and do nothing about
    denormalized numbers and not-a-numbers."

    There is also notes about transcendantal functions (built-in or emulated
    in library).
    --
    Thierry Laronde (Alceste)
    http://www.kergis.com/
    Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

+ Reply to Thread