[Oberon] Volatile variables in Oberon
Jörg Straube
joerg.straube at iaeth.ch
Mon Aug 1 12:28:51 CEST 2016
In general importing SYSTEM is just a hint that you use low level functions that are not guaranteed to be portable.
I mean the address I'm using in my example does not do something useful on my machine but on your FPGA it might.
If address assignment to a variable would be part of the language (without using SYSTEM) you could compile your code and wonder why it doesn't work on your machine.
Whenever there is SYSTEM in the import list you know: watch out when porting this code to another machine/environment.
Whether you use SYSTEM.GET or address assignment via SYSTEM.VAL is a case by case decision.
Jörg
> Am 01.08.2016 um 10:33 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>
> 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