Embedded Basic interpreter recommendations?

On Mar 13, 7:34=A0pm, cfb <cfbsoftw...@hotmail.com> wrote:
> On Mar 13, 2:36=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> > That leaves the problem of the memory image needed for Compile,
> > and I suspect RAM will be the stumbling point, more than Code space.
> > 64K is large RAM on a uC, and very small RAM for a compiler.
>
> Good question. Obviously not an issue when compiling on the PC. I'll
> do some measurements when I have a spare moment.
>
> > I suppose only (very?) small programs would be targeted for 'self-
> > compile'
>
> Small *modules* perhaps - that does not necessarily mean small
> *programs*.

You still need to compile the symbols in all the DEF files, tho I
guess a single pass compiler can spool the output into OBJ files in
SPI/CF memory,
and not keep it in RAM.

The linker has a smaller exe than the compiler, but it needs to read
all OBJ
files and create the HEX file, so a low-memory linker would need
special design ?.
On the PC I've always gone for speed, so this is a little different :)


> > > For the .NETphobes the compiler, linker and loader are both written i=
n
> > > Component Pascal so a Win32 version of the command-line versions coul=
d
> > > easily be built using Oberon microsystems BlackBox compiler.
>
> > So what is .NET being used for ?
>
> All of the standard Windows GUI features and the rest of the IDE - the
> multi-window / multi-file / split-screen, Oberon-07 syntax aware
> editor; the procedure / imports navigator etc. etc.

There are a wide range of editors/IDE around designed for command line
tools
Notepad++ is one, ConTEXT is another.
Could be interesting to see how large these all are, as stand-alone
tools,
and how small the memory usage can be easily pushed to....

>
> > > True. Can't see that size or speed are too relevant though - it's all
> > > in the interest of reliability / security / maintainability /
> > > testability i.e. a return to the old idea of a rigorous single-entry =
/
> > > single-exit approach for all blocks of code. Yeah, I also groan when
> > > I'd really like to code a couple of exits from my loops or procedures=
.
> > > However, although it takes a bit more effort I've found that nine
> > > times out of ten the resulting code is far more digestible.
>
> > You don't sound that convinced either ;)
>
> You guessed it - I'm basically lazy and am as guilty as anybody else
> of risking long term pain for short term gains when I can get away
> with it. It's a heck of a lot easier to just write a LOOP and throw in
> a couple of exits than worry about trying to achieve a good flow of
> control. Not so good a few months later when you have to go back and
> untangle the spaghetti ;-)

I've tended to code three EXITs from LOOPs, in code that
allows more compact results. Typically the top one is a sanity check,
the centre one is the main result, and the bottom one is the 'ELSE'

For Function returns, RETURN compiles directly to RET, which is
always smaller and faster than chained Jumps.

When you are targeting microcontrollers, these details matter - it all
adds up.

>
> > The strangest change I see, is the new WHILE else, called ELSIF..
> > DO ?!
>
> I have to agree. Apart from the example quoted I have yet to find any
> use for it. Can you think of any real-world applications for it?

The claim was it allowed removal of LOOP ?

>
> > Was the paranoia at adding a new explicit and correct keyword so high,
> > that an existing one had to be press-ganged into service ?.
> > ELSIF now means two different things, and is entirely context
> > dependant,
> > which will make reading large blocks of code risky.... (shudders)
>
> Maybe the length of an alternative keyword was a factor in the
> decision? The maximum length of any Oberon-07 keyword is only seven
> characters -

Hmmm...  PROCEDURE is over 7 Chars ?

>  presumably for efficiency reasons. Besides, you wouldn't
> really prefer ELSEWHILE or ELSWHILE would you? ;-)

Well, the word has to be 'english correct' (which ELSIF..DO badly
fails)
and following the ELSIF precedent, we get ELSWHILE..DO ?

-jg

Jon Kirwan wrote:
>
>Guy Macon <http://www.GuyMacon.com/> wrote:
>
>>Jon Kirwan wrote:
>>
>>>There is a definite niche for what you are talking about -- especially
>>>in education.  I don't consider the Parallax BASIC Stamp to be
>>>anything close to as sophisticated, nor as useful for education.,
>>>despite the fact that much better was achieved on slower processors
>>>and with less available code memory.  But it may be the simpler choice
>>>at this time.
>>
>>IMO, the BasicX BX24P stamp is a superior alternative.
>>
>>http://www.basicx.com/Products/BX-24/bx24compare.htm
>>http://www.basicx.com/
>
>I know nothing about it, so you could be right.  However, I have yet
>to see an implementation on micros that comes close -- and with far
>more flash to deal with.  We included matrix mathematics along with
>all the usual transcendentals, conversion to and from very highly
>efficient tokenized code, the interpreter engine and a lot more all
>sitting inside 6k word (12k byte) of code space.  I would very much
>like to see something similarly well done, so I will take a look on
>your assurances.

