[Oberon] Emulating interrupts in oberon-risc-emu as in the RISC5 specification

Joerg joerg.straube at iaeth.ch
Wed Mar 31 11:10:13 CEST 2021


Gray

 

Indeed, from the CPU’s point of view, interrupt handlers have to store all registers they use.

“No register values are saved, because every interrupt handler is assumed to save (at least) registers R0 and R1.”

 

For interrupt procedures, the compiler automatically generates code to put R0 .. R2 onto the stack. If your interrupt routine has complex calculations involving more registers or calling procedures you have to store all used registers yourself. Especially, when calling procedures where you don’t have a clue what registers they are going to use, you best put the whole register set onto the stack.

 

br

Jörg

 

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von gray <gray at grayraven.org>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Mittwoch, 31. März 2021 um 04:39
An: <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] Emulating interrupts in oberon-risc-emu as in the RISC5 specification

 

For the multiple interrupt handling in software approach, if I understand Jörg's proposal correctly, it's important not to forget to explicitly store the link register before, and restore it after invoking the individual handler procedures. The processor does not do this. Thanks to Paul Reed for relieving my related headaches last year. :)

 

As an aside, with an FPGA it's not too complicated to implement a hardware-based interrupt controller with several input lines as a "front end" to the one interrupt of the processor. I have used mine for months now and it works well. I currently use it mostly for handling errors detected by hardware devices (eg. watchdog, stack overflow monitor).

 

Regards

-- gray

 

 

On Wed, 31 Mar 2021, at 04:45, Jörg wrote:

Although TestInt is low-level, it should use Kernel.Install (SYSTEM.ADR(Int), 4) to make it a little bit less low-level😀

 

This little wrapper makes interrupts a little bit better consumable:

MODULE Interrupts; (* jr/31mar21 *)

IMPORT S := SYSTEM, Kernel;

PROCEDURE Install*(handler: PROCEDURE);

  BEGIN Kernel.Install(S.ADR(handler), 4) END Install;

PROCEDURE Set*(on: BOOLEAN);

  BEGIN S.LDPSR(ORD(on)) END Set;

END Interrupts.

 

With it TestInt.Mod gets

MODULE TestInt;

IMPORT Interrupts;

VAR led, cnt: INTEGER;

PROCEDURE* MyInterrupt;

  BEGIN

    INC(cnt); IF cnt = 500 THEN led := 3-led; LED(led); cnt := 0 END

  END MyInterrupt;

PROCEDURE On*; BEGIN Interrupts.Set(TRUE) END On;

PROCEDURE Off*; BEGIN Interrupts.Set(FALSE) END Off;

BEGIN

  led := 1; cnt := 0; Interrupts.Install(MyInterrupt)

END

TestInt.On

TestInt.Off

 

Interrupts.Mod could be enhanced servicing multiple interrupt handlers. Comparable to the background tasks in Oberon.Mod. This enhancement would install its own interrupt handler doing the scheduling, and the user‘s „interrupt handlers“ are normal procedures without * marking of the procedure. You would then install your handler like this

PROCEDURE MyTask; BEGIN led := 3 - led; LED(led) END MyTask;

BEGIN led := 1; Interrupts.Install(MyTask, 500) END TestInt.

 

br, Jörg

 

Am 30.03.2021 um 23:45 schrieb Charles Perkins <chuck at kuracali.com>:



Hello Everybody,

 

I wanted to explore interrupt handling in Oberon and I discovered that Peter De Wachter's excellent emulator did not implement them, which is not surprising, as the current Project Oberon source doesn't use them as far as I can tell and the only example source code showing how to use interrupts is the TestInt module on Professor Wirth's own 2018 update to RISC5: https://people.inf.ethz.ch/wirth/ProjectOberon/RISC5.Update.pdf

 

Since I wanted to compile and run that small example I forked Peter's emulator and added support for Interrupts in a branch here: https://github.com/io-core/oberon-risc-emu (only a few small changes were needed.)

 

With those changes I am able to compile the TestInt module and execute it in the emulator using the 2019 disk image in the repo. Emulated LEDs update once per second as expected.

 

I don't intend to maintain a fork of Peter's emulator, I just wanted to experiment with interrupts and share the implementation in case anyone else is interested.

 

Best Regards,

Chuck

--

Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

https://lists.inf.ethz.ch/mailman/listinfo/oberon

--

Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

https://lists.inf.ethz.ch/mailman/listinfo/oberon

 

 

-- 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/20210331/610571a1/attachment.html>


More information about the Oberon mailing list