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=ham 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-03-29 00:47:01 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!news.iac.net!news-out.cwix.com!newsfeed.cwix.com!news.tele.dk!194.213.69.151!news.algonet.se!algonet!pepsi.tninet.se!not-for-mail From: Mats Karlssohn Newsgroups: comp.lang.ada Subject: Re: Compile time executed functions Date: Thu, 29 Mar 2001 10:43:34 +0200 Organization: MIDA Systemutveckling AB Message-ID: <3AC2F5B6.AB04D238@mida.se> References: <3AC03CCE.70E3C2D5@mida.se> <3AC192D0.B1E48088@mida.se> NNTP-Posting-Host: sdu40-250.ppp.algonet.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: cubacola.tninet.se 985855429 27065 195.163.250.40 (29 Mar 2001 08:43:49 GMT) X-Complaints-To: abuse@algo.net NNTP-Posting-Date: 29 Mar 2001 08:43:49 GMT X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:6197 Date: 2001-03-29T08:43:49+00:00 List-Id: Robert A Duff wrote: > > Mats Karlssohn writes: > > > I agree on the location issue (RAM vs. ROM), but the control over how > > and when the code is executed is already a language issue I think. > > We already have generics in the language wich controls how code should > > be generated. > > I don't think so. Some compilers generate a separate piece of code for %< OK, understood, let's not waste time on that issue. > >...We also have pragma Inline and representation pragmas > > that controls the layout of code and data. > > Pragma Inline doesn't *require* anything (it's just a hint). > Representation pragmas and clauses specify data layout, but not code > layout. Maybe you could see my proposed pragma as a representation pragma for code then ? > >... So why couldn't we also > > have pragma(s) to _hint_ to the compiler that this piece of code is > > only used for initializing constants and is therefore NOT needed in > > the runtime image if the compiler executes it. > > Oh, hint? Like pragma Inline? Well, maybe. But why shouldn't the > compiler just do the optimization? I mean, if I write "2 + 2", I want > the compiler to generate "4" in the machine code. Likewise, if I have a > function call, and the function returns "2 + 2", and the function is > inlined, I want the compiler to do the same. I don't think any hint is > needed here. And anyway, the compiler can always ignore hints. 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. %< > Some compilers are capable of guessing when inlining is a good idea, > even *without* pragma Inline. If the guesses are good, then that's > better than using the pragma. Hmmm, actually, no. I want to be able to control what goes where and how, in wich form it goes there. But I want to know the compilers opinion on my chioses to. Perhaps I should state it like: When I have said someting to the compiler, like a representation pragma or pragma Inline, the compiler shall damn well do as I tell it, it may Warn or cause an error, but when it produces output it shall be of the form I've asked. As for stuff I havn't said enything about it should just do what it can. %< > Compilers already do some of what you want (if you inline). And adding > hint pragmas won't make them do better. An open checkbook, on the other > hand, might cause a compiler writer to do certain table lookups (or > whatever it is you wanted) at compile time. ;-) Obviously my experience with different compilers is not great enough, I havn't come across one. Would you care to name one ? -- Mats Karlssohn, developer mailto:mats@mida.se Mida Systemutveckling AB http://www.mida.se Box 64, S-732 22 ARBOGA, SWEDEN Phone: +46-(0)589-89808 Fax: +46-(0)589-89809