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,FORGED_YAHOO_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,aba1514f4a1fc450 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.66.74.41 with SMTP id q9mr1782507pav.41.1345989958193; Sun, 26 Aug 2012 07:05:58 -0700 (PDT) Path: t10ni62970945pbh.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.snarked.org!newsfeed.news.ucla.edu!ihnp4.UCSD.Edu!nntp.ucr.edu!usenet.stanford.edu!postnews.google.com!d9g2000vbf.googlegroups.com!not-for-mail From: Michael S Newsgroups: comp.arch,comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 05:43:05 -0700 (PDT) Organization: http://groups.google.com Message-ID: <7399f70e-ffca-4517-8b8d-532d09539a85@d9g2000vbf.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: 62.219.244.2 Mime-Version: 1.0 X-Trace: posting.google.com 1345639718 21699 127.0.0.1 (22 Aug 2012 12:48:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 22 Aug 2012 12:48:38 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d9g2000vbf.googlegroups.com; posting-host=62.219.244.2; posting-account=yxhsVAkAAAAd1ExczpaZ2Ptm4WnXJOwS User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0,gzip(gfe) X-Received-Bytes: 5063 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-08-22T05:43:05-07:00 List-Id: On Aug 22, 1:54=A0pm, Niklas Holsti wrote: > On 12-08-22 12:29 , Michael S wrote: > > > > > 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 =A0"checked > > Ada" is still much closer in # features to the "full Ada" than to > > SPARK. > > =A0... > >>> Q. > >>> Do people actually use the "second" Ada language > > (i.e. "checked Ada") > > >>> for really big and > >>> really complex application programs? > > >> It is certainly possible. For example, the main SPARK tools are writte= n > >> 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 understand. Another term, currently popular, is "enterprise application= s". Not exactly. Take, for example, word processor or spreadsheet or advanced game. They are RBaRCAP but I would not call them "enterprise applications". > > I have no personal knowledge of terrestrial RBaRCAPs. I have experience > of on-board SW in spacecraft, which may not qualify as "really big", > except in terms of the ratio of program size to available memory size, > but it is certainly complex and handles many inputs as a long-running > service. I've never used Unchecked_Deallocation in such programs, and > Unchecked_Conversion only for safe conversions. > This sort of programs are what I called in my original post "relatively simple embedded software" (RSES). We write plenty of such stuff in C for embedded targets and in C++ for general-purpose computers. Some of those "simple" programs are measured in hundreds KLOCs. And yes, we, too, never use free() on embedded targets and use free()/delete() on general-purpose target only during program shutdown phase. I'd say, the biggest difference between RSESs and RBaRCAPs is that in RSES maximal load as well as minimal available resources are know up front. RBaRCAP, on the other hand, should, at least to a certain degree, handle increased loads and decreased resources by gracefully degrading the quality of service (i.e. typically response time). It's also desirable for RBaRCAP to supply better than normal quality of service when the loads are low or resources are high. Restating the same from slightly different angle, RSES are [hard or soft] real-time while RBaRCAP are ether non-real-time (if you believe that true non-real-time still exists) or, more realistically, extremely soft real time. > -- > Niklas Holsti > Tidorum Ltd > niklas holsti tidorum fi > =A0 =A0 =A0 . =A0 =A0 =A0@ =A0 =A0 =A0 .