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-Thread: 103376,aba1514f4a1fc450 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.88.133 with SMTP id bg5mr1558277pab.11.1345631410808; Wed, 22 Aug 2012 03:30:10 -0700 (PDT) Path: a5ni2pbv.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 03:28:24 -0700 (PDT) Organization: http://groups.google.com Message-ID: <741f71aa-deb9-49eb-8d33-1f6d5bebdacd@googlegroups.com> References: <5021874F.1747D0BF@sonic.net> <1e1tf9-0kp2.ln1@ntp6.tmsw.no> <46f19bfc-930e-4f06-b5a6-c60f39cfda0c@p14g2000yqk.googlegroups.com> <077b12f6-1196-4b5c-bbdb-04291b1ae616@q22g2000vbx.googlegroups.com> <589825d2-d998-456a-9c37-c8ae13e1e7bc@e29g2000vbm.googlegroups.com> <4c83f0f4-30e2-44bd-8b73-ada05de9322b@q22g2000vbx.googlegroups.com> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 X-Trace: posting.google.com 1345631410 3578 127.0.0.1 (22 Aug 2012 10:30:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 22 Aug 2012 10:30:10 +0000 (UTC) In-Reply-To: <4c83f0f4-30e2-44bd-8b73-ada05de9322b@q22g2000vbx.googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-08-22T03:28:24-07:00 List-Id: Michael S a wrote on comp.lang.ada: > "not possible to clobber arbitrary memory locations" is probably good > enough definition of what I consider "safe" computer language. [...] > So let's do not call it "two languages". Let's talk about "full Ada" > and "checked Ada" where "checked Ada" is a subset in which "it is not > possible to clobber arbitrary memory locations". Hopefully "checked > Ada" is still much closer in # features to the "full Ada" than to > SPARK. Yes. SPARK imposes a lot of restrictions which in turn exclude most of the standard run-time library. >>> Q. >>> Do people actually use the "second" Ada language for really big >>> and really complex application programs? >> >> It is certainly possible. For example, the main SPARK tools are >> written in SPARK. > > Well, so let's define "really big and really complex application > programs" (RBaRCAP) as something that not only executes complex > processing, but also handles multiple tightly or loosely related > inputs for hours/days/weeks/months either as long-running service or > as an interactive [GUI] application. > Then compilers or lint-like tools are not RBaRCAP. I work on such an application: 2 million lines of code, multiple processes running 24x7 on multiple machines, mission-critical, multiple GUIs. This application uses almost every feature of Ada and then some more :) (e.g. we've patched the compiler and run-time library so that every exception dumps core for post-analysis before being handled the normal way). SPARK would be unsuitable for this application but full Ada is *eminently* suitable. Like I said we use almost every feature Ada has to offer, from high- level tasks and protected objects to the lowest level of bit manipulation in memory addresses (e.g. in a tree structure we align all objects on 8 bytes; the 3 low-order bits of all addresses are therefore zero and we use some of them to store booleans). We also use custom memory pools that call mprotect(2). But these "scary" bits are few, far between and well isolated; they must represent less than 0.5% of our code base (still, 10 kSLOC or so...). It is important to note that we could do without those low-level tricks; they exist only for performance reasons or to detect and diagnose rare errors. -- Ludovic Brenta. The standard-setters boost roadmaps.