Re: Ada is almost useless in embedded systems

Re: Ada is almost useless in embedded systems

[Robert Dewar]

John McCabe said

"If you check the detail of pragma shared, I think you'll find this
does not provide the same facilities as the C 'volatile' attribute. I
have checked this according to my compiler manual, so I do know what
I'm talking about here.

Also, as I've mentioned elsewhere, I know nothing about Ada 95, all my
comments are purely Ada 83."

This is wrong, pragma shared corresponds to pragma Atomic in Ada 95,
not to pragma Volatile (and the volatile keyword in C).

Volatile does not require atomic access and can be applied to anything.
Atomic (Shared) can only be applied to objects for which atomic access
can be guaranteed, which is likely to be very restrictive.

There is no equivalent of pragma Volatile in Ada 83.

Re: Ada is almost useless in embedded systems

[Ken & Virginia Garlington]

John McCabe wrote:
> That's all very well, but if you are _not_ using tasking, and your
> compiler knows this (which it obviously should), then this implies
> that this pragma is redundant - no tasks = no shared objects.

Actually, one of the things that's easy to forget in Ada is that you
are _always_ using tasking. The main program is just another task. 
Another issue is that the compiler may _not_ know you are using tasking 
when it encounters the pragma, since the task referencing the object may 
not have been compiled yet. So, I suspect that many Ada compilers don't 
do the optimization you're assuming.

> What pragma shared is _not_ is a directive to enforce no optimisation
> of an object. On the other hand, this is exactly what the C volatile
> qualifier is.

There is a distinction between shared and volatile, which is why some 
Ada 83 vendors (e.g. DEC Ada) added it as an extra pragma, and why it is 
now part of the Ada standard.

Re: Ada is almost useless in embedded systems

[Tore Joergensen]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Nasser, of course he did not post his reasons. This was a troll, one of the
: more transparent trolls one sees these days. [...snip...] There
: typically are two kinds of trolls, ones that make people mad enough to
: respond (the case here), or ones that entice people to respond ("I have
: XXX pictures free, but don't send me email, post here instead"). 
: Newsgroups are nicer places to be if people simply ignore trolls of both
: kinds :-)

Off topic: I'm just a little curious about this use of 'troll'...
Oxford Advanced Learner's Dictionary of Current English (1984) lists
two interpretations; "(in Scandinavian myth) supernatural being, a giant,
or, in later tales, a mischievous but friendly dwarf" and "fish with rod
and line by pulling bait through the water behind a boat". Even a 'Current
English'-dictionary from 1984 isn't current anymore :-), so I'm wondering:
Is this a common use of 'troll', and if it is, is it a noun made from the
'fishing' verb?
--
+-------------------------+-------------------------------------------+
| Tore B. Joergensen      | e-mail : tore@lis.pitt.edu                |
| Centre Court Villa      | web    : http://www.pitt.edu/~tojst1      |
| 5535 Centre Avenue # 6  |                                           |
| Pgh, PA 15232, USA      | Norwegian MSIS-student at Univ. of Pgh.   |
+-------------------------+-------------------------------------------+

Re: Ada is almost useless in embedded systems

[Robert Dewar]

John McCabe says

"> What pragma shared is _not_ is a directive to enforce no optimisation
> of an object. On the other hand, this is exactly what the C volatile
> qualifier is."

Not quite, in particular the "exactly" here is confusing. THe exact
definition of volatile is a little tricky (but quite precise). The
meaning of "optimization" is also tricky and not at all precise.

Re: Ada is almost useless in embedded systems

[Robert Dewar]

Tore asks

"Off topic: I'm just a little curious about this use of 'troll'...
Oxford Advanced Learner's Dictionary of Current English (1984) lists
two interpretations; "(in Scandinavian myth) supernatural being, a giant,
or, in later tales, a mischievous but friendly dwarf" and "fish with rod
and line by pulling bait through the water behind a boat". Even a 'Current
English'-dictionary from 1984 isn't current anymore :-), so I'm wondering:
Is this a common use of 'troll', and if it is, is it a noun made from the
'fishing' verb?"

The trouble with English is that it is a very large language, so you need
a big dictionary :-)

I just went downstairs to haul up volume XVIII of OED 2nd edition, to see
what it says.

Troll as a noun is an old usage. There are two entries, one for the 
meaning we are interested in, and a second one for the Scandinavian
creature.

Under the first meaning, we have

"The act of trolling, a going or moving round; routine or repetition"

This is probably not the origin of the Internet use, but seemed
entertainingly relevant. A 1790 quote is

"The troll of their categorical table might have informed them that
there was something else ... besides substance and quantity" 

:-)

The relevant use is probably

"The method of trolling in fishing" 

or

"A lure used in trolling"

The first reference to the method is 1681, and first reference to the lure
that is quoted is 1869.

Anyway the internet usage is an adaptation of an old word that seems
well adapted for the internet use (i.e. a post whose primary intention
is to have other people respond with a post). John McCabe's original
post was a classical troll, the kind that works by aggravating people
into replying, even before there is anything of substance to reply to.

