Embedded Basic interpreter recommendations?

"Frank Buss" <fb@frank-buss.de> wrote in message
news:1qqbvwpfjwuyq.14j0560xa4itf$.dlg@40tude.net...
>
> Code size and execution time should be no problem, my targets are bigger
> with at least 16k flash and fast. My idea was to start with a virtual
> machine, so I'll compile the program on PC and upload some bytecode, only,
> which should be very compact, too. Maybe I provide multiple frontend
> languages, like Basic, C and Modula. Then the programmer can choose the
> language he/she likes most.
>

In case you missed the link in another branch of this discussion the source
and executables of a Modula-2 compiler that generates bytecode (M-Code as
used on Lilith), an interpreter that runs on the PC, and a sample listing,
in Modula-2, of an M-Code interpreter already exist:

http://www.cfbsoftware.com/modula2

All you need to do is port the interpreter to an MCU and implement a linker
/ loader.

Additional source code for these components are available at the
same site as EmuLith, Jos Dreesen's impressive Lilith emulator:

ftp://jdreesen.dyndns.org/ftp/

Windows / Linux / Mac OS-X versions are all available. Details are in the
readme.txt file there.

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

ArarghMail903NOSPAM@NOT.AT.Arargh.com wrote:

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

>>The RepRap world would eat it up.
>RepRap ?

See my post titled "RepRaps and RepStraps."

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

On Sat, 14 Mar 2009 21:31:25 GMT, Jon Kirwan
<jonk@infinitefactors.org> wrote:

>
>(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.)

Overlay loading was more or less standard practice in minicomputer
programming 30-40 years ago. Opening a file (including file name
parsing) was put into one overlay tree branch and when the file was
successfully opened, the code space was occupied by the actual
routines performing file reading/writing.

Unfortunately this does not work well on current microcontrollers,
since these usually have a very limited amount of RAM and some Harvard
architecture systems do not even allow execution out of RAM.

However, with a microcontroller with 16-64 KiB RAM and even some slow
serial flash memory could be used to run quite complicated systems
with overlay loading. In such systems 16 bit addresses are more than
enough.

Paul
 

On Sun, 15 Mar 2009 14:26:16 +1030, "Chris Burrows"
<cfbsoftware@hotmail.com> wrote:

>"Frank Buss" <fb@frank-buss.de> wrote in message
>news:1qqbvwpfjwuyq.14j0560xa4itf$.dlg@40tude.net...
>>
>> Code size and execution time should be no problem, my targets are bigger
>> with at least 16k flash and fast. My idea was to start with a virtual
>> machine, so I'll compile the program on PC and upload some bytecode, only,
>> which should be very compact, too. Maybe I provide multiple frontend
>> languages, like Basic, C and Modula. Then the programmer can choose the
>> language he/she likes most.
>
>In case you missed the link in another branch of this discussion the source
>and executables of a Modula-2 compiler that generates bytecode (M-Code as
>used on Lilith), an interpreter that runs on the PC, and a sample listing,
>in Modula-2, of an M-Code interpreter already exist:
>
>http://www.cfbsoftware.com/modula2

But the early BASIC I have been talking about included both the
compiler and decompiler, held in 12kbyte of core memory.  No
cross-compilation here.

What I think I'd like to see is the execution engine, which interprets
a coded version of the source, as a required part but with optional
pieces that include the compiler to convert ASCII text into the coded
version that is suitable for interpreting and the lister which
converts the coded version back into an ASCII text version, along with
all the necessary lex/parse and error handling for in-situ use.  I
mean, as optional pieces that one may.. or may not.. decide to link
into the target.  The execution engine would be necessary, obviously,
but the rest is important for interactive development on the target
and should be available, if desired.

And do all of that in a relatively small part of the flash -- which,
if coded carefully and in assembly, should be quite doable.  Not only
does careful coding provide small footprints, but it also provides
faster execution times.  The problem would be that the flash available
seems to grow almost by the month, so maybe no one cares one way or
another and those times are behind us all.

>All you need to do is port the interpreter to an MCU and implement a linker
>/ loader.
>
>Additional source code for these components are available at the
>same site as EmuLith, Jos Dreesen's impressive Lilith emulator:
>
>ftp://jdreesen.dyndns.org/ftp/
>
>Windows / Linux / Mac OS-X versions are all available. Details are in the
>readme.txt file there.

Thanks for the links.  I'm curious and I'll look.  Not hopeful,
exactly.  But I will probably enjoy it very much, regardless.

Jon

On Sun, 15 Mar 2009 07:57:13 +0200, Paul Keinanen <keinanen@sci.fi>
wrote:

>On Sat, 14 Mar 2009 21:31:25 GMT, Jon Kirwan
><jonk@infinitefactors.org> wrote:
>
>>(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.)
>
>Overlay loading was more or less standard practice in minicomputer
>programming 30-40 years ago. Opening a file (including file name
>parsing) was put into one overlay tree branch and when the file was
>successfully opened, the code space was occupied by the actual
>routines performing file reading/writing.
>
>Unfortunately this does not work well on current microcontrollers,
>since these usually have a very limited amount of RAM and some Harvard
>architecture systems do not even allow execution out of RAM.

Indeed.  I certainly wasn't arguing for swap space.  Just reading my
notes.

>However, with a microcontroller with 16-64 KiB RAM and even some slow
>serial flash memory could be used to run quite complicated systems
>with overlay loading. In such systems 16 bit addresses are more than
>enough.

Which brings up the ancient concept of named and unnamed COMMON blocks
and CHAINing -- &#4294967295; la mode FORTRAN and BASIC.  I can see some definite
utility here.

Jon

On Sun, 15 Mar 2009 14:26:16 +1030, "Chris Burrows"
<cfbsoftware@hotmail.com> wrote:

><snip>
>ftp://jdreesen.dyndns.org/ftp/
>
>Windows / Linux / Mac OS-X versions are all available. Details are in the
>readme.txt file there.

Yes.  In that readme, it says, "Do not blindly download the whole
site, as it is well over 150MB, and my homeserver sits on a basic DSL
line....."  An important caution in days when folks blithely expect to
be able to haul down 150Mb without much thinking twice about it.

Jon

"Jon Kirwan" <jonk@infinitefactors.org> wrote in message 
news:0vcpr45k404j6koq9uhc0u78l4vn6bis0b@4ax.com...
>
> Yes.  In that readme, it says, "Do not blindly download the whole
> site, as it is well over 150MB, and my homeserver sits on a basic DSL
> line....."  An important caution in days when folks blithely expect to
> be able to haul down 150Mb without much thinking twice about it.
>

Yes - there's an amazing collection of really interesting stuff there. As 
well as the emulator there's all of the original Lilith circuit diagrams, 
photos, even source code for the microcode of the custom CPU, documentation 
etc. etc. The Emulith executable for Windows is only 600k.

Chris 

"Jon Kirwan" <jonk@infinitefactors.org> wrote in message 
news:po5pr4dg1e87fts5kcd73vuga4pqitlshj@4ax.com...
>>
>
> But the early BASIC I have been talking about included both the
> compiler and decompiler, held in 12kbyte of core memory.  No
> cross-compilation here.
>

Understood - but then BASIC is a significantly more basic (pun intended) 
programming language than Modula-2. My reply was more directed to Frank B 
who seemed to be particularly interested in Modula-2.

> What I think I'd like to see is the execution engine, which interprets
> a coded version of the source, as a required part but with optional
> pieces that include the compiler to convert ASCII text into the coded
> version that is suitable for interpreting and the lister which
> converts the coded version back into an ASCII text version, along with
> all the necessary lex/parse and error handling for in-situ use.  I
> mean, as optional pieces that one may.. or may not.. decide to link
> into the target.  The execution engine would be necessary, obviously,
> but the rest is important for interactive development on the target
> and should be available, if desired.
>

That should not be a problem with today's typical MCUs.

The PC implementation of the Lilith M-Code execution engine occupies 22Kb. 
The *total* M-code files of the full Modula-2 compiler occupy about 60kb. 
However, this comprises five passes each of which is loaded in separately 
(like an overlay), the largest being 16kb.

To put everything into perspective the original Lilith only had 256k of RAM 
(organised as 16-bit words) and 44k of that was used for the bit-mapped 
graphics display. The CPU clock speed was about 6Mhz, and the hardware 
supported by the operating system included a hard disk drive, laser printer, 
local area network etc.

Chris

On Sun, 15 Mar 2009 21:45:44 +1030, "Chris Burrows"
<cfbsoftware@hotmail.com> wrote:

