[Oberon] Volatile variables in Oberon

[Srinivas Nayak]

> But the Oberon compiler does not do such kind of optimizations and loads the value of „p" every time. So no „volatile" needed in Oberon.
>
> Jörg


This answers the question nicely.


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 07/30/2016 11:12 AM, Jörg Straube wrote:
> Wojtek
>
> If you really want a memory-mapped variable you could do it e.g. as follows
> - - -
> TYPE MemoryMapped = POINTER TO INTEGER;
> VAR p: MemoryMapped;
> BEGIN
>    p := SYSTEM.VAL(MemoryMapped, 0E7F00H) (* assign address of memory to variable *)
>    WHILE p^ # 0 DO END;
> END
> - - -
>
> But as Chris mentioned the „usual" way in Oberon to do the same is as follows:
> - - -
> VAR i: INTEGER;
> BEGIN
>    SYSTEM.GET(0E7F00H, i);
>    WHILE i # 0 DO SYSTEM.Get(0E7F00H, i) END;
> END
> - - -
>
> But we don’t have to mark „p" as „volatile" as the Oberon compiler does no optimization.
> If the compiler generates code for the WHILE loop, and would see „oh, „p" is not changed in the loop so I load „p" to register R3 only once and just check R3", this optimized code would fail in case p is a memory mapped variable. Then you have to mark „p“ as volatile, as hint for the compiler to re-load the value every time.
> But the Oberon compiler does not do such kind of optimizations and loads the value of „p" every time. So no „volatile" needed in Oberon.
>
> Jörg
>
>> Am 30.07.2016 um 04:57 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>>
>> Chris wrote:
>>> I cannot think of a situation where you would need to specify that a
>>> variable is volatile when using Oberon-07. Can you think of one?
>>
>> Yes I can. If a variable is mapped to a register which can be changed "from the other end" then it is volatile.
>>
>>> This constraint is typically only required on systems that implement unsafe
>>> optimisations and variables that are mapped to peripheral registers.
>>
>> I am not sure of optimizations. But register mapping is the gist of programming the FPGA.
>>
>> I would rephrase the question: how do we handle memory-mapped registers whose value can change at any time?
>>
>> Regards,
>> Wojtek
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>