Re: Have the Itanium critics all been proven wrong?

Re: Have the Itanium critics all been proven wrong?

[Niklas Holsti]

(I'm cross-posting (I hope) this to comp.lang.ada, since there are
questions on how Ada is used.)

On 12-08-21 16:00 , Michael S wrote:
> On Aug 21, 1:35 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
   ...
>> And where any dynamic allocation is not good enough, the SPARK subset
>> currently mandates pure static allocation (and fixed size stack objects)
>> to allow formal proof of storage requirements. Harsh, but I'd rather not
>> see a segfault in my car. These restrictions may be relaxed if proof
>> technologies improve, but I wouldn't hold my breath...
> 
> SPARK is an Ada analogue of MISRA C?

Not really, as I understand them. MISRA C is a bunch of rules that are
supposed to define a safer subset of C, and for which rule violations
can (mostly?) be detected automatically. But I don't think that the
MISRA rules automatically make a C program much more amenable to static
analysis or formal proof.

SPARK is a Ada, plus annotations embedded in the Ada source, where the
goal is to allow automatic proof that the program is safe and correct
per some formal criteria expressed in the annotations and elsewhere. For
example, one can prove that all run-time checks in the Ada program will
succeed and will not raise exceptions. Limitations in the SPARK proof
tools mean that only a subset of Ada can be handled by the tools.
Moreover, the proofs often need some manual guidance.

> I guess, without reading a single
> line of spec, I already don't like it .

At present, SPARK handles a rather small subset of Ada that forbids some
major features, for example access types (pointers). I would use SPARK
only for very critical code. However, it is possible to write parts of
an application in SPARK, and mix in full Ada code for the rest, "hiding"
it from the SPARK tools. Of course, the SPARK proof then formally covers
only the SPARK part.

> So, I have more generic question about Ada state of the art.
> 
> Preface:
> According to my understanding, one of the Ada objectives was creating
> two languages in one.
> The first language intended primarily for complex embedded software,
> but also suitable for general-purpose system programming.
> The second language intended primarily for big complex application-
> level programming, but is also applicable for relatively simple
> embedded software and for some system programming tasks.

I've been involved wih Ada for a long time, but I don't remember such a
"two languages" thing being discussed. Perhaps it was a topic in the
early language definition stages.

> The second language, at source level, but not necessarily at pragma
> and run-time support level, is a strict subset of the first language.
> There is clear distinction line between the first and second
> languages, drawn around built-in procedures with the names starting
> with unchecked_ and with external procedure calls.
> The first language does not pretend to be "safe". And sorry, I am not
> in the mood of defining exactly what "safe" means.

One can certainly do unsafe or wrong things in Ada, even without using
any "unchecked programming", as it is called. A simple mistake like
using an uninitialized variable can make the program give unpredictable
results. But it is not possible to clobber arbitrary memory locations in
this way; for that, one must use Unchecked_Conversion to generate a wild
pointer. (OK, there are some other low-level ways to generate wild
pointers, too.)

The things called Unchecked_ in Ada are the Unchecked_Conversion
generic, which reinterprets data of one type as being of a different
type, the Unchecked_Deallocation generic, which deallocates heap memory
(just like "free" in C), and the Unchecked_Access attribute, which can
make a pointer value live longer than the object to which it points. All
can cause run-time trouble in obvious ways, but are not enough IMO to
make "two languages".

Oh yes, and the Unchecked_Union pragma, for interfacing with C union
types. But mixed-language programs are more or less completely
"unchecked" anyway.

> The second language is "safe" and, supposedly, very portable.

There are many, many tales that confirm the portability, and my own
experience also agrees.

> 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.

> I mean where covering of 95% of
> 'C' dynamic memory use cases with variable length arrays, storage
> pools etc is not enough and have to handle somehow the remaining 5%.

I think the answer here depends on the kind of data structures used in
the program. My own applications use graph structures with many links
between nodes, and therefore I do use heap memory (and some
Unchecked_Deallocation). Applications that are more array-oriented may
be able to avoid heap.

> According to my understanding, garbage collector implemented by the
> run-time support is the only sane way to handle these last 5% while
> remaining in the envelop of the "second" Ada language.
> So what happens in practice?
> Do people that develop big apps in Ada use "second" language + runtime
> with GC?

As far as I know, the only Ada systems with automatic garbage collection
are those that compile Ada to Java byte-code and run on the JVM. I have
heard that some people have used the Boehm "conservative" GC with Ada,
but I'm not sure if it works reliably (because some Ada compilers play
tricks with array base addresses).

So the answer here is "no", I think; GC is not used much with Ada.
Unfortunately, IMO.

> Or do they opt for unchecked_deallocation() thus, effectively, finding
> themselves in the "first" language, even if they don't use any other
> unchecked_xxx procedure?

Unchecked_Deallocation is used a lot. However, Ada has a class of
"controlled" types with user-defined initialization and finalization
that can be used to automate deallocation by reference counting. Of
course, Ada is not unique in this; C++ has similar means.

