Re: CPU recommendations from an Ada perspective?

Re: CPU recommendations from an Ada perspective?

[Ted Dennison]

In article <nJEU3.1529$G51.395421@news.wenet.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:
> against) those 32 bit CPU families which are supported by good Ada
> tools. The project would be a large engine controller, with control
> loops running at 5 mS, 20 mS and 2 sec (don't yet know the details on
> the calculations involved).  Rough industrial setting (temperature
> extremes, electrical noise, etc).  We'd probably by COTS hardware, but

If you are looking to reduce hardware expenditures, I know of at least
one engine controller that was done for the navy using PC-based hardware
and GE Fanuc I/O control blocks. On the ship shock and vibration was our
main concern, so we found a moderately rugged touchscreen PC with PCMICA
support, and replaced its hard drive with a solid-state PCMCIA hard
drive. With a bit of hoofwork by your EE/ME folks, you might be able to
come up with some PC-based solutions that will work in your environment.

But the neat thing is that it ran NT (insert laughter here). Yeah, yeah,
I know; but that meant we had a relatively large range of tools and
vendors to choose from for our software development environment.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: CPU recommendations from an Ada perspective?

[Marin Condic]

Mike Silva wrote:

> I'm reluctant to ask this question because it's so vague at this point, but
> my curiosity has won out.  I'd like to hear any recommendations for (or
> against) those 32 bit CPU families which are supported by good Ada tools.
> The project would be a large engine controller, with control loops running
> at 5 mS, 20 mS and 2 sec (don't yet know the details on the calculations
> involved).  Rough industrial setting (temperature extremes, electrical
> noise, etc).  We'd probably by COTS hardware, but that's not entirely
> decided.  Any opinions / experiences?
>

FWIW, we've built engine controllers out of M680x0's and Mil-Std-1750a's and
had no real hardware problems with them. Ada support has been mostly with the
XD-Ada compiler for both targets. We plan on doing the next generation of
control using the PowerPC chip. Of course, all the electronics are custom built
for the harsh environment and we're not using the dime-store cheapo chips
either. (It used to be all Mil-Spec hardware until the Mil decided to stop
Spec-ing it.)

We've also mucked about with a computer built for the Dodge Neon which was
encased in jello and would have been expected to drive a rocket engine. (Due to
cutbacks and the fact that all us software guys are quitting, it will never
drive a real engine so we probably won't find out if chilling it down and
heating it up would make it break. ;-) Of course it was entirely too small to
do much of anything besides turn some valves on and off and hit the igniter.
You couldn't do much in the way of any real serious control laws with this box.
{No Ada, either :-( }

The 1750a just barely had enough room to do "real" control laws for a rocket
engine and I don't think we could get the rad-hard versions of the chip anyway,
so its pretty dead.

For us (or, more realistically, those who will follow after me) the future
looks to be PowerPC with the Aonix compiler. You never get everything you want,
but the setup looks pretty good!

MDC
--
Marin David Condic
If you hurry, you may still find me for a while at.......
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: CPU recommendations from an Ada perspective?

[Rakesh Malhotra]

Mike

I am a little unclear as to what the questions is here - are you asking
about 32 bit CPUs or Ada support for these CPUs ?    I'll try and answer
both.

I've been developing embedded applications using 32 bit CPUs for many
years.  The CPUs have been Motorola ones - 68302, 68332, 68030 and
68360.  All of them are 32 bit CPUs.  I have used Ada and C,C++ with all
these CPUs and have not had any trouble with Ada support on them.  
There are quite a few Ada compiler vendors who support these CPUs.  And
Ada itself is excellent as a programming language.

(A bit off topic) In fact, I am presently working on an embedded box
which has 1 68332 and 4 68302's and we are implementing the software in
C, C++, proprietary RTOS.   In spite of using PC-Lint on our code it is
interesting to note that we have to find many bugs at runtime - most of
these bugs just would not have happened if Ada had been used.  (Not only
would the bugs not be there but the overall software would be better
designed - we do use a lot of Ada here, just that this project was a
pre-existing product already done in C). 

I have also used a couple of Intel CPUs (8085, 8086, 8088, 80186 - not
with Ada) but my personal preference is for the Motorola ones.

--
Rakesh
Opinions expressed are personal ones.

Mike Silva wrote:
> 
> I'm reluctant to ask this question because it's so vague at this point, but
> my curiosity has won out.  I'd like to hear any recommendations for (or
> against) those 32 bit CPU families which are supported by good Ada tools.
> [snip]
> Mike

