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:..
BEGIN PC := 0; R := pc * 4; R := LEN(M)*4;
I would have prefered:
BEGIN PC := 0; R[<RegDescription>] := pc * 4;...
}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
?! 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
== Chris Glur.
More information about the Oberon