The other kind of troll lures people with an irresistable promise (e.g. 
"I have XXX pictures free, but don't email me, post to this newsgroup
if you want me to send a copy to you"), but it's hard to figure out
a positive troll of this kind that would work on CLA. I suppose if
early on we had posted something like

"Free copy of Ada 95 compiler, post to this group if you want one",
we would have got a fair number of poeple taking the bite (but I
still don't think that we could match the appeal of XXX pictures :-)

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe said

>"If you check the detail of pragma shared, I think you'll find this
>does not provide the same facilities as the C 'volatile' attribute. I
>have checked this according to my compiler manual, so I do know what
>I'm talking about here.

>Also, as I've mentioned elsewhere, I know nothing about Ada 95, all my
>comments are purely Ada 83."

>This is wrong, pragma shared corresponds to pragma Atomic in Ada 95,
>not to pragma Volatile (and the volatile keyword in C).

I'm sorry Robert but I don't see understand why you are saying this is
wrong. I am not suggesting here that there is a correspondence between
shared and anything to do with Ada 95.

>Volatile does not require atomic access and can be applied to anything.
>Atomic (Shared) can only be applied to objects for which atomic access
>can be guaranteed, which is likely to be very restrictive.

>There is no equivalent of pragma Volatile in Ada 83.

I do appreciate the response though as myself and Jon have also been
discussing this using email and I was going to attempt to email you
for an explanation of pragma volatile. I had a look at John Barnes'
book Programming in Ada 95 yesterday and it seems to skimp over it.

Additional detail would be appreciated on this one.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe says

>"> What pragma shared is _not_ is a directive to enforce no optimisation
>> of an object. On the other hand, this is exactly what the C volatile
>> qualifier is."

>Not quite, in particular the "exactly" here is confusing. THe exact
>definition of volatile is a little tricky (but quite precise). The
>meaning of "optimization" is also tricky and not at all precise.

As far as K&RII is concerned, in the section in the back with the
annotations it explains the purpose of the volatile qualifier as being
to ensure that the compiler doesn't optimize e.g. redundant
assignments etc on a particular object.

I'll check the book when I get to work tomorrow and give you the exact
comment if you want.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[Robert Dewar]

pragma Volatile is identical to the volatile keyword in C. Most people, even
those who think they know C, don't accurately know the semantics of volatile,
it is a little tricky, but the informal view (don't optimize away loads
and stores) is close enough for most purposes.

Re: Ada is almost useless in embedded systems

[Robert Dewar]

John says

"As far as K&RII is concerned, in the section in the back with the
annotations it explains the purpose of the volatile qualifier as being
to ensure that the compiler doesn't optimize e.g. redundant
assignments etc on a particular object."

John, get a copy of the ANSI standard if you want to discuss things at
this level. K&RII is not a full accurate description of the standard (nor
does it pretend to be!)

Any serious C programmer should (a) have a copy of the ANSI standard and
(b) know their way around it.

The same of course is true for Ada programmers.

I am not saying that people should learn the languages from the standard,
that's asking too much, but you should learn to use it as a reference,
since it is the only authoritative source for detailed semantic information
in both cases.

Re: Ada is almost useless in embedded systems

[R.A.L Williams]

In article <4g3ljv$mmc@news.pacifier.com> steved@199.2.117.161  (Steve Doiel) writes:

> From: steved@199.2.117.161  (Steve Doiel)
> In ... (Daniel Grambihler) writes:
> 
> [snip]
> 
> >
> >I don't recall a claim the it was *impossible* to interface to hardware. Just
> >that it is badly designed for that job. I agree. Interfacing to hardware with
> >Ada is a pain.
> >
Yes that has been my experience too. At least compared with doing the same
job in C. I have to admit, however, that I haven't tried it for quite a
few years and perhaps compiler quality has improved.

[snip]

> 
> Well Daniel if portability is an issue, I think you need to scrap using
> 'C' bit fields to map to hardware registers or test your particular compiler
> for what it generates and settle for non-portable.
>
 
[snip]

I think one of the problems we are all having with this discussion is the 
context in which various statements are being made:

- programming in the large vs. programming in the small
- portability vs. fixed target environment

to mention but two sources of contention. Let's take an example I was 
peripherally involved in recently. We had to produce a small interface unit
that did a certain amount of data processing (all done in dedicated hardware
because of the desired rates) and, in addition, logged time-stamped
information onto a 'legacy' tape unit. Unfortunately the time-stamped
information also came from 'legacy' equipment, but a different legacy. I 
won't go into details but hardware designers can come up with thouroughly
unpleasant specifications when they want to! Portability didn't come into
the matter because this was a one-off system for a particular research
application. We knew the platform, in fact we designed it (the CPU board
at least), we knew the host and the job was so small that we couldn't
justify the expense of any compiler we didn't already have. Programming 
'in the large' was not an issue because, again, the whole job was so
small. To be honest, the engineer in charge of the development didn't
even consider using Ada but, if he had, I would have advised strongly
against it because, leaving aside the issues of large projects and
portability of representation, Ada (83 at least) is IMO far harder to
use than C.

Large system developments certainly get all the headlines and certainly 
represent a larger 'concentrated' risk if they go wrong, but at what
level, I wonder, is the bulk of man-power in the industry expended? In the
UK more people are employed in 'small businesses' than in multi-nationals.
I wonder if, by analogy, the same is also true of software development. If
this is the case, then maybe us 'little people' should have a voice too :-)

Bill Williams


-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 478639

Re: Ada is almost useless in embedded systems

[John McCabe]

>Still off topic:

>Quoting The Jargon File, version 3.3.0:

>> :troll: v.,n.  To utter a posting on {Usenet} designed to
>>    attract stupid responses or {flame}s.  May derive from the
>>    phrase "trolling for {newbie}s" or some similar construction.
>>    The well-constructed troll is a post that induces lots of newbies
>>    and flamers to make themselves look even more like idiots than they
>>    already do, while subtly conveying to the more savvy and
>>    experienced that it is in fact a deliberate troll.  If you don't
>>    fall for the joke, you get to be in on it.

That's interesting. As the originator of this thread, I can only say
that the original posting was _not_ designed to attract _stupid_
responses. 

Hopefully some of the discussion that has gone on under this thread
has shown that to be the case.

I honestly believed that I would receive intelligent responses
explaining all the good features of Ada for embedded systems but I was
obviously a bit naive.

As you should have seen by now I had what I felt to be a number of
valid points on the unsuitability of Ada (83 remember) in embedded
systems. 

During the discussions that have taken place as a result of this, I
have learned a great deal about Ada, especially that the new version
(Ada 95) is well worth looking into, although it is unlikely that I
will be able to use Ada 95 for some time.

In particular, w.r.t the original points I mentioned (and in that
order):

1) Strong Typing is also very good if you have a large system with a
large number of programmers. Obviously it is advisable to catch errors
as early as possible as the later you find them, the more expensive
they tend to be to find. Also I have seen an article on 'lint' and its
usage and there are some very good points in it related to the fact
that it gives a lot of detail about trivial errors which can lead to
the user unintentionally ignoring the serious errors!

2) Bitwise logical functions - can be used on one dimensional packed
arrays of booleans.  I have also learned a more general lesson which
is to be a lot more sceptical about my customer's requirements and to
design defensively. Finally, I have learned about Ada 95's modular
types which from what I have heard, will be a very valuable addition
to the language.

