Forums

Embedded Basic interpreter recommendations?

Started by John Speth March 9, 2009
On Mar 13, 7:34=A0pm, cfb <cfbsoftw...@hotmail.com> wrote:
> On Mar 13, 2:36=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > 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*.
You still need to compile the symbols in all the DEF files, tho I guess a single pass compiler can spool the output into OBJ files in SPI/CF memory, and not keep it in RAM. The linker has a smaller exe than the compiler, but it needs to read all OBJ files and create the HEX file, so a low-memory linker would need special design ?. On the PC I've always gone for speed, so this is a little different :)
> > > For the .NETphobes the compiler, linker and loader are both written i=
n
> > > Component Pascal so a Win32 version of the command-line versions coul=
d
> > > 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.
There are a wide range of editors/IDE around designed for command line tools Notepad++ is one, ConTEXT is another. Could be interesting to see how large these all are, as stand-alone tools, and how small the memory usage can be easily pushed to....
> > > > 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 ;-)
I've tended to code three EXITs from LOOPs, in code that allows more compact results. Typically the top one is a sanity check, the centre one is the main result, and the bottom one is the 'ELSE' For Function returns, RETURN compiles directly to RET, which is always smaller and faster than chained Jumps. When you are targeting microcontrollers, these details matter - it all adds up.
> > > 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?
The claim was it allowed removal of LOOP ?
> > > 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 -
Hmmm... PROCEDURE is over 7 Chars ?
> presumably for efficiency reasons. Besides, you wouldn't > really prefer ELSEWHILE or ELSWHILE would you? ;-)
Well, the word has to be 'english correct' (which ELSIF..DO badly fails) and following the ELSIF precedent, we get ELSWHILE..DO ? -jg


Jon Kirwan wrote:
> >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.
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 <http://www.GuyMacon.com/>
Guy Macon wrote:

> I really wish someone would make something that runs on a modern
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: http://www.personal.leeds.ac.uk/~bgy1mm/Minibasic/MiniBasicHome.html don
On Fri, 13 Mar 2009 19:15:22 -0700, don <don> wrote:

>Guy Macon wrote: > >> I really wish someone would make something that runs on a modern > >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: > >http://www.personal.leeds.ac.uk/~bgy1mm/Minibasic/MiniBasicHome.html
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
On Mar 13, 5:22=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Mar 13, 7:34=A0pm, cfb <cfbsoftw...@hotmail.com> wrote: > > > Small *modules* perhaps - that does not necessarily mean small > > *programs*. > > You still need to compile the symbols in all the DEF files,
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*.
> > > > 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? > > The claim was it allowed removal of LOOP ? >
"As a sort of compensation ..." were the actual words used.
> > > 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 - > > Hmmm... =A0PROCEDURE is over 7 Chars ? >
Doh! That's that theory shot down in flames ...
> > =A0presumably for efficiency reasons. Besides, you wouldn't > > really prefer ELSEWHILE or ELSWHILE would you? ;-) > > Well, the word has to be 'english correct' (which ELSIF..DO badly > fails) > and following the ELSIF precedent, we get ELSWHILE..DO ? >
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 http://www.cfbsoftware.com/armaide
On Mar 14, 5:11=A0pm, cfb <cfbsoftw...@hotmail.com> wrote:
> > New WHILE statement with cascade decisions: > > WHILE m > n DO m :=3D m - n > ELSIF n > m THEN n :=3D n - m > END; >
Oops! Correction: WHILE m > n DO m :=3D m - n ELSIF n > m DO n :=3D n - m END; Chris.
On Sat, 14 Mar 2009 01:01:33 +0000, Guy Macon
<http://www.GuyMacon.com/> wrote:

<snip>
> >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.
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.
>The RepRap world would eat it up.
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.
> > New WHILE statement with cascade decisions: > > > WHILE m > n DO m := m - n > > ELSIF n > m THEN n := n - m > > END; > > Oops! Correction: > > WHILE m > n DO m := m - n > ELSIF n > m DO n := n - m > END;
I rest my case ;) I guess they can't always avoid dropping a clanger like this one... ?! -jg

Guy Macon wrote:

> 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.
:) 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 http://www.bytecraft.com
On Fri, 13 Mar 2009 04:59:13 GMT, I wrote:

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