Re: Oberon and Wirthian languages

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-04-24 21:51 , Simon Clubley wrote:
> On 2014-04-24, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> On 14-04-24 03:20 , Simon Clubley wrote:
>>> On 2014-04-23, Simon Wright <simon@pushface.org> wrote:
>>>>
>>>> But hardware isn't (usually) elegant! If what the hardware designer
>>>> wants is for you to read the register, change the values you need to in
>>>> the local copy, then write the modified value back, that's what the code
>>>> should do, surely, without relying on compiler magic with obscure
>>>> pragmas to make it happen? (Ada's pragma Atomic is quite obscure enough
>>>> already!)
>>>
>>> The problem is the compiler does this automatically when you use C style
>>> masks,
>>
>> Not really so, for the most common forms of C. AIUI, before C 2011 there
>> was no way in C to declare that a particular variable or type should be
>> "atomic" in the sense of being read and written indivisibly; this was
>> only possible by using the predefined integer type sig_atomic_t.
>>
> 
> Sorry, I probably wasn't clear enough.

Nor was I, see below...

> What I meant was that if you write (in C) something like:
> 
> 	device_register = (device_register & mask1) | mask2;
> 
> while accessing a volatile register then gcc generates exactly one read
> and exactly one write and the size of the access is the size of the
> device_register declaration.
> 
> This is true at least on ARM and I have never seen any complaints about
> it being untrue on other architectures.

Gcc usually does the right thing, which is good. But gcc on ARM has no
reason to do otherwise, because the "load;and;or;store" instruction
sequence is also the shortest and fastest implementation of this C
statement.

IIRC, your original question was if the Ada RM *guarantees* single
load/store instructions; my point above was that the C standard (pre
2011) guarantees it only for the type sig_atomic_t.

To be very precise, C 1999 says only that sig_atomic_t "can be accessed
as an atomic entity, even in the presence of asynchronous interrupts".
There is no mention of single load/store instructions. In principle, a C
compiler could implement read (write) of sig_atomic_t by several load
(store) instructions, executed with interrupts disabled. But I don't
know of any C compiler that does that.

> That's interesting. I wonder if this is a case of gcc implementing the
> "expected" behaviour and there's now a large set of code which relies on
> this "expected" behaviour.

That's "Situation Normal" for C :-). For this case (accessing device
registers), it is usually good enough because programs that depend on it
are not expected to work on different machines without rewriting these
parts of the program.

>> For example, assume that the variables A and B are of a record type with
>> the components x and y and some more components, Then, instead of the
>> three statements
>>
>>    B   := A;
>>    B.x := 42;
>>    B.y := False;
>>
>> we could say something like
>>
>>    B := (A overriding x => 42, y => False);
>>
>> (The "overriding" keyword is a bit misleading here, because it implies
>> that the left-hand operand (A) overrides the right-hand aggregate, while
>> the opposite should happen. Oh well.)
>>
> 
> Although I agree the syntax needs changing, I do like the general
> idea behind this suggestion.

Thanks. Perhaps the syntax (A and then x => 42, y => False) is a little
better.

I also considered using "others" in a new way:

   (x => 42, y => False, others => all A)

or

   (x => 42, y => False, all others => A)

but for some reason I feel that "A" should come first, and the changed
components after.

> It will be interesting to see if Randy and company have any comments on
> this syntax.

Overload resolution may be an issue. I think it could be based purely on
the "initial values" part ("A" in the examples above) and could ignore
the named component associations.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .