[Oberon] Undocumented FP feature in RISC5

[Joerg]

Hellwig

Just a few weeks ago, I mentioned this very fact to NW.
I said, I would prefer to add the FLT and FLOOR instructions to his document "The RISC architecture" http://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC-Arch.pdf
I made a proposal how to do this. Interesting enough, other special meanings of the u and v bits that modify the behavior of existing instructions are described, but the FLT and FLOOR behavior is missing.

NW replied that the instructions FLT and FLOOR are not missing, as they are "easily implemented by-products" of FAD.

I didn't insist further as I guess he didn't get the point. That the two functions are indeed cleverly implemented in FPAdder.v is one part.
But the special meaning of the u and v flags with FAD (instruction 12) should be described in the RISC architecture.
The u and v flags have to be set in a very special way with FAD, that FPAdder.v triggers FLT and FLOOR.

A side remark for emulator authors: The current implementation in FPAdder.v does handle FLOOR(x) correctly, if x<2^25.
A lot of emulators are "too clever" and handle FLOOR correctly for all x < 2^31.
The knowhow of the allowed range of x is important for the correct implementation of REAL to String conversion.

br
Jörg

Am 21.01.21, 10:27 schrieb "Oberon im Auftrag von Hellwig Geisse" <oberon-bounces at lists.inf.ethz.ch im Auftrag von hellwig.geisse at mni.thm.de>:

    Hi all,

    while working on a re-implementation of RISC5,
    I stumbled over a feature of the floating-point
    adder, which is not documented in the paper "The
    RISC Architecture" (dated NW 5.12.10, rev. 9.8.2018),
    not even in section 4 (Special Features).

    The FP adder is able to perform the conversion
    functions REAL->INTEGER ("FLOOR" in Oberon) and
    INTEGER->REAL ("FLT" in Oberon). These operations
    are choosen on the basis of the u- and v-bits of
    the format part of the instruction, which in this
    case is "FAD".

    A quick look into ORG.Mod (the code generator of
    the compiler) reveals that these instructions are
    indeed generated (ORG.Floor, ORG.Float), and thus
    must be implemented in hardware; otherwise, the
    compiler back-end must be changed.

    Hellwig

    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon