[OT] Thoughts on extending EhBasic?

[BigEd]

Hmm, yes, making all addresses 24 bit and arranging the memory allocator to work with various lumpy memory mappings would be good. There's a couple of BBC Basic variants which make use of paged or banked memory.

[Chromatix]

I really meant also going beyond that, reworking arithmetic etc to use the 16-bit operations and improved addressing modes effectively. The result might turn out to be noticeably faster than even the 65C02 version of BBC BASIC, which is already relatively good.

[BigEd]

Yes, certainly - I think there are a few ideas there which are somewhat independent
- using 'C02 instructions where possible
- using '816 instructions and modes where possible
- supporting non-linear coarse-grained memory maps where they exist (BBC Micro's paged 16k space)
- supporting 64k banked memory on '816

The first two for speed and code density, the second two for space.

An interesting option for systems with many 64k banks - say 512k RAM or more - would be an option to construct and use extended tables for multiplication and perhaps also other purposes.

[cjs]

BigEd wrote:

Hmm, yes, making all addresses 24 bit and arranging the memory allocator to work with various lumpy memory mappings would be good. There's a couple of BBC Basic variants which make use of paged or banked memory.

One issue with using 24-bit pointers instead of 16-bit pointers is that suddenly your references take up 50% more memory. There are ways of expanding the memory space available while using 16-bit pointers, however.

1. Allocate only to aligned addresses and use the LSBs you save for tags. For example, if your allocation unit is 8 bytes, the lowest three bits of the pointer are unused, and could be repurposed to indicate the bank in which the data resides.
2. Use implicit information to determine the bank for a pointer. If for any particular variable reference you know the type from information other than the pointer itself, you can put different types in different banks, e.g., string variables in one bank, scalar numerics in another, and arrays in a third.
3. If you're using a semi-space garbage collector, you can put the from-space and to-space in different banks. This gives you the speed advantage of a semi-space collector without reducing the amount of address space available for heap or increasing your pointer size, though of course you still use twice the amount of memory you would otherwise.

I have some notes on a design for objects in heaps for 8-bit microprocessor systems that might provide further ideas. There I'm particularly trying to avoid an expansion of pointer size beyond 16 bits because I'm aiming to be able to run on machines with fairly small amounts of memory (16K or less RAM+ROM).

[drogon]

Chromatix wrote:

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.

There is a version of BBC Basic that was made for the '816... It was fitted into the lesser-known Acorn Communicator which was aimed at the business market. It had a GUI written in BBC Basic (and bits of ASM from what I can tell).

-Gordon

[Chromatix]

It seems to me that you could still use 16-bit addresses (referring to the active data bank) for single named variables, including locals. You would then use 24-bit addresses for arrays.

[BigEd]

Some nice ideas there Curt... I had got as far as thinking that the interpreter, the program, and the variables could each be in their own banks (or 16 bit spaces) but you're quite right, there are finer ways of slicing allocation, and making use of slightly coarser allocations is a nice idea.

[drogon]

Chromatix wrote:

It seems to me that you could still use 16-bit addresses (referring to the active data bank) for single named variables, including locals. You would then use 24-bit addresses for arrays.

I do something similar in my Ruby816 BCPL system. The bytecode interpreter keeps stacks and global variables in bank 0 and program code and variable data is in the rest of RAM. (Banks 1 upwards)

So the interpreter can use explicit 16-bit operations to access local variables (which are all stored in a stack frame) and to access global variables (which are variables or function or data pointers) a bit more efficiently than accessing the data if it were in another bank. Tthe interpreter itself also runs in bank 0, I don't run any native '816 code in any other banks.

Everything in (this) BCPL is a 32-bit number, so that keeps things simple, although it does require a little more coding effort - e.g. function pointers are all 32-bit too but that's ok as it keeps everything nicely aligned. The stack and global pointer "registers" are 32-bits wide (and stored in direct/zero page), but the interpreter only looks at the bottom 16-bits, so offsets into bank 0 are easy.

Also worth noting that BBC Basic (sorry to keep coming back to it!) sort of already does similar to this too on the 6502 - the 27 integer variables @% through Z% are stored in fixed memory locations (From $0400) with explicit code to access them making them much faster than regular integer variables.

-Gordon

[teamtempest]

Quote:

Also worth noting that BBC Basic (sorry to keep coming back to it!) sort of already does similar to this too on the 6502 - the 27 integer variables @% through Z% are stored in fixed memory locations (From $0400) with explicit code to access them making them much faster than regular integer variables.

In MS-based BASICs, variables are kept in two separate tables, one for array variables and one for non-array variables. As each new variable is added during execution, it gets added to the end of the proper table. So the interpreter searches either table from the start each time it wants to look up a variable value (not finding it is the cue to expand a table).

I've always thought that one way to add "local" variables to BASIC would be to have an "anonymous" array at the start of the arrays table, just big enough to hold 26 scalar variables. Because it's known to be the first array, lookups would be very fast. Subroutine calls would expand that array by 26 scalar variables each time the nesting depth increased, so every subroutine would get its own set (these would never be de-allocated once allocated).

I once wrote an extension to C64 BASIC. That was relatively easy because most of the key routines - tokenizing, de-tokenizing, token dispatch, and error reporting (at least, I may have forgotten one or two) were reached via indirect vectors. You could point those to your new routines to insert your own preferred keywords and their handlers, limited only by the 128-token total limit allowed.

That might be one way to extend EHBASIC, though I doubt it could be ever be quite as simple as blithely chaining whatever you like whenever you like. Keywords that overlap each other would have to be in a specific order to avoid being mistaken for each other is the first thing that comes to mind.

But that whole scheme is probably better suited to a BASIC that is by and large ROM-based. If you're going to assemble your own BASIC, you might be better off using an assembler that can handle conditional assembly, so you can include or exclude whatever keywords you like from as large a library of them as people are willing to collectively write.

[GARTHWILSON]

Chromatix wrote:

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.

I suspect that's true.  I have never seen a BBC Micro, but I hear nothing but good about its BASIC.

I am truly spoiled on my HP-71's BASIC.  The 6502 is much more limited in memory space, but maybe there are things here anyway that could be applied to EhBASIC.  The 71 is a hand-held computer with a 60%-size QWERTY keyboard (which I could type on at about 30wpm, a little over half what I can do on a regular full-sized keyboard).  It came out in the early 1980's.  It has so many outstanding features that I could write pages and pages here; but I'll have to limit myself to just a few features.

The LEX (Language EXtension) files Ed alludes to in the head post are just that—files.  The '71 can hold as many files (including LEX files) in memory at once as you want, limited only by the quantity of memory you have installed.  (It could address half a megabyte.  I have about 350KB in mine, about half of that being ROM and the other half being RAM.)  HP did provide several outstanding plug-in modules, or "pacs" as Ed called them; but I also have a lot of LEX files from the users' groups in RAM, particularly the Paris users' group, each LEX file containing lots of new keywords, or adding capability to existing ones.  LEX files were written in assembly language.  When you load one in, it was automatically incorporated and the BASIC system recognized it.

CALL was not for calling assembly-language routines, but rather for calling BASIC subprograms.  Any BASIC file could also have as many subprograms in it as you like, again limited only by the amount of available memory.  If you have duplicate subprogram names and want one in a different file, you would need to specify which file, for example,

Code: Select all

   CALL CONTROL(A1(4), P(), Q(,), D$[3,10]) IN IOSUBS

where CONTROL is the name of the subprogram, then you see the list of input and output parameters, then it specifies that the desired subprogram is in BASIC file IOSUBS.  The subprogram will set up its own local variables and environment and not interfere with any others.  The memory used for them will be freed up when the subprogram is exited.  Any subprogram can call any other one, or even itself, nesting as many levels deep as you want, until you run out of memory.  You can still have user-defined functions, which is a separate thing.  (And yes, DEF FN allows multiple variables.)

Note that I did not put a line number in the example above.  I did not always use line numbers when I programmed (although they'll be there when the program is ready to run).  You can use labels instead.  I put spaces in for readability; but in most cases, you can type without spaces, and it will figure it all out.  It will also alert you to any syntax errors when you enter the line.  Obviously it cannot determine if a valid line will do exactly what you intended, but if it's not runable, it tells you immediately, and gives you back the line with the cursor where the first error is, so you can fix it.

It has full interrupt support for I/O, timers, and errors.  In the case of timers, you could have some action scheduled by one of the timers, and when it comes due, have the 71 carry out the job.  This is one of the few areas where the 71 is not as flexible as the HP-41cx with its timers; but if the machine is off when a time comes due, the timer can still turn the machine back on and begin execution of whatever it was supposed to do at that time.  If you wanted the job run repeatedly on a schedule, you could have the routine re-set the timer for the next interval and turn the machine off until the next time.

I/O was through HP-IL which is basically a serial implementation of IEEE-488, with all devices daisychained in a loop.  One advantage is autoaddressing.  Another is that there's no fan-out limit; and with primary addressing, you could have 31 devices, and using secondary addressing, over 900.  Multiple 71's could be on the loop and pass control from one to another, or one could even seize control.  All messages go all they way around the loop and return to the sender, which checks to make sure it did not get corrupted on the way.  Maximum speed was 5,000 bytes per second, plus overhead bytes.

The math module makes the 71 able to handle complex numbers as easily as real numbers, and has loads of complex-number functions, including a lot of matrix operations.  In spite of its 650kHz clock and 4-bit data bus, it could do an FFT (fast Fourier transform) twice as fast as the original IBM PC running GWBASIC, and could do bigger ones too since GWBASIC was more memory-limited.

The 71 had plug-and-play for software and hardware ten years before they even started talking about doing it on PCs.

RAM usage was dynamic.  You could have one program create or delete other files, or destroy no-longer-needed variables, and other things would get scooted around to fill in the new hole so as not to leave RAM fragmented.  Nothing ever gets lost as to where the variables are, where to RETURN to, where the beginning of a loop is, etc..  Truly amazing.  The memory-moving exception is the RAM used by Forth which expects addresses of Forth words to stay put.  It wasn't a very good Forth, but since it was Forth, I was able to expand and improve it a lot.  The Forth module also had an assembler but I never did learn the Saturn processor's assembly language.

Keyboard customization is valuable, especially when the keyboard is small and you can't type as quickly as you can on a full-sized one.  Keys have their f- and g-shift complements, similar to <Alt> and <Shft> on a PC, leaving 150+ combinations re-assignable to take on custom roles when you're in USER keyboard, indicated by the USER annunciator in the display.  There are three kinds of key assignments:

• A "typing aid" key assignment displays the assigned string as though you manually typed it in.
• A "direct execution" key assignment executes the assigned string without altering the display.
• An "immediate execution" key assignment displays the assigned string as if you had typed it in, then executes it as if you had additionally pressed EndLine.

Most of mine are of the first type, but I have several that make the cursor operations more like a modern PC's.  You can have lots of key-assignment files in memory at once, and make one or another active at any given time.  You can label your key assignments on keyboard overlays, which can be quickly changed.  I have a main one I use for BASIC programming and OS operations, another for Forth, and another for my own text editor which has far more features than many of of the text editors of the day had.  You can also have an outboard keyboard, although I hardly used this feature.

The display was small, at 8 dots high by 132 dots across, but was dot-addressable and could also be windowed.  You could do graphics but pretty limited by the small height, and of course custom characters.  My text editor allowed moving the little display nimbly around in the text files (of which sometimes I had several open at once) so the small display was not nearly as limiting as one might think.  Different character sets could be loaded.  I initially used the Roman8 set which my ThinkJet printer used, but now I use the DOS/ANSI [Edit: that should say IBM437] set since I use an Epson dot-matrix impact printer with it.  This is for the characters above 127, like for the Greek letters we use all the time in engineering, accented characters, box-drawing characters, etc..  When I did not need to operate portable, I could connect my HP92198 80-column text monochrome video display.

There's a command stack, with a default of four levels but can be set to have up to 15 levels.  If for example you wanted to do a command line that you did just three commands ago, you'd go into the stack and press the up arrow cursor key three times, and the whole line would be there, ready to make any desired changes and then execute again.

The 71 adhered to the IEEE floating-point standard before the standard was even officially adopted.

The HP-71B was definitely expensive.  I bought my first one in 1986 for $495 for the mainframe.  The various modules and accessories were extra, although the LEX files from the users' groups were free, entered manually from a magazine.  Long after the 71 was out of production but before eBay came around, I bought a second 71, surplus but never been used, for $25!  Now I could get a couple thousand dollars if I eBay'ed the whole set!

[BillO]

GARTHWILSON wrote:

I am truly spoiled on my HP-71's BASIC.

I'd be really impressed just to own one. They go for about $300 these days in working condition.