compilador separado

[sindecencia]

But who really needs line number? Okay, to compile old existing programs, but as ZXBC already supports line numbers, it just only needs a switch to tell the compiler, "Compile in legacy mode", so it will not need "END IF" anymore. That will be okay, but splitting the compiler and work on two versions is too much, I think.

Totally agree with you. I tell Boriel to use this switch as FreeBasic does. But It's true that in QBasic this is more important: if you can compile an old app this works in a modern computer. If ZXBC does, the app works on the same machine (or emulator) slightly faster. And as I discussed with Boriel 100% accuracy is imposible because VAL, READ DATA, etc...

When I said 2 compilers I point 2 different parsers for the same compiler.

But Boriel sad me that option 1 was no sense, because there are other proyects that are almost 100% Sinclair Basic compatible.

I support Boriel 100% with this decision.

I also agree with you and Boriel.

Maybe only as option because most coders use integers only, with rare use of FP. Adding Fixed Point library will blow the code up, and if it is rarely used, it makes no sense to replace all the routines, because if FP is rarely used, the speed does not matter that much, but wasting some of the 41 Kb free memory will kill some projects. This is my opinion.
I already suggested to give the user switch to control which Runtimes the user want to use: "ROM Routines" for slow but small programs or "Custom routines" for fast but larger programs.

Fixed point and Integer shares the implementation. For example when you multiply 2 16bit numbers, the result is a 32bit number. If you use UInteger you choose the lower 16bits of result. If you use smallFixed (doesn't exists, but Fixed in ZXBC is 32bit) you chose the middle 16bits.

The fact that it's rarely used is not a reason for not doing it. At least EXP, LN, and trigonometrical functions are useful not only in 3D. You can do Fourier transforms, differential equations, etc...

Until now the only option for do it in realtime is filling lookup tables with FP Rom routines and interpolate that.

The user needs full control about the 2nd screen. Transparent buffer is maybe good for sprites, but I do not like the idea. If every graphics command will switch the buffers, drawings will apear faster, but for EVERY object! You will see the drawings appear line by line by circle. With present system you can draw complex figures in backbuffer and then switch the screens. If there should be a backbuffer, so I propose following commands:
SetBackbuffer nr,address,mode - Sets the address od a backbuffer (maybe continuous memory as on SAM Coupé, which can address 512 KB, this will be also good for other planed supported plattforms), mode only for other systems where screen modes use different bytes count.
DisplayBuffer nr - Displays a buffer number
UseBuffer nr - Uses Buffer for drawing
SwapBuffer - Swaps tho hardware Buffers (on 128K), changes other Screen to be viewed and Use Buffer to the now invisible screen automaticaly.
Or something similar, but on the other side, nobody stops me to write Subroutines which will do that for me.
Greetings.

See my other post about double buffer, I am agree with "nobody stops me to write Subroutines which will do that for me", of course this will be optional (specified in code or compilation switch)