Re: Ideas for Ada 200X

[Bill Findlay <yaldnifw@blueyonder.co.uk>]

On 1/6/03 01:15, in article bbbgnb$ia3@library1.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

>>> In particular, consider:
>>> 
>>> DEVICE_DATA_REGISTER : BYTE;
>>> for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
>>>  ...
>>> DEVICE_DATA_REGISTER := 16#40#;
>>> DEVICE_DATA_REGISTER := idem;
>>> DEVICE_DATA_REGISTER := idem + 1;
>>> 
>>> How many times should DEVICE_DATA_REGISTER be *read* by the above code
>>> fragment?  Why?
>> 
>> I note that DEVICE_DATA_REGISTER  is not declared volatile.
> 
> You are correct.  I am an old Ada programmer, and I am not up to speed on
> Ada95.

Does Ada 83 define this number? I'd be surprised!
If you declare it volatile in Ada 95 then you get 2 read accesses (assuming
the equivalent code below). What more certainty do you need?
 
> On the other hand, I also did not bother to say whether DEVICE_DATA_REGISTER
> was even readable at all.  I do device drivers often enough that write-only
> registers, that physically cannot be read, that hang the bus if any attempt
> is made to read them, are not unusual to me.

If your location is write-only, why are you trying to read from it?
Either the h/w location supports update-in-place or it does not.
Either it supports writes or not.
Either it supports reads or not.

So what?

If an Ada implementation presently lets you control the way that location is
accessed, using necessarily implementation-dependent knowledge to get the
code you need, then it could do so for any new constructs too.

>> How many times would it be read by:
>> 
>> DEVICE_DATA_REGISTER := 16#40#;
>> DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER;
>> DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER + 1;
>> 
>> ?
>> 
>> The answers 2, 1 and 0 all seem reasonable to me.
>> Why do you think the language *should* define this?
> 
> Predictability and portability.

Well, it is predictable and portable if you ensure that it has that
property, and it isn't if you don't. How could things be otherwise?
 
> If the language does not define the semantics of that particular
> pathological case, then the risk occurs that a toolset update down the road
> would break the existing code.  That scenario, in my personal opinion, is
> 100% bad.

You seem to be asking, not just that the semantics be defined, but that they
be defined in a particular, invariable way. Not the same thing.
I'm all for predictability and portability, but I think that modern hardware
and modern software environments make what you seem to be asking for
unachievable, unless the language is so encumbered with restrictions as to
verge on the crippled.

> Now, an argument can be made for machine code insertions and/or explicit
> assembly language for this kind of thing.  However, the trend on modern
> processor design is to make the hardware very unpredictable, to the point
> that the programmer, OR THE COMPILER, may issue the instructions in one
> order, and the hardware actually execute them in a different order, and,
> worse, that order may vary from run to run.  This can be VERY DANGEROUS when
> you are doing device drivers.  You usually don't want to apply the defib
> pulse until AFTER you have disconnected the EKG leads (unless your EKG
> buffer amps are VERY robust indeed!).

Quite so. 
You have to write your code so these indeterminacies provably do not matter.
In the example you gave that is easy. In general it is hard.

What do you want the semantics of Ada to do about this?

It can do little more than it does now, AFAIKS, and that is: not much.

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")