Embedded Basic interpreter recommendations?

> 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