Re: Best for small embedded systems - was RE:ada and robots

Re: Best for small embedded systems - was RE:ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

SMTP%"WhiteR@no.spam.please.crpl.cedar-rapids.lib.ia.us" writes:
>  I tend to agree, with the exception that there are a lot of Forth
>users/usages for small, resource constrained, embedded applications.
>You can't beat the memory efficiency.  Difficult to get up to speed
>and be able to _think_ in Forth, but once you do a lone wolf
>programmer can be very very productive (with his personal Forth
>vocabulary of reuseable code).
>
    I think the key is that we're talking about very small
    microcontrollers which are programmed by a single individual (or
    maybe one programmer and one or more domain experts.) For the
    "lone wolf" programmer on a smallish sort of job, you want to go
    with a) inexpensive, readily available target processor, b) the
    least expensive, most readily available development environment
    and c) what the "lone wolf" is most familiar with.

    Ada is great and for me, satisfies item "C". The problem is item
    "B" for most of your microcontroller projects. The development
    cost *is* the lifecycle cost, so you can't afford to spend a lot
    of time or money trying to get a language targeted to the
    processor. If it isn't already on the shelf and available at
    nominal cost, it looses. Sorry that life isn't fair to computer
    languages.

>  But for those medium to large (with a lot of floating point)
>embedded applications which involve team programming Ada seems, IMHO,
>to work best.  Also it tends to be much easier to maintain when
>revisited by new personnel years later.
>
>
    I'll agree - although the "with a lot of floating point" part
    confuses me. Is this because Forth doesn't handle floating point
    particularly well? (I don't think Ada is head-and-shoulders above
    most other languages in its ability to do floating point.
    Certainly C has the ability to do floating point - albeit without
    the nice safety nets of strong typing, constraint checking, etc.)

    Our engine control projects tend to run on for *years* (The F119
    Advanced Tactical Fighter control was just ramping up when I got
    here some 8.5 years ago and we're just now going into production
    with it.) Granted, there comes a point where we consider the
    software to be "done" but you're almost forever going in and
    tweaking things because somebody got a performance improvement
    idea or some such. Ada's superior readability contributes a lot to
    being able to toss the software at a new guy and getting him up to
    speed.

    While I'm an Ada advocate, I still believe you have to look at the
    whole project and try to do the right thing by accounting for all
    the various factors. Tiny microcontrollers that already have C or
    Forth compilers, but not Ada compilers stacks the deck against Ada
    in my book.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
West Palm Beach, FL                             Internet:   CONDICMA@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."

        --  G.K. Chesterton
===============================================================================

Best for small embedded systems - was RE:ada and robots

[Robert S. White]

In article <97060510492534@psavax.pwfl.com>, condicma@PWFL.COM says...
>
...
>    Before I start my tirade, let me preface by saying that I *like*
>    Ada and prefer Ada to C. I 'reach', I'm 'of the body', Resistance
>    was futile: I have been absorbed, I am part of The Borg, etc. But
>    that doesn't mean there aren't some valid criticisms of Ada or
>    times when C is more appropriate.
>
>    I believe when the original poster was discussing this issue, it
>    was about small, inexpensive microcontrollers for robotics. I've
...
>
>    The embedded microcontroller market seems to have been conceeded
>    to C for the time being and, especially for student projects,
>    small development jobs and quick&dirty fixes, I'd recommend not
>    spitting into the wind. (You certainly can't argue that life cycle
...
 
  I tend to agree, with the exception that there are a lot of Forth 
users/usages for small, resource constrained, embedded applications.  
You can't beat the memory efficiency.  Difficult to get up to speed 
and be able to _think_ in Forth, but once you do a lone wolf 
programmer can be very very productive (with his personal Forth 
vocabulary of reuseable code).

  But for those medium to large (with a lot of floating point) 
embedded applications which involve team programming Ada seems, IMHO, 
to work best.  Also it tends to be much easier to maintain when 
revisited by new personnel years later.

_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer

Re: Best for small embedded systems

[John Howard]

An Ada 95 subset allowing machine code support of Philips XA will be
offered by my company. An XA is a 16-bit target designed with hardware 
support for real-time multitasking. Further details will be made available
when the product is ready for release.

On Fri, 6 Jun 1997, Marin David Condic wrote:
> "WhiteR@no.spam.please.crpl.cedar-rapids.lib.ia.us" writes:
> >  I tend to agree, with the exception that there are a lot of Forth
> >users/usages for small, resource constrained, embedded applications.
> >You can't beat the memory efficiency.  Difficult to get up to speed
> >and be able to _think_ in Forth, but once you do a lone wolf
> >programmer can be very very productive (with his personal Forth
> >vocabulary of reuseable code).

I started with Forth in 1980 and stayed with it for about ten years. It is 
alot of fun to experiment with. But every project becomes a new dialect of
the language. I used Forth dialects on TRS-80, C-64, Atari 1200, TI 99/4A,
Apple II, Mac Plus, IBM PC, and an i8051 derivative microcontroller. My
experience was that most Forths didn't have a compiler which optimized at
the lowest level. Maintenance of Forth code is typically difficult and
readability is often poor. I appreciated the conciseness of Forth; its
extensibility; and especially the freedom to directly access the hardware.
Still Forth is mainly a working experiment forever in progress. 
Interestingly, Forth is both a language and a virtual machine.

>     I think the key is that we're talking about very small
>     microcontrollers which are programmed by a single individual (or
>     maybe one programmer and one or more domain experts.) For the
>     "lone wolf" programmer on a smallish sort of job, you want to go
>     with a) inexpensive, readily available target processor, b) the
>     least expensive, most readily available development environment
>     and c) what the "lone wolf" is most familiar with.
>
>     Ada is great and for me, satisfies item "C". The problem is item
>     "B" for most of your microcontroller projects. The development
>     cost *is* the lifecycle cost, so you can't afford to spend a lot
>     of time or money trying to get a language targeted to the
>     processor. If it isn't already on the shelf and available at
>     nominal cost, it looses. Sorry that life isn't fair to computer
>     languages.

