Embedded Basic interpreter recommendations?

C

You investigated every option here? I see three at least that would probably fit your needs:

I was also similarly interested in something akin. 30 years ago I was part of those involved in writing a commercially used interpreter -- at the time, it was over timeshared service, though. The final result fit in 32k byte of the main cpu (which included 20k byte of swap space that did NOT include the interpreter, so the interpreter itself took up only 12kbyte) and used an I/O processor with 16kbyte of memory (most for buffers, not code.) This included pretty much everything one could want -- line number editing (just retype the linenumber with a line and it replaces the prior line) and pre-compilation into very fast code for interpretation. This meant all line numbers being replaced with addresses of the lines they referred to (no lookup), all variables being replaced with addresses into the variable table (no lookup needed), etc. It had to be, back then, so there the interpreter included an interpreter precompiler, an editor decompiler, the editor features, a variety of commands, support for all transcendentals, matrix math including inversion and determinants, and the execution engine, of course. Chebychev was used throughout the transcendentals, with minimax techniques to minimize accumulation of errors by setting constants appropriately, for very fast conversion and controlling error bounds rather than controlling average error, as does Taylor's, for example.

I've considered the idea of doing it in a modern context for flash systems, but it was a lot of work and time (all coded in assembly for speed and compactness, which was vital then) and doing it all over again would not be easily considered.

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.

You might also write some of the compiler vendors. A few of them may have developed a useful BASIC they couldn't really sell, but would be willing to part with. You'd need to be in a position to make modifications.

If you find a worthy team to work on it, I'd be happy to share some of the details that turned out to work so well in the past -- I still have all the source code for it and I remember a great deal of the details, too. And I may be able to put in some time, as well. I applaud the idea.

You will likely get some suggestions about Forth. I am no expert in it, only having small experiences with it (and enjoying the learning), but frankly I think you are on the right track for your target and I don't think Forth would serve it well.

Jon

A quick skim follows. In it, I pretty much discount systems that require .NET, Windows, or other sophisticated operating systems. Often, their dependencies aren't merely surface but quite deep and not infrequently also require extensive graphics libraries to support their use of graphical interactions with the user. All of these make the useful parts very difficult to extract from the rest. So I discount them. There are a few possibilities that caught my eye, but I didn't investigate them further. There may be additional reasons that would have showed up to eliminate them, as well. For example, the OP mentioned "free embedded basic interpreter with C source code" and some of what remains may not fit that requirement.

Microsoft SmallBasic: No, requires .NET and Windows

Free Microsoft Visual Basic 2008 Express No, Windows.

ThinBasic Basic Interpreter No, Windows.

Chipmunk BASIC Interpreter No, Mac and PowerMac.

XBLite - xbasic BASIC lite compiler No, requires Win32.

Gambas - Gambas Almost Means Basic No, requires extensive operating system support under Linux, FreeBSD, and OpenBSD. And requires graphics.

TNT Basic No, Mac and PowerMac.

GLBCC - GNU / Liberty Basic Compiler Collection No, actually compiles -- not interpreter code. Among other issues.

Mono's VisualBasic.NET Compiler (Mono Visual Basic Compiler) No, it's a cross-platform implementation of .NET with VB.

Blassic Not sure. Maybe.

FreeBASIC No, generates executables, not interpreted code.

Just BASIC Maybe.

Basic4GL No, Windows, OpenGL, etc.

wxBasic Not promising. Probably not, but a weak maybe.

SmallBASIC Maybe.

MoonRock Compiler No, makes executables for MSDOS real-mode or DPMI.

Mole BASIC Interpreter Not sure. Couldn't tell if it interprets, or not.

Bas BASIC Interpreter Sounds more promising to me.

ScriptBasic BASIC Interpreter No, back to Linux and Win32.

Envelop Basic Compiler No, Windows.

XBASIC BASIC Compiler No, Windows and Linux.

Bywater BASIC Interpreter No, Linux.

BCX BASIC Compiler No, makes c source code.

Enhanced 6502 BASIC Maybe.