But although many Ada programs use some unchecked stuff, the web of
checks in Ada is so dense that even if the unchecked computation creates
an error, the error is usually detected rapidly as an exception.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Have the Itanium critics all been proven wrong?

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> As far as I know, the only Ada systems with automatic garbage collection
> are those that compile Ada to Java byte-code and run on the JVM.

Or .NET.

>...I have
> heard that some people have used the Boehm "conservative" GC with Ada,
> but I'm not sure if it works reliably (because some Ada compilers play
> tricks with array base addresses).

I have used the Boehm GC with Ada compiled with GNAT.  It works.
But I wouldn't use it in a real-time/embedded/safety-critical
program.

Boehm GC doesn't work very well if the amount of memory you use
is a large fraction of the virtual address space.  This is because
of the way "blacklisting" works.  If the GC runs across the value
12345000, which might be a pointer to a heap object, it checks whether
something has been allocated at that address.  If not, it black-lists
that page of virtual memory, which means it refuses to ever allocate
any heap object on that page.  That means 12345000 can never be
mistaken for a pointer.  So large chunks of virtual memory get
black listed.

I had problems with that years ago, on 32-bit machines with heap sizes
in the hundreds of megabytes.  But on a 64-bit machine, it's not a
problem -- nobody can afford enough RAM to make up (say) 10% of
the virtual address space.

Anyway, this isn't Ada specific -- Boehm GC works that way with all
languages.

> Unchecked_Deallocation is used a lot.

