[Oberon] Volatile variables in Oberon
Skulski, Wojciech
skulski at pas.rochester.edu
Mon Aug 1 10:51:06 CEST 2016
Joerg:
I misunderstood the comment "with our SYSTEM". It probably should have been "without SYSTEM".
Your solution looks ingenious to me, and also very tricky. It is basically a pointer manipulation like in C. (Are we getting close to pointer arithmetic?)
Thinking of it a bit more, I would never think of this solution because I still remember that a high level Oberon array carries the hidden memory tag. But here it looks like you are assigning a starting address to the array, which is very much like C.
Does it mean that the Oberon-07 records and arrays are [untagged] in the sense of Component Pascal? If so then Oberon-07 arrays would be close to C arrays.
How are the runtime type guards handled without the hidden tags?
Wojtek
________________________________________
From: Skulski, Wojciech
Sent: Monday, August 1, 2016 4:33 AM
To: ETH Oberon and related systems
Subject: RE: [Oberon] Volatile variables in Oberon
Joerg:
are you saying that the only penalty is that SYSTEM is on the import list, but otherwise the module is high level, and I can access the array as usual?
If so then it looks very good to me.
I must admit that I feel quite confused. If the solution is that simple, then why do we need PUT and GET?
Thank you,
Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Joerg [joerg.straube at iaeth.ch]
Sent: Monday, August 1, 2016 3:14 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Volatile variables in Oberon
Wojtek
Your low-level module looks something like that
MODULE DSP:
IMPORT SYSTEM;
CONST ArraySize* = 32
TYPE Array* = POINTER TO RECORD a: ARRAY ArraySize OF INTEGER END;
VAR a*: Array;
BEGIN
a := SYSTEM.VAL(Array, 32400H)
END DSP.
Your super-duper algo in high level (with our SYSTEM)
PROCEDURE FindPeaks(arr: DSP.Array);
VAR i, tmp: INTEGER;
BEGIN
FOR i := 0 TO 31 DO
tmp := arr.a[i]
(* do clever things with tmp *)
END
END FindPeaks;
and call it with
FindPeaks(DSP.a)
Jörg
> Am 01.08.2016 um 07:37 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>
> Joerg:
>
> thank you. This is nice.
>
> Let's talk of an array. The array access will be done the same way by stepping "c" in a loop. Since I am using SYSTEM, it has to be done inside a "low level module".
>
> Now imagine I want to use my array in a high-level code. Imagine, that I have developed a nice module DSP.Mod of DSP functions. For example, I want to find some features in the array, like for example impulses. I have my own favorite algorithm. I wrote a function DSP.FindPeaks (arr: ArrayPTR).
>
> Now I need to pass the array to the function FindPeaks. So I export the array from the low-level module, and I use the array as an argument to FindPeaks. Great!
>
> I notice that the export is read-only. No problem.
>
> Now in my DSP.FindPeaks I have a FOR loop. I access the array element like this:
>
> tmp := arr [i];
>
> Ooops. I cannot do this because I must access the array with GET.
>
> No problem. In the low-level module I make a copy of the volatile array to a regular Oberon array which I export to be used in DSP.FindPeaks.
>
> Ooops. My waveform is 32k samples. So I must copy 32k integers in order to use the array in my high level function. It is inefficient.
>
> An efficient algorithm needs to be performed without copying the array. But how can I implement the high-level algorithm, if I cannot access the array elements in the high-level code in the first place?
>
> What am I missing?
>
> Wojtek
> -----------------------------------------
>
> And in Oberon
> VAR c: BYTE;
> SYSTEM.GET(UART0UDR, c);
>
> Have fun
> Jörg
>
> Am 30.07.2016 um 19:00 schrieb Magnus Karlsson <magnus at saanlima.com<mailto:magnus at saanlima.com>>:
>
> Your C code seems to a bit convoluted if just want to access a register.
> This is quite often done by defining the registers as volatile pointers like this:
>
> Register address definitions (in this case for a UART):
> #define UART0_UDR (*(volatile uint8_t *)(0x44000000))
> #define UART0_UCR (*(volatile uint16_t *)(0x44000004))
> #define UART0_UBRR (*(volatile uint16_t *)(0x44000008))
>
> You can then access registers like this (read UART data register):
> uint8_t c = UART0_UDR;
>
> Magnus
>
> On 7/29/2016 11:06 PM, Skulski, Wojciech wrote:
>
> Chris:
>
>
>
> But Oberon variables are not mapped to registers that can be changed "from
> the other end". The explicit operations SYSTEM.GET and SYSTEM.PUT are used
> when you want to transfer data between a peripheral register (mapped to an
> absolute memory location) and Oberon variables.
>
>
> Pardon my C on this mailing list. The point I want to make is that it is ugly.
>
> Here is a sample of my C program where I am reading from an absolute memory location mapped to an FPGA register. The "target" is an integer, which is then used to retrieve a value from the FPGA. The address is not constant, but I can make it constant using a #define.
>
> long target; /* long int holds addr, needs a typecast */
> short value;
> short *virt_saddr; /* typed pointer to 16-bit short */
>
> virt_saddr = (short *) target; /* convert target to pointer */
> value = * virt_saddr; /* read value from address */
>
> I would prefer to write in C something like the following:
>
> short value at address; /* address is constant, which is most often the case*/
>
> In Oberon it would be something like this:
>
> CONST address = ....;
> VAR value: INTEGER AT address; (* address must be constant*)
>
> Now the question, is this unreasonable?
>
> Wojtek
> --
> Oberon at lists.inf.ethz.ch<mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=bwcNzK3igbLTc51joi2ukqQAKwoCpVw8KST4sPDO23k&s=XwMAdQD5p1fahnD99NTes2a0RZ-HK2lAFQ0oQhvhwjY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwMFaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=bitBRpmXOMbIlH-tyDdfNX20KHa96OvM7K3v7PfbD1Y&s=tNIIZKSzd6zd8FsW_rRVPFPr5almnnjplw034cryWwc&e=>
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch<mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=bwcNzK3igbLTc51joi2ukqQAKwoCpVw8KST4sPDO23k&s=XwMAdQD5p1fahnD99NTes2a0RZ-HK2lAFQ0oQhvhwjY&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwMFaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=bitBRpmXOMbIlH-tyDdfNX20KHa96OvM7K3v7PfbD1Y&s=tNIIZKSzd6zd8FsW_rRVPFPr5almnnjplw034cryWwc&e=>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=bwcNzK3igbLTc51joi2ukqQAKwoCpVw8KST4sPDO23k&s=XwMAdQD5p1fahnD99NTes2a0RZ-HK2lAFQ0oQhvhwjY&e=
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=CwIFAw&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=bwcNzK3igbLTc51joi2ukqQAKwoCpVw8KST4sPDO23k&s=XwMAdQD5p1fahnD99NTes2a0RZ-HK2lAFQ0oQhvhwjY&e=
More information about the Oberon
mailing list