UBASIC BASIC Interpreter No, different target (2500 digit math, for example.)

YABASIC BASIC Interpreter No, Windows and Linux.

-------------

Now, I'll add one of my own. There is the BASIC available for the

8031 core from Intel, "8052 BASIC." I don't consider it of much use, either, as it isn't in c.

Jon

Why not making your own? It is not big deal to parse the trivial BASIC program flow and math. equations. The whole thing from scratch would take only several k lines of code.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Does it have to be BASIC ? If not then LUA might be a good option.

Regards Anton Erasmus

There is this: . The BASIC interpreter is probably written i C, but it's not open source. There is a skeleton that is open source.

I have a STM32 Primer1 and that could possibly run a BASIC interpreter.

I think BASICs in C for Linux could be ported to embedded systems without to much trouble.

I would hope you are right. But wouldn't they tend to depend on more than just simple serial port I/O services for what they do? Sometimes, just the presence of an operating system and support facilities like X and POSIX _encourages_ their use, and in doing so entwines them. It's worth some looking, though.

Jon

I think the "non-programmer types" part of the OP's discussion points otherwise.

Jon

Forth is nice for interactive development, but hard for new programmers, because you have to think about memory handling etc., which is much easier in Basic. But I don't see any reason why to use a dumb terminal interface. With wxWidgets a GUI can be developed which works on Windows, Mac and Linux, and even some portables and you need another PC or device anyway, if you want to use it with a serial port. The GUI could provide more modern file editing, debugger etc., instead of old-style C64 line numbers.

BTW: I'm planning to develop such a system, too. What do you think of Modula-2? It is supposed to be more safe than Basic or C, but I don't know if it is easy for new programmers and if C or Basic programmers would like to use it.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

I think the OP is talking about the simplicity of line number replacement for editing and typing LIST when you need to see a list. This is an RS-232 port application, after all. It could require features, such as screen-clear, x/y positioning, and so on, but in doing so you would expand the code in the target and reduce the set of "terminals" that one might use on the PC end. I'd tend to go with simple and basic, here.

I like Modula-2 and spent a little time reading the Modula-3 book, though I've never used a Modula-3 compiler and I'm still weak on some of its concepts. But I like pretty much all languages (well, except RPG-II unless I am writing very simple reports and COBOL unless there is a legacy app that needs modification) I've been exposed to. I find c fine, as well. I would be worried about the Modula-2 compiler for developing embedded BASIC, mostly for code size and execution time questions, if not wondering whether or not there was one that targeted the device I was looking at. c is pretty much ubiquitious, now, for embedded use and I'd prefer that for that reason alone, if no other. (With assembly, as appropriate.)

Jon

No, but could be recoded in C/ASM fairly easily, with macro calls etc.? :)

-jg

erial

ol

If this uses a Terminal, then another angle would be something like the original TurboPascal, which IIRC was just 39K for compiler+editor. Of course, that was mostly x86 ASM, and not open source, but does give a performance/size reference point.

-jg

I don't see why this is simple. You are right, simple to implement, but not simple to use. I've started programming on C64 with Basic programs and lines, too (and switched to assembler some months later), but I never missed it on PC with the usual file editing in my favorite editor (starting with "Boxer" in DOS, now most of the time Ultraedit), or in a good IDE like Visual Studio. Writing a simple IDE for Windows, Linux and Mac with wxWidget is not that difficult.

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.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

For a non-programmer doing simple commands, Lua is not really any more difficult than Basic. And if you want to do non-simple stuff, it quickly becomes easier.

w e

Modula-2 is fussier in types than BASIC, and less string-friendly. Since this needs to be simple, an early Pascal variant could also do (along the lines of Turbo-Pascal) and a 32 bit target, can relax some of the Type-Soup, for a simpler implementation.

Newer BASICs are somewhat more structured, so move closer to Modula-2 and there is also IEC 61131

Perhaps a base such as Wirth's earlier PL/0, which DOES mention source code, could create a medium-typed compiled language ?