Another alternative in Ada is storage pools (sometimes called
"region-based memory management).  Not 100% safe in Ada, but much safer
and much more efficient than Unchecked_Deallocation (in cases where
storage pools are appropriate).

- Bob

Re: Have the Itanium critics all been proven wrong?

[Bill Findlay]

On 22/08/2012 01:58, in article
keb838pn40uf3pq1536e9b3dptgd57h3se@invalid.netcom.com, "Dennis Lee Bieber"
<wlfraed@ix.netcom.com> wrote:

> On Tue, 21 Aug 2012 23:48:29 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following in
> comp.lang.ada:
> 
>> (I'm cross-posting (I hope) this to comp.lang.ada, since there are
>> questions on how Ada is used.)
>> 
>> On 12-08-21 16:00 , Michael S wrote:
> 
>>> Preface:
>>> According to my understanding, one of the Ada objectives was creating
>>> two languages in one.
>>> The first language intended primarily for complex embedded software,
>>> but also suitable for general-purpose system programming.
>>> The second language intended primarily for big complex application-
>>> level programming, but is also applicable for relatively simple
>>> embedded software and for some system programming tasks.
>> 
>> I've been involved wih Ada for a long time, but I don't remember such a
>> "two languages" thing being discussed. Perhaps it was a topic in the
>> early language definition stages.
>> 
> At least during the AJPO period and MIL-STD/1815A, the Ada
> specification was NO SUBSETS and NO SUPERSETS were permitted to call
> themselves Ada. (This doesn't cover optional annexes, just the core
> language).

Yes.  That was enforced rigorously.  But things are different now.
The Restrictions pragma allows the programmer to exclude features that are
considered inappropriate for a particular application.  So it could be said
that Ada now has 2**N subsets, where N is the number of Restrictions
options.  I don't have an exact count, but N is of the order of 50.

Here are the restrictions I impose on my own code:

   pragma Restrictions(Max_Asynchronous_Select_Nesting => 0);
   pragma Restrictions(Max_Tasks => 0);
   pragma Restrictions(No_Abort_Statements);

The above disallow the concurrency feature so that overheads for concurrency
support are not imposed on my sequential programs.

   pragma Restrictions(No_Implementation_Attributes);
   pragma Restrictions(No_Obsolescent_Features);

These are intended to promote portability and forward compatibility.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Have the Itanium critics all been proven wrong?

[Adam Beneschan]

On Tuesday, August 21, 2012 7:32:55 PM UTC-7, Bill Findlay wrote:
 
> > At least during the AJPO period and MIL-STD/1815A, the Ada 
> > specification was NO SUBSETS and NO SUPERSETS were permitted to call
> > themselves Ada. (This doesn't cover optional annexes, just the core
> > language).
> 
> Yes.  That was enforced rigorously.  But things are different now.
> 
> The Restrictions pragma allows the programmer to exclude features that are
> considered inappropriate for a particular application.  So it could be said
> that Ada now has 2**N subsets, where N is the number of Restrictions 
> options.  I don't have an exact count, but N is of the order of 50.

That's not at all the same thing.  The first has to do with implementors providing a compiler that only implements a subset of the required Ada features, and still calling it Ada; the second has to do with the language providing a feature by which users can restrict the features they themselves use.  A compiler that handles all the features of Ada is not implementing a "subset" of Ada even if it supports all the Restrictions pragmas.  

The big thing that's different is that while in the past, the US government tried to copyright the name "Ada" and prevent implementors from calling incompletely implemented compilers "Ada compilers" by legal means, they don't try to do that any more.

                           -- Adam

Re: Have the Itanium critics all been proven wrong?

[Bill Findlay]

On 22/08/2012 03:42, in article
0ca8e290-722c-4f9d-9324-b29469874559@googlegroups.com, "Adam Beneschan"
<adam@irvine.com> wrote:

> On Tuesday, August 21, 2012 7:32:55 PM UTC-7, Bill Findlay wrote:
>  
>>> At least during the AJPO period and MIL-STD/1815A, the Ada
>>> specification was NO SUBSETS and NO SUPERSETS were permitted to call
>>> themselves Ada. (This doesn't cover optional annexes, just the core
>>> language).
>> 
>> Yes.  That was enforced rigorously.  But things are different now.
>> 
>> The Restrictions pragma allows the programmer to exclude features that are
>> considered inappropriate for a particular application.  So it could be said
>> that Ada now has 2**N subsets, where N is the number of Restrictions
>> options.  I don't have an exact count, but N is of the order of 50.
> 
> That's not at all the same thing.  The first has to do with implementors
> providing a compiler that only implements a subset of the required Ada
> features, and still calling it Ada; the second has to do with the language
> providing a feature by which users can restrict the features they themselves
> use.  A compiler that handles all the features of Ada is not implementing a
> "subset" of Ada even if it supports all the Restrictions pragmas.

These are legalistic differences, not real semantic ones.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Have the Itanium critics all been proven wrong?

[Adam Beneschan]

On Tuesday, August 21, 2012 9:08:34 PM UTC-7, Bill Findlay wrote:
> On 22/08/2012 03:42, in article
> 
> >>> At least during the AJPO period and MIL-STD/1815A, the Ada
> >>> specification was NO SUBSETS and NO SUPERSETS were permitted to call
> >>> themselves Ada. (This doesn't cover optional annexes, just the core
> >>> language).
> 
> >> Yes.  That was enforced rigorously.  But things are different now.
> 
> >> The Restrictions pragma allows the programmer to exclude features that are
> >> considered inappropriate for a particular application.  So it could be said
> >> that Ada now has 2**N subsets, where N is the number of Restrictions
> >> options.  I don't have an exact count, but N is of the order of 50.
> >
> > That's not at all the same thing.  The first has to do with implementors
> > providing a compiler that only implements a subset of the required Ada
> > features, and still calling it Ada; the second has to do with the language
> > providing a feature by which users can restrict the features they themselves
> > use.  A compiler that handles all the features of Ada is not implementing a
> > "subset" of Ada even if it supports all the Restrictions pragmas.
> 
> These are legalistic differences, not real semantic ones.

Not that I want to start a long discussion nitpicking about what words mean--we have enough of those threads--but you seemed to be contrasting two things that shouldn't have been contrasted.  If the early Ada designers had thought a Restrictions pragma would be useful, it could have been in the language, allowing programmers to enforce "subsets" on themselves, and the AJPO still could have imposed a "no subsets" rule on implementors.  The two aren't contradictory.  That was my point.  But it's an unimportant nitpick, and that's all I'm going to say about it.

                            -- Adam

Re: Have the Itanium critics all been proven wrong?

[Michael S]

On Aug 21, 11:48 pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:
> (I'm cross-posting (I hope) this to comp.lang.ada, since there are
> questions on how Ada is used.)
>
> On 12-08-21 16:00 , Michael S wrote:
>
> > On Aug 21, 1:35 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>    ...
> >> And where any dynamic allocation is not good enough, the SPARK subset
> >> currently mandates pure static allocation (and fixed size stack objects)
> >> to allow formal proof of storage requirements. Harsh, but I'd rather not
> >> see a segfault in my car. These restrictions may be relaxed if proof
> >> technologies improve, but I wouldn't hold my breath...
>
> > SPARK is an Ada analogue of MISRA C?
>
> Not really, as I understand them. MISRA C is a bunch of rules that are
> supposed to define a safer subset of C, and for which rule violations
> can (mostly?) be detected automatically. But I don't think that the
> MISRA rules automatically make a C program much more amenable to static
> analysis or formal proof.
>
> SPARK is a Ada, plus annotations embedded in the Ada source, where the
> goal is to allow automatic proof that the program is safe and correct
> per some formal criteria expressed in the annotations and elsewhere. For
> example, one can prove that all run-time checks in the Ada program will
> succeed and will not raise exceptions. Limitations in the SPARK proof
> tools mean that only a subset of Ada can be handled by the tools.
> Moreover, the proofs often need some manual guidance.
>
> > I guess, without reading a single
> > line of spec, I already don't like it .
>
> At present, SPARK handles a rather small subset of Ada that forbids some
> major features, for example access types (pointers). I would use SPARK
> only for very critical code. However, it is possible to write parts of
> an application in SPARK, and mix in full Ada code for the rest, "hiding"
> it from the SPARK tools. Of course, the SPARK proof then formally covers
> only the SPARK part.
>
> > So, I have more generic question about Ada state of the art.
>
> > Preface:
> > According to my understanding, one of the Ada objectives was creating
> > two languages in one.
> > The first language intended primarily for complex embedded software,
> > but also suitable for general-purpose system programming.
> > The second language intended primarily for big complex application-
> > level programming, but is also applicable for relatively simple
> > embedded software and for some system programming tasks.
>
> I've been involved wih Ada for a long time, but I don't remember such a
> "two languages" thing being discussed. Perhaps it was a topic in the
> early language definition stages.
>
> > The second language, at source level, but not necessarily at pragma
> > and run-time support level, is a strict subset of the first language.
> > There is clear distinction line between the first and second
> > languages, drawn around built-in procedures with the names starting
> > with unchecked_ and with external procedure calls.
> > The first language does not pretend to be "safe". And sorry, I am not
> > in the mood of defining exactly what "safe" means.
>
> One can certainly do unsafe or wrong things in Ada, even without using
> any "unchecked programming", as it is called. A simple mistake like
> using an uninitialized variable can make the program give unpredictable
> results. But it is not possible to clobber arbitrary memory locations in
> this way; for that, one must use Unchecked_Conversion to generate a wild
> pointer. (OK, there are some other low-level ways to generate wild
> pointers, too.)
>

"not possible to clobber arbitrary memory locations" is probably good
enough definition of what I consider "safe" computer language.

>
> The things called Unchecked_ in Ada are the Unchecked_Conversion
> generic, which reinterprets data of one type as being of a different
> type, the Unchecked_Deallocation generic, which deallocates heap memory
> (just like "free" in C), and the Unchecked_Access attribute, which can
> make a pointer value live longer than the object to which it points. All
> can cause run-time trouble in obvious ways, but are not enough IMO to
> make "two languages".

o.k.
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.

>
> Oh yes, and the Unchecked_Union pragma, for interfacing with C union
> types. But mixed-language programs are more or less completely
> "unchecked" anyway.
>
> > The second language is "safe" and, supposedly, very portable.
>
> There are many, many tales that confirm the portability, and my own
> experience also agrees.
>
> > 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 mean where covering of 95% of
> > 'C' dynamic memory use cases with variable length arrays, storage
> > pools etc is not enough and have to handle somehow the remaining 5%.
>
> I think the answer here depends on the kind of data structures used in
> the program. My own applications use graph structures with many links
> between nodes, and therefore I do use heap memory (and some
> Unchecked_Deallocation). Applications that are more array-oriented may
> be able to avoid heap.
>
> > According to my understanding, garbage collector implemented by the
> > run-time support is the only sane way to handle these last 5% while
> > remaining in the envelop of the "second" Ada language.
> > So what happens in practice?
> > Do people that develop big apps in Ada use "second" language + runtime
> > with GC?
>
> As far as I know, the only Ada systems with automatic garbage collection
> are those that compile Ada to Java byte-code and run on the JVM. I have
> heard that some people have used the Boehm "conservative" GC with Ada,
> but I'm not sure if it works reliably (because some Ada compilers play
> tricks with array base addresses).
>
> So the answer here is "no", I think; GC is not used much with Ada.
> Unfortunately, IMO.
>
> > Or do they opt for unchecked_deallocation() thus, effectively, finding
> > themselves in the "first" language, even if they don't use any other
> > unchecked_xxx procedure?
>
> Unchecked_Deallocation is used a lot. However, Ada has a class of
> "controlled" types with user-defined initialization and finalization
> that can be used to automate deallocation by reference counting. Of
> course, Ada is not unique in this; C++ has similar means.
>
> But although many Ada programs use some unchecked stuff, the web of
> checks in Ada is so dense that even if the unchecked computation creates
> an error, the error is usually detected rapidly as an exception.
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>       .      @

