[Oberon] Volatile variables in Oberon

Joerg joerg.straube at iaeth.ch
Mon Aug 1 09:14:17 CEST 2016


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://lists.inf.ethz.ch/mailman/listinfo/oberon<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://lists.inf.ethz.ch/mailman/listinfo/oberon<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://lists.inf.ethz.ch/mailman/listinfo/oberon



More information about the Oberon mailing list