Simpler is better, for the smaller targets :)

Seems versions are around in Modula-2,

and C++

-jg

I've looked at it, a bit -- mostly in terms of features from the user point of view, though. And on that score, it has a LOT of extras that are associated closely with the 8031/32 core, itself. Would need to carefully cull through all that. I kind of imagine it easier to start fresh with clear goals in mind.

Jon

It is VERY easy to teach. Not only from my own experience working with literally hundreds and hundreds of users (as a tutor, then as a teacher of classes, and as support staff with a timesharing system.) People from all walks, a large portion without any prior experience. At that time, computer expertise (heck, even typing skills) was a bit short in supply. But it was very easy, by comparison with other languages I had similar experiences trying to convey to others.

Actually, line editing isn't all that easy to implement if your system pre-compiles for speed. What we did was when the RUN command was given was to check a flag -- if the code was in pre-compiled state (fast interpretive, really), then it just started running. But if it was still in "text only" mode (editing), then a pre-compile step was required first. When a line was typed, if the code was already in pre-compiled state, then it had to be de-compiled back into text, then the line update made. In addition, the memory requirements were different in the two stages (variable tables in one case, none in another; etc.) So it can get a little bit hairy. Though, with crafted thinking it works smoothly enough.

We could achieve no more than about 1/2 second delay in pre-compiling code from text source in rather large programs and do this while dealing with 31 other users at the same time and swapping code on a timesharing basis (no virtual memory, no stacks [subroutines were handled like the PDP-8, for example, where the first address of the routine was stuffed with the return address... so recursion was a no-no.]) So the users "felt" an acceptable delay during these conversions. The only annoyance might be when typing in a large program, typing run, and running out of memory only when starting the code because the scrunched/precompiled code + variable tables was a bit larger. The advantage to the pre-compilation step was that EVERY variable was pre-allocated -- the entire program was scanned and all variables allocated at the start. So you knew right away if it could run well.

But that isn't my experience in teaching, tutoring, etc. So I guess we don't agree.

Well, of course. But you probably never had to live with a KSR-35 or ASR-33, either. But here we get to the nub of it.

It is great having visual editors. You won't get an argument from me about that. I love being able to edit text without having to retype entire lines, for example. But I do this as my profession, so I do a lot of it. It counts, then. For non-programmers, which the OP is talking about, many other issues become important. For example, when you typed a line into the system I worked on, it was checked immediately. If it was wrong, you got feedback instantly about it. One of the best ways to begin learning programming is to do things wrong -- and get feedback right away. There are lots of other aspects here, too. But I think you may really need to see it happening, do the teaching yourself using this kind of BASIC with non-programmers, and see how you feel afterwards. I've done all of this, in classroom settings as well as one-on-one, and I _know_ that line number replacement is quite practical on that level and that the issues of a screen-based editor in conjunction would complicate things on many, many levels. I have strong feelings about this, as you can see.

Well, you are talking to programmers then. I have considered the idea of a nicely partitioned system -- an execution unit that resides on the target or may reside on a host, an interpreter that _may_ also reside on the target OR it may also reside on a host system connected to it, and a compiler as well that may generate final target code in machine language, as well. I was considering how to modify BASIC to support constant, initialized arrays that might be placed into flash, etc. It's nice to have choices.

But the OP's question, if I'm getting the message correctly (and I may not be), is about non-programmers. And there, I'm in concert with what was originally said.

Jon

I actually wrote the PL/0 compiler right out of his (black colored) book. I still have it, in fact, sitting just a few feet away from me. And modified it, too.

I'm partial to BASIC for non-programmers.

Jon

serial

find

I'm not thinking about command line stuff. I've been using c since

1978 (Unix v6) and BASIC in some form or another since... 1972. So similar time periods. I've tried to teach both to non-programmers in classrooms where I was a paid teacher (Tektronix classrooms.) And I'm talking about __non-programmers__, such as secretaries. I've no question in my mind which would be easier to gain some early success with. Lua is too similar to c in my mind.

Jon