robcfg wrote:
You're plain wrong here. Integers do not need any shift to be stored in memory, nor for any operations, as the 6809 has opcodes to do the math. What the 6809 doesn't natively have, and what it has to be done by the Basic interpreter, is opcodes to handle floating point numbers.
I would judge that hard. Maybe I am not able to express myself that exact. What a want to say is that's this packing is nothing special, it's only one of several possibilities of an compound representation of a value which is not a simple byte or 16 bit word. Just because 6809 has some 16 bit operation other operations like logical operations, shifts and other more complex arithmetics has to be done bytewise (in same cases wordwise too) and has to be handled like a compound datatype.
To give an example that a representation may have also its advantage: The ABS() function on floats is in MS interpreters only the test and flip of a single bit, where integers needs a twos-complement (at least 2 bytewise NEG operations with carry handling in 6809).
robcfg wrote:
If you read something on Floating Point Arithmetics, like the IEEE754 standard for floating point number representation, you'll see that sign, mantissa and exponent values, are packed into a number of bytes (unlike your example which uses 4 bytes for the mantissa, none for the sign, wastes 4 bits and uses 1 full byte for the exponent).
Now, as the 6809 only handles integer arithmetics by itself, the Basic interpreter has to separate the three values, operate on them and pack it back, which is obviously slower than just doing any operation between integers.
I know and read IEEE754 and do not doubt anything what you have stated. Just want to point to fact, that even you say integer, you obviously meant 16-bit integers which fits into 6809 registers. But as soon we talk about greater integers (e.g. 32-bit, which are generally of greater use, see the BBC Basic implementation), we also have to serializing processing of bytes or words packed in a "structure". Agreed, floats are much complexer than compound integers, but everything can be reduced to integer operations and takes more or less time ...
robcfg wrote:
As I explained above, representation IS a problem. Integer arithmetics are done by the processor, while Floating point arithmetics requires a small program, which is stored in inside the Basic itself.
Yes, you right in this aspect too. But this is limited to 16 bit integers (and just for some basic operations, think about logical operations, division, multiplication, ... all not natively covered by the processor).
robcfg wrote:
The problem of converting the text on screen to actual data manageable by the processor is both a problem of integers and floats, and it has no solution unless you write your code in assembler or you don't need any input from the user.
The reason not to include integer shifts and other operations is a design decision, not related to integer arithmetic performance as it's handled by the processor natively.
Yes, but I wasn't able to focus my point. Just because 6809 has some basic 16 bit operations, it is not said that it you get native integers into the interpreter just for nothing. As explained, one have to add variable handling and type casting in expressions too. So the "design decision" in Dragon basic was (in my eyes) just a decision of space in ROM. No doubt, integers, especially of type 16 bit would be fast and a real "nice to have", but they are not necessary to get a competitive Basic interpreter for those days. And the pointer on how costly are text to number representation is just a hint that even you have fast integers, the interpreter may lost far much time in converting constants (in average programming style). I want give some notion that a Basic coder have to take the interpreters properties into account, with or without fast integers.
I did'nt want to dispute on this, I just want to give some other points of view. I don't say you are wrong. Please have patience if I'm still wrong in expressing my opinion.
