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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c21db05aee31ddfc X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wn14feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Direct Quote from the RM Reply-To: anon@anon.org (anon) References: X-Newsreader: IBM NewsReader/2 2.0 Message-ID: Date: Sun, 18 Nov 2007 09:43:08 GMT NNTP-Posting-Host: 12.64.134.88 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1195378988 12.64.134.88 (Sun, 18 Nov 2007 09:43:08 GMT) NNTP-Posting-Date: Sun, 18 Nov 2007 09:43:08 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:18476 Date: 2007-11-18T09:43:08+00:00 List-Id: Paragraph of 10 from Design Goal. 10 No language can avoid the problem of efficiency. Languages that require over-elaborate compilers, or that lead to the inefficient use of storage or execution time, force these inefficiencies on all machines and on all programs. Every construct of the language was examined in the light of present implementation techniques. Any proposed construct whose implementation was unclear or that required excessive machine resources was rejected. "Any proposed construct whose implementation was unclear or that required excessive machine resources was rejected." That statement suggest that "gnatmake" in using requires 5 complete programs to be loaded at one time just to compile a single routine or package when 3 to 3 will do should be rejected! gnatmake => use in core 5 program. gnat compile => uses 4 program 3 in core. gcc -c => uses 3 in core program (gcc which calls gnat1 then calls as). So using "gcc -c" is the best and is worst "gnatmake". Of course, this can become excessive in execution time if the GNAT system is compiled with "-fstack-check". Defaulting the "-fstack-check" which can not at the movement be remove by the "pragma Suppress (Storage_Check);". Leads "to the inefficient use of storage or execution time, force these inefficiencies on all machines and on all programs." So it too must be rejected! And there are more places in the RM then just this part. But most people I think had skip reading the Intro section. And as for parallel. The way I write code allows me to compile in parallel even though that development design is not support in the RM. But I have learned a few trick alone the way that allows this. Note: Parallel => I mean the number of complete compilers loaded and running in core (no swapper file usage) at the same time. That is on the old single-cpu system it was called Concurrency, but with two/four/+ cpus that is called Parallel. For example on a system with 4G with 1G given to the OS/(user interface), that leave 3G or about 3_000 in core compilers if the gcc, gnat1, as, and file/package take less than 1MB in size or 1_500 in core compilers if they require 2MB. And "gnatmake" does not use the Ada Task and to insure "Safety and Security" of the code will only allow the compiling of one package at a time because of the design of Ada structure. (As someone pointed out). This is defined also in the RM if you look. Note: The "make -jN" or "gnatmake -jN" does not allow multiple compilers to be loaded in core at the same time. In , Simon Wright writes: >anon@anon.org (anon) writes: > >> 10 No language can avoid the problem of efficiency. Languages >> that require over-elaborate compilers, or that lead to the >> inefficient use of storage or execution time, force these >> inefficiencies on all machines and on all programs. > >This is the only part of the text you quote that addresses the >compilation environment. And what it says is, the design of the Ada >language is such that it does not require over-elaborate compilers, >and that (once compiled) a program doesn't have to be inefficient. > >But there's nothing there that says the compiler itself has to be >efficient! of course inefficient compilers will be unpopular, but >that's quite a different matter.