[Oberon] Memory array [WAS: Re: NAstrobe for RISC5 on Pepino]

[Paul Reed]

Hi Wojtek,

> Do you mean that SYSTEM is not typed? This I can see. But what is the
> problem?

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
language.

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
hardware alone.


> 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
> contortions?

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
hardware drivers.

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.

HTH
Paul