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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c70bb16b3813e0fd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-21 15:56:06 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!xlink.net!news.fhg.de!berlin.fhg.de!isst.fhg.de!hahn.informatik.hu-berlin.de!zib-berlin.de!prise.nz.dlr.de!news.dfn.de!swiss.ans.net!howland.reston.ans.net!usc!crash!telesoft!kst From: kst@alsys.com (Keith Thompson) Subject: Re: Ada Portability... NOT! Message-ID: Originator: kst@pulsar Sender: news@alsys.com (USENET News Admin @flash) Organization: Alsys, San Diego, CA, USA References: <199411182104.PAA04854@mail.cs.utexas.edu> <3alalm$9di@gnat.cs.nyu.edu> Date: Mon, 21 Nov 1994 23:56:06 GMT Date: 1994-11-21T23:56:06+00:00 List-Id: In <3alalm$9di@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes: > It is probably a reasonable implementation choice to restrict reals to be > on a properly aligned boundary, since it is an annoying amount of fiddling > to deal with unaligned floating-point stuff, and yes, of course most > processors *do* require floating-point values to be aligned. When you use > rep clauses you are definitely wandering into the area of implementation > dependent non-portable constructs (most appropriately, since one of the > functions of rep clauses is to deal with special target dependent > requirements). > > There is certainly no *requirement* that an implementation reject these > declarations on a RISC machine, the code generator could generate the > code to fiddle around and copy the value. Is it a good idea to do this > behind the scenes? Not clear. Suppose a user just casually wrote rep > clauses to pack the data in a way that worked fine on one machine but > generated long inefficient sequences of code on another, do you want > to be allowed or stopped? Either answer is possible. I've just thought of a couple of ways an implementation could handle this that might have some chance of satisfying everybody. 1. By default, provide a "reasonable" level of support for representation clauses. For example, one might allow a floating-point component to be aligned on any boundary that allows it to be accessed with a single instruction (4 or 8 bytes). Alignments that require fancier access code (e.g,. loading the value a byte at a time into a register or using bit-shifting) would be rejected -- unless a special pragma is given to allow it. It occurs to me that such a pragma already exists: pragma Pack. For example: type Rec1 is record ... F: Float; end record; for Rec1 use record ... F at 1 range 0 .. Float'Size - 1; -- byte-aligned, rejected end record; type Rec2 is record ... F: Float; end record; pragma Pack(Rec2); -- permit tighter packing for Rec2 use record ... F at 1 range 0 .. Float'Size - 1; -- byte-aligned, permitted end record; One could argue that this is an abuse of the semantics of pragma Pack, but I *think* the current definition is vague enough to allow it. 2. Similar to the above, but the compiler issues a warning (or informational message) for representations that require fancy access code. The addition of a pragma Pack might suppress the warning message, reduce its severity from warning to informational, or whatever. I don't know of any existing compiler that does this, including ones I've worked on. I've also often thought it would be nice if pragma Pack took an optional second argument to specify how enthusiastically the compiler should perform packing. For example, pragma Pack(Some_Type) might ask the compiler to pack to byte alignment, while pragma Pack(Some_Type, Dammit), might ask it to pack to bit alignment. (Note that an implementation may not legally add arguments to an existing language-defined pragma.) Whaddya think? -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 /user/kst/.signature: I/O error (core dumped)