3) Enumeration representation clauses - I knew that I could get round
the problem I described and I now also know the reasons why the
restrictions exist although I have not really changed my opinion on
that point. Richard O'Keefe pointed out the Ada 95 definition of these
clause, but I have not managed to obtain the Ada 95 LRM yet to get the
exact context so I cannot really comment for the moment.

4) Variant Records. Now here is one place where I believe I really
screwed up! As soon as I was given an example (well, a 2nd example) by
Bob Gilbert on this point, the stuff I'd learned on my 1989 Ada
Training course came flooding back. In my defense all I can say is it
was about 2 years between that course and actually getting into the
position where I could use Ada in earnest and I had forgotten it.
Still no excuse really! I appreciate all the information I've been
given on this one.

5) Chapter 13. Mmmm well. Yes, Ada makes it obvious that there are
implementation dependant language features whereas other languages do
not. I'm still not convinced about the flexible this allows on the
implementations but the impression I get from what I've heard on Ada
95 is that far more definition has gone into this area.
Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John says

>"As far as K&RII is concerned, in the section in the back with the
>annotations it explains the purpose of the volatile qualifier as being
>to ensure that the compiler doesn't optimize e.g. redundant
>assignments etc on a particular object."

>John, get a copy of the ANSI standard if you want to discuss things at
>this level. K&RII is not a full accurate description of the standard (nor
>does it pretend to be!)

I know that and I will try to get hold of the ANSI standard, however
K&RII contains a summary of the standard with annotations explaining
the reasoning behind some of the features and to this end it is very
useful.

>Any serious C programmer should (a) have a copy of the ANSI standard and
>(b) know their way around it.

>The same of course is true for Ada programmers.

>I am not saying that people should learn the languages from the standard,
>that's asking too much, but you should learn to use it as a reference,
>since it is the only authoritative source for detailed semantic information
>in both cases.

Very true.
Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>pragma Volatile is identical to the volatile keyword in C. Most people, even
                    ^^^^^^^^^
I mentioned somewhere else that I believed the volatile qualifier in C
could be ignored by the compiler. Can youo confirm that, and if this
is true, is it the same for Ada 95?

>those who think they know C, don't accurately know the semantics of volatile,
>it is a little tricky, but the informal view (don't optimize away loads
>and stores) is close enough for most purposes.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[AdaWorks]

John McCabe (john@assen.demon.co.uk) wrote:
: I believe that Ada is badly designed with respect to interfacing to
: hardware and because of this should not be recommended for use in
: embedded systems.

  There have been truly abominable embedded systems project deployed
  written in Ada.  One could say the same of C, assembler and Forth.

  There are truly excellent embedded systems deployed written in Ada.
  This is also true of C, assembler, and Forth.

  The question, "Can Ada be used for the construction of well-performing
  embedded systems," is no longer a valid question. There are enough 
  operational systems in place to answer, "Yes."  

  We have no need to prove, through argument, whether Ada is appropriate
  for embedded systems software.  The Ada track-record speaks for itself.
  You have the burden of proof.  Since so many embedded systems are doing
  so well programmed in Ada, how do you prove it is not suited to such
  systems?

  The fact that some Ada software applications are horrible is not a function
  of the language, but a function of poor design, poor software practice,
  and often, in my experience, poor configuration management.

  Whatever reasons you may have are not relevant given Ada's record of 
  success.

  Do you recall the scientific proof that the Bumblebee could not fly because
  of its aerodymanic properties and wing-span?  

                      "Sweeny shifts from ham to ham,
                        Stirring the water in his bath."

  I do not recal the next two lines of Mr. Eliot's poem, but they 
  have to do with the folly of such proofs.                           

  Richard Riehle
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada is almost useless in embedded systems

[AdaWorks]

Joe Gamache (jgamache@mailgw.sanders.lockheed.com) wrote:
: In article <824056183.18993@assen.demon.co.uk>, 
: john@assen.demon.co.uk says...
: >

: >1) Strong typing is very good if your coders are learners or 
: possibly


  The fact that several contibutors to this thread are focusing their
  comments on "strong typing" indicates that there are still a large 
  number of software practitioners who do not understand the underlying
  rationale for Ada.  

  Ada is not about strong typing.  

  The type model is a feature of the language, albeit an important one. Of
  equal importance (maybe of greater importance) is the set of rules related
  to scope and visibility.  These rules are often misunderstood, and 
  sometimes ignored.  There are other characteristics of the language that
  must be considered in evaluating its role as a software engineering tool.

  So what is the criteria you use for selecting a programming environment?
  The overriding issue is whether one wants a language in which the compiler
  catches most of the errors.  If the answer is, "Yes," the correct choice
  is Ada.  If it is, "No," use something else.  Decide on your criteria and
  the select the language.  As for me, I am not very smart, so I like to
  use a language that helps me avoid stupid misteaks. [sic]  :-)

  Richard Riehle
  adaworks@netcom.com

-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada is almost useless in embedded systems

[Jon S Anthony]

In article <824495640.102@assen.demon.co.uk> john@assen.demon.co.uk (John McCabe) writes:

> >In passing, it may be of interest to note that the original VAX Ada
> >did not implement shared, and opted instead to implement a pragma
> >volatile.  Volatile basically did the "optimization" bit that you are
> >concerned about, but explicitly did _not_ provide for indivisible
> >operations.
> 
> That's interesting and sound like what Ada95 does (according to Robert
> Dewar's comment elsewhere).

Not quite.  Ada95 _splits_ these two things between pragma volatile and
pragma atomic.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ada is almost useless in embedded systems

[Keith Thompson]

In <4g54r5$57j@toads.pgh.pa.us> tore@lis.pitt.edu (Tore Joergensen) writes:
> Off topic: I'm just a little curious about this use of 'troll'...
> Oxford Advanced Learner's Dictionary of Current English (1984) lists
> two interpretations; "(in Scandinavian myth) supernatural being, a giant,
> or, in later tales, a mischievous but friendly dwarf" and "fish with rod
> and line by pulling bait through the water behind a boat". Even a 'Current
> English'-dictionary from 1984 isn't current anymore :-), so I'm wondering:
> Is this a common use of 'troll', and if it is, is it a noun made from the
> 'fishing' verb?

