[Oberon] Volatile variables in Oberon

Jörg Straube joerg.straube at iaeth.ch
Mon Aug 1 12:35:06 CEST 2016


implementation wise the type tag is "before" the data. if the data starts at position 0, the type tag is at position -4.

but if you write your code with this kind of knowledge, you are really low kevel (either you write a compiler or debugger..).

Jörg

> Am 01.08.2016 um 10:51 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> 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=
> --
> 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