Thank you.

Re: Have the Itanium critics all been proven wrong?

[Dmitry A. Kazakov]

On Wed, 22 Aug 2012 02:29:21 -0700 (PDT), 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.

I don't understand why people keep on talking about two languages.
Annotations should be optional like Unchecked_Deallocation is. If you
annotate some Ada program unit, you might prove certain things about that
unit. An conversely if you upfront require certain propositions to be
proved/provable about given units you have to annotate something in these.
Why two languages?

The only real problem is the power of the prover to mandate.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Have the Itanium critics all been proven wrong?

[Ludovic Brenta]

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.

Re: Have the Itanium critics all been proven wrong?

[Niklas Holsti]

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".

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Have the Itanium critics all been proven wrong?

[Brian Drummond]

On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:

> On Aug 22, 12:09 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>
>> Heh, the book I learned C++ from didn't even mention STL, (or
>> namespaces for that matter) and regarded templates as a bit unstable.
>> When did STL appear? (And yes, I have newer books now...)
>>
>>
> Interview with Alex Stepanov.
> http://www.sgi.com/tech/stl/drdobbs-interview.html

So, not long after Ada-95. 
Interesting article - he even speculates that STL could be implemented in 
Ada. I suppose Ada.Containers goes some way towards that.

>> > Obsession with separate compilation does not help either.
>>
>> Does not help what? I'm unclear what point you have in mind? 

