- Oberon - mailman3.inf.ethz.ch

Stimulus driven interrupts?
by Jeff Maggio 07 May '21

07 May '21

Gray - that would be fantastic! I'd love to look more into it Jorg - thank you, that module simplifies things a lot. Would it be possible for you to walk me through how it works in more detail? I'm not following every line - for instance what does SYSTEM.LDPSR do? 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 > *

5 4

Re: [Oberon] Stimulus driven interrupts?
by Jeff Maggio 07 May '21

07 May '21

Thank you Jörg - this clears a lot up In the paper from N Wirth that I linked ( http://norayr.am/papers/WirthTasksVersusThreads.pdf) he mentions an "interrupt vector" (page 10). Does this mean that multiple interrupts can be setup in a priority order? much obliged, Jeff In addition to Chris’ reply. Here a minimum implementation of > Install*(handler: PROCEDURE); > SYSTEM.LDPSR(0); > (* disable/clear interrupt *) Kernel.Install(SYSTEM.VAL(INTEGER, handler), > 4); (* install the interrupt handler at memory address 4 *) > SYSTEM.LDPSR(1); > (* enable/set interrupt *) LDPSR is the abbreviation for “load processor > status register”. The last bit of this status register is “interrupt: > on/off” As interrupts begin and end differently than “normal” procedures, > and it has bad consequences if you install a “normal” procedure as > interrupt handler, I decided to check that the parameter “handler” is > really an interrupt procedure. To do this I check the procedure’s prolog. > Here the start of the prolog (=the code the compiler generates when it sees > a BEGIN) > normal proc: interrupt proc: > SUB SP SP localsize SUB SP SP localsize > STW LNK SP 0 STW R0 SP 0 > …. … The first instruction is the same > but the second instruction differs. > SYSTEM.LDPSR(0); > (* disable/clear interrupt *) Kernel.Install(SYSTEM.ADR(Empty), > 4); (* see below *) > SYSTEM.GET(SYSTEM.VAL(INTEGER, handler)+4, instr); (* get second > instruction of the “handler” code. If “handler” is NIL the check below is > never true *) IF instr = 0A0E00000H THEN (* valid interrupt handler > *) (* check for STW R0 SP 0 *) Kernel.Install(SYSTEM.VAL(INTEGER, > handler), 4); (* install interrupt handler at memory > address 4 *) > SYSTEM.LDPSR(1) > (* enable/set interrupt *) END The “Empty” interrupt is a precaution in > case the programmer’s interrupt handler is not valid or NIL and the > programmer would code a SYSTEM.LDPSR(1) on his own after Install(). I could > put this code in the ELSE. Instead of SYSTEM.GET(SYSTEM.VAL(INTEGER, > handler)+4, instr); the compiler would also accept the shorter > SYSTEM.GET(ORD(handler)+4, instr); As the Oberon report does not define > ORD() on procedure variables, I use the “official” way of doing it. br Jörg

1 0

Stimulus driven interrupts?
by Jeff Maggio 06 May '21

06 May '21

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

4 3

INC(i) vs i := i + 1
by Jeff Maggio 05 May '21

05 May '21

Thanks everyone! That was very helpful

1 0

Re: [Oberon] INC(i) vs i := i + 1
by Chris Burrows 05 May '21

05 May '21

> > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Joerg > Sent: Wednesday, 5 May 2021 6:00 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] INC(i) vs i := i + 1 > > Just as an example, find below the output of the RISC5 compiler: > > The statements i := i+1; and INC(i); generate exactly the same output, That is true if i is a local or global variable or a value parameter. However, if i is a VAR parameter, the INC version generates one less instruction. Regards, Chris Burrows CFB Software https://www.astrobe.com

2 1

Re (2): Re (2): Streams.
by peter＠easthope.ca 04 May '21

04 May '21

From: Charles Perkins <chuck(a)kuracali.com> Date: Thu, 22 Apr 2021 15:31:34 -0700 > I would like to be able to chain commands, where the output of one command > is treated as the input to another command. Something like: > > Stream.Do List.File AFile.txt | Lines.Uppercase | Lines.Sort | Lines.Uniq | Lines.Count > ... OK, thanks. That gives me some perspective. I need to read Streams in Oberon and in A2 again and review use in Mail again. In the Oberon subsystem of UnixAos, I encountered a limit on the number of executions of Files.Old(). According to memory, enough executions froze the system. Appeared that the limitation came from Linux. Each execution created a temporary file until a limit was struck? That motivates my interest in the use of Files in Streams. Understanding software (or any technology) retrospectively can be a challenge. Thx, ... P. -- VoIP: +1 604 670 0140 Bcc: peter at easthope. ca

2 1

INC(i) vs i := i + 1
by Jeff Maggio 03 May '21

03 May '21

Hi all, In most Oberon source, people tend to increment i with INC(i). Is there an efficiency reason for this, or is i := i + 1 just as fast? I'm trying to write code that would be very easy for someone coming from python/C++ to understand, so I'd prefer to use i := i + 1 because it's syntactically familiar best, Jeff

4 3

INC(i) vs i := i + 1
by Jeff Maggio 03 May '21

03 May '21

Good to know! Thank you both! -Jeff

1 0

AppleGS Orca Modula-2 Compiler
by edzard＠kolks.nl 27 Apr '21

27 Apr '21

Hello All, I know this is a Oberon mailing list but maybe a few are interested in (a good) Modula-2 compiler as well. Ken Gagne and Mike Westerfield reached out to to Peter Easdown, developer of the OCRA Modula-2 for AppleGS. Ken just e-mailed me that Peter made the source available at https://github.com/pkclsoft/ORCA-Modula-2 Best regards, Edzard

1 0

Resetting a file rider without creating a new stream.
by peter＠easthope.ca 27 Apr '21

27 Apr '21

Hi, I'm interested to add this procedure to the Oberon Mail module. PROCEDURE WriteMsgLine(CONST no: SIGNED32); VAR len, pos: SIGNED32; h: MIME.Header; cont: MIME.Content; str: ARRAY BufLen OF CHAR; strm: Streams.Stream; BEGIN Texts.WriteString(W, "Mail.Show "); Texts.WriteInt(W, no, msgNoWidth); Texts.Write(W, " "); strm := Streams.OpenFileReader(msgsF, msgs[0].pos); strm.mode := Streams.binary; Files.Set(strm.R, msgsF, msgs[no].pos); ... END WriteMsgLine; No problem with the two lines following BEGIN. The third line is meant to reposition the rider on msgsF but it fails to compile. A FileStream extends a Stream and has rider R. A Stream does not have a rider and consequently strm.R is meaningless. A new stream with new rider can be created but changing the rider in the existing stream would be more efficient. Is there a way change the rider without creating a new stream. Thx, ... P.L. -- VoIP: +1 604 670 0140 Bcc: peter at easthope. ca

3 2