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.72.73 with SMTP id b9mr1657409pav.9.1345990018908; Sun, 26 Aug 2012 07:06:58 -0700 (PDT) Path: a8ni56467944pbd.1!nntp.google.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!l9g2000vbj.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 06:20:48 -0700 (PDT) Organization: http://groups.google.com Message-ID: <00dcc463-e9d2-490d-93bc-4ec2084522db@l9g2000vbj.googlegroups.com> References: <5021874F.1747D0BF@sonic.net> <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> <7399f70e-ffca-4517-8b8d-532d09539a85@d9g2000vbf.googlegroups.com> NNTP-Posting-Host: 62.219.244.2 Mime-Version: 1.0 X-Trace: posting.google.com 1345641648 8662 127.0.0.1 (22 Aug 2012 13:20:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 22 Aug 2012 13:20:48 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l9g2000vbj.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) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-08-22T06:20:48-07:00 List-Id: On Aug 22, 3:43=A0pm, Michael S wrote: > 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"checke= d > > > 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 writ= ten > > >> 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 applicati= ons". > > 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, =A0handle increased loads and =A0decreased resources by gracefull= y > 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. > Oh, I forgot another difference, likely even more important for the question at hand: RBaRCAPs are expected to be "nice" or "good citizen", RSESs do not. That is, resources consumption by well-behaving RBaRCAP is dynamic both ways - not only grows when the load grows, but also shrinks when the load shrinks.