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

Jörg joerg.straube at iaeth.ch
Thu Aug 2 18:59:21 CEST 2018


Wojtek

NEW() is meant for allocation on the heap.
Your case is different: you ask for pointer with a specific base address not on the heap. This is not done with NEW(). Here an example on how it could be done...

MODULE Wiz;
IMPORT SYSTEM;
CONST
  W5300Address = 0FF0A0H; (* or wherever your mapped IO is *)
  W5300Size = 3000H; (* or whatever the datasheet says *)
TYPE
   WizMemory = POINTER TO WizBuffer;
   WizBuffer = RECORD
      buf: ARRAY W5300Size OF CHAR
   END;
VAR
   m: WizMemory;
BEGIN
   m := SYSTEM.VAL(WizMemory, W5300Address);
   m.buf[1234] := 55X; (* writes directly to your mapped memory *)
END Wiz.

Jörg

> Am 02.08.2018 um 15:01 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Paul:
> 
>>> could you please remind me how I can handle the following situation. ...
>>> WizMemArrayPtr := New (W5300_address, W5300_size);
>>> ...It would be a very clean and natural programming. But it is not
>>> supported. What are the alternatives? I guess SYSTEM. But why?
> 
>> Because it's not typed.
> 
> Do you mean that SYSTEM is not typed? This I can see. But what is the problem? I am describing a use case which is very common. 
> 
> 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? 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.
> 
> Thank you,
> Wojtek
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon



More information about the Oberon mailing list