[Oberon] Undocumented FP feature in RISC5
joerg.straube at iaeth.ch
Thu Jan 21 12:12:17 CET 2021
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.
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>:
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.
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon