HP 2000F TSB ported to MSP430FR5994

Question

Preface

I'm considering the idea of porting the time-shared BASIC (TSB) that was developed by Hewlett-Packard for the HP 2000F TSB system, which used two processors at the time (one for the I/O and the other for time-shared BASIC operations for each user on the system.)

I can elaborate on why this particular edition was so good, if asked. But let's suffice it that it was very good.

At the time, we (yes, I worked on TSB back in the day) worked with core memory (which remains one of the best inventions for non-volatile memory.) Texas Instruments is including FRAM (up to 256kb of it) in its MCU ICs. FRAM is not the same thing as core, but it has many of its excellent features. And it is attractive (to me) to consider adapting the HP 2000F TSB language features to the MCU. Many of the design choices made are appropriate for this kind of limited memory size (256 kB + 8 kb SRAM) and I think it would be a good fit.

Question

I'm facing a question, right now, for which I could use some thoughtful input. TSB only supports one numeric data type -- a floating point format. All variables, arrays, and matrix operations assume this single, simple format. There are no integers and, obviously, no variations in memory footprint. Every numeric value is floating point and occupies exactly the same space.

It worked well enough 'back in the day.' But it imposed some limitations on array sizes -- especially in cases where only integers were being kept there. We'd spend time "packing data" into FP for denser formating, with added code to achieve it. But it was a pain and required some care because FP doesn't follow some math rules (like the distributive property.)

Also, I'm planning on using the FRAM for storage of "compiled-save" and "ASCII-save" BASIC code, and also for "FILES" containing preserved data. I'd like to reserve the SRAM for running variable storage. This will limit the size occupied by all the arrays and variables.

The question is this: Is there a strong reason for supporting integer data types?

The downside for me is that expression execution will have to accommodate different types if I support them. This will increase the FRAM footprint for the simulator and will force me to carefully consider conversion rules. The reduction in remaining FRAM will impact saved code and data space. And I don't think there will be much advantage in execution time. On the other hand, it will allow smaller SRAM allocations for arrays of integers. And that may be worth the trouble.

This isn't an easy question for me, as I'm a little unsure of the market interest for end users. Only time will tell on that score. I'm also not looking to make any money on this. I make plenty already doing my regular activities -- way more than I need. But I enjoy writing interpreters (not the first by any shot) and I would like to build something that will help others. This 'balancing' issue is bothering me right now and I'm interested in any thoughtful comments.

Summary

This is something I will do. And I have the experience and background to complete it. (Done it before, at least.) My hope is to allow users to leverage the TI launchpad products (which can be used to program individual, external ICs on protoboards, for example) to generate their own custom-programmed MCUs that include the execution-code for BASIC, as well as creating, editing, and saving BASIC code in FRAM. Using the techniques developed with HP's TSB, RAM usage can be mitigated/adjusted by breaking the code up into multiple programs (the CHAIN command can be used to preserve certain variable values in SRAM while releasing others, allowing the 8kb to be more effectively used in tight situations.)

My main thrust right now is about the value/cost relationship of supporting more than one datatype. I'm not expecting 'the answer' that clarifies everything for me. But I'd love to hear some good arguments. I'll select the best, regardless of how much it actually helps me with this project.

Answer 1

The question is this: Is there a strong reason for supporting integer data types?

In the MCU with limited memory? Sure. But you can get most of the benefits without a new type with very little additional code.

In this former thread the format on the Sinclair machines was discussed. Their BASIC set a flag in the data to indicate it was "short" and then short-circuited the evals in those cases. This gives you better performance on integers. However, I see a major flaw in their implementation - they used the same storage format for these values, meaning they took up the same amount of memory even for small constants. The space in the variable value table is really a non-issue because it tends to be small (~70 vars in the largest program I have), but in an app with lots of DATA statements or doing file reads into an array, their implementation could be greatly improved by using a second storage format.

Answering these exact questions is why I wrote RetroBASIC. It has some basic stats gathering that I found extremely revealing. For instance, an integer type seems like a very good idea when you consider that 669 of the 712 numbers (not including line numbers) in Super Star Trek are 16-bit ints. But that obscures another important stat that 1/3rd of all the numbers are 1 or 0, and the vast majority of those are found in logic statements (IF X>0...) or loop increments. An example: there are 101 zeroes in Super Star Trek, and 77 of those are in =0 or [<|>|=]0 tests. So if you're trying to save memory in a typical program, you're better off making a token for "1" and "0", or perhaps looking for and tokenizing the entire A=A+1 into inc(A) and things like IF X>0... into ``IF GT_ZER(X)...` which will reduce the size of the tokenized code and improve performance.

Answer 2

As far as I can see the question here is:

Is there a strong reason for supporting integer data types?

Well there is no definitive answer. It's, as usual, defined by naming advantage/disadvantage and prioritze them according to your needs/profile. In addition there's a historical dimension, especially when recreating classic software

• Original BASIC was intended to be a simple (learners) language. So simple it should be.

• Data was only numeric (*1).

• Float can cover (*2) integer fine.

• At that point is was a similar to using a combined type today.

• When (much later) the need for string did arise the added typing was rather a hack than a planned development

• Original Dartmouth BASIC and many early BASICs - including HP - did not add other types at all, or only very late in the game.

• Main reason to add integers is space saving. and integer is some 1..4 bytes of data storage compared to 4..8 for float. Most notably with shorter int sizes (like 16 bit).

• Space saving was important at both ends:

  • in professional computing it allowed to fit large(r) data sets into limited Memory
  • in home/micros with their initially small memory it might have enabled useful applications at all

• Especially with early micros space saving was important.

• Using integer may increase speed. In searching as well as in execution

• The later may require a good deal of additional code not needed otherwise.

---

So ask yourself, do you ...

• ... see any advantage of dedicated integers in your project?

  • That is speed or storage size.

• ... want to diverge from the original language by adding?

  • Or better stay as close as possible to the original language?

• ... want to consider various ways of adding integer?

  • Like adding
    • type suffix ('%') or
    • type definition (DEFINT A-F *3) or
    • internal discrimination.

• ... want to only change the internal workings by adding an automated integer type - to realize the speed advantage without changing the language?

  • That is, if speed is an issue at all?

You port, your language, your choice.

---

Now, if you allow a personal opinion, I would go ahead an do it as close to HP TSB as possible do all materials about that language could be used 1:1. At the same time I would think about extending on the original idea of Dartmouth BASIC of not having types at all.

This can be easy done by only noting the type as result of a variable being set using implicit type conversion. If a certain type is needed, explicit conversion can be forced with the usual functions (INT, STR, etc.), eventually adding a FLOAT() for completeness.

It would add back simplicity for average small programs while preserving the ability to force certain formats when needed.

Under the hood (aka in the interpreter) one can do any other optimization as well without telling the user - like for example Sinclair did with their int/float handling.

---

*1 - Strings were eye candy for printing, like with most early computing at the time.

*2 - Within limits that are fine for a learners language.

*3 - Like Microsoft did with Extended BASIC. Here any variable name or name range could be (pre) defined as a specific type, saving the need to add a type suffix. Made much sense as it allowed to just program ahead and add specific types only later to optimize.

Answer 3

My immediate inclination would be to say no, don't add it, at least not now.

Although I'm a long ways from being a religious believer in Agile methodology, I think in this respect they have at least something of a point. It's best to start with some "minimum viable product", and add features primarily in response to demand from users.

I'd say TSB probably doesn't need features added to be viable. As such, I wouldn't add features until or unless users ask for it.

But I'll admit that's something of a blind assumption. If memory serves, HP had previously been purely an instrumentation company, and the 2000 was their first computer, so it was used primarily for controlling instrumentation (and similar). So the obvious question would be whether that's the market you're addressing today, or whether your likely users are doing things that are different enough that they demand different features.

The other obvious question would be whether during its life there were features that were heavily demanded for TSB, but (for whatever reason) simply weren't practical to implement at the time. Given that you're basically rebooting the project, it may well be worth considering including things you know people wanted but you just couldn't do at the time.

But ultimately, I'd go back to the basic idea: don't add features until you have some factual basis to support doing so. And right now, the available facts say TSB was pretty solid exactly as it was. You don't yet know enough about how anybody is likely to use it today to make a meaningful decision about what changes will be good, so it's probably better to leave it alone.