Sorry for being unclear. Better than the Basic Stamp. Not as good 
as what I used to see on minicomputers with far fewer resources.

I really wish someone would make something that runs on a modern
microcontroller that is as as good as those old BASICs, add 
special capabilities from the stamp world such as PWM and 
reading a pot/capacitor using a digital pin, maybe steal a few 
ideas about structure from QBASIC (which is *not* the same thing 
as QuickBasic) and release it as open source.  The RepRap world
would eat it up.


-- 
Guy Macon
<http://www.GuyMacon.com/>

Guy Macon wrote:

> I really wish someone would make something that runs on a modern

Well, this sounds like an opportunity.

You might make some money off of it.

But, I am sure thats not what you want to hear, so:

http://www.personal.leeds.ac.uk/~bgy1mm/Minibasic/MiniBasicHome.html


don

On Fri, 13 Mar 2009 19:15:22 -0700, don <don> wrote:

>Guy Macon wrote:
>
>> I really wish someone would make something that runs on a modern
>
>Well, this sounds like an opportunity.
>
>You might make some money off of it.
>
>But, I am sure thats not what you want to hear, so:
>
>http://www.personal.leeds.ac.uk/~bgy1mm/Minibasic/MiniBasicHome.html

Hi, Don.  I just scanned the page a little.  It says, "MiniBasic
programs are written in ASCII script. They are then interpreted by the
computer," so it does NOT appear to do anything to the source code
before running it.  Now, that is no different from what a lot of
interpreters do, also.  So it's not a check mark against it.  It's
just not very fast that way.

Some of the things that really counted in terms of speed, back when
processors actually ran at near-1MHz instruction rates (and often
less, for example like the PDP-8/e which was if memory serves
something like 1.4us/cycle), was to replace line numbers with memory
addresses pointing to the statement that possessed it and replacing
variable names with pointers to their entry in the variable table, to
name two of the more important cases.  Expressions were also adjusted
a bit to further improve their execution speed, as they were often the
target of FOR loops and were executed many, many times.  So even a
some improvement went a long way.

Jon

On Mar 13, 5:22=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 13, 7:34=A0pm, cfb <cfbsoftw...@hotmail.com> wrote:
>
> > Small *modules* perhaps - that does not necessarily mean small
> > *programs*.
>
> You still need to compile the symbols in all the DEF files,

These will only be the *public* symbols though. Apart from the big one
- the LPC2000 definitions (which is about 2.6k) the average size of
all Armaide library SYM files is only ~ 170 *bytes*.

>
> > > The strangest change I see, is the new WHILE else, called ELSIF..
> > > DO ?!
>
> > I have to agree. Apart from the example quoted I have yet to find any
> > use for it. Can you think of any real-world applications for it?
>
> The claim was it allowed removal of LOOP ?
>

"As a sort of compensation ..." were the actual words used.

>
> > Maybe the length of an alternative keyword was a factor in the
> > decision? The maximum length of any Oberon-07 keyword is only seven
> > characters -
>
> Hmmm... =A0PROCEDURE is over 7 Chars ?
>

Doh! That's that theory shot down in flames ...

> > =A0presumably for efficiency reasons. Besides, you wouldn't
> > really prefer ELSEWHILE or ELSWHILE would you? ;-)
>
> Well, the word has to be 'english correct' (which ELSIF..DO badly
> fails)
> and following the ELSIF precedent, we get ELSWHILE..DO ?
>

Translating Dijkstra's GCD example using the new WHILE construct into
an equivalent LOOP helps convince me that the right choice of keyword
(i.e. ELSIF vs ELSWHILE) was made. I can see why in this case it might
be considered "a sort of compensation".

New WHILE statement with cascade decisions:

WHILE m > n DO m :=3D m - n
ELSIF n > m THEN n :=3D n - m
END;

Equivalent old LOOP statement:

LOOP
  IF m > n THEN m :=3D m - n
  ELSIF n > m THEN n :=3D n - m
  ELSE EXIT END
END;

--
Chris Burrows
CFB Software
Armaide: ARM Oberon-07 Development System for Windows
http://www.cfbsoftware.com/armaide

On Mar 14, 5:11=A0pm, cfb <cfbsoftw...@hotmail.com> wrote:
>
> New WHILE statement with cascade decisions:
>
> WHILE m > n DO m :=3D m - n
> ELSIF n > m THEN n :=3D n - m
> END;
>

Oops! Correction:

WHILE m > n DO m :=3D m - n
ELSIF n > m DO n :=3D n - m
END;

Chris.

On Sat, 14 Mar 2009 01:01:33 +0000, Guy Macon
<http://www.GuyMacon.com/> wrote:

<snip>
>
>I really wish someone would make something that runs on a modern
>microcontroller that is as as good as those old BASICs, add 
>special capabilities from the stamp world such as PWM and 
>reading a pot/capacitor using a digital pin, maybe steal a few 
>ideas about structure from QBASIC (which is *not* the same thing 
>as QuickBasic) and release it as open source.  
While you are correct about QBasic and QuickBasic not being the same
thing, they both come from a common source code base, IMO.  I have dug
around the insides of all of them, and the common points get pretty
obvious after a while.

>The RepRap world would eat it up.
RepRap ?

QBASIC 1.1 is 194,309 bytes, compressed.  250k or so uncompressed.
And it relies on DOS for file I/O and memory management -- another
100k or so?  Would it even fit on a modern microcontroller? 
-- 
ArarghMail903 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

> > New WHILE statement with cascade decisions:
>
> > WHILE m > n DO m := m - n
> > ELSIF n > m THEN n := n - m
> > END;
>
> Oops! Correction:
>
> WHILE m > n DO m := m - n
> ELSIF n > m DO n := n - m
> END;

I rest my case ;)
I guess they can't always avoid dropping a clanger like this one... ?!
-jg

Guy Macon wrote:

> I really wish someone would make something that runs on a modern
> microcontroller that is as as good as those old BASICs, add
> special capabilities from the stamp world such as PWM and
> reading a pot/capacitor using a digital pin, maybe steal a few
> ideas about structure from QBASIC (which is *not* the same thing
> as QuickBasic) and release it as open source.  The RepRap world
> would eat it up.

:)

Sounds like that was what happened to the current basics.

RepRap is important not in its current form but in its technical
potential. It has gone through a lot of thought development
to the first practical steps now. 30 years ago Jim Albus (not
the golfer the "Behavior and Robotics" guy) and Ernie Kent
had a project at National Bureau of Standards  that
proposed a large scale RepRap that was just not possible
at the time.

There are a couple of language standards that are very
compatible to the modular structure of RepRap. IEC61131
and IEC61499 both do well at programming distributed
systems. Programming is done at the data and event level
where programming modules could be in separate
processors.

Google "The Automated Manufacturing Research Facility"


Regards,

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

On Fri, 13 Mar 2009 04:59:13 GMT, I wrote:

><snip>
>We included matrix mathematics along with
>all the usual transcendentals, conversion to and from very highly
>efficient tokenized code, the interpreter engine and a lot more all
>sitting inside 6k word (12k byte) of code space.
><snip>

Okay.  I just found some of my notes.

We included a lot of stuff for time-sharing, that wouldn't be as
necessary for most embedded application situations.  A system console
and associated commands, parsing for the commands, execution of the
commands, support for swap tracks, teletype tables (ASR-33's, for
example, took longer to handle a CR than they did to handle an LF,
which also took longer than a 'g'), communications buffers and
handling for 32 ports, a scheduler, error handling for the swap tracks
and system death and announcements, file handling and directory
searching routines, to name most of what I see in my notes.

(Most of the system console commands were handled by swapping them
from disk into the user area, so their code didn't occupy the scarce
memory available.)

We also included various output routines that included formatted I/O
and driver support, of course; a compiler and decompiler (to and from
the encoded form that the interpreter execution engine used); the
statement execution engine and main exec loop; formula execution, its
associated library functions and support subroutines; syntax handling
and error reporting; various execution and library utility functions;
a complete matrix execution engine; all the necessary name tables; and
some other things.

All that plus still a fair amount of the system console and all of the
scheduler (obviously) was kept in memory; in 12k byte.

Yes, it was written in assembly.

Jon