[Oberon] Emulators / Hardware Enumerator

[Michael Schierl]

Am 07.02.2022 um 02:20 schrieb Hellwig Geisse:

>> Probably it could be made working without changing the instruction set,
>> by having a special MMIO address that can be written to to flush caches.
>
> Yes.

So you could e.g. specify a `CaCM` (Cache Coherency Manager) hardware
descriptor which describes such a MMIO address. Ignoring that it will
not reach any peripherals but be handled by the system itself. A
Kernel.InvalidateInstructionCache or similar procedure could be provided
that is called at the required places.

>> And it is fairly simple to emulate that scenario in emulators, by just
>> providing two copies of RAM, and only synchronizing them on a cache
>> flush.
>
> This is one possible way to simulate caches. You can also simulate
> them in more detail, implementing different cache architectures, e.g.,
> direct-mapped vs. two-way set-associative. Then it is possible to
> gather statistics in order to decide which one is worth implementing
> in hardware.

I was only thinking about testing the correctness of an Oberon
implementation which handles the cache coherency in software (without
having access to such a system), not about testing performance. But one
could of course do a lot more if one was interested in it.

> This is surprisingly simple. Just over a year ago, a small group of
> students ported Andreas' Extended Oberon to our ECO32:
> https://github.com/hgeisse/THM-Oberon

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 part dealing with caches needed only a tiny fraction of the total
> porting effort.

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.

Having a (no-op) Kernel.InvalidateInstructionCache procedure and calling
it "just in case" could of course alleviate the issue.


Regards,


Michael