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: border1.nntp.ams.giganews.com!nntp.giganews.com!news.roellig-ltd.de!open-news-network.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Oberon and Wirthian languages Date: Thu, 24 Apr 2014 23:11:54 +0300 Organization: Tidorum Ltd Message-ID: References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> <%J32v.70539$kp1.45343@fx14.iad> <8761m535e4.fsf_-_@ludovic-brenta.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net qIdRZfile7ephwOizOGtDw5cAVnecHaFxK/eOKN3KLtLM061Fe Cancel-Lock: sha1:H8WOyIf13qk9sukRoftZvPDfWPo= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 In-Reply-To: Xref: number.nntp.dca.giganews.com comp.lang.ada:186075 Date: 2014-04-24T23:11:54+03:00 List-Id: On 14-04-24 21:51 , Simon Clubley wrote: > On 2014-04-24, Niklas Holsti wrote: >> On 14-04-24 03:20 , Simon Clubley wrote: >>> On 2014-04-23, Simon Wright wrote: >>>> >>>> But hardware isn't (usually) elegant! If what the hardware designer >>>> wants is for you to read the register, change the values you need to in >>>> the local copy, then write the modified value back, that's what the code >>>> should do, surely, without relying on compiler magic with obscure >>>> pragmas to make it happen? (Ada's pragma Atomic is quite obscure enough >>>> already!) >>> >>> The problem is the compiler does this automatically when you use C style >>> masks, >> >> Not really so, for the most common forms of C. AIUI, before C 2011 there >> was no way in C to declare that a particular variable or type should be >> "atomic" in the sense of being read and written indivisibly; this was >> only possible by using the predefined integer type sig_atomic_t. >> > > Sorry, I probably wasn't clear enough. Nor was I, see below... > What I meant was that if you write (in C) something like: > > device_register = (device_register & mask1) | mask2; > > while accessing a volatile register then gcc generates exactly one read > and exactly one write and the size of the access is the size of the > device_register declaration. > > This is true at least on ARM and I have never seen any complaints about > it being untrue on other architectures. Gcc usually does the right thing, which is good. But gcc on ARM has no reason to do otherwise, because the "load;and;or;store" instruction sequence is also the shortest and fastest implementation of this C statement. IIRC, your original question was if the Ada RM *guarantees* single load/store instructions; my point above was that the C standard (pre 2011) guarantees it only for the type sig_atomic_t. To be very precise, C 1999 says only that sig_atomic_t "can be accessed as an atomic entity, even in the presence of asynchronous interrupts". There is no mention of single load/store instructions. In principle, a C compiler could implement read (write) of sig_atomic_t by several load (store) instructions, executed with interrupts disabled. But I don't know of any C compiler that does that. > That's interesting. I wonder if this is a case of gcc implementing the > "expected" behaviour and there's now a large set of code which relies on > this "expected" behaviour. That's "Situation Normal" for C :-). For this case (accessing device registers), it is usually good enough because programs that depend on it are not expected to work on different machines without rewriting these parts of the program. >> For example, assume that the variables A and B are of a record type with >> the components x and y and some more components, Then, instead of the >> three statements >> >> B := A; >> B.x := 42; >> B.y := False; >> >> we could say something like >> >> B := (A overriding x => 42, y => False); >> >> (The "overriding" keyword is a bit misleading here, because it implies >> that the left-hand operand (A) overrides the right-hand aggregate, while >> the opposite should happen. Oh well.) >> > > Although I agree the syntax needs changing, I do like the general > idea behind this suggestion. Thanks. Perhaps the syntax (A and then x => 42, y => False) is a little better. I also considered using "others" in a new way: (x => 42, y => False, others => all A) or (x => 42, y => False, all others => A) but for some reason I feel that "A" should come first, and the changed components after. > It will be interesting to see if Randy and company have any comments on > this syntax. Overload resolution may be an issue. I think it could be based purely on the "initial values" part ("A" in the examples above) and could ignore the named component associations. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .