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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Oberon and Wirthian languages Date: Sat, 26 Apr 2014 18:32:12 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <8761m535e4.fsf_-_@ludovic-brenta.org> <1zhiqb89npa6$.1z9j4otjchcb.dlg@40tude.net> Injection-Date: Sat, 26 Apr 2014 18:32:12 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="21184"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+foHk7sGPWGpVrIgfvoGkPaorrd/wcGq0=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:uWp5N9k7J+VI2KnIyqsXwngbzyE= Xref: news.eternal-september.org comp.lang.ada:19608 Date: 2014-04-26T18:32:12+00:00 List-Id: On 2014-04-26, Dmitry A. Kazakov wrote: > > Regarding original proposal, maybe I missed something, but I don't find it > useful in the case of hardware I/O, except maybe for very specific cases. > The reason is that reading from a hardware register is often impossible or > else has a physical side effect. In no way it can be done atomically with > the consequent read. We don't want to lock the whole machine for many > cycles? Hardware registers are very slow. When the copy of the register is > supposed to be stored elsewhere in RAM, then where is a problem? > I suspect you are thinking of accessing the registers in user mode while running under a operating system, that isn't what these proposals were about. The original intended usage was for Ada code to directly control the device either in bare metal mode or as part of a driver. Some background on how we got here might be useful. With Heartbleed we were talking about how people used C instead of Ada to write these critical libraries. I pointed out that Ada (sadly) wasn't suitable because C code runs on far more targets than Ada code does and others also pointed out that the C programmers would likely not use Ada anyway due to the software engineering nature of Ada. I suggested there was a place for a new language (my hypothetical Oberon-14) which implemented basic Wirth style functionality with some core Ada style concepts added on and which would be much more "hackable" than Ada but be more type safe than C. The idea was you would get C level functionality but in a type safe(r) language and which would be more likely to be experimented with by C programmers than Ada would be. When discussing the removal of C style masks in Oberon-14 and replacing them with bitfield records, I realised (when writing bare metal or device driver code in this new language) you would need the ability to perform multiple simultaneous bitfield updates while preserving the other existing bitfields in the record. I asked if something like that would be useful for Ada along with a suggested syntax (which was too Pascal like for Randy :-)) and that resulted in the discussion we have just had. Some of the proposed Ada syntax would be useful as well in a more general purpose role which had nothing to do with device registers. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world