Re: Have the Itanium critics all been proven wrong?

[Michael S <already5chosen@yahoo.com>]

On Aug 22, 3:43 pm, Michael S <already5cho...@yahoo.com> wrote:
> On Aug 22, 1:54 pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
> 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  "checked
> > > Ada" is still much closer in # features to the "full Ada" than to
> > > SPARK.
>
> >  ...
> > >>> 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 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 understand. Another term, currently popular, is "enterprise applications".
>
> 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.
>

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.