CPU recommendations from an Ada perspective?

[Mike Silva]

I'm reluctant to ask this question because it's so vague at this point, but
my curiosity has won out.  I'd like to hear any recommendations for (or
against) those 32 bit CPU families which are supported by good Ada tools.
The project would be a large engine controller, with control loops running
at 5 mS, 20 mS and 2 sec (don't yet know the details on the calculations
involved).  Rough industrial setting (temperature extremes, electrical
noise, etc).  We'd probably by COTS hardware, but that's not entirely
decided.  Any opinions / experiences?

Mike

Re: CPU recommendations from an Ada perspective?

[Tucker Taft]

Mike Silva wrote:
> 
> I'm reluctant to ask this question because it's so vague at this point, but
> my curiosity has won out.  I'd like to hear any recommendations for (or
> against) those 32 bit CPU families which are supported by good Ada tools.
> The project would be a large engine controller, with control loops running
> at 5 mS, 20 mS and 2 sec (don't yet know the details on the calculations
> involved).  Rough industrial setting (temperature extremes, electrical
> noise, etc).  We'd probably by COTS hardware, but that's not entirely
> decided.  Any opinions / experiences?

The PowerPC seems to have the most support from almost every
Ada vendor these days.  It has pretty much taken the place of
the 68K as the premier 32-bit CPU family for embedded development.
That seems to be true whether you are programming in C, C++, or Ada.

> Mike

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: CPU recommendations from an Ada perspective?

[Robert Dewar]

In article <nJEU3.1529$G51.395421@news.wenet.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:
> I'm reluctant to ask this question because it's so vague at
this point, but
> my curiosity has won out.  I'd like to hear any
recommendations for (or
> against) those 32 bit CPU families which are supported by good
Ada tools.


There are really a lot of choices here. Just looking at the
GNAT world, we have customers doing embedded programming using
all of the following chips

ia32
i960
ARC
mips
alpha
m68k
ppc

and I may well have forgotten some. At this stage you can
probably choose the hardware based on the application
requirements rather than development environment requirements
(other vendors also support multiple targets). I am assuming
that you are talking general purpose microprocessors here. If
you move into specialized areas like DSP's, then you need to
do more research!

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: CPU recommendations from an Ada perspective?

[Ada2001]

In article <nJEU3.1529$G51.395421@news.wenet.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:
> I'm reluctant to ask this question because it's so vague at this
> point, but my curiosity has won out.  I'd like to hear any
> recommendations for (or against) those 32 bit CPU families which are
> supported by good Ada tools.

The PowerPC architecture seems to be supported by almost all Ada
compiler vendors.

However I've been curious about a somewhat different question: Which
currently popular CPU family, if any, has an architecture that is
especially well suited for Ada code generation?

My company still uses a proprietary 16-bit stack architecture CPU that
was designed with Ada in mind and it works very well for us.

I've read Tucker Taft's paper on compiling Ada into Java byte codes.  I
came away with the impression that, while it is possible to do, the JVM
is not an optimal architecture for Ada.

I'm currently working on start-up code for an Intel 80386EX bare-machine
target and it's no fun at all. It seems every Intel chip, even a Pentium
III, has to act like an 8088 on power-up for reasons of backward
compatibility with DOS and the original PC architecture. The start-up
code needed to configure the chip for 32-bit flat-memory operation is
rather intricate. [BTW: the best description I've seen of the
awkwardness of the Intel architecture is in Robert Dewar's
"Microprocessors: A Programmers View" book.  I was able to get a copy
from a used book store.  Is there any chance of an updated second
edition, Dr. Dewar? :) ].


F. Britt Snodgrass


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: CPU recommendations from an Ada perspective?

[Sascha Welter]

Ted Dennison <dennison@telepath.com> wrote:

> I know of at least
> one engine controller that was done for the navy using PC-based hardware
> and GE Fanuc I/O control blocks. On the ship shock and vibration was our
> main concern, so we found a moderately rugged touchscreen PC with PCMICA
> support, and replaced its hard drive with a solid-state PCMCIA hard
> drive. With a bit of hoofwork by your EE/ME folks, you might be able to
> come up with some PC-based solutions that will work in your environment.
> 
> But the neat thing is that it ran NT (insert laughter here). Yeah, yeah,
> I know; but that meant we had a relatively large range of tools and
> vendors to choose from for our software development environment.


