Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: Andy Walker Newsgroups: comp.compilers Subject: Re: Is multi-level function return possible? Date: Wed, 26 Mar 2014 12:16:29 +0000 Organization: Not very much Lines: 84 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-03-061@comp.compilers> References: <14-03-020@comp.compilers> <14-03-022@comp.compilers> <14-03-025@comp.compilers> <14-03-030@comp.compilers> <14-03-044@comp.compilers> <14-03-046@comp.compilers> <14-03-047@comp.compilers> <14-03-048@comp.compilers> <14-03-053@comp.compilers> <14-03-057@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1395851803 32983 2001:470:1f07:1126:0:676f:7373:6970 (26 Mar 2014 16:36:43 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 26 Mar 2014 16:36:43 +0000 (UTC) Keywords: C, history, comment Posted-Date: 26 Mar 2014 12:36:43 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1183 On 24/03/14 17:06, Anton Ertl wrote: >>> Keeping a feature may just be loyalty, but adding it back after it had >>> been removed says something about what the language designer thought >>> about the usefulness of the feature. >> Well, it certainly implies that the designer [or the committee!] >> is admitting to a mistake. > In the case of the C branch of the Algol family, I very much doubt > that the designers see it that way. B had a reduced feature set not > because the language designer did not like the features they removed, > but because B had to work on a very small machine. They added some > features back in C, which ran on larger machines. But B and C are different languages, with differing design aims and criteria. Having a feature in C that was absent from B is not the same as adding to C a feature that had previously been removed. K&R C was not B Mk 2, but a new language with inputs [conscious or unconscious] from many languages, including (B)(CPL) and Algol 68. OTOH, modern versions of C have several features missing from K&R C but present in [eg] Algol. Presumably the committee at least feels that their omission had been a mistake; I don't know whether K&R felt the same way. > The designers of > C++, Java and C# are different persons than the designers of B and C, > so if they add a feature, why would they see it as "admitting to a > mistake"? Again, these are different languages and it's one thing to design a new language with new aims [which may include being leaner and meaner than earlier languages], and quite another to revise a language to include features previously dropped. >> [...] >>> "Parameters have a run-time cost": So has access to non-local >>> variables. >> That depends on the machine and compiler. The first compiler I >> used extensively [for Atlas Autocode] accessed variables at lexical >> depth N by offsetting from register N, so all variables were accessed >> at exactly the same cost. > So this compiler maintained a display in the registers. The costs here are: > 1) Accessing the variable in memory, whereas a parameter can be passed > in a register and accessed in a register. As above, it depends on the machine and compiler. On Atlas, the registers were 24 bits whereas most parameters were 48 bits. Integers were usually stored as denormalised reals [ie, also 48 bits] because multiplications and divisions had to be done in the accumulator anyway [and there were only very limited shift instructions]. > 2) Maintaining the display. AFAIK it turned out that maintaining the > display is more costly in typical uses than the access cost it saves, > so displays fell out of favour. Well, it's one instruction on entry to a procedure and one on exit, so it's not exactly expensive. It's certainly cheaper than passing several parameters around all the time, so the overall balance depends on how many and how often intermediate variables are used. I thought that displays fell out of favour more because of a paucity of registers? Not many minis and micros had the 100+ available to the general user on Atlas. But in any case, you are again looking only at the cost in terms of computing resources, and not at the programmer's view. The notions of "literate" or "top-down" programming may have fallen out of favour, but in the pre-Unix era [after which the emphasis switched to tools and to libraries] it was natural to write programs in the form of nested procedures, each of which was expanded in turn as the program developed. Functions also were naturally written within the procedures where they were used, and variables were declared at the most natural level for their life-times. It's not impossible to write C programs that way, but it's much harder than the equivalent [eg] Pascal. > [We do forget that Ritchie's C compiler ran in 12K bytes of RAM, > two passes plus assembler, and generated quite respectable code > for the PDP-11. -John] 12K? Luxury. Why, in my day, .... But some early compilers ran in ridiculously small computers by modern standards. -- Andy Walker, Nottingham. [C was influenced by PL/I. C++ is where the Algol68 got mixed in, and some of the C++ stuff was backported into C. -John]