compilador separado

[LCD]

Hello LCD

Hi sindecencia

Thanks for your answer. I have discover the compiler recently and I am impressed. When I talk (with twitter) with Boriel, my main suggestion was to separate the compiler, as FreeBasic does:
1. One compiler for compatibility with Sinclar Basic (line numbers)
2. Another compiler improved, with sintax similar to FreeBasic (without line numbers)

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.

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.

So my main suggestion is make the 2 option, avoiding slow FP ROM routines. Use fixed point instead, there are some algorithms <!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/CORDIC">http://en.wikipedia.org/wiki/CORDIC</a><!-- m --> than are focused in hardware without arithmetic multiplier.

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.

About the double buffer, my idea was make it transparent to the user. So for example you write Circle 100, 100, 10, and the compiler writes the circle in the back buffer, and flip the buffers when completes, avoiding flickering.

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.