Handling variables in a basic interpreter

[Dajgoro]

A while ago I started writing a basic interpreter that should be portable to any system which can compile C code.
Before I started I looked on the web, and found a similar basic interpreter written in C, but the problem there was that it assumed that the program is stored in a array, and reworking that was a complete pain(I did try).
What I am trying is to detach the interpreter part from memory management and IO. That would give me the ability to store the program on any medium, from memory arrays to slow i2c eeproms, or any sort of medium that might require seeking.

A simple scenario would be a pic with a i2c/spi eeprom for program storage, but then I started thinking about the 6502, and since I now am working on a new modular system I want to have some proper software for it.
The problem is with the cc65 and its limitations. When it comes to numerical values a easy way to handle that would be to store them all as floats, but there is no float support for the cc65. If I was to manually implement float operations it might end up messy and that would be completely unnecessary when porting it to any other system which has float support.
So I am thinking what would be the best way to handle numerical values? Always integers? Always floats? Combination of int and float data types? Use fixed point values?

[BigDumbDinosaur]

Dajgoro wrote:

A while ago I started writing a basic interpreter that should be portable to any system which can compile C code...So I am thinking what would be the best way to handle numerical values? Always integers? Always floats? Combination of int and float data types? Use fixed point values?

Most business BASIC interpreters offer both integers and floating point values in ranges that are very large.  For example, Thoroughbred BASIC has a floating point range of ±0.99999999999999^-114 to ±0.99999999999999^141.  Thoroughbred BASIC also offers an integer type with a range of ±99,999,999,999,999.  Neither of these ranges is practical on an eight bit MPU.  I suspect they are being implemented in some form of packed BCD, but not having ever seen the interpreter's source code, can't say for sure.  Business BASIC interpreters tend to gravitate to BCD due to the need to avoid the typical ASCII <—> binary conversion errors that often arise with fractional amounts.  While BCD addition and subtraction on the 65C02 run at about the same speed as the binary equivalents, BCD multiplication and division are much more laborious, as, of course, are transcendental operations.

A more practical range for use with the 65C02 would be an integer range of +32,767 to -32,768 and a floating point range comparable to a float in C.  The 65C816 readily handles 32 bit unsigned integers, which I use a lot in my filesystem software, and could probably handle a floating point range comparable to a double in C with reasonable alacrity—though I would expect that transcendental functions would tend to be slow.

Yet another possibility would be scaled integer math for everything, such as what Garth has advocated.  However, you would be sacrificing precision and memory to gain compute-bound performance.

[Dajgoro]

I don't mind so much about the speed. Its more of a questions how to make it fit on various systems without having to redo a lot of code each time. Since I am using C compilers I cannot rely on architecture specific functions like the 6502 BCD arithmetic.

[BigEd]

I think the only natural choice is signed integers - you just need to decide between 16 bit and 32 bit. These days most systems have more than a few kilobytes of RAM, so 32 bit is probably best - the density advantage of 16 bit is not worth much.

[White Flame]

Fixed point wouldn't be that much more expensive to add, but given that it's not as generally useful as floating point, may or may not be worth adding.

[GARTHWILSON]

I'm not sure there is really any one right answer. I like that BDD specifically said "scaled integer" though. The opposite of floating-point is often quickly concluded to be fixed-point; but note that fixed-point is a limited subset of scaled integer, and is not as flexible as scaled-integer.

When I was first introduced to scaled-integer, I liked the idea, but was skeptical. As I gained experience with it, I came to prefer it (for systems that don't have a floating-point coprocessor). There will always be a place for floating-point, like calculators where the range of input numbers is not known ahead of time. For most applications that I deal with, the range is well known ahead of time, for example taking numbers from an analog-to-digital converter whose precision is 8 bits, 12 bits, or other number. It will never surprise you with something outside its designed range. In the example of a 12-bit converter with a 5.000V reference, each count will be 1.2207mV; so in that sense it's already scaled-integer.

Even a lot of digital signal processing is done without floating-point math.

If you never need precision finer than one in 65,536 parts, 16-bit integers will always be enough if you scale the needed range to fit into the number of bits you have to represent it. Avogadro's number? Nanometers? Microvolts? Picofarads? GHz? No problem. However, the burden of scaling is borne by the programmer, rather than a floating-point unit that has to keep doing it at run time. Intermediate results may be double precision, which in 6502 normally means 32 bits rather than 16. You can also have triple- and quad-precision numbers, although I don't remember if I've ever used them myself (meaning the need is rare.)

There's much more about it on my web page on the subject. I probably ought to change the title of the page, because although it's the second most popular part of my website (not far behind the 6502 primer), I think the name (about the tables) causes potential readers to ignore it just because they're not interested in the tables themselves (or at least think they're not). There is much benefit to be had from scaled-integer math without necessarily using the huge tables.

[theGSman]

White Flame wrote:

Fixed point wouldn't be that much more expensive to add, but given that it's not as generally useful as floating point, may or may not be worth adding.

I would have thought that the opposite would be the case.

[White Flame]

I meant in reference to signed integers as per the post above mine, not that they're comparable in expense to floating point!