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