[Oberon] Emulators / Hardware Enumerator

[Michael Schierl]

Hello Hellwig,


Am 06.02.2022 um 01:27 schrieb Hellwig Geisse:

> thanks for successfully tackling this problem. I took a very
> brief look into your specification and I see descriptors for
> various peripherals, but none for CPU-internal hardware (e.g.,
> cache and FPU).

So far, there has not been any need for them by Jörg or me.

There is the CPUID instruction (available as SYSTEM.H(1) in the Oberon
compiler), which returns a single byte of CPU ID.

Floating point is very rarely used in Oberon (I can only think of a
single module, Splines, in the default system that really uses it; apart
from the possibility of printing floats in the Texts module and of
course compiling float instructions in the compiler), so you can get
very far even if your board does not support floating point. And even if
the software knew there is no floating point support, I am not aware of
any software floating point implementation which could be used as a
replacement.

SRAM based boards do not use cache. DRAM based boards do, but what could
software do if it knew about the cache setup?

> Main memory size could perhaps also be specified
> in this way.

Main memory layout is set up by the boot loader and passed to
Kernel.Mod, then available as exported variables memLim, stackOrg etc.

It would of course be possible to redundantly provide these again in the
hardware enumerator.

(The only thing where my HardwareDetect.Mod currently has to probe for
is the address bus width. So in case some CPUi or similar descriptor is
added, we might want to add the address bus width as well.)

> Is your enumerator flexible enough to describe
> these also?

These could be provided in a CPUi descriptor. What values exactly would
you like to get about CPU, cache and FPU? In case of absence of such a
descriptor, memory size can still be negotiated via the boot loader.

> Is it correct to assume that you are the "central
> authority" where one would register such extension? ;-)

As currently it is hosted in my GitHub account, that would be a good
bet. If anyone else wants to host it and become a "central authority", I
won't mind either.


Regards,


Michael

PS: I noticed that I forgot to write in the specification that hardware
descriptor names should only use characters that can appear in the
middle of an Oberon module name, to make dynamic loading of drivers
easier. Something for next revision :-)