Still off topic:

Quoting The Jargon File, version 3.3.0:

> :troll: v.,n.  To utter a posting on {Usenet} designed to
>    attract stupid responses or {flame}s.  May derive from the
>    phrase "trolling for {newbie}s" or some similar construction.
>    The well-constructed troll is a post that induces lots of newbies
>    and flamers to make themselves look even more like idiots than they
>    already do, while subtly conveying to the more savvy and
>    experienced that it is in fact a deliberate troll.  If you don't
>    fall for the joke, you get to be in on it.
>  
>    Some people claim that the troll is properly a narrower category
>    than {flame bait}, that a troll is categorized by containing
>    some assertion that is wrong but not overtly controversial.

(I'm not commenting on whether the article that started this thread was
a deliberate troll.)

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As God is my witness, I thought turkeys could fly." -- Arthur Carlson, WKRP

Re: Ada is almost useless in embedded systems

[Robert Dewar]

"I mentioned somewhere else that I believed the volatile qualifier in C
could be ignored by the compiler. Can youo confirm that, and if this
is true, is it the same for Ada 95?"

Volatile can only be ignored by a C compiler if it treats everything
as volatile by default, which is I suppose conceivable for a very
poor compiler, but other than this rather trivial observation I know
nothing that would justify or suggest this "belief". 

Re: Ada is almost useless in embedded systems

[Norman H. Cohen]

In article <4gechc$g26@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU
(Richard A. O'Keefe) writes: 

|> In defence of Lint, I have to say that all of the things it reports are
|> likely symptoms of serious errors, and that it is next door to impossible
|> to UNINTENTIONALLY ignore the serious errors.  The only way you can ignore
|> the serious errors is by not tracking down all the lint reports to see how
|> serious they are.  A typical experience with someone else's code might be
|>      - 16 000 lines of source code
|>      -  1 000 lines of lint warnings
|>      -     10 hours checking the lint warnings
|>      -     10 days fixing the serious bugs.
|> Many categories of warnings can easily be switched off.
|>
|> There are two real problems with lint.

You mean you don't consider the ten hours checking the lint warnings (let
alone ten days fixing only the "serious" bugs) to be a "real problem"?
Or did I miss your smiley?

|> (1) The declarations of C do not provide enough information for really
|>     effective checking.  (E.g. all integer types are compatible.)

Indeed.

|> (2) There are legions of C programmers who apply lint, if at all, far too
|>     late in the life cycle, after they have already populated their code
|>     with tons of lint.

Not an option with Ada.  You can't get a successful compilation until
your code has been delinted.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada is almost useless in embedded systems

[Richard A. O'Keefe]

ralw@valiant.gmrc.gecm.com (R.A.L Williams) writes:
>To be honest, the engineer in charge of the development didn't
>even consider using Ada but, if he had, I would have advised strongly
>against it because, leaving aside the issues of large projects and
>portability of representation, Ada (83 at least) is IMO far harder to
>use than C.

This statement, coming from someone with such a background, deserves
a fuller exposition.  I hope R. A. L. Williams will provide one.

My personal experience, having used C since 1979, and Ada only for the last
couple of years, is precisely the opposite.  I consider myself expert in C;
perhaps that's why I thought it was hard to use.  I may say that it seems
to be easier to _teach_ Ada than to teach C; you can get a heck of a long
way without worrying about pointers, and it is so refreshing to be able to
answer questions of the form "how do I do X" with "well, it's really a topic
for later, but here's how you do it in Ada" instead of "well, there's no
language support for that in C in order to keep the compiler simple back in
the 70's."

(I hope this crashes before the written-in-C operating system crashes again...)

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Ada is almost useless in embedded systems

[Richard A. O'Keefe]

john@assen.demon.co.uk (John McCabe) writes:
>I honestly believed that I would receive intelligent responses
>explaining all the good features of Ada for embedded systems but I was
>obviously a bit naive.

With all due respect, it is a mystery to me how anyone could have expected
a posting whose title is
	"Ada is almost useless..."
to be perceived as anything other than flame bait.  When the first thing you
say is, in effect, "I know you have nothing worthwhile to tell me", you have
no right to be surprised if you fail to receive the response you expected.

>1) Strong Typing is also very good if you have a large system with a
>large number of programmers. Obviously it is advisable to catch errors
>as early as possible as the later you find them, the more expensive
>they tend to be to find. Also I have seen an article on 'lint' and its
>usage and there are some very good points in it related to the fact
>that it gives a lot of detail about trivial errors which can lead to
>the user unintentionally ignoring the serious errors!

In defence of Lint, I have to say that all of the things it reports are
likely symptoms of serious errors, and that it is next door to impossible
to UNINTENTIONALLY ignore the serious errors.  The only way you can ignore
the serious errors is by not tracking down all the lint reports to see how
serious they are.  A typical experience with someone else's code might be
	- 16 000 lines of source code
	-  1 000 lines of lint warnings
	-     10 hours checking the lint warnings
	-     10 days fixing the serious bugs.
Many categories of warnings can easily be switched off.

There are two real problems with lint.
(1) The declarations of C do not provide enough information for really
    effective checking.  (E.g. all integer types are compatible.)
(2) There are legions of C programmers who apply lint, if at all, far too
    late in the life cycle, after they have already populated their code
    with tons of lint.


>2) Bitwise logical functions - can be used on one dimensional packed
>arrays of booleans.  

But you didn't need the net for this.  It's in the manual!
Think "logical", find "logical operators" in the Ada83 LRM, go to
section 4.5.1 "Logical Operators and Short-Circuit Control Forms",,
and there staring you in the fact is a table that says 'and', 'or',
'xor' apply to "array of boolean components".

>3) Enumeration representation clauses - I knew that I could get round
>the problem I described and I now also know the reasons why the
>restrictions exist although I have not really changed my opinion on
>that point. Richard O'Keefe pointed out the Ada 95 definition of these
>clause, but I have not managed to obtain the Ada 95 LRM yet to get the
>exact context so I cannot really comment for the moment.

For the sake of completeness, I should point out the possibility of generating
the Ada source text.  I can well imagine that if your primary source for the
names and values of the enumeration literals puts them in some funny order,
then you might want the manually edited document to have them in the same
order so that they can be the more easily checked.

Let your codes document have the form

	<number in decimal>	<identifier>	<optional comment>
	...
	<number in decimal>	<identifier>	<optional comment>

with the entries in the order of your primary source.  Call this file
	typename.org

You want to generate
	type <type name> is (
	 <identifier>	-- <optional comment>
	...
	,<identifier>	-- <optional comment>
	);
	for <type name> use (
	 <identifier> => <number>
	...
	,<identifier> => <number>
	);
in a file called
	typename.ada

Put the following shell script in a file called mk-ada-enum:
#!/bin/sh
typename=$1
echo "type $typename is ("
echo "for $typename use (" >$$.use
separator=" "
sort -n | while read number identifier comment ; do
    echo "$separator$identifier	-- $comment"
    echo "$separator$identifier => $number" >>$$.use
    separator=","
done
echo ");"
echo ");" >>$$.use
cat $$.use
rm $$.use

Use it like this:
	mk-ada-enum "Ada_Type_Name" <typename.org >typename.ada

For example, I put these lines in "funny.org":
	4	foo	"d" is not supported
	1	bar	not a wet one
	3	ick	the shut down signal
	2	ugh	response to the shut down signal
Running "mk-ada-enum Funny <funny.org >funny.ada" produced this output:
type Funny is (
 bar	-- not a wet one
,ugh	-- response to the shut down signal
,ick	-- the shut down signal
,foo	-- "d" is not supported
);
for Funny use (
 bar => 1
,ugh => 2
,ick => 3
,foo => 4
);

It isn't pretty, but that doesn't matter, because you maintain the table,
not the generated Ada code.  (The scripting language isn't important; if
it were in TCL I could run it on a Macintosh.)

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Ada is almost useless in embedded systems

[Ken Garlington]

AdaWorks wrote:
> 
>   So what is the criteria you use for selecting a programming environment?
>   The overriding issue is whether one wants a language in which the compiler
>   catches most of the errors.  If the answer is, "Yes," the correct choice
>   is Ada.  If it is, "No," use something else.

Actually, I think you short-change Ada here. Another question to ask is: Who will
need to read the software?

I have been very impressed with the readability of (well-written) Ada, particularly
by non-software engineers. If a hardware engineer wants to read our software to
understand how it manipulates the hardware, he can read it with only infrequent
access to any manuals, etc. If a system test engineer wants to read our software
to understand a data structure or algorithm, no problem. Even a (shudder) customer
with little software expertise can review our code and understand with very little
assistance.

I have also seen these same engineers presented with a C++ program. First, out come the
manuals...

Re: Ada is almost useless in embedded systems

[Ken Garlington]

AdaWorks wrote:
> 
>   Whatever reasons you may have are not relevant given Ada's record of
>   success.

I think that's a little harsh. Certainly with Ada 83 (which was the original
context of the topic), there were problems with using it for certain classes
of embedded systems - some technical, some not. None of them were insurmountable,
but they existed.

The point is: Ada is no longer Ada 83. Some of the Ada 95 revision requests were 
written by people with the same gripes as Mr. McCabe, and those RRs were 
incorporated into Ada 95 where possible. As a result, I think Ada 95 is a better 
language for embedded systems programming than Ada 83, and so the Ada 83 
experience is becoming obsolete from the technical side. From the non-technical 
side (compiler maturity, cost, etc.) the Ada 95 world is also much improved from 
the early days of Ada 83.

Re: Ada is almost useless in embedded systems

[Hugh Dunne]

AdaWorks wrote:
> 
> Joe Gamache (jgamache@mailgw.sanders.lockheed.com) wrote:
> : In article <824056183.18993@assen.demon.co.uk>,
> : john@assen.demon.co.uk says...
> : >
> 
> : >1) Strong typing is very good if your coders are learners or
> : possibly
> 
>   The fact that several contibutors to this thread are focusing their
>   comments on "strong typing" indicates that there are still a large
>   number of software practitioners who do not understand the underlying
>   rationale for Ada.
> 
>   Ada is not about strong typing.[snip]
>   So what is the criteria you use for selecting a programming environment?
>   The overriding issue is whether one wants a language in which the compiler
>   catches most of the errors.  If the answer is, "Yes," the correct choice
>   is Ada.  If it is, "No," use something else.  Decide on your criteria and
>   the select the language.  As for me, I am not very smart, so I like to
>   use a language that helps me avoid stupid misteaks. [sic]  :-)

Good point. Strong typing is part of a larger issue: having the compiler
catch as many mistakes as possible. I can't think of a situation where it's 
preferable to have the application crash at run time, or worse still, silently 
give wrong answers.

Another meta-issue is having code that is readable and self-documenting. This
is _not_ just for the benefit of novice coders. No matter how expert your
fellow team members are, give them a break and things will go more smoothly
for the whole team. Even if you're a one-person team, remember that the code
you write today may have to be set aside for a while and then looked at again.
A little foresight will pay dividends.

Of course Ada by itself doesn't guarantee readable code, but it does make it
easier for a conscientious programmer to produce readable code. Very often
you can produce a code fragment which looks almost exactly the same as the
text of the requirement. You don't have to mess around with the ampersands,
asterisks and various dingbats that are unavoidable in C and C++.

-- 
-----------------------------------------------------------------------------
Hugh Dunne/Logica UK Ltd/Medina House/Randalls Way/Leatherhead KT22 7TW/UK
dunneh@lhd.logica.com +44 171 637-9111 x5973           http://www.logica.com/
DISCLAIMER: Any opinions expressed are those of the author and not of Logica.

Re: Ada is almost useless in embedded systems

[Fergus Henderson]

john@assen.demon.co.uk (John McCabe) writes:

>dewar@cs.nyu.edu (Robert Dewar) wrote:
>
>>pragma Volatile is identical to the volatile keyword in C. Most people, even
>                    ^^^^^^^^^
>I mentioned somewhere else that I believed the volatile qualifier in C
>could be ignored by the compiler. Can youo confirm that, and if this
>is true, is it the same for Ada 95?

No, C and C++ compilers can't ignore the volatile qualifier.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

Re: Ada is almost useless in embedded systems

[Alan Brain]

>In article <824056183.18993@assen.demon.co.uk>, john@assen.demon.co.uk (John McCabe) writes:
>> 
>> 
>> 1) Strong typing is very good if your coders are learners or possibly
>> not very good,

Agree. Mice ditto. Keyboards as well. Real Programmers use the Front 
Panel switches, and have their teeth filed to bite holes in the punched 
cards. Anyone who uses Keyboards is a Wimp, Loser and Weenie who does not 
understand Machine Code, and who makes mistakes when coding in binary. 
001000110110 obviously shows which registers you're using, which ALUs and 
even which communications pipeline you have. It is terser (only 2 
different possibilities in each position) and more powerful than 
favourites of the aforementioned Wimps, Losers and Weenies such as 'for 
i++:'.

Sorry, Flame off. But this supercilious balderdash has been repeated too 
long for me to let it go unchallenged.

Look at the recent Byte article "Why Software Projects Fail". One of the 
Cardinal rules set forth for success is to use Assertions. A lot. Any 
Strongly typed language automatically provides sanity-checks every time 
you do an operation, without you having to code it handraullically.

I've programmed for over 20 years in various assemblers, Fortran II, 
Fortran IV, Cobol, Forth, Trac, PLZ/Sys, Ada95, and coded large projects 
in Assemblers, APL, Fortran 77, CMS-2M, CMS-2Y, Meta, C, SMR-2, Pascal, 
Basic (for my sins..), and Ada 83.

I've written complete accounting systems (Client-Server using a GOSH-WOW 
5 Mb!!! Hard Disk costing many thousands of $) in APL. It was Terse. And 
Powerful. But write-only.

I've written hard real-time systems in C, from being involved in the 
second port of Unix into C in 1976 at Sydney University.

Since 1983, I've been working 90% in Ada, 10% in C ( and some C++ 
recently).

I'm sure the next time a significant advance in the art comes along, 
people will complain that Real Programmers use Ada 95, and only Wimps, 
Losers and Weenies use a Virtual Reality Programming System, which is 
only "good if your coders are learners or possibly not very good.".


In the meantime, I'd say that C is great for ameteurs in small projects, 
( hey, even I'd prefer it in many circumstances ), but Ada X, Modula Y or 
Eifel are the languages of choice for professionals who aren't slaves to 
COBOL.

  

Re: Ada is almost useless in embedded systems

[AdaWorks]

Ken Garlington (GarlingtonKE@lfwc.lockheed.com) wrote:
: AdaWorks wrote:
: > 
: >   Whatever reasons you may have are not relevant given Ada's record of
: >   success.

: I think that's a little harsh. Certainly with Ada 83 (which was the original
: context of the topic), there were problems with using it for certain classes
: of embedded systems - some technical, some not. None of them were insurmountable,
: but they existed.

  Well, OK, all right, Ken.  I do somemtimes tend to hyperbole.  
  However, the main point is that Ada (even Ada 83) has been used
  successfully for a large variety of projects, both embedded and
  non-embedded.  While it is true that Ada 83 had its difficult 
  issues (or Ada 95 might have been superfluous), it was possible 
  to overcome these difficulties when they manifested themselves.

  I wonder if anyone can cite a high-level language that has no
  difficulties.  

  Regarding your point in an earlier posting about my understating the
  value of Ada, I plead guilty. My purpose was to summarize what
  I see as two important contributions of Ada, but with no intention
  of nullifying any of the other important benefits of the language.
  Certainly, we each have our favorite features about the tools
  in our toolset.  

  Richard Riehle
  adaworks@netcom.com
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada is almost useless in embedded systems

[R.A.L Williams]

In article <4gea0h$ckd@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

> ralw@valiant.gmrc.gecm.com (R.A.L Williams) writes:
> >To be honest, the engineer in charge of the development didn't
> >even consider using Ada but, if he had, I would have advised strongly
> >against it because, leaving aside the issues of large projects and
> >portability of representation, Ada (83 at least) is IMO far harder to
> >use than C.
> 
> This statement, coming from someone with such a background, deserves
> a fuller exposition.  I hope R. A. L. Williams will provide one.

The specification for some of the data formats had things like:
- values split across several bit fields, ie.
   a bit of A
   a bit of B
   some more of A
   the rest of B
- bit reversed values
- fixed point numbers with 'weird' resolutions.

OK, so Ada (83 and 95) can handle all these things. 95 far easier than
83 I suspect (modulo types are a tremendous improvement for example).
My attitude to this sort of thing is that you find the right tool for 
the job. I strongly suspect, based on my experience with Ada 83 at
least and having seen the solution in C, that any solution is bound to
be pretty much unreadable because of the nature of the problem. That
said C seems to be the better tool for this particular type of low
level manipulation because it is, basically, a high level assembler
and, as such, has syntax and semantics which maps very directly to the
architecture of the 'typical' CPU. Ada implements a higher level
abstraction which, although useful for writing 'high level'
applications, makes it comparatively clumsy for this sort of low level
code. Essentially what I am saying is that, where this sort of low
level manipulation is required using Ada will tend to obscure the
solution because of its high level abstraction where C, which is
inherently low level, expresses it succinctly.

Of course, the decision must look at the whole problem. In the system
discussed above there was very little else. We do a lot of this sort
of thing - interfaces between existing pieces of kit which are too
complex to implement entirely in hardware - and, franly, C is still
the ideal language. If there had been significant other processing or
control to do we might have looked at Ada or C++ or a mixed language
solution. As it was, these other choices were sub-optimal.
> 
> My personal experience, having used C since 1979, and Ada only for the last
> couple of years, is precisely the opposite.  I consider myself expert in C;
> perhaps that's why I thought it was hard to use.  I may say that it seems
> to be easier to _teach_ Ada than to teach C; you can get a heck of a long
> way without worrying about pointers, and it is so refreshing to be able to
> answer questions of the form "how do I do X" with "well, it's really a topic
> for later, but here's how you do it in Ada" instead of "well, there's no
> language support for that in C in order to keep the compiler simple back in
> the 70's."
> 
That's an interesting point. Ada certainly makes it easy to avoid the 
normal C beginners mistakes. Also, of course, we don't normally let
beginners loose on implementing devious embedded systems so the places
where the issue we're discussing is relevant don't arise.

