[Oberon] Stimulus driven interrupts?
Charles Perkins
chuck at kuracali.com
Thu May 6 18:19:37 CEST 2021
If you are going to use an emulator to explore interrupts in the RISC5
edition of Project Oberon, Peter De Wachter's oberon-risc-emu needs only a
few small changes to handle interrupts. I believe the version on Peter's
github page doesn't have them because it was originally developed before
Professor Wirth presented the Interrupts extension. I put my branch of his
emulator here: https://github.com/io-core/oberon-risc-emu. (My own emulator
project is shelved at the moment.)
On Thu, May 6, 2021 at 9:08 AM gray <gray at grayraven.org> wrote:
> Adding to Jörg's post, below, I have a simple eight channel interrupt
> controller in the FPGA hardware as "front end" to the single interrupt of
> the RISC5 CPU, including the corresponding Oberon driver of course. It adds
> one clock cycle of latency, IIRC. Let me know if you're interested. It
> requires some minor changes to the RISC5 CPU, though.
>
> -- gray
>
> On Thu, 6 May 2021, at 19:53, Joerg wrote:
>
> Hi Jeff
>
>
>
> The interrupt signal is handed over by the HW to the RISC5 CPU in
> RISC5Top.v.
>
> The interrupt signal in the CPU is called .irq, and the current RISC5Top.v
> hands over periodic interrupts with the Verilog code below
>
> RISC5 riscx(.clk(clk), .rst(rst), *.irq(limit),*
>
> .rd(rd), .wr(wr), .ben(ben), .stallX(vidreq),
>
> .adr(adr), .codebus(codebus), .inbus(inbus),
>
> .outbus(outbus));
>
>
>
> assign limit = (cnt0 == 24999);
>
>
>
> But you are totally free to set the CPU’s .irq signal on other HW
> conditions, e.g. a packet on the Ethernet board arrived or the temperature
> sensor says the meat is tender.
>
>
>
> Below I attached an older mail on an “simple” API to facilitate
> programming with interrupts. Instead of Kernel.Install you would call
> Interrupt.Install to install the interrupt handler.
>
>
>
> br
>
> Jörg
>
>
>
> *Von: *Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Jeff
> Maggio <jmaggio14 at gmail.com>
> *Antworten an: *ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> *Datum: *Donnerstag, 6. Mai 2021 um 13:44
> *An: *<oberon at lists.inf.ethz.ch>
> *Betreff: *[Oberon] Stimulus driven interrupts?
>
>
>
> Hi all,
>
>
>
> I'm using Oberon on an embedded RISC5 system, and am able to modify both
> firmware and software.
>
>
>
> In this Oberon-1 paper (*http://norayr.am/papers/WirthTasksVersusThreads.pdf
> <http://norayr.am/papers/WirthTasksVersusThreads.pdf>*) from 1996, Wirth
> discusses a method of "real-time tasks". *(Page 10)*. In which I believe
> interrupt handlers installed with *Kernel.Install(Handler, N)* are
> triggered when a device or buffer is updated? The details are unclear in
> the paper.
>
>
> I see that *Kernel.Install* still exists in the RISC5 source. Can this
> method still be used for "real-time tasks" in which a procedure is run when
> an external stimulus changes? So far all the interrupt examples I've seen
> make use of interrupts triggered periodically by the millisecond timer.
>
>
> My end goal is to trigger an interrupt (from firmware or otherwise) in
> reaction to stimulus without having to wait for the millisecond timer
>
>
>
> best,
>
> Jeff
>
> -- Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
> . . . . . .
>
> Hi
>
>
>
> A remark on interrupts in ProjectOberon:
>
> The current implementation of interrupts looks to me a little bit like a
> quick and dirty hack or proof of concept. I don‘t find it user-friendly a
> programmer has to import SYSTEM and has to know the „magic“ address 4. Let
> me explain.
>
>
>
> Offering interrupts to the programmer needs three parts:
>
> - CPU support: instructions to enable/disable interrupts and return
> from interrupts.
>
> DONE.
>
> - Compiler support: PROCEDURE* is parsed and correct instructions are
> generated.
>
> DONE.
>
> - OS support: an easy to use API to use the interrupt in a program.
>
> MISSING.
>
>
>
> Of course I can provide an API myself. Eg:
>
>
>
> MODULE Interrupt; (* jr/31dec19 *)
>
> IMPORT SYSTEM, Kernel;
>
>
>
> PROCEDURE* Empty; END Empty;
>
>
>
> PROCEDURE Install*(handler: PROCEDURE); (* handler=NIL:
> deactivate interrupts *)
>
> VAR instr: INTEGER;
>
> BEGIN
>
> SYSTEM.LDPSR(0);
>
> Kernel.Install(SYSTEM.ADR(Empty), 4);
>
> SYSTEM.GET(SYSTEM.VAL, INTEGER, handler)+4, instr);
>
> IF instr = 0A0E00000H THEN (* valid interrupt handler *)
>
> Kernel.Install(SYSTEM.VAL(INTEGER, handler), 4);
>
> SYSTEM.LDPSR(1)
>
> END
>
> END Install;
>
>
>
> BEGIN Install(NIL) END Interrupt.
>
>
>
> For me something like the above should be part of the inner core (e.g.
> Kernel.Mod) or at least a module of the outer core to be provided with the
> standard distribution.
>
> With the above API, interrupts are easily consumable (no import of SYSTEM,
> all the nitty gritty details hidden in Interrupt.Mod)
>
>
>
> MODULE TestInt;
>
> IMPORT Interrupt;
>
> VAR led, cnt: INTEGER;
>
> PROCEDURE* Int; (*interrupt handler called every millisecond*)
>
> BEGIN
>
> INC(cnt); IF cnt = 500 THEN led := 3 - led; LED(led); cnt := 0 END
>
> END Int;
>
> PROCEDURE On*; BEGIN Interrupt.Install(Int) END On;
>
> PROCEDURE Off*; BEGIN Interrupt.Install(NIL) END Off;
>
> BEGIN
>
> led := 1; cnt := 0
>
> END TestInt.
>
>
>
> br
>
> Jörg
>
>
> Am 30.12.2019 um 16:12 schrieb Charles Perkins <chuck at kuracali.com>:
>
>
>
> Hi Paul and Jörg,
>
>
>
> Sometimes I am too clever for my own good. I thought I saw a way out of
> the name confusion. I'll make it clear that RISC5 is the correct name for
> the architecture. Also, I missed the CPU version bits in the emulator -- I
> will have to make sure the SYSTEM.H code works too... after I correct DIV
> for negative operands and finish floating point!
>
>
>
> Of course this is just another emulator and the Oberon community already
> has plenty of those but I wanted to work with just one emulation platform
> across several porting efforts, and QEMU is to me the obvious choice. And
> as a side benefit it seems quite fast, comparatively.
>
>
>
> Cheers,
>
> Chuck
>
>
>
>
>
> On Mon, Dec 30, 2019 at 1:43 AM Jörg <joerg.straube at iaeth.ch> wrote:
>
> Hi
>
> You can ask the RISC processor to reveal its version with this code
>
> cpu := SYSTEM.H(2019) MOD 80H;
> 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 = A0H THEN (* RISC0, 26.12.2013 *)
> END;
>
> br
> Jörg
>
> Am 30.12.19, 09:56 schrieb "Oberon im Auftrag von Paul Reed" <
> oberon-bounces at lists.inf.ethz.ch im Auftrag von paulreed at paddedcell.com>:
>
> Hi Chuck,
>
> > ...the target is named risc6
> > to avoid confusion with the already existing riscv target in qemu and
> > because in one communication (An Update of the RISC5 Implementation
> > [1]) Professor Wirth defines module RISC6 to introduce interrupts
> into
> > the architecture.
>
> Sorry I think that's a mis-print since it's the only occurrence, I'm
> pretty sure the intention was to keep it as RISC5. Apologies for any
> confusion.
>
> As it happens most of the stuff for interrupts was there originally
> anyway before the update, especially in the compiler. The RISC5
> source
> on Prof. Wirth's site definitely contains the interrupt code now.
> There's also a RISC5a version, without interrupts and without
> floating-point.
>
> Cheers,
> Paul
> --
> 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
>
> -- 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/20210506/3469e99d/attachment-0001.html>
More information about the Oberon
mailing list