I've got a version that does LONG as well as uInteger later in this thread.

I note that the compiler uses the Spectrum ROM square root routine. This routine is hideously slow. It actually calculates x^(0.5) instead, and takes ages about it. The Newton-Raphson method would be a lot faster, and pretty easy to put in.

If you are willing to sacrifice accuracy, an integer square root would be faster still. For a lot of situations, an integer root would be just fine - for example, if I had to calculate the nearest of two objects on screen, I'm going to have to use pythagoras' theorum to calculate distances. [ A^2 = B^2 + C^2 ] that needs square roots to make a distance. But probably the nearest whole pixel would be a perfectly good enough result!

So, here are two functions, and some code to demonstrate them. One is a perfect replacement for sqr.asm in the library, actually - it's full floating point compatible, 100% accurate, and about 3-6 times faster. It actually uses the FP-Calculator in the rom. It just doesn't use the SQR command. [Note: It comes back with something instead of an error in case of a negative square root request. Boriel - you might want to change that behavor. Not sure.] The integer version... well - look for yourself! I reckon it's about 40 times faster than the fast version.

Also: Should be able to do a something similar for a 32 bit LONG integer.

Copy and compile this program. I hope you like it:

One of the reasons you are probably looking at this is that you have some idea how to program in Sinclair Basic, and no idea how to code in machine code (or z80 assembler as it's sometimes called). You want to go play with the old spectrum stuff, and want faster programs - and it must be easier these days, right?

Well, with Boriel's compiler, it is. Most programs can be put into the compiler in a form almost identical to an original sinclair basic program, and it will work. It will be faster. But you want to make it as fast as you can, right?

First thing then: variable types. (see http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Types for details on what variable types the compiler supports.)

Nothing you can do to your program will make as big a speed increase as making sure you use the smallest variable type possible in every case. A byte is better than an integer is better than a long and all those are better than using floating point numbers if you can avoid them.

Have a look at this program:

There has been several forum technical problems regarding to cache and template issues. All of them seems to be fixed now.
Please read here for more info: <!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/viewtopic.php?f=9&t=375">viewtopic.php?f=9&t=375</a><!-- l -->

Sorry again, and thanks to Britlion for notifying me. 8)

=== English ===

There has been several problems regarding to this site styles and template caches, all of them has been fixed now:

• New users could not register, because Captcha code was failing! (Fixed)
  
• Private mensajes and Forum email notifications were not working so I was not aware about new users questions! Sorry. Thes has been fixed!
  
• Template glitches and misbehaviour (Fixed)

• No se podían dar de alta nuevos usuarios, porque el código visual de Captcha estaba fallando! (Arreglado)
  
• Los mensajes privados y las notificaciones por email no estaban funcionando, así que no me estaba enterando de los nuevos mensajes de los usuarios. Lo siento. Eso está arreglado!
  
• Diversos fallos en la plantilla así como comportamientos erráticos. (Arreglado)

Okay, I've made several posts and it's all getting confusing. Here's what seems to be wrong:

