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: Ada-Comment proposals (version 3) Date: Sun, 13 Jul 2014 23:45:49 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Sun, 13 Jul 2014 23:45:49 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="9030"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/hH/1lAZf4Di1fHH19G48msZUDQMkA5+I=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:l32nTRlsu6XrhoVB+Wh67evMato= Xref: news.eternal-september.org comp.lang.ada:20922 Date: 2014-07-13T23:45:49+00:00 List-Id: On 2014-07-13, Niklas Holsti wrote: > On 14-07-13 21:16 , Simon Clubley wrote: >> On 2014-07-13, Niklas Holsti wrote: >>> This brings to mind an interesting question: if the processor has some >>> fully atomic read-modify-write instructions, and the semantics of one of >>> these instructions matches the way the record variable is updated with a >>> partial aggregate, is the compiler allowed to use that read-modify-write >>> instruction? I don't know if such instructions always work with >>> memory-mapped peripheral registers -- for example, their timing in terms >>> of clocks between the read and the write may be different. >>> >> >> We would have to be _very_ careful here that we didn't introduce >> behaviour which could be platform specific. > > I should have been clearer in my comment -- I did not really mean that > this question should be added to this Ada-Comment, rather I meant to ask > if someone knows of examples of peripheral registers for which > read-modify-write instructions do not work. > Don't worry. I didn't think you were suggesting such a thing. :-) >> For example, we would not want people to write code which didn't >> consider what happens during an interrupt simply because that wasn't >> an issue on the original platform due to the generated code emitted >> by the compiler. > > Does this mean that you want to forbid Ada compilers from using > read-modify-write instructions? > To be honest, it was just an instinctive reaction which was more stronger than intended. Along with my preference for type safe languages, I also have a dislike for code generators which save 0.01% of runtime by doing some "clever" code generation trick and introduces platform specific behaviour as a result. I would be more tolerant of these things in Ada than in some other languages because I assume the type of person who uses Ada would be disciplined enough to write code which doesn't depend on specific compiler code generation behaviour. Even then, such a person can be caught out as the current ldr/ldrb and str/strb issues prove. > It is always possible to write platform-specific code, intentionally or > accidentally. In particular, the execution timing and therefore the > locations of preemptions and interrupts is platform specific. For > example, a shared but unprotected variable may work reliably on one > platform but fail due to race conditions on another. It can even succeed or fail on the same platform, depending on whether, for example, you have instruction and/or data caching turned on. > Therefore, I would > let the compiler use read-modify-write instructions if it wants to, and > as long as the ARM is obeyed. I don't see it as an important problem > that this would make the some updates fully atomic on some platforms, > while the same source code result in a non-atomic update on another > platform. > For Ada, I'm going to agree with you after having thought about it. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world