Newsgroups: comp.robotics
Path: brunix!cat.cis.Brown.EDU!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!jonk
From: jonk@netcom.com (Jonathan Dale Kirwan)
Subject: Re: The Design of a BASIC for Embedded Use
Message-ID: <jonkCuF02F.M4F@netcom.com>
Organization: New World Computing Services
X-Newsreader: TIN [version 1.2 PL1]
References: <jonkCuC4B1.LvA@netcom.com> <32c4qa$mtg@ohlone.kn.PacBell.COM> <32c81r$885@rand.org> <jonkCuDG08.Hpo@netcom.com> <32dtpa$4a8@handler.Eng.Sun.COM>
Date: Fri, 12 Aug 1994 09:08:39 GMT
Lines: 158

Chuck McManis (cmcmanis@Sun.COM) wrote:
: I am NOT trying to start a language war, I AM trying to shed some light
: on the embedded programming language issue.

I am old enough that I assume the best from everyone.

: I use icc11, the ANSI C cross compiler from ImageCraft on a 68HC11 with 
: 2K of EEPROM and it works fine. My "null" program with basic support 
: for the 6811's peripherals takes 140 bytes of EEPROM and 4 bytes of
: RAM. (42 bytes of EEPROM are also dedicated to the interrupt vector
: table). 

: Your comment about the linker "sucking in excess baggage" is more a
: testament to bad design than a bad language. The icc11 implemntation
: only "sucks in" what you ask for, and if you are constrained in memory
: you don't ask to use printf. There is a very simple "puts" function
: that is much like "print" in BASIC. 

Yes.  I am not complaining about C.  I have used C since 1979 and C++ for 
the past three years.  I like them and use them frequently.  I have _not_
had an embedded instrument, since 1985 when I started doing this kind of 
work, that I used C with.  My clients love the fact that I can sample an 
A/D at 1Msps, apply logarithms to every data point, compute standard 
deviations to estimate noise, process IEEE 488.2 style commands and 
queries, and produce 5000 measurements per second with less that 2kbyte 
of code.  That's an example, not a challenge.

