In article <f9rlMcEJj5JCFA7$@phaedsys.demon.co.uk>, Chris Hills <c...@phaedsys.org> writes:
> In article <3...@individual.net>, Ulf Samuelsson <ulf@a-t-m-
> e-l.com> writes
>>
>>So what about the IAR EC++ for the AVR?
> 
> of course. My mistake... not withstanding it is EC++ rather than C++.  
> ( I will borrow one  from Jason to have a look at it.)
>  

Also, the Ada gcc front end has been ported to the AVR. (However, since
I don't use AVRs, I don't know how good the port is.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Standard Oil Company of the 21st century

In article <4...@News.individual.net>, Dave Hansen
<i...@hotmail.com> writes
>On Thu, 3 Mar 2005 17:34:52 +0000, Chris Hills <c...@phaedsys.org>
>wrote:
>>but a lot less well supported. It is effectively as dead as Pascal.
>>There is more Forth about than Mod2 and Pascal.
>
>A few years back, GM required the use of Modula-GM for safety-critical
>software, such as that in antilock braking systems.  They may still,
>I'm not sure.  Modula's advantages over C are widely (if not
>universally) recognized.

I think most automotive things have moved to C now. 

>
>>
>>>Hmmm.  Is PLM still around?
>>Yes but not supported at all AFAIK. Though I do have one of the last
>
>Which means "no."  I last used PLM-80 on an avionics project back in
>1983/84.  I recently read that Boeing built the last of that aircraft
>the end of last year.

Actually "yes."  Boeing is not the only user. There are several
aerospace systems in service that still use it. There was recently some
modifications done to one of the systems.  Also some security systems in
current use.  The last Intel PLM compiler I have is dated 1986.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Paul Burke <p...@scazon.com> writes:

> I expect that by the time I retire, assembly will be largely forgotten
> except by compiler writers.

Not really.  Someone has to write all the code that appears between
a system reset and the call to main().  Someone has to write all the
stuff that inside the system libraries (and the C library). 

-- 
Darin Johnson
    Gravity is a harsh mistress -- The Tick

Chris Hills wrote:
> Dave Hansen <i...@hotmail.com> writes
>> Chris Hills <c...@phaedsys.org> wrote:
>>
>>> but a lot less well supported. It is effectively as dead as
>>> Pascal. There is more Forth about than Mod2 and Pascal.
>>
>> A few years back, GM required the use of Modula-GM for safety-
>> critical software, such as that in antilock braking systems. 
>> They may still, I'm not sure.  Modula's advantages over C are
>> widely (if not universally) recognized.
> 
> I think most automotive things have moved to C now.

I certainly hope not.  That in itself would show gross disregard
for safety, and could be the grounds for all sorts of lawsuits and
punitive awards.  Ada would be more reasonable.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:

>> 
>> I think most automotive things have moved to C now.
> 
> I certainly hope not.  That in itself would show gross disregard
> for safety, and could be the grounds for all sorts of lawsuits and
> punitive awards.  Ada would be more reasonable.

Considering that there are quite well known projects, that used Ada, that 
still failed (some in quite spectacular fashion) I would have thought would 
have constituted sufficient evidence that the proogramming language used 
has little to do with the final system safety.

There are constructs in every language that, if used, are probably 
potentially lethal in a system. What seems to be evident, though, is that 
using an inadequately rigourously applied development process leads to 
important facets of the system being missed. Such development processes 
should include plenty of reviews, unit, integration and system level 
testing and reviews of the results obtained.

I am not sure of the current distribution of languages in automotive 
projects at present but I am sure that you will find quite a wide range, 
including assemblers are still in there.

-- 
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>;
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

On Sat, 05 Mar 2005 02:32:18 GMT, CBFalconer <c...@yahoo.com>
wrote:

>> I think most automotive things have moved to C now.
>
>I certainly hope not.  That in itself would show gross disregard
>for safety, and could be the grounds for all sorts of lawsuits and
>punitive awards.  Ada would be more reasonable.

C or assembly coding with a good coding standard and thorough code
reviews will catch much more problems than an Ada compiler alone.

This can be quite critical especially if the Ada users are
overconfident due to "it compiles, it is ready for shipping" attitude.

Paul

On Fri, 04 Mar 2005 22:55:15 GMT, Darin Johnson <darin_@_usa_._net>
wrote:

>Paul Burke <p...@scazon.com> writes:
>
>> I expect that by the time I retire, assembly will be largely forgotten
>> except by compiler writers.
>
>Not really.  Someone has to write all the code that appears between
>a system reset and the call to main().  

Just put the address of the init routine (written in some high level
language) into the reset vector of the processor. The requirement is
only that the high level language can access the processor registers
e.g. as pseudo variables, as many compiler extensions have done for
decades. On critical requirement is that the compiler only use
internal processor registers before the stack pointer and other
critical globally used registers have been set up. 

After the stack pointer(s) have been set up in the high level code,
other registers as well as hardware registers can been set and
interrupt vectors can be written all in the high level language. 

Many high level compilers already have various "interrupt" keywords to
generate a register save/restore preamble, before an interrupt service
routine is started. 

For the startup code, it would be quite trivial to add some kind of
"init" keyword to force the compiler to generate code, which uses only
the internal register and not referencing any external memory, except
through the program counter. In this way, the initialisation code for
any environment (e.g. location of RAM and ROM) could be written in a
high level language for each system separately.

>Someone has to write all the
>stuff that inside the system libraries (and the C library). 

On minicomputers, run time libraries were written in assembler for a
quarter of a century ago. But with 32 bit super minis the situation
changed. For instance, much of the VAX run time library was written in
BLISS, which, IMHO did not generate a very effective code, not at
least compared to current compilers. Assembler was used mostly in
kernel mode code, especially accessing hardware registers, some of
which were processor type specific.

For current small and medium sized embedded systems with a more or
less sensible processor architectures, there are only a few cases, in
which larger routines really needs to be coded in assembly for
acceptable performance. Such routines are typically any extended
precision arithmetics, involving frequent use of the Carry bit, which
is typically not supported in any high level language. Access to
machine specific instructions can be handled with in-line assembly
(which can be disguised as functions) etc. 

Thus, these days there is not much need to be able to write large
assembly programs (except for 4 bitters and processors with awkward
architecture), however, assembly reading skill is still very
important, e.g. in the "init" example in the beginning of this
message.

Paul
  

On Sat, 05 Mar 2005 09:53:45 +0000, "Paul E. Bennett"
<p...@amleth.demon.co.uk> wrote:

>There are constructs in every language that, if used, are probably 
>potentially lethal in a system. 

Yes, these include the assignment statement in most high level
languages, various "move", store" and "out" in various assembly
languages. With a detonator connected to a PC port can be quite
lethal, if an out instruction is executed on that port address. Thus,
all such instructions and constructs should be banned from all
environments :-) :-).