> (I hope this crashes before the written-in-C operating system crashes again...)
> 
On our network it's the P(ersonal) C(atastrophes) that cause all the
problems. What do Microsoft use?
> -- 
> Election time; but how to get Labour _out_ without letting Liberal _in_?
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Bill Williams
-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 478639

Re: Ada is almost useless in embedded systems

[Norman H. Cohen]

In article <9603131418.AA01642@eight-ball>, Bob Crispen
<revbob@EIGHT-BALL.HV.BOEING.COM> writes: 

|> What I'm shocked at is that Ada stopped at 16!  How hard would it have
|> been to permit *any* numeric base?  Anyone who's ever written a Forth
|> compiler knows how simple it is, and how useful things like base-36
|> encoding can be.  How many encoding/decoding routines have been written
|> that could have been obviated by making the compiler do this work?

And for bases 37 and higher, from what alphabet do you choose the digits
for 36, 37, 38, ...?

Let's face it, based literals were placed in Ada to provide a clear
correspondence with bit patterns and with specifications expressed in
binary, octal, or hex.  Has anybody out there ever found a genuine
application for literals in any of the bases 3 .. 7 | 9 | 11 .. 15?

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada is almost useless in embedded systems

[Robert Dewar]

Norm Cohen asks

"Let's face it, based literals were placed in Ada to provide a clear
correspondence with bit patterns and with specifications expressed in
binary, octal, or hex.  Has anybody out there ever found a genuine
application for literals in any of the bases 3 .. 7 | 9 | 11 .. 15?"

In Ada 83, 3#0.1# is a nice way to write a literal value that is
exactly 1.3.

In Ada95, with its new rules on static expressions, it works equally
well to write 1.0/3.0, so this is not so important

Re: Ada is almost useless in embedded systems

[Robert I. Eachus]

In article <RALW.96Mar13101857@vulcan.gecm.com> bill.williams@gecm.com writes:

  > When you're inspecting someone elses code I like the shortcuts that the
  > rich C operators give you. My favourite example has got to be the
  > assignment operators, += etc. Take this (contrived) case...

  > How much easier to *require* (by means of coding standards etc.) the
  > first to be written

  >   bibble_bobble.wibble_wobble += 3;...

  > And what if the coder had actually meant

  > OK, these names are clearly fatuous. But similar cases *do* arise in
  > complex software where, for perfectly sensible reasons a coding standard
  > requires all variables and structure members to have 'meaningful' names.
  > I don't think Ada is immune to this sort of problem.

   No, but the differnce is cultural, not linguistic.  There have been
programs where I needed to do lots of incrementing and declared:

   procedure Inc(X: in out Integer; Y: in Integer := 1) 
   is begin X := X + Y; end Inc;
   pragma Inline(Inc);

   ...and then went and used it all over.  I even had one program that
provided half a dozen similar operations, and instantiated it for
several integer types.  Note that I COULD have written things in terms
of the 'SUCC attribute, but the Ada cultural convention seems to be to
only use 'SUCC and 'PRED for enumeration types, or generic formal
enumeration types.
  
  > > (6) Strong Typing: In the Ada code, the type casting is and must
  > >     be explicity coded.  This provides secure compile-time
  > >     documentation of how big each integer is at each step. This
  > >     is especially useful when you are doing something tricky,
  > >     like writing over memory in a segment register.

  > I approve of strong type *checking*. As we all know (except those
  > who either never write any 'difficult' apps. or never test what
  > they write) type mismatches are a major cause of errors. What
  > irritates me about Ada (and Eiffel is even worse!) is that when *I
  > know* that what I am doing is desirable and correct the language
  > won't let me produce a concise and easily readable expression of
  > it. And, no, I don't consider having to declare my conversion
  > routines in one part of a program so I can use them elsewhere a
  > particularly neat way of solving the problem. Ada deliberately
  > makes it 'unpleasant' to do an unchecked_conversion. IMO it goes a
  > bit too far.

    Ah, but in Ada CHECKED conversions are easy to write and don't
require declarations.  

    In Ada "X := Float(Y);" does just what you would expect, convert Y
to Float and assign it to X.  It is defined for Y of any numeric type.
In fact, when you declare any numeric type you also implicitly create
such a conversion operation.  You also get well defined conversion
operations with derived type declarations, and with many array
declarations.  It is only where you need to convert between types with
no obvious mapping, or when you specifically want no checking, that
you have to resort to Unchecked_Conversion.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada is almost useless in embedded systems

[Kevin Dalley]

>>>>> "Laurent" == Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> writes:

> Scott H. James writes

> : (5) Verbosity: Ada has all of C's unary and binary operators, but Ada
> :     requires C's assignment operators to be spelled out. This is an
> :     aesthetic issue, and possibly a readability issue.

> Readability  for what ???  I always thought that a+=b  was  a hint for
> poor optimizers. But that's a matter of taste ;-)

I once thought that.  Currently, I find that it is more clear for
programmers, and less prone to error then spelling out the same same
variable twice.  This is particularly true if the variable name is
long, for example an element of an array or of a structure:

	fred->array[x+i] += 5;

is much easier for a human to understand than:

	fred->array[x+i] = fred->array[x+i] + 5;

and easier to distinguish from:

	fred->array[x+i] = fred->array[x+i-1] + 5;

kevin

-- 
kevin
kevin@aimnet.com

Re: Ada is almost useless in embedded systems

[Robert Dewar]

Peter Herman said

"Ada200x possibly going up to 36 could be useful for encoding
numerical material into non-critical (i.e. no control chars)
ascii-sequences while saving space, formed by a-z+0-9"

I don't believe this justification for a moment. Peter, please write
some real code using this wonderful new feature, and I will bet you
that it can be done much better in some other manner.

Re: Ada is almost useless in embedded systems

