From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: John Howard Subject: Re: Best for small embedded systems Date: 1997/06/10 Message-ID: #1/1 X-Deja-AN: 247503637 References: <97060615152267@psavax.pwfl.com> Organization: SkyNET Corporation Newsgroups: comp.lang.ada Date: 1997-06-10T00:00:00+00:00 List-Id: 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 -- Team Ada Team OS/2 --