[Oberon] RISC5 Architecture

[Hellwig Geisse]

Jörg,

thanks for your answers. You may have overlooked, however,
my remark "please note that I myself guessed answers while
writing my RISC5 simulator, but I was never sure to have
guessed right"... :-) I did of course analyze the boolean
expressions in NW's RISC5 implementation and incorporated
this knowledge in my simulator; otherwise I would not have
been able to run the system.

I posed the list of open questions because I wanted to show
that the "specification" of RISC5 (without its implementation)
is incomplete, and does not guarantee that a new machine,
while observing the specs, can run the existing software.

I pick out only two points:

On Mi, 2021-01-06 at 16:19 +0100, Jörg wrote:
> 
> > 1. What is the endianness of RISC5?
> Oberon code assuming a certain endianness is bad code. Why do you see the need to specify this? Of
> course, Oberon code can find out easily the endianness of the HW it‘s running on, but where does
> it matter? When I programmed the TCP stack, I could do certain shortcuts when I know the
> endianness. But whether net-order is the same as memory-order should not play a role: you should
> call in all curcumstances the translate procedure, even if it is empty.  In my point of view,
> endianness is a property of the environment/memory (RISC5Top.v) not of the RISC-5 CPU.

With the wrong endianness, even the first instruction fetch
will fail - the byte order is wrong, if the code has been
produced on another machine with different endianness. You
could argue: do only run code produced on the very same
machine. Fine - how do I even start?
(Please do not answer this rhetorical question. I know
how to do that, and have done it in the past, which was
difficult enough. It involves re-writing part of the
compiler's back-end.)

The compiler has to generate floating-point constants, right?
Their endianness *must* be specified, otherwise the FP unit
cannot work properly. So again: do only run code...

That was the reason I wrote "This will severely hamper
exchanging software, especially in binary form."

> > 2. Is the offset in memory instructions (format F2) sign-extended?
> As the Oberon machine only has 1 MB of memory, it makes no difference whether it is sign extended
> or not. However, the „official“ RISC-5 Verilog implementation has an address bus of 24bit (up to
> 16 MB). Yes: it sign extends „off“ as you can see here:
> assign adr = stallL0 ? B[23:0] + {{4{off[19]}}, off} : {pcmux, 2'b00};

The "specification" does not define this behavior.
etc.

If I may sum up your argumentation: You propose to take
NW's implementation as reference design.

This is dangerous, regardless of which origin it is:
Did you try lately to multiply (1 << 31) by (1 << 31)
as unsigned numbers? The last time I did, the result
was wrong (see my mail from Sun, 4 Mar 2018).
Furthermore, it is in many cases unclear, if a specific
behavior is part of the specification or a by-product
of its implementation.

Nevertheless, thanks again for your answers.

Hellwig