>"Jon Kirwan" <jonk@infinitefactors.org> wrote in message 
>news:po5pr4dg1e87fts5kcd73vuga4pqitlshj@4ax.com...
>>>
>>
>> But the early BASIC I have been talking about included both the
>> compiler and decompiler, held in 12kbyte of core memory.  No
>> cross-compilation here.
>>
>
>Understood - but then BASIC is a significantly more basic (pun intended) 
>programming language than Modula-2. My reply was more directed to Frank B 
>who seemed to be particularly interested in Modula-2.
>
>> What I think I'd like to see is the execution engine, which interprets
>> a coded version of the source, as a required part but with optional
>> pieces that include the compiler to convert ASCII text into the coded
>> version that is suitable for interpreting and the lister which
>> converts the coded version back into an ASCII text version, along with
>> all the necessary lex/parse and error handling for in-situ use.  I
>> mean, as optional pieces that one may.. or may not.. decide to link
>> into the target.  The execution engine would be necessary, obviously,
>> but the rest is important for interactive development on the target
>> and should be available, if desired.
>
>That should not be a problem with today's typical MCUs.
>
>The PC implementation of the Lilith M-Code execution engine occupies 22Kb. 
>The *total* M-code files of the full Modula-2 compiler occupy about 60kb. 
>However, this comprises five passes each of which is loaded in separately 
>(like an overlay), the largest being 16kb.

Still, a lot more than we had.  Our main processor was 16k word,
total.  That's 32kb for everything, including the 20kb for the swap
space for user programs.  And when you say "more basic" above, keep in
mind that this included a complete matrix facility, as well.
Determinants, inversion, and multiplication, to name only some of it.

>To put everything into perspective the original Lilith only had 256k of RAM 
>(organised as 16-bit words) and 44k of that was used for the bit-mapped 
>graphics display. The CPU clock speed was about 6Mhz, and the hardware 
>supported by the operating system included a hard disk drive, laser printer, 
>local area network etc.

Well, Lilith had what could only have been considered "HEAVEN" when we
were working on the timesharing system.  256k of RAM?  My gosh! 6MHz?!
Jeesh, darn!  If only.

Jon

On Sun, 15 Mar 2009 21:19:04 +1030, "Chris Burrows"
<cfbsoftware@hotmail.com> wrote:

>"Jon Kirwan" <jonk@infinitefactors.org> wrote in message 
>news:0vcpr45k404j6koq9uhc0u78l4vn6bis0b@4ax.com...
>>
>> Yes.  In that readme, it says, "Do not blindly download the whole
>> site, as it is well over 150MB, and my homeserver sits on a basic DSL
>> line....."  An important caution in days when folks blithely expect to
>> be able to haul down 150Mb without much thinking twice about it.
>>
>
>Yes - there's an amazing collection of really interesting stuff there. As 
>well as the emulator there's all of the original Lilith circuit diagrams, 
>photos, even source code for the microcode of the custom CPU, documentation 
>etc. etc. The Emulith executable for Windows is only 600k.

I'm sure that seems like "only" to you.  And don't forget all the
support routines that Windows supplies which helps reduce towards that
"600k" by a fair margin...  But it's not "only" to me.  Not by a long
shot.  And that's just the executable part sitting on disk of a
program nestled inside a huge artifice and where memory allocation
comes afterwards?

Times have changed.  I remember developing applications for fairly
complex rental management, sitting on an IMSAI 8080 with a TOTAL of
16k RAM.  This had to hold the entire BASIC interpreter, which was 8kb
at the time ("papertape BASIC" as it was known in the day), too.  I
liked the Persei floppy disks because they used voice coils and were
fast, but not so reliable as the Shugart worm drive stuff.  That was
80kb per 8" disk.  So that's what we had for a file system.  I could
have shoveled the entire dataset, program, variable data space,
interpreter and it's own requirements, and operating environment into
1/6th the space that just the executable sits on that you mentioned.

Admittedly, no mouse and no graphics.  Oh, well.  But then, neither
are needed for an interpreter, either.

Jon

P.S.  
There are techniques that we studied, and Knuth's "semi-numerical"
book deals with many, were meant to do large scale tasks on systems
with very scarse resources.  For example, we used a huge "drum memory"
that was as big as a washing machine and provided barely 8kb of random
access memory (kind of.)  That was the size of faster secondary
storage that might be used as temporary file space before going out to
even slower and larger disks -- and the fast ram accessible by the cpu
was less than that!  Today, few programmers barely even know of the
techniques to make all this work smoothly and well, let alone have any
idea of how to pursue such code if faced with the need.  They'd need
to re-invent it.  But in micros, with external serial EEPROM, there
may be a place for some of this.  Not sure.  Interesting to think
about, now that I'm reminded to do so.