[Oberon] RISC5

eas lab lab.eas at gmail.com
Mon Apr 28 08:25:05 CEST 2014


]> What about a P-code interpreter for rPi? Instead of going via C:

]...Read the Compiler Construction document I recently recommended to you:..

Instead of:
  BEGIN PC := 0; R[13] := pc * 4; R[14] := LEN(M)*4;
I would have prefered:
CONSTANT 13=<RegDescription>...;
  BEGIN PC := 0; R[<RegDescription>] := pc * 4;...

*.pdf says:--
}The operations available are listed below.
}They are described in more detail in Appendix A2.
}The operand n is either a register or a part of the instruction itself.
]  0      MOV  a, n     R.a := n

Pity that NW perpetuated the Intel [AFAIK] mistake of "move";
instead of "LoadImmedidte"
  LDI a,n  : n->Ra  or perhaps better
  LDI n,a

?! Where's the <Store Instruction> : Rx->MemN
OK, none of the listed instructions of: PO.Computer.pdf , RISC.Mod.txt
 consider accessing memory.
What's going on?
Perhaps the RISC is only an ALU, and RAM is via the SD?

IMO at the most fundamental level, the bytes are NOT moved,
they are copied. And the difference is crucial for understanding programming.
Starting out. calling "copy", "MOVE" is bad.

]> But having Oberon, without the ETHO-interface is of little value?
]>

]On the contrary, Oberon-07 is great value for developing predictable,
]realtime, embedded software without an OS and without having to use C. One
]of the key features of the FPGA RISC instruction set is that the majority
]of instructions execute in a single clock-cycle on the FPGA hardware
]which gives you the timing predictability.

Yes sure, realtime systems are important & valuable, but I taking about
rPi for 'human' activities. OTOH, perhaps ETHO's display doesn't need fast
refresh?

== Chris Glur.



More information about the Oberon mailing list