Please tell me that it wasn't the thing that did a divison-by-zero error
and they had to haul the ship to the port to get it fixed... it could
not believe this to happen if it was programmed in Ada.

Regards,

Sascha

Re: CPU recommendations from an Ada perspective?

[Robert Dewar]

In article <8075qa$cie$1@nnrp1.deja.com>,
  Ada2001 <ada2001@my-deja.com> wrote:
>[BTW: the best description I've seen of the
> awkwardness of the Intel architecture is in Robert Dewar's
> "Microprocessors: A Programmers View" book.  I was able to get
a copy
> from a used book store.  Is there any chance of an updated
second
> edition, Dr. Dewar? :) ].

It is in the works for next year :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: CPU recommendations from an Ada perspective?

[Ted Dennison]

In article <1e0ymjc.1fjcxni1os2v7cN@[192.168.0.5]>,
  swelter@mus.ch (Sascha Welter) wrote:
> Ted Dennison <dennison@telepath.com> wrote:
>
> > I know of at least
> > one engine controller that was done for the navy using PC-based
> > hardware

> Please tell me that it wasn't the thing that did a divison-by-zero
> error and they had to haul the ship to the port to get it fixed... it
> could not believe this to happen if it was programmed in Ada.

Happily. It was not that system. That was done in C (Visual C++ I'd
wager) by our competitors. The demo I saw had it running on Win95,
but I don't know which OS they used on the ship. The mandate was in
force at the time, but they got around it by doing the development under
a R&D contract. I won't mention their name, but their initials are CAE.
:-)

Frankly I'm suprised their system lasted as long as it did. Our system
by contract had to pass rigorous shock and vibe tests, and they still
didn't trust it without a traditional backup system and a manual
workaround. I don't believe CAE had to do any of that.

When I first joined that group I was told about the seriousness of
causing a ship to need a tow. Apparently its a rather humiliating
experience for its captain. So in this group there was nothing (and I
mean NOTHING) more serious than a software problem that causes the ship
to go "dead in the water". Well, you can imagine the cruel glee around
our offices when that ship had to be towed. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: CPU recommendations from an Ada perspective?

[bobplested]

Ted Dennison wrote:

> In article <1e0ymjc.1fjcxni1os2v7cN@[192.168.0.5]>,
>   swelter@mus.ch (Sascha Welter) wrote:
> > Ted Dennison <dennison@telepath.com> wrote:
> >
> > > I know of at least
> > > one engine controller that was done for the navy using PC-based
> > > hardware
>
> > Please tell me that it wasn't the thing that did a divison-by-zero
> > error and they had to haul the ship to the port to get it fixed... it
> > could not believe this to happen if it was programmed in Ada.
>
> Happily. It was not that system. That was done in C (Visual C++ I'd
> wager) by our competitors. The demo I saw had it running on Win95,
> but I don't know which OS they used on the ship. The mandate was in
> force at the time, but they got around it by doing the development under
> a R&D contract. I won't mention their name, but their initials are CAE.
> :-)
>
> Frankly I'm suprised their system lasted as long as it did. Our system
> by contract had to pass rigorous shock and vibe tests, and they still
> didn't trust it without a traditional backup system and a manual
> workaround. I don't believe CAE had to do any of that.
>
> When I first joined that group I was told about the seriousness of
> causing a ship to need a tow. Apparently its a rather humiliating
> experience for its captain. So in this group there was nothing (and I
> mean NOTHING) more serious than a software problem that causes the ship
> to go "dead in the water". Well, you can imagine the cruel glee around
> our offices when that ship had to be towed. :-)

I was talking with a friend about salvage rights in international waters. He
indicated that your ship may be considered salvage even if you're still
aboard and willingly accept a tow. That would be an expensive software
error.

bob

Re: CPU recommendations from an Ada perspective?

[Robert I. Eachus]

bobplested@attglobal.net wrote:
 
> I was talking with a friend about salvage rights in international waters. He
> indicated that your ship may be considered salvage even if you're still
> aboard and willingly accept a tow. That would be an expensive software
> error.

    Correct, and there have been cases where the owner of the vessel
choose to allow the ship and cargo to be salvage rather than pay towing
costs.  (Salvage typically entitles you to 25% of the value of the ship
and cargo, and that is often less than the towing costs demanded.)

    In the case of the Navy, they usually have other ships around that
can do the towing--warships are designed for this--but it is still very
embarrassing outside of combat.
 
-- 

                                        Robert I. Eachus

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