In that case, it meant the difference between wasting board space and 
other costs on an external memory or saving it.  They liked the cash a 
lot.  I think folks depend on floating-point processors far too much.  
They don't know how to keep and process the data in the integer domain 
until the last possible moment.  Using floating-point costs speed, space, 
and power (to find a chip that supports it in hardware when you need the 
speed.)  I've done floating-point FFT outputs, but performed in the 
integer domain for speed and space savings.  You need to have a handle on 
numerical methods, though.  I think people depend on C compilers and 
BASIC interpreters too much, as well.  Many dollars of savings can be 
had (and some frustration saved, when _that_darned_library_function_ 
turns out to have a side-effect you hadn't anticipated) by staying in 
assembler.

But my digression and your comment about C misses the point.  I didn't
mention some of the difficulties with some C compilers as justification
for my choosing to implement BASIC nor did I intend to begin a debate
about which language is appropriate for which application.  C will be
used.  BASIC will be used.  I don't like the BASIC's I've seen and I know
(because this isn't the first time I've written a BASIC interpreter or a C
compiler) that I can do much better.  BASIC is the language I intend to
perseverate on for the next little while.  Period.  The only question is 
on how best to go about delivering as useful of a BASIC interpreter tool 
as I can.

: Anyway, I also look at the code generated by the compiler and icc11
: does quite well (much better than I've any right to expect for
: a $50 compiler I'd say). I've also heard good things about David
: Dunfield's Micro-C product. Maybe you're just behind the times a bit.

I don't think so.  I am familiar with Dunfield's Micro-C.  It is a good 
product.  (Almost bought a copy for an application, a year back.)

Look, I spent two paid years evaluating compilers for clients, and 
particularly C compilers.  I've worked on modern optimizers for C 
compilers for two RISC chips (new techniques that will be long in coming 
to the PC marketplace.)  I'm familiar with most C compiler products 
and, in particular, their optimizations.  I own compilers from Borland, 
Microsoft, Zortec, Watcom, and Metaware for starters.  And where those 
companies have more than one compiler, I probably own most of them.

I'm as up-to-date as most, I think.

: : I chose to implement a BASIC for a variety of reasons ...

: : The BASIC implementations I've used stink.
: : They are far too slow because their implementation details are archaic.
: : GOTO's are slow because they have to search for the line everytime. 
: : Variable usage is slow because they have to search the symbol table every
: : time.  
: : Math is slow because they don't know how to use Horner's rule and
: : mini-max techniques for transcendentals and they aren't practiced with
: : floating-point, in general.  Etc.
: : My belief is that BASIC interpreters can be much, much faster than 
: : they are.  

: : I plan to prove it. 

: Bravo! If however you figure out that BASIC implementations are slow
: because the _language_ stinks that would add greatly to the general
: knowledge of the net. I know a lot of people think that BASIC stinks
: in principal but rarely have the means to prove it in any objective
: sort of way. I suggest you approach this problem like any good scientist
: would, you have your hypothesis : "BASIC is a good language, there has
: never been a good implementation of the language", and you have your
: experiment "Implementing a BASIC in a good way." (You'll probably need
: to take some time to define "good" both in terms of what it means to
: be "good" and that your definition is a reasonable definition).
: Once you've run the experiment you can publish your findings. Of course
: the more experiments you can run that either support (or disprove)
: your hypothesis, the more weight will be given to your findings.

I must have taken a wrong turn in describing my interest and reasons.  
Not your fault, mine.  Let me take another hack at it...

I'm not interested in proving that one language is better than another.  
I don't think such a question is worth pursuit.  Individuals, working one 
by one, will make those decisions on their own.  I really don't care.

I only argue that the equilibrium point, the balance of those choosing
BASIC for a particular application and those not making such a choice, may
be able to be influenced by a better implementation.  It may not.

But even that point isn't the central issue.  I'm not even terribly
interested to find out.  I am interested in the technical details of doing
the job and doing it well -- analysis, design, and implementation.  It's a
personal challenge, not a scientific investigation.  (I enjoy the math and
physics required to design and build new instrumentation far too much for
such an investigation to even begin competing with my regular work.)

In short, while it is important to me that I be effective in sourcing the
necessary information to develop a good quality concept, develop an
effective and practical design, and then write a clean implementation, it
is certainly _not_ my intent to settle some liguistic debate on the
applicability of one language or another.  That issue of language choice
is moot. 

: : ...  If the assumption that a ready market 
: : would have forced the development of quality tools is a good one, then 
: : it's a sure conclusion that there's little need for another BASIC.

: I'd be careful here if I were you, try not to come to a conclusion prior
: to running the experiment. Another perfectly valid conclusion is that
: the market was unable to produce a quality BASIC in spite of the pressure
: to do so, thus BASIC is unsuitable as a quality language. Now I'm not
: saying this other conclusion is any more true than yours, only that
: without some experimental evidence there is no way to support either
: one. 

Note that my comment was _indeed_ careful.  I did not say that there was 
little need, only that if one were to make the indicated assumption, then
such a conclusion might be reasonable.  In any case, it's not my issue.  
Whether or not one wants to accept such an assumption, the suggested 
conclusion (or it's lack) makes no difference to me.  I will develop the 
BASIC, regardless.  And again, I am not running an experiment.

: You may discover that thinking this way (like a scientist) will often
: save you from coming to incorrect conclusions, and that will save you
: from making sometimes costly mistakes.

I am a theoretical scientist and, where care is appropriate, I believe I
exhibit it.  This was certainly not one of those times.  Some of what I
said was intended to provoke a smirk, or simply nudge one's thoughts down
a particular line, little else.  You apparently ascribed far-reaching
intent where none was meant.  I apologize for leading you in the wrong
direction and I will try to exhibit better care next time.  I only hope 
your interpretations (and patronizing viewpoint) were unqiue in this case.

Jon


