[Oberon] Emulators / Hardware Enumerator

Hellwig Geisse hellwig.geisse at mni.thm.de
Tue Feb 8 11:58:22 CET 2022

On Mo, 2022-02-07 at 21:30 +0100, Michael Schierl wrote:
> Great! Did they stay with the original RISC5 instruction set or
> use a different one? If the former, how did they implement the
> cache flush/invalidate?

The instruction set of ECO32 is quite different from RISC5,
although it's also a RISC architecture. So we had to modify
the back-end of the Oberon compiler accordingly. Furthermore,
the peripherals of ECO32 are different (at least in details),
so the Oberon driver modules had to be adapted. Last but not
least, the module loader and the associated object format had
to be thoroughly understood so that we were able to modify
them for the ECO32 instruction set. We initially underrated
the effort needed for that by far... ;-)

Cache flush/invalidate instructions are part of the instruction
set of ECO32. We made them accessible from Oberon through the
SYSTEM module. E.g., in KERNEL.MOD you find the statement
"SYSTEM.CCTL(7)" which does the combined D-cache flush and
I-cache invalidate needed after loading a module.

> I was thinking more about modules not part of the "official"
> distribution, i.e. about "userspace". In my Oberon Modifications there
> are a few modules that dynamically create code (inside an ARRAY OF
> INTEGER) and execute it. If you do not change those, they will not work.

This is of course correct, although the technique of dynamically
creating executable code outside the OS is usually abhorred,
exactly because of the consequences for caches (and for security).
Debuggers are the prominent exception from this rule.


More information about the Oberon mailing list