I think b) should be revised to "the most cost-effective, and easiest to 
use host development environment". It is not necessarily the cheapest but
it should offer tremendous value at an affordable price.
[ My host is OS/2 Warp 4. It lets me dictate text and control development 
  by using my voice. It has other nice ease-of-use features too. ]

To laugh about difficulty-of-use, see the UNIX Haters Handbook
http://catalog.com/hopkins/unix-haters/preface.html

[snip]
>     While I'm an Ada advocate, I still believe you have to look at the
>     whole project and try to do the right thing by accounting for all
>     the various factors. Tiny microcontrollers that already have C or
>     Forth compilers, but not Ada compilers stacks the deck against Ada
>     in my book.
>
>     MDC

I believe it is not worthwhile to target Ada to less than a 16-bit 
microcontroller. Most likely 16-bit microcontrollers will be used instead
of 8-bit microcontrollers. Their prices are becoming similar.

Ada 95 subsets can have big advantages over C and Forth. Classwide 
programming is not provided by C. C lacks inherent support for 
multitasking. Forth is difficult to maintain. Forth and C lack safety 
checks that Ada can provide. Ada subsets are allowed to support efficient
implementations of protected types and multitasking models. And bit-level
handling is inherent to Ada. For these reasons I don't believe Forth or C
are overly strong challenges to an Ada 95 subset which directly supports 
the hardware of an advanced 16-bit microcontroller.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

Re: Best for small embedded systems

[David Kristola]

In article 100000@sky.net, John Howard <jhoward@sky.net> () writes:
>An Ada 95 subset allowing machine code support of Philips XA will be
>offered by my company. An XA is a 16-bit target designed with hardware 
>support for real-time multitasking. Further details will be made available
>when the product is ready for release.

Great!

>On Fri, 6 Jun 1997, Marin David Condic wrote:
>> "WhiteR@no.spam.please.crpl.cedar-rapids.lib.ia.us" writes:
>> >  I tend to agree, with the exception that there are a lot of Forth
>> >users/usages for small, resource constrained, embedded applications.
>> >You can't beat the memory efficiency.  Difficult to get up to speed
>> >and be able to _think_ in Forth, but once you do a lone wolf

I did not think it was hard to think in Forth, but then i am a stack
oriented person (you should see all the stacks of paper on my desk ;-).

>> >programmer can be very very productive (with his personal Forth
>> >vocabulary of reuseable code).
>
>I started with Forth in 1980 and stayed with it for about ten years. It is 
>alot of fun to experiment with. But every project becomes a new dialect of
>the language. I used Forth dialects on TRS-80, C-64, Atari 1200, TI 99/4A,

Ah yes, Forth on the TI 99/4A.  That brings back some great memories.

[snip]

>Ada 95 subsets can have big advantages over C and Forth. Classwide 
>programming is not provided by C. C lacks inherent support for 
>multitasking. Forth is difficult to maintain. Forth and C lack safety 
>checks that Ada can provide. Ada subsets are allowed to support efficient
>implementations of protected types and multitasking models. And bit-level
>handling is inherent to Ada. For these reasons I don't believe Forth or C
>are overly strong challenges to an Ada 95 subset which directly supports 
>the hardware of an advanced 16-bit microcontroller.

How much of a subset are we talking about (it seems that most of the
language is included if you support classwide proramming, multitasking,
and protected types).  I would hope that generics are not left out.
Can you say, or will i have to wait for the official release? :-(

>------------------------------------------------------------------------
>-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --
>



---
--david kristola (not speaking for Lockheed Martin or SAMCO)
(My news reader does not understand the firewall, oh well, automatic spam shield)
Home: David95037 at aol dot com
Work: don't bother, this account will be gone in a few days.
Spam: eat-spam-and-die@dev.null

Re: Best for small embedded systems

[John Howard]

On 11 Jun 1997, David Kristola wrote:
> How much of a subset are we talking about (it seems that most of the
> language is included if you support classwide proramming, multitasking,
> and protected types).  I would hope that generics are not left out.
> Can you say, or will i have to wait for the official release? :-(

Bear in mind that this is a subset of Ada 95. The subset will be expanded
with each successive major version. Tentatively the product will be known 
as DesignDoc (tm) for XA. It is hosted on OS/2 Warp 4 using OpenDoc.

Firstly, I do not intend to validate the compiler for this version.
Secondly, some of the core Ada 95 is absent but may be added later.

Generics and classwide programming are absent in the first version.
The Interfaces package is not supported (since there is no legacy code).
Text_IO and Wide_Text_IO are not supported (no default output device). 
Command_Line is not supported (no default input device). Support for
Strings and Numerics packages are minimal but will be expanded. etc...

As a subset for a 16-bit target, the focus of support is unique. A 
priority has been for the kernel to provide efficient multitasking on a
Philips XA. Further information will become available when the subset is 
officially released. I can't say when that will be. Nor can I provide 
further details until then.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

DesignDoc is a trademark of Howards L.L.C.
Other company, product, and service names mentioned may be trademarks or
service marks of others.