fixed is broken (*solved*)

[britlion]

Code:

CLS

#include <input.bas>
dim num AS FIXED
value$=input(8)
cls
print value$
num=VAL(value$)

print num
print num/2
print ln (num)

The last line - ln(num) breaks it. Without that line it compiles, but gives nonsensical answers. I think this is the reason why my fSin benchmark isn't compiling. fSin works with fixed point numbers.

There's an issue with input / strings as well though:

Code:

CLS

#include <input.bas>

dim num AS FIXED

value$=input(8)
cls
print value$

Compiles, but gave an out of screen error for me.

[britlion]

Oh, just saw your reply to the speed trial:

fSin is in the library at <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:FSin.bas">http://www.boriel.com/wiki/en/index.php ... C:FSin.bas</a><!-- m -->

Code I'm using:

Code:

#include "fSin.bas"
FUNCTION t() as uLong
asm
    DI
    LD DE,(23674)
    LD D,0
    LD HL,(23672)
    EI
end asm
end function
cls
DIM i as uInteger
DIM k,var,j as uByte
DIM time as uLong

LET k=5
LET i=2
let time =t()
goto start

subroutine:
return



'start:
label:
LET i=i+1
LET var=k/2*3+4-5
gosub subroutine
DIM M(5) as uInteger
FOR j=0 to 4
LET M(j)=i
NEXT j

IF i<1000 then GOTO label: END IF


REM BM8
start:
FOR i=1 to 100
result=i^2
result=ln(i)
result=fSin(i)
next i

REM print (CAST (FLOAT,t())-time)/50
print time, t()
print "Done!"
print result
print M(1),k,i,var, "\*"

For the three trials I comment /uncomment Bm7 and 8 start points and comment out the BM8 code if I'm doing BM7, and change the Sin into fSin if necessary and run. That's all I changed.

[boriel]

This is related to the completely rewritten backend compiler module (1.2.7 undergone an entire new preprocessor which now allows function inlining -using complex macros with parameter substitution). Now it's time to fix backend when I realised the bug I introduced in 1.2.6 :oops: This means I have to re-check almost every expression case in every context for every type (array, assignation, evaluation, etc for UByte, Byte, Uinteger, Integer, Ulong, Long, Fixed, Float, String) :oops:

Currently I've finished both 8 & 16 bits types (and probably strings). Because they're used most frequently. But It will take time to check & fix every case. The other good news is that now I've switched to Mercurial and start using Unitary Testing so once a fix is done, it won't be undone again with subsecuent fixes onwards (as it happened before!). Test where introduced in 1.2.6. So, in short:

• 1.2.6 - Start unitary testing
  
• 1.2.7 - Heavy refactoring to introduce the new zxbpp (I'm very proud of :lol: )
  
• 1.2.8 - Fix the bug (and a subtle silent bug introduced :x ), and optimize the backend. Faster and shorter code. Some other code refactoring towards 2.x branch.
  
• 1.2.9 - Introduce READ, DATA, RESTORE to enhance compatibilty.

They aren't not so small steps, so they take some time to recode. The idea is to move towards 2.x to implement other nice features (insted of stop here and rewrite a new compiler from scratch).

PS: I think fsin.bas should be renamed to fmath.bas since it contains many math functions (even sqrt?). It you think it's ready it can be packaged with the compiler from now on.

[britlion]

This is related to the completely rewritten backend compiler module (1.2.7 undergone an entire new preprocessor which now allows function inlining -using complex macros with parameter substitution). Now it's time to fix backend when I realised the bug I introduced in 1.2.6 :oops: This means I have to re-check almost every expression case in every context for every type (array, assignation, evaluation, etc for UByte, Byte, Uinteger, Integer, Ulong, Long, Fixed, Float, String) :oops:

Oh dear. Sorry! Some of the adjustments you've made have been pretty big - and quite clever - but sadly, that sort of thing almost always causes bugs. If there's anything I can do to help, please let me know.

PS: I think fsin.bas should be renamed to fmath.bas since it contains many math functions (even sqrt?). It you think it's ready it can be packaged with the compiler from now on.

Um, no? fSin only does Sine functions, as a fast and rougher (less accurate) calculation as written there. I have fcos.bas and ftan.bas as separate files, though they do call fSin. I suppose we could package them all up as fTrig.

There's are two square root functions in the library; fSqrt, which uses the FP calculator to calculate square roots six times faster than the rom code, with full decimal accuracy. I still think that's small enough you might want to default to it if someone uses square roots. iSqrt does integer square roots - so iSqrt(10) comes back as 3 - it basically loses the decimal in the answer. It's about 100X faster than the ROM code for 16 bit numbers, and 50X faster for 32 bit numbers; and given how slow the ROM code is, it can be quite a big difference. If anyone is ever thinking of doing anything like 3d/2d vector graphics, these two will come in very useful.

The maths functions in the library seem solid, apart from issues with the fixed point type.

Please see <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Library">http://www.boriel.com/wiki/en/index.php ... IC:Library</a><!-- m --> for details.

[boriel]

Well at this moment the best help is... testing, testing, TESTING :twisted:
Currently there are 100+ test cases created. So everytime a fix is introduced, a new test is created. Later the compiler is run against all those test and must pass all of them. So... at first it means much work, but in the end it's worth the hassle because now the compiler is much more robust and fixed bugs won't be reintroduced again.

Regardless to FP (not fixed) arithmetic, I'm thinking in introducing a flag I've seen in gcc and other compilers: --fast-floating-point or --ffast-math so it will use it's own floating point routines for +,-,*,/,SIN,COS,SQRT etc... What do you think?

I'm also glad to see even GCC has it's own bugs (similar to ZX BASIC :!: ) and their own regression test <!-- m --><a class="postlink" href="http://bit.ly/hAqYxc">http://bit.ly/hAqYxc</a><!-- m -->
I guess this is a common problem in compiler design. When ZX Basic reach a minimun quality I will open it to public contribution so people cna contribute to the code directly. :roll:

[boriel]

Okay: Download current latest version 1.2.8-s644. This is a half fix for ALL remaining types (Float, Fixed, Ulong, Long); Integer, Uinteger, Byte and Ubyte were already fixed.

There are still pending fixed. Please be patient and expect some errors (e.g. the fsin _identifier error should still remain), but calculations and prints should print accurate results now. I'm also puzzled with the benchmark result you have published as it seems 1.2.6 performing better, but this also might be bug-related. Please run your (very) interesting benchmark and update the thread... ? maybe there is some improvement...
Update: Just re-uploaded the revision s644 and should have this error fixed... Please, check and tell me :roll:

[britlion]

s644 does indeed fix the issue - the benchmark now compiles correctly with fSin included.

Well found, Boriel!

I posted the speed, though. 1.26 does still seem to be 40% faster generally.

[boriel]

Ok. This bug is closed. Let's discuss the benchmark and performance issues in the related thread! 8)