fixed is broken (*solved*) - Printable Version

fixed is broken (*solved*) - Printable Version

+- Forum (https://www.boriel.com/forum)
+-- Forum: Compilers and Computer Languages (https://www.boriel.com/forum/forumdisplay.php?fid=12)
+--- Forum: ZX Basic Compiler (https://www.boriel.com/forum/forumdisplay.php?fid=11)
+---- Forum: Bug Reports (https://www.boriel.com/forum/forumdisplay.php?fid=15)
+---- Thread: fixed is broken (*solved*) (/showthread.php?tid=333)

fixed is broken (*solved*) - britlion - 03-17-2011

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.

Re: fixed is broken - britlion - 03-17-2011

Oh, just saw your reply to the speed trial:

fSin is in the library at <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>

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.

Re: fixed is broken - boriel - 03-18-2011

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. Idea

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.

Re: fixed is broken - britlion - 03-18-2011

boriel Wrote: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.

boriel Wrote: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 <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> for details.

Re: fixed is broken - boriel - 03-18-2011

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 Idea

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 <a class="postlink" href="http://bit.ly/hAqYxc">http://bit.ly/hAqYxc</a>
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:

Re: fixed is broken - boriel - 03-19-2011

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:

Re: fixed is broken - britlion - 03-19-2011

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.

Re: fixed is broken - boriel - 03-19-2011

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