[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