> Ada has his own library/link system. They can store as little or as much
> info as they like in the intermediate files and do as much processing as
> needed in the link phase.
> Times change, noways C and in particular C++ developers very rarely rely
> on language-agnostic linkers, but language features that would make that
> type of analysis possible still absent.

Indeed - in gcc, Ada and C use the same linker! though Ada passes through 
a binding stage handling additional inter-module information. C and C++, 
as far as I can see, still rely on external tools to (mis?)manage the 
dependencies.

> BTW, how Ada deals with that? That it how pointer (access) to auto
> object distinguished from pointers to  dynamic or static objects when
> they (pointers) are passed to the different module?

Now you have caught me; it's a good question but I can't answer it 
accurately. So I have added c.l.a to the newsgroups in the hope that 
others will keep me straight.

I believe pointers to "auto" (C-speak for stack-allocated?) objects can 
only be passed down the call stack; accessibility checks would otherwise 
fail (unless defeated by unchecked_access).

Given modules A and B, it's not normal to actually access B's pointers 
from module A. More commonly A would only see a "private type" exported 
from B, and not even know it was a pointer. A can hold such types, but 
can only use them by invoking methods from B (such as accessors) on them. 
This puts B in charge of the object lifetimes; if A wants to access a 
stale object, expect an exception.

>> Ada ... doesn't by default supply a garbage collector. 
> Automatic garbage collection not aided by compiler is certainly possible
> and done in practice (Boehm ?). But is not such GC significantly less
> efficient than GC aided by compiler?

such as Java's GC for example?

I don't know that would generally be the case. If you need GC, you may 
often be able to structure the application to gain some advantage from 
its properties; for example, it may make identical sized garbage objects, 
or it may have natural "down times" when you can harmlessly schedule 
(part of) a GC. 

Without knowing those properties, you can't design a GC to optimally fit.
So I believe that compiler-supplied GC would often be less efficient. In 
that respect, I agree with the decision shared by Ada and C++, to not 
provide it by default.

- Brian

Re: Have the Itanium critics all been proven wrong?

[Michael S]

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.


> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>       .      @       .

Re: Have the Itanium critics all been proven wrong?

[Brian Drummond]

On Wed, 22 Aug 2012 03:28:24 -0700, Ludovic Brenta wrote:

> 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?
 
> I work on such an application: 2 million lines of code, multiple
> processes running 24x7 on multiple machines, mission-critical, multiple
> GUIs.  
...
> 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 ...  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.

Interesting and good to know. But dare I ask ... (if you have any such 
statistics to hand, or even a gut feel) ... what percentage of the bugs 
arise out of that 0.5% of the code?

- Brian

Re: Have the Itanium critics all been proven wrong?

[Michael S]

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.

Re: Have the Itanium critics all been proven wrong?

[Michael S]

On Aug 22, 3:39 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
> > On Aug 22, 12:09 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>
> >> Heh, the book I learned C++ from didn't even mention STL, (or
> >> namespaces for that matter) and regarded templates as a bit unstable.
> >> When did STL appear? (And yes, I have newer books now...)
>
> > Interview with Alex Stepanov.
> >http://www.sgi.com/tech/stl/drdobbs-interview.html
>
> So, not long after Ada-95.
> Interesting article - he even speculates that STL could be implemented in
> Ada. I suppose Ada.Containers goes some way towards that.
>
> >> > Obsession with separate compilation does not help either.
>
> >> Does not help what? I'm unclear what point you have in mind?
> > Ada has his own library/link system. They can store as little or as much
> > info as they like in the intermediate files and do as much processing as
> > needed in the link phase.
> > Times change, noways C and in particular C++ developers very rarely rely
> > on language-agnostic linkers, but language features that would make that
> > type of analysis possible still absent.
>
> Indeed - in gcc, Ada and C use the same linker! though Ada passes through
> a binding stage handling additional inter-module information. C and C++,
> as far as I can see, still rely on external tools to (mis?)manage the
> dependencies.

Well, we are not at managing dependencies now, don't we?
We are at error/warning detection and reporting during link phase.
Gnu ld of today is very far of language agnostic. In Microsoft world
people routinely use link-time  code generation. So, original
technical reasons for not doing that sort of checks do not exist any
more. But the checks are still not provided due to deficiencies of the
language itself.

>
> > BTW, how Ada deals with that? That it how pointer (access) to auto
> > object distinguished from pointers to  dynamic or static objects when
> > they (pointers) are passed to the different module?
>
> Now you have caught me; it's a good question but I can't answer it
> accurately. So I have added c.l.a to the newsgroups in the hope that
> others will keep me straight.
>
> I believe pointers to "auto" (C-speak for stack-allocated?) objects can
> only be passed down the call stack; accessibility checks would otherwise
> fail (unless defeated by unchecked_access).
>
> Given modules A and B, it's not normal to actually access B's pointers
> from module A. More commonly A would only see a "private type" exported
> from B, and not even know it was a pointer. A can hold such types, but
> can only use them by invoking methods from B (such as accessors) on them.
> This puts B in charge of the object lifetimes; if A wants to access a
> stale object, expect an exception.