Paul
 

"Paul E. Bennett" wrote:
> CBFalconer wrote:
> 
>>> I think most automotive things have moved to C now.
>>
>> I certainly hope not.  That in itself would show gross disregard
>> for safety, and could be the grounds for all sorts of lawsuits and
>> punitive awards.  Ada would be more reasonable.
> 
> Considering that there are quite well known projects, that used Ada,
> that still failed (some in quite spectacular fashion) I would have
> thought would have constituted sufficient evidence that the
> proogramming language used has little to do with the final system
> safety.
> 
> There are constructs in every language that, if used, are probably
> potentially lethal in a system. What seems to be evident, though, is
... snip ...

Of course a language is not a panacea.  But the appropriate choice
does avoid many errors.  How many C installations do overflow
checking, for example.  How many check a pointer range?  These
things can all produce fatal (in the larger sense) errors without
warning, and the sequences leading to them are easily missed even
by experienced programmers.  I want all the help I can get.

In the particular case under discussion I can envision the
plaintiff showing that previous practice would have detected the
error, and that sloppy programming, penny-pinching, and elimination
of the checks let it go through.  All that remains is to make it
clear to the jury, and the punitive awards should at least match
the potential savings.  The plaintiff can even show that modern
implementations such as Ada are available.  The results will
obviously vary with jurisprudence.

C has its place in critical software, but it is at the periphery,
not at the heart.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Paul Keinanen wrote:
> CBFalconer <c...@yahoo.com> wrote:
> 
>>> I think most automotive things have moved to C now.
>>
>> I certainly hope not.  That in itself would show gross disregard
>> for safety, and could be the grounds for all sorts of lawsuits and
>> punitive awards.  Ada would be more reasonable.
> 
> C or assembly coding with a good coding standard and thorough code
> reviews will catch much more problems than an Ada compiler alone.
> 
> This can be quite critical especially if the Ada users are
> overconfident due to "it compiles, it is ready for shipping" attitude.

I would expect that attitude to be less prevalent with average Ada
programmers than with average C programmers.  The reason being that
the Ada programmer probably has an idea why he or she is using the
language in the first place.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson