[Oberon] Memory array [WAS: Re: NAstrobe for RISC5 on Pepino]
paulreed at paddedcell.com
Thu Aug 2 19:02:39 CEST 2018
> Do you mean that SYSTEM is not typed? This I can see. But what is the
Sorry I wasn't clear, I was running out the door - I apologise.
I meant that your desired data structure isn't typed, and that's the
"problem", as you put it. Oberon endeavours to be a strictly-typed, safe
The virtual module SYSTEM is provided for such things as you describe, as
you now acknowledge; but as Prof. Wirth rues, it is often over-used.
> I am describing a use case which is very common.
Doesn't make it right! :) I'm speaking from experience, where my younger
self, obsessed with the desire for performance, wrote a lot of low-level
routines using SYSTEM.PTRs and inline machine-code, which going back to
them, were inscrutable and highly-unportable.
I wish I had only optimised what actually needed optimising, which in many
cases was nothing (Knuth). I know that your applications do indeed need
performance, but they need to be maintainable too, I assume. And with
FPGAs you have a lot of flexibility to get your performance from the
> In any hardware project there are always buffers, arrays, and individual
> registers which must live at fixed addresses. The sizes of such objects
> are known. Would it be nice to provide a universal mechanism to allocate
> an array or a variable at a given address, without going through SYSTEM
I think I was also confused by your use of "New". Memory-mapped
structures defined by the hardware don't need to be "allocated", they
already exist. They just need to be declared.
> Alternatively, maybe SYSTEM can provide a clean syntax to
> handle such cases?...What I mean is a clean language construct to handle
such "dirty" cases, which are unavoidable if one is programming the
I think the clean language construct required here is the module. Define
a module expressing your hardware structures in a type-safe way (and even
runtime-checked if it doesn't cost too much), and export them from a
module, which uses SYSTEM internally.
A good example of this is module Input from Project Oberon. It imports
SYSTEM, and exports a keyboard input FIFO and mouse status, and an
initialisation procedure. No SYSTEM contortions necessary to use it.
More information about the Oberon