Exception, if I am lucky.
If I am less lucky, the physical place of old auto object is now
occupied by new auto object of the same or compatible type and the
call to accessor caused silent corruption.

>
> >> Ada ... doesn't by default supply a garbage collector.
> > Automatic garbage collection not aided by compiler is certainly possible
> > and done in practice (Boehm ?). But is not such GC significantly less
> > efficient than GC aided by compiler?
>
> such as Java's GC for example?
>
> I don't know that would generally be the case. If you need GC, you may
> often be able to structure the application to gain some advantage from
> its properties; for example, it may make identical sized garbage objects,
> or it may have natural "down times" when you can harmlessly schedule
> (part of) a GC.

That's not a good argument.
Compiler-supplied GC can also provide hint interface, like
Compact_righ_now, Please_do_not_compact_if_you_dont_have_to.

>
> Without knowing those properties, you can't design a GC to optimally fit.
> So I believe that compiler-supplied GC would often be less efficient. In
> that respect, I agree with the decision shared by Ada and C++, to not
> provide it by default.
>
> - Brian

But when compiler is aware of GC the tracking of liveness of objects
become much easier (for some implementations - trivial). You can
organize your memory database in such way that you will never have to
scan things.

Re: Have the Itanium critics all been proven wrong?

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
>
>> On Aug 22, 12:09 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>>
>>> Heh, the book I learned C++ from didn't even mention STL, (or
>>> namespaces for that matter) and regarded templates as a bit unstable.
>>> When did STL appear? (And yes, I have newer books now...)
>>>
>>>
>> Interview with Alex Stepanov.
>> http://www.sgi.com/tech/stl/drdobbs-interview.html
>
> So, not long after Ada-95. 
> Interesting article - he even speculates that STL could be implemented
> in Ada. I suppose Ada.Containers goes some way towards that.

Yes; the STL inspired the overall design of Ada.Containers.

Re: Have the Itanium critics all been proven wrong?

[Brian Drummond]

On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:

> On Aug 22, 3:39 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:

[... discussion of private types exported to module A from B]
>> This puts B in charge of the object lifetimes; if A wants to access a
>> stale object, expect an exception.
> 
> Exception, if I am lucky.
> If I am less lucky, the physical place of old auto object is now
> occupied by new auto object of the same or compatible type and the call
> to accessor caused silent corruption.

If a module has exported a pointer to an "auto object" then the 
accessibility checks have been circumvented by unchecked_access or 
unchecked_conversion. In which case ... yes, caveat programmer!

Pointers passed from a module will generally be to static or dynamic 
objects. Which, if dynamic, can be freed by unchecked_deallocation.
Again : caveat programmer. 

One benefit of the private type, forcing all accesses to an object being 
through its own methods, is that B can be implemented as a "controlled 
type", which allows B's programmer to make such mistakes less common.
For example, B's object may be reference counted, and only freed after 
all its handles are released. (And yet a pathological A may cheat, and 
access it after release.)

Controlled types could probably be used as the basis for a garbage 
collector.

>> > But is not such GC
>> > significantly less efficient than GC aided by compiler?
>> I don't know that would generally be the case. If you need GC, you may
>> often be able to structure the application to gain some advantage from
>> its properties; ...

> That's not a good argument.
> Compiler-supplied GC can also provide hint interface, like
> Compact_righ_now, Please_do_not_compact_if_you_dont_have_to.

True. If the GC implementor has foreseen the pattern you need or 
something close enough, then compiler-provided GC would probably be more 
efficient. 

- Brian

Re: Have the Itanium critics all been proven wrong?

[Bill Findlay]

On 22/08/2012 16:06, in article k12shq$4ii$1@dont-email.me, "Brian Drummond"
<brian@shapes.demon.co.uk> wrote:

> On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:
> 
>> On Aug 22, 3:39�pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
> 
> [... discussion of private types exported to module A from B]
>>> This puts B in charge of the object lifetimes; if A wants to access a
>>> stale object, expect an exception.
>> 
>> Exception, if I am lucky.
>> If I am less lucky, the physical place of old auto object is now
>> occupied by new auto object of the same or compatible type and the call
>> to accessor caused silent corruption.
> 
> If a module has exported a pointer to an "auto object" then the
> accessibility checks have been circumvented by unchecked_access or
> unchecked_conversion. In which case ... yes, caveat programmer!
> 
> Pointers passed from a module will generally be to static or dynamic
> objects. Which, if dynamic, can be freed by unchecked_deallocation.
> Again : caveat programmer.

