From Basic to ROM

no, that's not exactly what I had in my mind...

I was thinking that... for example if in a program it could be possible to call an assembly routine instead of a basic command... it would make the application a lot faster.

For example, if we need to write a string of text in a portion of the screen, instead of writing:

LOCATE 5, 10: PRINT "HELLO EVERYBODY"

we could invoke an already-made assembly routine that could do the same thing but faster:

DEFUSR=ADDRESS: A=USR(0)

My idea is: Let's take a basic program and replace as many instructions as possible with assembly routines, and then cram it in a ROM file. Basically it's a semi-compiler...

It is quite easy to take a block of text and replace some basic instructions with calls to some routines... I was actually making (for myself) a tiny application that takes a Basic program (with labels and without line numbers) and transform it in a proper MSX Basic program. What is really difficult for me is to write these assembly routines, since I know nothing of Z80 instructions and nothing about VDP hardware

For example, this is a screenshot taken from the "toy" I'm currently developing:

I know that the look is crappy, but take a look at the source code I wrote on the left, and then look at the MSX Basic version created by the application...

IMHO with the indentation of the code and the use of labels/functions instead of line numbers the code is more readable and easier to mantain. The application I wrote is simply replacing some sentences with the proper MSX Basic code... a really easy task, in the vast majority of the cases it's just a matter of Search&replace substrings here and there.

Now for example think if it could be possible to convert the line

LOCATE 12,16 : PRINT "This is the introduction"

into a call to a assembly routine that makes the same thing, but faster... even faster than using VPOKEs to change VRAM values
A lot of people that don't know anything about assembler but are skilled enough to make a basic game could be able to make games that could be both easier to develop and that could run faster IMHO

Yes. I think it can be quite trivial to build an MSX-Basic parser.
I've done several parsers during my study.

Then you'd still need to optimize the generated assembly code. The real challenge.

To be more precise my idea was to remove some bad things like this:
10 FOR T%=0 to 100
20 IF T% AND 10 THEN BEEP:NEXT T%
30 PRINT T%
40 NEXT T%

OMG.

This is not exactly a compiler, it's something simpler. A true Basic compiler would involve the conversion of every single line of code in its assembly equivalent.

I can assure that for a conceptual point of view, when having a syntax tree already built , there is no pratical difference in generating 'c' code or machine code. The real problem when working in asm on a CPU like z80 is to find the 'better' way to generate it.

Two considerations:

1) for example a statement like

A%= B%+C% that is a very simple expression tree could be done in several ways:

LD HL, (A%)
LD DE, (B%)
ADD HL,DE
LD (C%), HL

but may also be:

LD A,(A%) ; low byte of word ptr in accu
LD HL, B% ; point HL to of word ptr of B%
ADD A%,(HL) ; sum the low bytes,
LD (C%),A ; store the low byte
LD A,(A%+1) ; store high byte to accu
INC HL ; point to high byte
ADC A%,(HL) ; sum the high bytes with carry
LD (C%+1),A ; store the result, high byte.

but may also be: (another series of possibility)

choosing the best is the real challenge. At a quick look appear the the first is more fast and compact, but uses four registers, the latter only tree. So what's the better? Depends.

2) Using 'c' code as an intermediate step allow me to quickly verify some code-generation bugs.

The final step would be asm.