[Oberon] RISC5 Architecture

[Jörg]

Hellwig

Interesting questions. Most of them are left to the implementation...

> 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.

> 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};
> 3. The SUB instruction "also sets the C flag". How is this to be
>    interpreted? Example: compute 3-5. If you really subtract in
>    binary, the carry will be set. If you add -5 in 2's complement
>    representation, the carry will be cleared.
If you subtract, RISC5.v sets the C bit according to this boolean expression 
(~sb&sc&~sa) | (sb&sc&sa) | (~sb&sa)
Looking at your example a=3, b=5, c=-2 ==> C is set (1st rule)
If you add, the C bit is set to the following boolean expression:
 (~sb&sc&~sa) | (sb&sc&sa) | (sb&~sa)
Looking at your example a=3, b=-5, c=-2 ==> C is set. (3rd rule)

> 4. What happens on (synchronous) exceptions?
>    a) unaligned word access
Not detected by the CPU. The environment (RISC5Top.v) just ignores the two lowest bits when accessing memory.
assign SRadr = vidreq ? vidadr : adr[19:2];
VAR m: INTEGER;
SYSTEM.GET(0, m); SYSTEM.GET(1, m);
SYSTEM.GET(2, m); SYSTEM(3, m) return exactly the same m.
>    b) unknown instruction
The „op“ field in F0 and F1 are decoded completely. The u flag is only looked at if needed. There is no check whether u=0, when there is no special meaning for u=1.
So, as example: LSL behaves the same whether u=0 or u=1.

>    c) division by zero
Integer (Divider.v): algorithm generates nonsense. So, the compiler generates check on 0 and generates a Trap.
Floating point(FPDivder.v): result is +-infinity depending on the sign of the numerator.

>    d) floating-point overflow
Denormalized or 0 is generated.
>    e) floating-point underflow
Result is NaN.

> 5. What happens exactly on interrupt?
When the irq signals becomes high, an interrupt is pending. It causes intAck to become high, if a) interrupts are enabled (intEnb), b) the processor is not currently executing another interrupt handler (~intMd), and c) the processor is not stalled. When intAck is high, the current PC is saved in the new SPC register, and pcmux becomes 1, i.e. the next instruction is read from address 4. At the same time, the condition bits are also saved (in SPC[21:18]), and the processor enters the interrupt mode.

> 6. Are nested interrupts supported?
No, see b) above

> 7. Does STI delay the setting of intenb by one instruction?
No. After execution of STI 1, intenb is set.
>    Does RTI automatically set intenb?
No, RTI resets intMd, thus enabling interrupts again, if they were enabled before.
intMd can be seen as filter for intEnb.
Interrupts need one cycle to be detected.   (irq1 <= irq; // edge detector)

>    If both questions are answered negatively, then there is
>    a race condition in the sequence (STI, RTI), with a nested
>    interrupt as a possible result.

> 8. Can external devices other than the timer interrupt?
Yes. „irq“ is an input signal to the CPU. The current implementation of RISC5Top.v sets irq equal to cnt==24999, so an interrupt every millisec. Other RISC5Top.v might do differently.

> 9. All external devices are grossly underspecified.
> (The list is not complete.)

> Although I really want these questions to be answered, what
> interests me most is: *how* do we find answers to them?
> Some alternatives are:
>  - Anything that is not specified is intentionally left so.
>    Implement at your free choice. This will severely hamper
>    exchanging software, especially in binary form.
>  - Take NW's implementation and analyze the circuits (or
>    just try it out). This promotes his implementation to
>    a "reference design".
>  - Choose any one of the various simulators and declare it
>    to be the "gold standard". Which one?
>  - Discuss each question here on the list and come to
>    an agreement. A bit cumbersome, but manageable.
> Other ideas?
> 
> Thanks,
> Hellwig
> 
> [1] https://people.inf.ethz.ch/wirth/FPGA-relatedWork/RISC-Arch.pdf
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20210106/cfcf01b2/attachment.html>