[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