From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-31 17:21:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.airnews.net!cabal12.airnews.net!usenet From: "John R. Strohm" Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X Date: Sat, 31 May 2003 19:15:38 -0500 Organization: Airnews.net! at Internet America Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> Xref: archiver1.google.com comp.lang.ada:38256 Date: 2003-05-31T19:15:38-05:00 List-Id: 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" 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" 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 > > > > := idem op expr; > > > > to > > > > shadow := idem op 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()" or "++" > > 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" 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!).