[OT] Thoughts on extending EhBasic?

[BigEd]

Nearby, Garth mentions the "language extension" packs for the Basic on HP's handheld computer.

So, I wondered: what language extensions might people want in a Basic?

GARTHWILSON wrote:

I looked into EhBASIC years ago (although admittedly not very seriously) and it did appear that Lee did a really good job considering the small amount of memory the code had to fit into. The BASIC I used the most was on my HP-71B hand-held computer which way, way better, in ways most BASIC users could never imagine; but with the LEX (Language EXtension) files, it amounts to over 170KB. Is EhBASIC simple enough for the serious user to add capability to it (like the HP-71's LEX files)...?

[Chromatix]

There are several categories of extensions one might want. Most of the following examples actually exist in some dialect of BASIC.

1: Structured programming tools. BBC BASIC has not only GOTO, GOSUB-RETURN, FOR-NEXT and REPEAT-UNTIL but PROC, FN, and in later versions CASE-OF-WHEN-OTHERWISE-ENDCASE, WHILE-ENDWHILE, and multi-line IF-THEN-ELSE-ENDIF. These are sufficiently powerful that serious programs can be written without line numbers (ie. without GOTO or GOSUB). BBC BASIC for Windows adds "breakout" functionality through EXIT FOR, EXIT WHILE, etc.

2: Convenience keywords for accessing machine functions such as graphics and sound. BBC BASIC has MOVE, DRAW, PLOT, POINT, SOUND, ENVELOPE. Later versions have LINE, ELLIPSE, CIRCLE, RECTANGLE, with optional FILL and BY, etc. These all expand to VDU code sequences or MOS calls.

3: Structured data. This is probably a more difficult feature to retrofit to an existing interpreter, but makes a huge difference in the ease of writing even moderately complex programs. I'm certain that VB has this, but several other dialects probably do as well. BBC BASIC for Windows can do the following:

Code: Select all

DIM object{name$,pos{x,y,z}}
object.name$ = Name$
object.pos.x = X
object.pos.y = Y
object.pos.z = Z

[floobydust]

Not being a big BASIC programmer, I'm not in a SME position to suggest specific enhancements to EhBasic. However, as it is derived from MS Basic, perhaps looking at the Commodore Programmer's Aid cartridge (for the VIC-20) would be somewhat useful as a source for some extensions to EhBasic. A PDF of the manual can be found here:

http://www.classiccmp.org/cini/pdf/Comm ... %20Aid.pdf

There were some useful commands added, like auto numbering when entering and a renumber function. Other interesting extensions where find, dump, help and the ability to use function keys as shortcuts.

[BigEd]

> Structured programming
And LOCAL too!

I rather like the complex value support you see in some advanced calculators. It's like floating point but twice as nice.

Double precision would be nice.

Long integers or bignums can be fun.

Support for hex and binary (and bitwise operations) is always appreciated.

BBC Basic's inline assembler is transformative.

[drogon]

BigEd wrote:

Nearby, Garth mentions the "language extension" packs for the Basic on HP's handheld computer.

So, I wondered: what language extensions might people want in a Basic?

People have often added extensions to the MS Basics via the USR statements, as well as CALL, (Applesoft also has an '&' operator to do the same thing), so there is always that - the question is what extensions... Things like graphics and sound are very platform dependant but language constructs like while/until, switch, multi-line if/then/else really require big changes to the interpreter core itself.

Having written my own Basic, I've got a pretty good idea of what I wanted, but my Basic currently is written in C and needs a modern Unix-like OS as a host platform. I do feel that writing (or re-writing) a BASIC will never please everyone...

Back in the 8-bit world.... I think it's hard to beat BBC Basic for an interpreted BASIC. 32-bit integers, 40-bit floats, named procedures and functions with local variables supporting recursion. Built-in multi-pass assembler, file handling, sound and graphics. It is true to say that while the language supports various things, it does require an underlying operating system to do the donkey work (e.g. sound and the physical interface to the filing system), however it's almost all there and fits inside a 16KB ROM. It's also the fastest 8-bit Basic that I know of - almost twice the speed of an MS Basic on the same hardware, but the boffins at Acorn were Cambridge computer science graduates and had the benefit of writing it in 1980 (with prior experience of Acorn Atom Basic), some years after the MS Basics in the Apple, PET, etc. and didn't have the space (= cost) concerns of early 8 or 12KB ROMS of the early micros.

The original 8-bit BBC Basic lacks SWITCH, but it's always been there via ON x GOTO ... (it's crude, but it's BASIC)

And the bit about the OS doing some of the donkey-work is a good one to note - (or I'd like to think so) - while BBC Basic has sound, graphics and file commands built-in, it calls the underlying operating system to actually execute them, so I'd like to think that anyone writing a new 8-bit BASIC might do similar via simple set of "system calls" (The Beeb, Apple, PET and I'm sure some others) all have fixed address entry points into the underlying monitor or OS so look at doing the same? I did the bare minimum to get BBC Basic going on my Ruby6502 board, and once it was going, I deleted what was a Wozmon look-a-like and implemented an Acorn MOS look-a-alike and most other (Acorn) system calls which indirectly also enabled me to run other BBC Micro application ROMs, so keeping a common interface would be nice to help porting to other platforms. (My OS is now just under 12KB, but it's very verbose with text error messages and I've made no attempt to code for size)

BBC Basic isn't perfect and it has things that irritate me - spaces can sometimes be problematic, but that's the limitations of squeezing it into the available ROM space.

Other more modern constructs? objects/structures? I'm not sure they need to belong in an 8-bit BASIC. I did add associative arrays into my Basic - more as a challenge from a friend than anything else - a$ ("foo") = "bar" sort of thing - initially to interface to SQLite, but I didn't go that far - which leads to feature creep - when friends, or "the internet" makes a suggestion then puts pressure on you (My Basic doesn't have 'next' but I was persuaded by a very small number of people to put it in, so I did - then they never used it, so I took it out again and decided after that that it was my basic and not theirs)

And then there is the assembler that the implementer will use - does it run under MS DOS/Windows, Linux, Mac,Apple II, ... ? Does it use assembler specific features, etc. I think it's really hard to make something universal and able to please everyone.


Back to the subject: There are a small number of things that I want in my own Basic that I didn't implement, so these might be handy - one is a string split operator - I was tasked with writing some code to parse a CSV file and having a string split operator would have sped it up a little. Another other is the "classic" matrix operations. I also never bothered with integer variable types because integer arithmetic is not significantly faster than double precision floats on a modern CPU these days. (although it is something I'll add when I re-implement my Basic on my Ruby system) However in the 8-bit world, if you have proper integers, then a MULDIV operator might be useful where interpreted floating point may well be slower than integer arithmetic - so foo% = muldiv (a%, b%, c%) would take a% multiply by b% to produce an un-truncated number internally, then divide by c%. This can make fixed point arithmetic somewhat more flexible and faster.

So with all that in-mind - write the "core" of a modern 8-bit Basic, make it well documented and extensible/customisable by others and use a common interface to the underlying OS. Use a relatively plain old assembler and off you go... (Oh, and make it store programs to some underlying OS/filing system as plain text and not tokenised binary!)

Cheers,

-Gordon

[cjs]

BigEd wrote:

BBC Basic's inline assembler is transformative.

Indeed. It's something I think that pretty much every language for 8-bit home computers should have. Though I must admit I find BBC BASIC's syntax around the assembly to be rather baroque, though perhaps I just don't understand the reasons for the way it's done.

[BigEd]

Oh, strings: Sinclair's slicing might be nice.

And how about associative arrays, like awk's? [Edit: oops, I see Gordon already mentioned that idea]

I think there was an 8 bit Basic with some concept of timers and events, with event-handling subroutines or possibly subroutines which sort of ran in an interrupt context.

[Chromatix]

String slicing, taken to its logical conclusion, could mean code like the following works:

Code: Select all

DEF PROCreplace(RETURN a$, s$, r$)
LOCAL o%
o%=-1
WHILE (o% = STR$(a$,s$,o%+1)) >= 0
MID$(a$, o%, LEN(s$)) = r$
ENDWHILE
ENDPROC

c$ = "classic"
PROCreplace(c$, "ass", "butt")
REM now c$ = "clbuttic"

To make proper use of that, you need a memory allocation scheme that can free memory as well as allocate it. Most micro BASIC interpreters allocate strings and arrays permanently.

[drogon]

Chromatix wrote:

To make proper use of that, you need a memory allocation scheme that can free memory as well as allocate it. Most micro BASIC interpreters allocate strings and arrays permanently.

I think most MS derived 8-bit Basics have a free(0) function to garbage collect/compact/free-up RAM. (I remember the Applesoft one being very slow though, but ProDOS patched that with a much faster one) BBC Basic doesn't, but I'd have to dig deeper to see how it handles it all.

(I used malloc/free in my Basic)

However there should be no reason to not have a memory allocator for strings (given the code space to write it in) - when developing my BCPL system I needed it's equivalent of malloc (getvec), so I wrote one initially in Sweet16 (with the intention of re-writing in native '816 ASM). A simple first-fit allocator really isn't that hard to write and would probably work well for the lifetime of your average BASIC program.

It does beg the question of dynamic RAM in BASIC though - should it be a thing? Should there be

DYNADIM a (2000) with a corresponding free (a) or the equivalent of alloca() (to allocate from the stack inside a function/subroutine) ... Or should we really think to use another language for that sort of programming?

-Gordon

[Chromatix]

Well, at some point it does become easier to just implement some more modern language, rather than continually bolting things onto BASIC. Lua is a good candidate for that, I think; it's a small and simple language whose relatively few features are carefully chosen for their expressive power. But none of what I've suggested is completely out of reach; it still fits into BASIC syntax relatively easily.

I don't think you need a separate DYNADIM keyword. DIM is used for allocations, including of raw memory areas as well as BASIC arrays; I'm sure I've seen REDIM for resizing arrays (preserving values already held), and you could use something like FORGET to free up the memory entirely. Once you have a memory allocator, that shouldn't be difficult to implement.

[BigEd]

I'm reminded of the early MS Basic (at least) which at cold start would prompt for loading the LOG/TRIG routines - without those, it was much smaller. Likewise, in the land of Sinclair, an external ROM was able (somehow) to patch into Basic's parsing and add new keywords.

So perhaps a nice interface which allows for additional packages or facilities is a way to go: there's no large ultimate version with all features, instead there's a core, and there are plugins, and it's not too difficult to write a new plugin which adds a new feature. Naturally, plugins should be chainable and the order of adding them should be unimportant.

[White Flame]

DEF FN could use multiple variables instead of just 1.

[drogon]

BigEd wrote:

I'm reminded of the early MS Basic (at least) which at cold start would prompt for loading the LOG/TRIG routines - without those, it was much smaller. Likewise, in the land of Sinclair, an external ROM was able (somehow) to patch into Basic's parsing and add new keywords.

So perhaps a nice interface which allows for additional packages or facilities is a way to go: there's no large ultimate version with all features, instead there's a core, and there are plugins, and it's not too difficult to write a new plugin which adds a new feature. Naturally, plugins should be chainable and the order of adding them should be unimportant.

The thing is ... This has already been done to an extent in other 8-bit BASICs of the era,, but in the context of EhBASIC, then, it's a good candidate for systems with very limited resources.

The BBC Micro Graphics extension ROM for example - BBC Basic already has the generic PLOT command and the built-in OS supports basic points, lines and triangles but the graphics extension ROM added many more features including circles, sprites and so on - all via the existing PLOT command which the underlying OS provided a chainable vector mechanism to extend.

And going a bit further back - the way that Apple DOS worked was to intercept the character output vector (and input) where you then PRINTed commands that when prefixed by CR + Ctrl-D were picked up by the DOS. This mechanism was chainable too, although somewhat inefficient, but it worked...

Maybe a better effort might be put to properly documenting the existing EhBASIC disassembly and work out exactly how to extend it, or adapt it for a more modern style underlying OS?

-Gordon

[BillO]

At the risk of repeating other's wish list items...

1) Labels instead of line numbers.
2) Local and global variables.
3) Functions with arbitrary complexity which can be passed multiple variables or data structures
4) Complex number support
5) in-line assembler
6) Support for placing subroutines and functions at specific memory locations so that we can use page switching to take advantage of more memory
7) Enhanced library of built-in functions
8] Ability to define specific memory locations and specific bits as variables to support I/O
9) Full suite of variable types (Bit, Nibble, Byte, Word, LWord, a full set of Integers (signed - 8, 16, 32 and 64 bit), Float, DFloat, QFloat, Imaginary, Complex, Character, Fixed String, Variable String, Pointer/Address)
10) Data structures that can be defined to incorporate the above variable types
11) An optimized compiler.


I could go on, but it would be tough to make all that work on an 8 bit CPU... BASIC816 - maybe?

VAX BASIC comes pretty close to all of that. I need to get myself a VAX to play around with. I miss it a lot...

[Chromatix]

A BASIC interpreter/compiler that actually takes advantage of the '816 could certainly be an interesting project. But I suspect that starting from BBC BASIC might be a better choice than EhBASIC for that purpose.