Astrobe Forum

SYSTEM.LDREG is also used in Oberon.Mod, and its sibling SYSTEM.REG in Kernel.Mod, Modules.Mod, System.Mod, as well as in the bootloader. SYSTEM.H, probably another undocumented feature, is used in Kernel.Mod. Hence, without undocumented features, no Oberon system as we know it.

Just re-reading some old forum posts... and it occurred to me that, undocumented or not, SYSTEM.LDREG is arguably the most central feature of the compiler. Without it, the system would not even boot. See the bootloader, it's literally the first instruction the system executes. :)

I have implemented the Embedded Project Oberon (EPO) RISC5 CPU and environment in an Intel Altera FPGA, specifically, using the Terasic Cyclone V GX Starter Kit board [1]. It's a nice board in the same price range as the Digilent Arty A7 100, with lots of LEDs, switches, buttons, SRAM, seven segment...

I have always found a "stack trace", ie. the display of the chain of procedure calls that lead to an error, very useful to find the causes of run-time problems. This chain is unrolled by walking the stack backwards from the error point -- or from any state of calls -- frame by frame using the frame ...

Thanks for the pointers. I don't have intention to change the compiler to use R13, but I am grinding my teeth on an in-circuit debugger, and an otherwise unused register could be handy from assembly code.

ORG.incR allocates registers up to R11. R12 is MT, R14 is SP, and R15 is LNK. What about R13, may I use it, or does it have a special purpose as well?

The Astrobe RISC5 compiler creates erroneous code in the following case: PROCEDURE P; VAR i: INTEGER; BEGIN i := 0; SYSTEM.LDREG(i, 13) END P; The procedure compiles without error message, but the code created is: 4400000DH MOV r4, r0, 13 Evidently, the target register number must be a constant, as ...

Wow. Thanks! Also for CPIde.

Thanks! The indirectly imported modules do count as regards the max allowed 15 imported modules, which we can check in the BL opcode of an external procedure call, where the module number is encoded in a 4 bit value (hence the restriction of 15, zero is not a valid module number for BL instructions)...

OK, thanks, I have read up. Does the Astrobe compiler more or less work like the Project Oberon one in that area? In particular the import and export of symbols (reading and writing of symbol files, ORB. Import and ORB.Export) and creating object files (ORG.Close)? The way the symbol table is built ...