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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,319ef0454c7765d5 X-Google-Attributes: gid103376,public From: kevq@banana.demon.co.uk (Kevin F. Quinn) Subject: Re: Why no exception hierarchy ? Date: 1995/03/29 Message-ID: <19950329.215548.46@banana.demon.co.uk>#1/1 X-Deja-AN: 100721935 sender: news@demon.co.uk (Usenet Administration) x-nntp-posting-host: banana.demon.co.uk references: <3ksv4s$f9e@news.uni-c.dk> <1995Mar28.115614.9511@eisner> organization: The Banana Arc reply-to: kevq@banana.demon.co.uk newsgroups: comp.lang.ada Date: 1995-03-29T00:00:00+00:00 List-Id: In article <1995Mar28.115614.9511@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) wrote: > In article , ka@socrates.hr.att.com (Kenneth Almquist) writes: > > kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) writes: > >> For an address representation clause, which might be used to access hardware, > >> optimizing out dead assignments seems quite inappropriate. Is there no > >> Ada83 method of avoiding such an optimization for such objects? > > > > Pragma Atomic will suppress these optimizations. > > I find no reference to Pragma Atomic in the manual for DEC Ada, which > is supposedly validated against the Ada83 standard. Pragma Atomic is not required by Ada83. And there is no equivalent that is. Try looking under Pragma Volatile instead - XDAda certainly has it so DEC Ada might, given that they have the same front-end. Couldn't tell you for sure off-hand though - I have this nagging feeling that it's an XD enhancement. Note that GNAT has both Atomic and Volatile, and that they achieve different goals; Atomic forces reads and writes to an object to be indivisible, and Volatile forces all access to be direct to/from memory. Volatile is the one that stops the optimisations you're worrying about. I think some Ada83 compilers implement a pragma Atomic that does the job of pragma Volatile; but I'm not sure. I would have thought that anything with an address clause would not be optimised in such a way, and that the compiler would make no assumptions as to its stability. The '95 LRM says this explicitly: 13.3.19 If the Address if an object is specified, or it is imported or exported, then the implementation should not perform optimizations based on assumptions of no aliases. Note that this means that you could use pragma Export, for example, to achieve the desired effect. Just because you export something doesn't mean you actually have to use it outside the Ada environment :) You should check this with the '83 LRM et. al. though. Try writing something like: with System; procedure ResetKevsASIC is Kevs_Command_Register : Integer; for Kevs_Command_Register use at System.To_Address(16#101010#); begin Kevs_Command_Register := 16#0000#; Kevs_Command_Register := 16#0123#; end Test; and compile with assembly listing switched on (ADA/LIS/MAC ) and take a peek at the output. If you see two writes to the relevant location, you should be alright. If you just see one (where the value is 16#1234#) then you know that you need something else. I'd be surprised though... (horrified might be a better adjective :) ) pragma Volatile of course allows you to stop those optimisations from occurring on data that isn't located specifically with an address clause. That's the important difference. P.S. Forgive me if the System.To_Address bit is wrong; I don't have DEC Ada to hand here. You might need to use UnChecked_Conversion from Integer to System.Address. -- Kevin F. Quinn * "No-one ever made any money out of good kevq@banana.demon.co.uk * looks and charm." kevq@cix.compulink.co.uk * "You obviously haven't met Lady Hamilton..." Compu$erve: 100025,1525 * Blackadder III