Worth pointing out that access types /cannot/ point to auto objects unless
declared as "access all", and in Ada it is unusual to do so, as pointers to
non-heap objects are very much less needed than in other languages.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Have the Itanium critics all been proven wrong?

[Ludovic Brenta]

Brian Drummond writes on comp.lang.ada:
>> I work on such an application: 2 million lines of code, multiple
>> processes running 24x7 on multiple machines, mission-critical, multiple
>> GUIs.  
> ...
>> 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 ...  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.
>
> Interesting and good to know. But dare I ask ... (if you have any such 
> statistics to hand, or even a gut feel) ... what percentage of the bugs 
> arise out of that 0.5% of the code?

No bugs in the past few years because those parts of our code base are
20 years old or more and have been debugged to death; also only experts
are ever asked to work on them.  The fact that they are isolated in a
few package bodies helps, of course.

-- 
Ludovic Brenta.

Re: Have the Itanium critics all been proven wrong?

[Michael S]

On Aug 22, 6:06 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:
> > On Aug 22, 3:39 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> >> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
>
> [... discussion of private types exported to module A from B]
>
> >> This puts B in charge of the object lifetimes; if A wants to access a
> >> stale object, expect an exception.
>
> > Exception, if I am lucky.
> > If I am less lucky, the physical place of old auto object is now
> > occupied by new auto object of the same or compatible type and the call
> > to accessor caused silent corruption.
>
> If a module has exported a pointer to an "auto object" then the
> accessibility checks have been circumvented by unchecked_access or
> unchecked_conversion. In which case ... yes, caveat programmer!
>