[Stephen Crawley]

In article <4ichi8$17tg@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>In article <9603131418.AA01642@eight-ball>, Bob Crispen
><revbob@EIGHT-BALL.HV.BOEING.COM> writes: 
>
>|> What I'm shocked at is that Ada stopped at 16!  How hard would it have
>|> been to permit *any* numeric base?  Anyone who's ever written a Forth
>|> compiler knows how simple it is, and how useful things like base-36
>|> encoding can be.  How many encoding/decoding routines have been written
>|> that could have been obviated by making the compiler do this work?
>
>And for bases 37 and higher, from what alphabet do you choose the digits
>for 36, 37, 38, ...?

Kanji?  We should be able to handle bases of a hundred thousand or so
if we try hard enough.

[Don't try this at home kids :-)]

-- Steve

Re: Ada is almost useless in embedded systems

[Peter Hermann]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:
: And for bases 37 and higher, from what alphabet do you choose the digits
: for 36, 37, 38, ...?

: Let's face it, based literals were placed in Ada to provide a clear
: correspondence with bit patterns and with specifications expressed in
: binary, octal, or hex.  Has anybody out there ever found a genuine
: application for literals in any of the bases 3 .. 7 | 9 | 11 .. 15?

it's nice to have this, e.g. for education or various math situations,
practical "exact" input of numbers with properties of a certain base, etc.
(e.g. input of 1/3 , 1/7, etc.)

Ada200x possibly going up to 36 could be useful for encoding 
numerical material into non-critical (i.e. no control chars)
ascii-sequences while saving space, formed by a-z+0-9

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Ada is almost useless in embedded systems

[David Weller]

In article <dirk.827148504@demokrit>,
Dirk Dickmanns <dirk@demokrit.informatik.unibw-muenchen.de> wrote:
>-- The second argument should be named "by" giving
>Increment(foobar, by => 5);
>-- for those formerly hurt by some assembler's sequence of operands/result,
>-- especially when using an assembler command as name for a function :-)
><picky mode off>
>

I like that.  I've also suggested
	Obj'Inc(Amount) and Obj'Dec(Amount)

The problem is that I heard Digital Equipment Corporation copyrighted
the word DEC :-)

( ^^^^^^  How urban myths are started :-)
-- 
		    GNAT = GNAT is Not an Ada Translator
==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller==
Reality: Work, Work, Work, Guitar.         | Plugged: Fender Telecaster Deluxe
Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA

Re: Ada is almost useless in embedded systems

[Alan Brain]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>   No, but the differnce is cultural, not linguistic.  There have been
>programs where I needed to do lots of incrementing and declared:
>
>   procedure Inc(X: in out Integer; Y: in Integer := 1) 
>   is begin X := X + Y; end Inc;
>   pragma Inline(Inc);
>
>   ...and then went and used it all over.  I even had one program that
>provided half a dozen similar operations, and instantiated it for
>several integer types.

Ditto here - mainly using generics. This also gives you the opportunity of 
defining exactly what exception you want raised if you accidentally overstray 
the bounds of the input type.

Hands up all those who have never done i++ and had the result go over the 
intended maximum value of i? Ada won't stop you doing this (ie committing a 
bug) - but will tell you about it at run-time, and allow you to write code that 
will work regardless.

Re: Ada is almost useless in embedded systems

[Laurent Guerby]

Robert Dewar writes
: Laurent said:
: 
: "  BTW, s-imgbiu.ad[sb] in the GNAT distribution will do the dirty work
: with very little  modification   (if you're not afraid  of   copyright
: issues ;-)."
: 
: Why should you be concerned with copyright issues? Just in case people
: don't know, the GNAT runtime library is issues with the following
: copyright notice:

[modified LGPL deleted, but everyone should have carefully read it ;-]

   Sorry  for the  poor wording.   I've  used a   smiley and  the word
"afraid" because  a lot  of people are   simply "afraid" of everything
that seems   to be related with  GPL  (it will  disallow business, etc
...). Of course this is most of the time  nonsense and lack of careful
reading. 

   Instead of spending  $$$$$$ with lawyers, just send  a  mail to the
author  who will be happy to  make his point  clear,  and if needed to
grant you extra permissions if you put  him in the credit section, and
it costs $0.  Human    relationships (and most of  simple   commercial
agreements) don't need lawyers 100% of the time,  only 0.00001% of the
time (well, you can raise this number for some commercial cases ...).

: There was quite a thread on this some time ago, and the above wording,
: resulted (in part at least) from this thread. 

   I hope I won't restart it. Flame by e-mail ...

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada
--  "Use the Source, Luke. The Source will be with you, always (GPL)"
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project)
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat)

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe says

<snip>

>It might be easy to use, but it obviously has nothing to do with
>package Machine_Code, which uses aggregates rather than procedure
>calls. What you describe is more closely related to the approach
>described in th Ada 95 RM as "intrinsic subprograms"

Yes, I've read about them.

>If the compiler you cite calls their package Machine_Code, then it clearly
>is not an accurate Ada 83 implementation, rather it is an impermissible
>extension.

If you remember some of my previous postings etc about my current Ada
compiler, I think you could probably reach the conclusion that _I_
don't think it is an accurate Ada 83 implementation (motive - be wary
of TLD!). It makes me wonder why there is such a fuss about
validation! I know the validation suite is limited in what is actually
checked but this seems a bit outrageous.

>However, in Ada 95, either approach is allowed (package Machine_Code or
<snip>

That does sound better to me (as far as the language is concerned),
but obviously TLD appear to be being a bit strange in their
interpretation here!

>For another example of this, look at the support for machine intrinsics
>in the Alsys x86 technology (that's my design, so I know it well :-)
<snip>

I don't think I'll bother looking for the moment thank you (at least
not until I need to use an x86 compiler) but that approach sounds
similar to the MSPs (Machine Specific Procedures) package that comes
with PSS's compiler. Do you know of it?

>By the way, the plan for GNAT in this area is to define some additional
>attributes which hook into the existing GCC mechanism for assembly
>language inserts (see description in GNU C manual).

Presumably this is related to the C compilers asm("string") call?


Best Regards
John McCabe <john@assen.demon.co.uk>