[Oberon] Emulators / Hardware Enumerator

[Hellwig Geisse]

Michael,

On Mo, 2022-02-07 at 00:33 +0100, Michael Schierl wrote:
> 
> Am 06.02.2022 um 23:48 schrieb Hellwig Geisse:
> 
> > 
> > If I- and D-caches are both present, and do not implement any
> > cache coherency protocol, you need instructions (for use in
> > the kernel and possibly in debuggers) to flush the D-cache
> > and invalidate the I-cache.
> Fair point, but would that still be the same ISA, if the cache
> coherency changes the behaviour and not just the performance?
> 

this can of course be debated, but IMO that's a rather philosophical
question. I only tried to imagine what will happen if RISC5 is ported
to more modern hardware. I understand very well the tension between
having a clean and simple architecture for teaching purposes and the
need for an up-to-date implementation for real applications. I've
always hoped that these goals can be somehow reconciled... :-)

> 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.

> 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.

> But all modules that dynamically create and execute code would
> need changing, of course, to work on such a machine.
> 

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

Regards,
Hellwig