My knowledge of Ada is rather rusty :(
Is it correct to say that applying 'access attribute to auto objects
is a syntax error and that the only possible way of getting access to
such objects is by applying  'unchecked_access attribute?

Thinking about it, it makes sense.
99% of cases of passing pointers to auto object as parameters in C are
not because programmer really wants to pass pointer, but because of
absence of 'out' and 'in out' modes and due to inefficiency of passing
of big objects in C language equivalent of 'in' mode.
Also nearly 100% of uses of  pointers to auto object in the local
context are due to [by now quite often false] programmer's believe
that he can optimize better than optimizing compiler.

Re: Have the Itanium critics all been proven wrong?

[Michael S]

On Aug 22, 6:59 pm, Michael S <already5cho...@yahoo.com> wrote:
> On Aug 22, 6:06 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>
>
>
>
>
>
>
>
>
> > On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:
> > > On Aug 22, 3:39 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> > >> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
>
> > [... discussion of private types exported to module A from B]
>
> > >> This puts B in charge of the object lifetimes; if A wants to access a
> > >> stale object, expect an exception.
>
> > > Exception, if I am lucky.
> > > If I am less lucky, the physical place of old auto object is now
> > > occupied by new auto object of the same or compatible type and the call
> > > to accessor caused silent corruption.
>
> > If a module has exported a pointer to an "auto object" then the
> > accessibility checks have been circumvented by unchecked_access or
> > unchecked_conversion. In which case ... yes, caveat programmer!
>
> My knowledge of Ada is rather rusty :(
> Is it correct to say that applying 'access attribute to auto objects
> is a syntax error and that the only possible way of getting access to
> such objects is by applying  'unchecked_access attribute?
>
> Thinking about it, it makes sense.
> 99% of cases of passing pointers to auto object as parameters in C are
> not because programmer really wants to pass pointer, but because of
> absence of 'out' and 'in out' modes and due to inefficiency of passing
> of big objects in C language equivalent of 'in' mode.
> Also nearly 100% of uses of  pointers to auto object in the local
> context are due to [by now quite often false] programmer's believe
> that he can optimize better than optimizing compiler.

Wrote it before seeing Bill's post above. Sorry.

Re: Have the Itanium critics all been proven wrong?

[Georg Bauhaus]

On 22.08.12 17:59, Michael S wrote:
> My knowledge of Ada is rather rusty :(
> Is it correct to say that applying 'access attribute to auto objects
> is a syntax error and that the only possible way of getting access to
> such objects is by applying  'unchecked_access attribute?


I'd like or add that "auto objects" must be marked "aliased" explicitly
if 'Access (or 'Unchecked_Access) is desired. That's true in general.

(Also, pointer types can be declared local to a procedure (or other
block), so that objects of the local pointer type cannot outlive
the block unless brute force is used explicitly.)

Re: Have the Itanium critics all been proven wrong?

[Bill Findlay]

On 22/08/2012 16:59, in article
793f28d5-8d61-48e7-adc8-266356cecd26@cf4g2000vbb.googlegroups.com, "Michael
S" <already5chosen@yahoo.com> wrote:

> On Aug 22, 6:06�pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>> On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:
>>> On Aug 22, 3:39�pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>>>> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
>> 
>> [... discussion of private types exported to module A from B]
>> 
>>>> This puts B in charge of the object lifetimes; if A wants to access a
>>>> stale object, expect an exception.
>> 
>>> Exception, if I am lucky.
>>> If I am less lucky, the physical place of old auto object is now
>>> occupied by new auto object of the same or compatible type and the call
>>> to accessor caused silent corruption.
>> 
>> If a module has exported a pointer to an "auto object" then the
>> accessibility checks have been circumvented by unchecked_access or
>> unchecked_conversion. In which case ... yes, caveat programmer!
>> 
> 
> My knowledge of Ada is rather rusty :(
> Is it correct to say that applying 'access attribute to auto objects
> is a syntax error and that the only possible way of getting access to
> such objects is by applying  'unchecked_access attribute?

No, 'Access is perfectly OK for an auto object, but the object must be
explicitly declared as of type "aliased T", and about the only thing you can
do with the access value is pass it into an "access all T" pointer (or
explicitly unsafely coerce it).   If the pointer type is declared in the
same scope as the object, or in an enclosed scope, no pointer value of that
type can survive leaving the object's scope (modulo explicitly unsafely
coercing to a type of wider scope).

It is not impossible to hang yourself with Ada - there is quite sufficient
rope - but it requires very deliberate and unusual preparation, and won't
happen by mere accident or ordinary negligence.

> Thinking about it, it makes sense.
> 99% of cases of passing pointers to auto object as parameters in C are
> not because programmer really wants to pass pointer, but because of
> absence of 'out' and 'in out' modes and due to inefficiency of passing
> of big objects in C language equivalent of 'in' mode.

Exactly so.

> Also nearly 100% of uses of  pointers to auto object in the local
> context are due to [by now quite often false] programmer's believe
> that he can optimize better than optimizing compiler.

And again, yes.  But sometimes the programmer is right about that. 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Have the Itanium critics all been proven wrong?

[Randy Brukardt]

"Michael S" <already5chosen@yahoo.com> wrote in message 
news:00dcc463-e9d2-490d-93bc-4ec2084522db@l9g2000vbj.googlegroups.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:
...
> 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.

The web server that runs the Ada search engine (providing search for various 
Ada standards and other documents) and hosting the Ada-auth.org website is 
such an application; it runs 24x7 and it is 100% Ada. I wouldn't call it 
"really big" though (I think it is around 120Kloc). And it does use 
Unchecked_Deallocation, I thought that might be a problem in a long running 
application, but I've never seen any problem with fragmentation or the like 
even when it is up for several months. (It tends to get restarted every 
couple of months to install the never-ending stream of patches from 
Microsoft, so I don't have any real data on what would happen if it ran for 
a year or more - although I would be surprised if it changed much.

I've also got a spam filter/mail exchanger program that also runs 24x7, is 
about the same size, and has similar characteristics.

My understanding is that these are small systems compared to those used by 
our customers, but I have no direct experience with those systems.

                            Randy.

Re: Have the Itanium critics all been proven wrong?

[Bill Findlay]

Following up my own post ...

On 17/08/2012 20:34, in article CC545B6F.1BA11%yaldnif.w@blueyonder.co.uk,
"Bill Findlay" <yaldnif.w@blueyonder.co.uk> wrote:

> On 17/08/2012 20:17, in article k0m5c3$t6t$1@dont-email.me, "Stephen Fuld"
> <SFuld@alumni.cmu.edu.invalid> wrote:
> 
>> On 8/17/2012 2:05 AM, Nomen Nescio wrote:
>>> The point of Ada is safety and runtime checks. That is provided through
>>> intensive compilation and an engineered runtime system. In a bare metal Ada,
>>> there is a limit to what safety it can provide and the runtime checks will
>>> introduce overhead over C. Otherwise Bill is arguing that there is a free
>>> lunch, and we see that can't very well be.
>> 
>> I don't think he is arguing for a free lunch, just a relatively low cost
>> one. Note that, as has been repeatedly pointed out, things like C's poor
>> aliasing limits prevent some optimizations that other languages allow.
>> So while there is a cost to the additional run time checks (the
>> compilation stuff doesn't cost at run time), there are some advantages
>> to using other languages too.  And if the cost is relatively small, it
>> may be worth the cost for the gain in security, reliability, etc.
> 
> Runtime security is not the same thing as runtime checks.

The magnitude of the checking "overhead" has been called into question.
Should it be prohibitive in special cases, a selection of particular checks
can be suppressed over well-defined scopes.  However, the real cost is often
surprisingly small.

Here is some actual data, rather than speculation.
 
My KDF9 emulator is about 20KSLOC.  Compiled with all runtime checking
disabled, it runs 1.25% faster than when compiled with default checking.
  
Interestingly, if I do not suppress absolutely all checks, but enable them
for "non-inner loop" modules, it runs a further 1.25% faster than when
completely unchecked.  More checks -> faster code!

Another program of mine, an assembler of about 10KSLOC, runs 1% faster with
default checking than it does with checking completely suppressed.

Such are the vagaries of performance measurement with modern CPUs.

So for some programs, at least, the overhead due to runtime checking is down
near the noise level.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;