Newsgroups: comp.robotics,sci.electronics
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!europa.chnt.gtegsc.com!news.sprintlink.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!xanth.cs.odu.edu!maui.cc.odu.edu!hearst.acc.Virginia.EDU!maxwell!gr3k
From: gr3k@Virginia.EDU (Gregory P. Riddick)
Subject: Re: BASIC STAMP ALTERNATIVES--THE STATE OF PLAY
Message-ID: <DA4GzJ.K40@Virginia.EDU>
Organization: University of Virginia
References: <3rjd6c$31h@rodin.tansu.com.au>
Date: Tue, 13 Jun 1995 17:38:07 GMT
Lines: 23
Xref: glinda.oz.cs.cmu.edu comp.robotics:21622 sci.electronics:136378

Peter,
I agree with you wholeheartedly that compiled Basic can be as
fast as C in an imbedded application, and in hindsight that
seemed to be the jist of your post.  About the issue concerning
the usefullness of a compiler for low-end Pic chips, I'm not so
sure.  There are commercial compilers for these chips, but all
the ones I'm familiar with have to work around the tiny
hardware stack and limited memory.  Even the Basic Stamp uses a
software stack to get beyond the two-level limit.  A two-level
stack presents a lot of problems for a compiler.  With a small
amount of program memory, compilers for imbedded applications
often uses subroutines for common expressions as a way of
reducing the size of the object code.  And most arithmetic for
values over a byte use *at least* two nested subroutines( for
PICS).
  So even with straight-line C, compilers need more than a
two-level stack.  It is possible to write a compiler for these
chips, of course, but at the expense of code efficiency and
code size.  People are buying and using C-compilers for low end
Pics, though, so maybe these drawbacks are not overwhelming.
  The PIC16CXX chips are much more compiler-friendly. IMHO the
real benefits of compilers don't start kicking in until you
reach this level.
