Forums

Embedded Basic interpreter recommendations?

Started by John Speth March 9, 2009
"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 -- &#2013265920; 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.