EC Container 5
29 November 2020
ASOFT with fast integers
29/11/20 15:30
I've not worked on ASOFT (my Applesoft clone) much...I made some progress in 2016, and then just haven't worked on it.
One thing I was working on was "fast integers". Applesoft does all math operations on 40-bit floating point numbers. The problem is that it spends a lot of time doing FP operations when it doesn't really need to. Each constant in the code needs to be converted to FP before use. This isn't terrible, but it's not great.
So I came up with a special FP encoding to mean "this is a 17-bit integer in the range from -65535 to +65535". Applesoft FP has a 8-bit Exponent, a 1-bit sign, and a 31-bit mantissa. When the exponent is 0, Applesoft treats the number as 0. But instead, I plan to change it so that when the exponent is 0, it's really an integer with the 16-bit integer value in the mantissa. One thing I haven't resolved is where in the mantissa this should be stored (placing it in the upper bits makes calculations easier; placing it in the low bits make converting a string to a number easier). So now, to determine if a value is 0, code would need to look at the exponent being 0, and the 16 bits of mantissa are also 0.
And then I modified the ADD and MUL routines to handle integers. If the other operand is FP, then the integer is converted to FP and then the usual FP operation is done. But if both are integer, then a faster simpler integer operation can be done.
One thing I was working on was "fast integers". Applesoft does all math operations on 40-bit floating point numbers. The problem is that it spends a lot of time doing FP operations when it doesn't really need to. Each constant in the code needs to be converted to FP before use. This isn't terrible, but it's not great.
So I came up with a special FP encoding to mean "this is a 17-bit integer in the range from -65535 to +65535". Applesoft FP has a 8-bit Exponent, a 1-bit sign, and a 31-bit mantissa. When the exponent is 0, Applesoft treats the number as 0. But instead, I plan to change it so that when the exponent is 0, it's really an integer with the 16-bit integer value in the mantissa. One thing I haven't resolved is where in the mantissa this should be stored (placing it in the upper bits makes calculations easier; placing it in the low bits make converting a string to a number easier). So now, to determine if a value is 0, code would need to look at the exponent being 0, and the 16 bits of mantissa are also 0.
And then I modified the ADD and MUL routines to handle integers. If the other operand is FP, then the integer is converted to FP and then the usual FP operation is done. But if both are integer, then a faster simpler integer operation can be done.