• * [Tested Fixed in 1.25 Beta r1489]@variablename - Seems to point at one byte BELOW the correct one.
  
  * [Can't replicate cleanly. Needs proved example of error.] [This was probably caused by the stack erorr which is fixed in r1489 ] CHR / CHR$ - CHR$(variable) seems to crash sometimes. CHR$(number) works fine.
  
  * [Tested Fixed in 1.25 Beta r1489] BOLD and ITALIC cannot be used as temporary attributes (BOLD 1 works. PRINT BOLD 1;"Hello" does not.) The compiler issues some very cryptic error messages about this.
  
  * -O2 and -O3 are likely to fail to compile what -O1 and no optimization compiles perfectly. (Seems to fail in 'update_goes_and_comes' in optimizer.pyc on larger files)
  
  * [Tested Fixed in 1.25 Beta r1489]SHL and SHR don't work for Integers (reported by LCD)
  
  *[Tested Fixed in 1.25 Beta 1] Comparisons : the Boolean logic for >= for type FIXED is bugged. (it always returns true)
  
  *[Tested Fixed in 1.25 Beta 1] uByte seem to have something wrong on the comparison front as well:
  
  Code:

  DIM ub as uByte
DIM b as byte
DIM ui as uInteger
DIM i as integer
DIM ul as uLong
DIM l as LONG
DIM fi as fixed
DIM fl as float

print ub,b,ui,i,ul,l,fi,fl

if 0<=20 then print "0<=20" : END IF
if ub <= 20 then print "ub <= 20" : END IF
if b <= 20 then print "b <= 20"   : END IF
if ui <= 20 then print "ui <= 20" : END IF
if i <= 20 then print "i <= 20"   : END IF
if ul <= 20 then print "ul <= 20" : END IF
if l <= 20 then print "l <= 20"   : END IF
if fi <= 20 then print "fi <= 20" : END IF
if fl <= 20 then print "fl <= 20" : END IF
  
  NOT strictly speaking broken, but serious "Quality of life" issues:
  
  * The compiler's errors could be a lot more helpful!
  1> Instead of "unexpected end of file" how about "You started a FOR loop on line 30 that never finished" and "You have an IF on line 100 that doesn't have an END IF" - if the compiler could say what statement or parenthesis isn't closed that would help me track down about 90% of my bugs. As it is, I type a line, compile, type a line, compile and so on - otherwise I'd never find the problem! [I'm REALLY bad at forgetting END IF]
  
  2> Could we get a warning any time a variable is used that hasn't been DIM first? Or just plain not allow it, even? A mistyped variable (vectory instead of vectorY) is very hard to find if the compiler simply creates it without telling me. So the program compiles and runs, but the math isn't working right...
  
  * The assembler seems to be very slow - zxb --asm program.bas returns to the command prompt within a few seconds. If we ask the assembler to assemble the file as well, it can stay away for several minutes.
  

The following two subroutines will support 42 character printing. Colour is allowed, but be aware that the characters are NOT guaranteed to fit into an attribute square, and as such, may cause colour clash.

Set colour with the permanent colour statements (ink/paper not in a print line).

The 42 character printing routine maintains its own X,Y coordinates for printing. Printing on all 24 lines is supported.

X values can range from 0 to 41 (0 <= X <= 42) and Y values can range from 0 to 24 (0 <= Y <= 24). Use the printAt42(y,x) call to change the current position of the printing, otherwise successive prints carry on where the last one left off (with runover to the next line, correctly after the 42nd character).

Size is kept to a minimum, because the routine uses the ROM character set and cuts out lines from it in order to reduce to 6 pixels wide; with a couple of exceptions that are improved by being thus defined here. A redesigned character set is possible, but only for about 31 characters, owing to space limitations in the data design.

Characters ARE vertically aligned to the 42 character grid, however. This is not proportional printing. Therefore this routine can be used safely for tables and other such gridded arrangements.

Original routine this is based on was written by Paul Wardle.

printat42 routine

Okay, this one is pretty small. It crashes.

Just a thought...but since ZXB is based on python, and the SkoolKit is python, and it has a disassembler built in python...

it would be very cool to have the option of disassembling other people's programs to steal routines from.


<!-- m --><a class="postlink" href="http://www.worldofspectrum.org/forums/showthread.php?t=28326&highlight=disassembler">http://www.worldofspectrum.org/forums/s ... sassembler</a><!-- m -->


Now I have NO clue about python, but to my mind it can't be too difficult to joint the dots there and make ZXB an assembler AND a disassembler all in one.

asm in -> .bin file out and .bin file in to .asm out!?

These items do seem to be quite high on a few people's wish list. I hope they help!

Right now I only know how to use FASTCALL with a single parameter. If anyone knows how standard multi parameter calls work when we get into m/c please let me know. For the moment, these work and are pretty fast, even though AND and OR cheat a little.

Binary NOT (8 bit version)