Marcel Kilgus wrote:
> Laurence W Reeves wrote:
>
>>> PRINT FLOAT$(-32768/1) gives $0810 C000 0000
>>>
>> You've detected the cause of the bug! SMSQ/E has allowed a unnormalised
>> value to get on the stack.
>>
>
> True. I found the following line in the code:
>
> [...]
> cmp.l #$c000000,d1 ; funny value?
> [...]
>
> So there is actually code for this special case. But notice how the
> comparison value is only 7 digits? Easy to overlook...
>
>
Excellent detective work. Especially noticing a missing zero. I dislike
code written with embedded numbers outside the range -4 to +4. I worry
when the numbers get bigger than -16 to +16. When you get to 201326592,
in error, when you meant -1073741824, it's inexcusable.
If I had to write the above instruction, I'd probably do it as:
cmp.l #-1<<30,d1 ; (abysmally) funny value?
I'd be curious to know why the code is using such a naff test in the
first place. I vaguely recall the JS ROM having something like it. All
Minnie's floating point normalisation handling works by careful usage of
the overflow flag, etc. There are only ten literal cmp.l instructions in
all of Minnie, almost all being obscure, messy values of one sort or
another. E.g.
cmp.l #$4498517a,2(a6,a1.l) compare to tan(pi/12) = 2
- sqrt(3)
<aside>
Wow! That makes me realise that there are four bytes of code I could
still save! There is the above instruction and another similar one where
there is really no need to do a cmp.l, as a cmp.w would be adequate.
They are just tests for optimal ranges of values where a particular
formula is best used. In neither case is a wildly accurate 32 bit value
critical - even 8 bit might suffice. Even better, the above instruction
could profitably be made to skip a bunch of code rather more often,
saving several FP ops which, at the end of the day, probably contribute
toward the actual computational error more so than letting past values
than are slightly higher than optimal (is anyone still following me here?).
</aside>
> Another thing discovered: I was already suspicious why QPC came to the
> same result like the other platforms, seeing that QPC should use the
> hardware FPU for this purpose. Turns out I broke the code in SMSQ/E
> 3.13 and as it uses the normal code as fallback it went unnoticed.
> Next release should have much faster floating point code again (at
> least 4 times as fast).
You never know what's under a rock until you turn it over...
--
L
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
