[Oberon] QEMU target implementation for Oberon RISC architecture

[Jörg]

All

 

Just to refine my idea. The second byte of the MOV’ instruction could identify the emulator as follows:
Peter de Wachter’s emulator could return     50H (ASCII “P”)
Andreas Pirklbauer’s emulator could return  41H (ASCII “A”)
Chuck Perkin’s emulator could return             43H (ASCII “C”)
Michael Schier’s emulator could return          4DH (ASCII “M”)
Roel de Jong’s emulator could return             52H (ASCII “R”)
 

I know this method does not scale. But to give the first brave emulator programmers one letter of credit ☺

And remember: it’s only an idea…

 

Happy New Year to all of you.

Jörg

 

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Jörg <joerg.straube at iaeth.ch>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Dienstag, 31. Dezember 2019 um 09:51
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] QEMU target implementation for Oberon RISC architecture

 

All

 

Sorry, I made a typo. The correct identification code should look like this:

 

        cpu := SYSTEM.H(2019) MOD 100H;

        IF cpu = 53H THEN       (* RISC5: with interrupts + floating-point, 31.8.2018 *)

        ELSIF cpu = 54H THEN (* RISC5a: no interrupts, no floating-point, 1.9.2018*)

        ELSIF cpu = 0A0H THEN (* RISC0, 26.12.2013 *)

        END ;

First of all, the CPU version identification is an undocumented feature. So only NW knows, if it will be supported in the future.

Perhaps we as Oberon community can agree on how emulators shall identify itself. I see four thinkable ways
Return one of the values above, as the real FPGA HW would do. Be totally transparent to the Oberon code.
Return another value, so the Oberon code might find out that it’s running on an emulator if he wants to do so
Use a few of the 20 unused bits in the instruction, currently set to 0. This has the benefit that the CPU version is still one of the defined ones, and we can detect the CPU feature set foreseen by NW. We still have the possibility to detect on what emulator this CPU is implemented.
Define a new (still unused) instruction to just return the emulator version.
 

My recommendation would be: c). Just as an idea: use the second lowest byte to identify the emulator.

As example: SYSTEM.H(2019) DIV 100H MOD 100H would identify the emulator.

 

br

Jörg

 

-- Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191231/8b0afc6e/attachment.html>