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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,571930b4ff0bc1ee X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-13 16:20:07 PST Newsgroups: comp.lang.ada Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!feeder.qis.net!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!bobduff From: Robert A Duff Subject: Re: Compile time executed functions Sender: bobduff@world.std.com (Robert A Duff) Message-ID: Date: Fri, 13 Apr 2001 23:18:33 GMT References: <3AC03CCE.70E3C2D5@mida.se> <3AC192D0.B1E48088@mida.se> <3AC2F5B6.AB04D238@mida.se> <3ACC1985.7CB6D9E8@mida.se> Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: supernews.google.com comp.lang.ada:6879 Date: 2001-04-13T23:18:33+00:00 List-Id: Mats Karlssohn writes: > Robert A Duff wrote: > > > > Mats Karlssohn writes: > > > > > Maybe you could see my proposed pragma as a representation pragma > > > for code then ? > > > > OK, but only as a hint. Rep pragmas or clauses for data can be tested, > > because you can Unchecked_Convert the data, and see if it's represented > > the way you asked. But how do you test a rep pragma for code? For > > example, how can you write an Ada program that behaves differently > > depending on whether pragma Inline was obeyed? No fair looking at the > > generated code. > > How to check it... there should't be more than initialize data left > at the place the function was called and since the function is not > (at least in my case) called from anywhee else the body shoule _not_ > be included in the output. When writing the previous sentence I > really felt thah my english isn't what it needs to be to discuss > really complicated matters, so maybe I didn't understand your point ? You seem to be saying "look at the generated code" to see if the compiler obeyed your pragma. But that's not meaningful in a formal language-definition sense. > As for the test for inlined code... hmmm, I guess it'd be kind of > hard. Right, and the same is true for any other pragma that (pretends to) require something about the generated code. > > > This leads me to another thing that I've sometimes have found annoy�ng: > > > Why isn't it required by the language that there should be a n option > > > to force the compiler to tell you wich pragma;s it cant obey ? > > > I just hate auditing machine code just to check that the compiler > > > hasn't generated silly code. Although I must admit that this stuff has > > > only occured a few times during the past 7 years. > > > > But how would you know if *that* option were obeyed? Suppose the > > compiler says "yes, I inlined your function", how do you know if it's > > lying? You still have to inspect the generated code. > > Well, until proven otherwise I trust the compiler vendor (a trust > that have proven false quite often), so if such an option was > availible I'd trust it (on my own projects, clients may have other > ideas) until I suspect that it lies, then som investigation is > needed. It would be useful to have a compiler option that warns you whenever you asked for inlining (or other code-generation-specific pragmas) and it didn't obey. I'm just saying it's not really appropriate as a requirement in the RM, because as a requirement, it's meaningless -- it can't be formally tested. So ask your compiler vendor for such a feature. > > In practise, though, compilers do give this kind of information. > > Eg, the documentation will normally tell you "we obey pragma Inline in > > the following circumstances...". > > Yes, aside from it beeing inconvenient to have to look for such > things in the documentation, I have found that the documentation > is often buried in some archive somwhere or just missing :( :-( - Bob