Forums

Embedded Basic interpreter recommendations?

Started by John Speth March 9, 2009
> Okay. Well, it's about time for the OP to jump in. We are proceeding > far beyond the original comment. I feel you may be taking this over > the top a bit, but then you might be right on target for all I know.
I'm the OP. My intent is this: Sometimes here at work we have a project idea. Then a circuit with a microcontroller comes along and the marketing types have little to no software requirements. I could spend all my time writing throw-away code asking "Is this what you wanted?" at the end of each iteration. It would be simpler for me to just let my associates have their own way with the circuit. It woud allow them to develop ideas and walk a mile in my shoes as a bonus. The language shouldn't be an impediment. I learned basic on a PDP-11 i in the 70's. I could execute "n=12" then "print n" interactively or I could assign line numbers and run, as in "10 n=12" then "20 print n" then "run". That's what I want. Extensions for the micro like peek and poke would be necessary. JJS
John Speth wrote:

> I learned basic on a PDP-11 i in the 70's. I could execute "n=12" then > "print n" interactively or I could assign line numbers and run, as in "10 > n=12" then "20 print n" then "run". That's what I want. Extensions for the > micro like peek and poke would be necessary.
Editing source code and interactivity is orthogonal. Maybe you and Jon Kirwan are right and for non-programmers with no previous word processing experience, it is easier to learn this PDP-11 (and C64) interface. A more modern approach would be GUI, but with an additional command line interface, like a Lisp REPL, or with separate windows, one for input and one for output, like I've seen and used in Squeak (a Smalltalk implementation). Then for the Lisp environment, e.g. with Lispworks, you have an additional text editor and you can hit "compile" to compile the content (and other included things) into the runtime system, where you can call the compiled functions etc. from the REPL. In Smalltalk it is even more integrated and (being object oriented) you have an object browser and you can inspect methods and open them in an editor. This would be the C64 concept, but in an advanced style: instead of "LIST 30-50", move cursor up, change content in line 40 (or even more worse: re-enter the whole line, with your changes) and finally press enter to recompile, it would be "inspect setLed" from the command line (or browse a function list in the GUI), which opens an editor, where you change the content by clicking the mouse to the text you want to change (which is another problem, if you use pure RS232), then hitting "save" to compile it to the runtime envionment, which finally can be tested interactively on the command line. BTW: I think using Basic is a good idea for my system. Modula is more clean, but more complicated. I've learned Basic, too, as my first language and it was very easy. But when I write programs in Pascal-like languages, like VHDL, I still make syntax errors (do I need a semicolon at this place or is this an error? Ok, I think Modula has improved the syntax a bit, but still some discipline is required, like one place where you define variables, then "begin" etc.), so this would require a really good editor support to avoid user frustration, which is easier for Basic. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
> I did a fair bit of work extending PL/0 to make it into something > usable - added REPEAT loops, SIZE, ORD and CHR, record and string > assignments etc. etc. However, that all that went into cold storage > when I changed direction and started the Armaide project with the > Oberon-07 compiler: > > http://www.cfbsoftware.com/armaide > > The Oberon-07 compiler in Armaide runs on Windows but I have used it > to compile itself to ARM code. The object files occupy about 80k bytes > - plenty small enough to fit in the Flash ROM of many ARM MCUs.
That's just the compiler ? - What about linker, and library OBJ files, and and Editor, with inbuilt Debug ....... (aka TurboPascal ) ? I see this uses .NET, which means it would not make the cut, for Jon ;) ( Not sure I'd agree with the removal of LOOP either... and the change in RETURN - Still, I guess Size and Speed matter less these days... )
> On a related track I've also been experimenting recently with an > interpreter based on Wirth's Lilith M-Code Interpreter. The source > code of the M-Code Modula-2 compiler and related documentation > (including a listing of the interpreter) are at:
interesting. -jg
On Thu, 12 Mar 2009 01:45:02 -0700 (PDT), -jg
<Jim.Granville@gmail.com> wrote:

><snip> >I see this uses .NET, which means it would not make the cut, for >Jon ;) ><snip>
I still have and use 80486 computers, running on Win98SE. Have you ANY IDEA what a program depending on .NET does to one of them??? I'm talking about tiny programs here, that depend on .NET to run. Long ago, I'd written my own MD5 program that runs in DOS under Win98SE (and later incarnations, yes.) I used it so that clients getting stuff from me could verify file versions, if there was any question about it. (Folks rename things, at times.) One day, I happened upon a Win32 program that allowed drag and drop and was very easy to use for some of my clients and I decided to point then in that direction. It was about as fast as my own (I didn't make precise measurements, but it was close enough.) The program fired up very fast and was easy to use and was free. So far, so good, yes? Then the author made a change to .NET for the same program. In fact, there was NO differences at all in the prior version and the new version except that he said he'd decided to change over to .NET for this new version (perhaps looking forward to other features once that "port" was done and working.) I loaded it over and tried it out. It took almost two minutes to just load up!!! Now, once I'd paid that price and .NET was "up", it did admittedly come up a bit quicker. Maybe in less than a minute, but still very very much longer than the earlier version, which was present and ready in about one second or less. It just wasn't worth the hassle anymore. Windows once ran "okay" in 8 Meg and pretty darned good in 16. Then it needed 32. Then 64. Now, a gig is considered pitiful. Widgets negotiate for positioning in toolbars or other widgets, toolbars dock now, there are interfaces just to enumerate the interfaces and then interfaces for those to enumerate the functions available, and 64 layers/interrupt levels for handling events, rings upon rings, layers upon layers, .... And despite the fact that computer hardware has advanced at a pace that boggles the mind (front side transactions that operate in parallel with transaction, error, cache hit and data phases all operating on the same clock, levels of caching not only in the cpu(s) but in the chipset, read around writes, relaxed transactions rules for graphics [where the order of arrival isn't all that important], etc.), with multi-GHz internal cycle times, many stages of cache and buffering going out to slower memories, huge memories unthinkable not so long ago, and so on.... Microsoft STILL manages to find ways to slog such a machine down to a crawl. Don't even think of getting me started. Yeah. .NET = .NOT. ;) Jon


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/ -- Guy Macon <http://www.GuyMacon.com/>
On Mar 12, 6:45=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:

> > On Mar 10, 5:20 pm, cfb <cfbsoftw...@hotmail.com> wrote: > > I did a fair bit of work extending PL/0 to make it into something > > usable - added REPEAT loops, SIZE, ORD and CHR, record and string > > assignments etc. etc.
Sorry - I should have said Oberon-0 (the later incarnation of PL/0) from Wirth's compiler construction book: http://www-old.oberon.ethz.ch/WirthPubl/CBEAll.pdf
> > > The Oberon-07 compiler in Armaide runs on Windows but I have used it > > to compile itself to ARM code. The object files occupy about 80k bytes > > - plenty small enough to fit in the Flash ROM of many ARM MCUs. > > That's just the compiler ? - What about linker, and library OBJ files, > and > and Editor, with inbuilt Debug ....... (aka TurboPascal ) ? >
Linker ~10k Library OBJ files =3D zero K for a simple app like Blinker, ~ 6k for runtime error trapping and reporting ala TP 1.0 via RS232. I haven't considered an editor yet. I'd do the same as somebody else suggested - do the primary editing on the PC with the terminal emulator. Have a simple editor on the target to fix simple compilation errors.
> I see this uses .NET, which means it would not make the cut, for > Jon ;) >
For the .NETphobes the compiler, linker and loader are both written in Component Pascal so a Win32 version of the command-line versions could easily be built using Oberon microsystems BlackBox compiler.
> ( Not sure I'd agree with the removal of LOOP either... > and the change in RETURN =A0- > Still, I guess Size and Speed matter less these days... > )
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. -- Chris Burrows CFB Software Armaide: ARM Oberon-07 Development System for Windows http://www.cfbsoftware.com/armaide
On Mar 13, 4:05=A0pm, cfb <cfbsoftw...@hotmail.com> wrote:
> > > > The Oberon-07 compiler in Armaide runs on Windows but I have used it > > > to compile itself to ARM code. The object files occupy about 80k byte=
s
> > > - plenty small enough to fit in the Flash ROM of many ARM MCUs. > > > That's just the compiler ? - What about linker, and library OBJ files, > > and > > and Editor, with inbuilt Debug ....... (aka TurboPascal ) ? > > Linker ~10k > Library OBJ files =3D zero K for a simple app like Blinker, ~ 6k for > runtime error trapping and reporting ala TP 1.0 via RS232.
You still need to store the OBJ files, but that could be a SPI flash and smaller executabe blocks could also be loaded from SPI as needed.... 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. I suppose only (very?) small programs would be targeted for 'self- compile'
> > > I see this uses .NET, which means it would not make the cut, for > > Jon ;) > > For the .NETphobes the compiler, linker and loader are both written in > Component Pascal so a Win32 version of the command-line versions could > easily be built using Oberon microsystems BlackBox compiler.
So what is .NET being used for ?
> > ( Not sure I'd agree with the removal of LOOP either... > > and the change in RETURN =A0- > > Still, I guess Size and Speed matter less these days... > > ) > > 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 ;) The strangest change I see, is the new WHILE else, called ELSIF.. DO ?! 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) -jg
On Fri, 13 Mar 2009 03:02:37 +0000, 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. Jon
On Fri, 13 Mar 2009 04:59:13 GMT, Jon Kirwan
<jonk@infinitefactors.org> wrote:

>On Fri, 13 Mar 2009 03:02:37 +0000, 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.
(Oh, and I forget to mention line editing and error checking.) Looks nice enough, having looked. Some things we didn't have that are appropriate differences considering time-sharing vs micro -- multiprocessing, for example. No matrix math, I see. Looks like a compiler, though, which wouldn't serve my purposes. Jon
On Mar 13, 2:36=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 13, 4:05=A0pm, cfb <cfbsoftw...@hotmail.com> wrote: > > > You still need to store the OBJ files, but that could be a SPI flash > and smaller executabe blocks could also be loaded from SPI as > needed.... >
Correct.
> 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*.
> > > For the .NETphobes the compiler, linker and loader are both written in > > Component Pascal so a Win32 version of the command-line versions could > > 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.
> > > 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 ;-)
> 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?
> 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 - presumably for efficiency reasons. Besides, you wouldn't really prefer ELSEWHILE or ELSWHILE would you? ;-) If I am correct about the rarity of its use any confusion is unlikely to be a problem in practice. As it is, the way it has been implemented only resulted in the addition of four lines of code to the compiler. Seeing as it was so easy to do I suspect Wirth may have just included it as a tribute to Dijkstra. Alternatively maybe he just wanted to give people like us something controversial to chew over ;-) -- Chris Burrows CFB Software Armaide: ARM Oberon-07 Development System for Windows http://www.cfbsoftware.com/armaide