[Oberon] ALU 2015 and 2018

Skulski, Wojciech skulski at pas.rochester.edu
Thu May 12 22:29:00 CEST 2022


> „Readable“ is a subjective term.

We just discovered that a computer science professor (Hellwig) does not fully understand RISC5 code. Neither do I despite 20 years of VHDL experience. This discovery is a disaster for the NW school of thought. It directly contradicts all NW ideals. How can RISC5 be ever taught to anyone, if the computer science professor has problems with answering some basic questions concerning its architecture? 

Lets compare two pieces of code. The 1st is from the latest RISC5. The other is my own translation. It compiles. Let's not dispute whether or not I made a mistake while translating. I am not a Verilog expert. The point is that one style is not readable (subjectively of course), while the other conveys the idea to an engineer or student with only cursory understanding of Verilog.

// Example 1. Code from RISC5.v dated 31.8.2018
assign pcmux = ~rst | stall | intAck | RTI ? 
   (~rst | stall ? (~rst ? StartAdr : PC) :
   (intAck ? 1 : SPC)) : pcmux0;

// Example 2. My translation of the above
// Alternative code. I changed pcmux from wire to reg in order to allow for assignments
always @*
  if (~rst | stall | intAck | RTI) 
	if (~rst | stall) 
	    if (~rst) pcmux = StartAdr; else pcmux = PC; 
	    if (intAck) pcmux = 1; else pcmux =  SPC; 
  else pcmux = pcmux0;

> Purely from a compiler construction‘s point of view, the ternary operator ?:; and if-then-else CAN produce exactly the same outout during syntesis but they DON’T have to. 

If they are equivalent, then according to NW ideals we should code in a human friendly style.

> It heavily depends on the Verilog compiler.

Can you substantiate this statement with some examples? 

> Generally, for assignments the ternary operator is cleaner as the output of both branches must have the same type.

The very same can be achieved under if-then-else. See my example, which is a direct translation. The branches are of the same type as you requested. But the code is cleaner for me, and perhaps to everyone else who was not directly involved in the development.

I suggest that we need two versions of RISC5. One which is coded in a human-friendly way. And perhaps another one optimized for performance but perhaps unreadable to non-experts. 

Furthermore, the human-readable code can be perhaps optimized to the same level as human-hostile code. There is no reason why if-then-else (see Example 2) should not be an exact equivalent of the obfuscated code (see Example 1).

The human readable code will consist of more lines. The line count should not be the decisive factor. We need to decide, which ideal is more important: line count or clarity? I vote for the latter.


More information about the Oberon mailing list