Embedded Basic interpreter recommendations?

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

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

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:

don

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*.

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

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

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

Oops! Correction:

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

Chris.

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.

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.

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

-jg

:)

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

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

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:

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

See my post titled "RepRaps and RepStraps."

--
Guy Macon

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

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.

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

Jon

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

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

Jon

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

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

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.

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

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.

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

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.