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-23 10:57:33 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!swrinde!pipex!uunet!psinntp!ss3!mjmeie From: mjmeie@ss3.magec.com (Michael J. Meier) Subject: Re: Ada Portability... NOT! Message-ID: Organization: Magnavox Electronics Systems Company X-Newsreader: TIN [version 1.2 PL2] References: <199411182104.PAA04854@mail.cs.utexas.edu> <3alalm$9di@gnat.cs.nyu.edu> Date: Wed, 23 Nov 1994 12:49:17 GMT Date: 1994-11-23T12:49:17+00:00 List-Id: Keith Thompson (kst@alsys.com) wrote: : 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. : 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? It all looks like the start of something very useful. Of course, we'd have to define a different pragma. But, the idea of being able to construct reasonably portable rep-specs seems like it should be do-able. While Ada 94 (95?) seems to go part way, it seems there should be some means along the lines that you describe that would support portability. After all, it seems that we always seem to do the same transformations when we port from VAX to 680x0 to x86 to various flavors of RISC (to VLIW?), whether in Ada or C/C++. So why not support these transformations directly in the language (or at least the language implementation). As a user of Alsys products (and possible future user of Verdix/Rational products), I'd be especially interested in hearing what these companies might do to support this concept. Of course, I recognize that GNAT is targeted to a non-embedded market so that it would have less need to be concerned with such extensions.