Re: Ideas for Ada 200X

["John R. Strohm" <strohm@airmail.net>]

X-A-Notice: References line has been trimed due to 512 byte limitation
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library1-aux.airnews.net
NNTP-Posting-Time: Sat, 31 May 2003 19:17:47 -0500 (CDT)
NNTP-Posting-Host: !_Ga)1k-XoM*B/H (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106


"Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote in message
news:BAFEF028.2F2D%yaldnifw@blueyonder.co.uk...
> On 31/5/03 20:18, in article bbavc7$ns8@library1.airnews.net, "John R.
> Strohm" <strohm@airmail.net> wrote:
>
> >> Does Oberon make adding 2, multiplying by 10, etc, equally concise and
> >> 'unmistakable'?
> >
> > Empirically, those operations do not happen nearly as often as the
canonical
> > I = I + 1.  See Knuth, "An Empirical Study of FORTRAN Programs", ca.
1970,
> > and various follow-on papers in the decades since.
>
> Agreed. But we are discussing ?:= operators here, not just increment.
> As I said in another post, "We have a perfectly good syntax for changing a
> variable, namely assignment. The fewer notations there are for the same
> thing, the better, surely."
>
> > ...  If I have to change
> >
> > <some_lvalue_expr> := idem op expr;
> >
> > to
> >
> > shadow := idem op expr;
> > <some_lvalue_expr> := shadow; -- This happens ALL THE TIME in device
drivers.
> >
> > I'd rather not have to worry about the implications of not doing fetch
*AND*
> > store on the device register.  I've gotten burned on this kind of thing
> > enough times to be wary.
>
> You seem to be making major assumptions about the target architecture and
> about the semantics of "INC(<some_lvalue_expr>)"  or
"<some_lvalue_expr>++"
>
> On many (if not most) ISPs, the fetch and store would be unavoidable, even
> for apparently update-in-place operations. On other, regrettably popular,
> ISPs there might well be no fetch. So what?
>
> Constraining a high-level language to get architecture-dependent effects
is
> not the way to go IMO. That's what machine-code inserts are for.
> (Or, better, abstracted operations that might use either the latter, or
> language-defined operations, *if* the compiler *happens* to give what you
> need.)
>
> Further,
>
> On 31/5/03 22:38, in article bbb7sv$8s2@library2.airnews.net, "John R.
> Strohm" <strohm@airmail.net> wrote:
>
> > OK, so what are the implications for parsing expressions?
>
> I don't see any significant implications for *parsing* as such.
> 'idem' or equivalent refers to the variable on the LHS of an assignment.
> It is meaningless elsewhere.
>
> > For example:
> > What does
> >   I := idem + idem;
> > mean?
>
> What it seems to.
>
> > How about
> >
> > do_some_proc(foo, baz, idem);
> >
> > Does "idem" refer back to foo, baz, or do_some_proc?
>
> No.
>
> > Should we allow, or not allow,
> >
> > J := idem;
> >
> > Why or why not?  What are the semantics?
>
> The precise semantics are up for discussion, but hardly seem difficult.
> I can immediately think of two reasonable definitions.
>
> 1. For the assignment:
>    V := f(idem);
> We set
>    A := V'access;
> and V and 'idem' in the assignment are replaced by A.all, passim:
>    A.all := f(A.all);
>
> 2. We define the anonymous procedure:
>    procedure assign_f_to_V (V : in out T) is
>    begin V := f(V); end;
> and replace the assignment by the call:
>    assign_f_to_V(V);
>
> In each case all reasonable optimizations would be permitted, nay
> encouraged.
>
> I'm sure these first cuts would need to be refined, and I'm sure there are
> other approaches.
>
> > 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.

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.

> 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.

Recall that Ada was intended for broad use across a certain very critical
domain: military embedded systems programming.  The intention was that there
would be ONE language that worked the SAME way EVERYWHERE.  The Department
of Defense already knew what would happen if the language was allowed to be
different, or have different semantics, on different implementations.  (They
only had to look at CMS-2 for a good reminder.)

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.

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!).