about a MSXBASIC compiler?

8)But also java hasn't changed to support as MSIL in the latest version?

nope, java bytecode doesn't support generics in the last version. the java language does however.

generic types in java are compiled as "object", then all code is parsed and everywhere where a java program calls a method with a generic type there is a cast included in the calling code! after this the code is compiled as if it was a normal java program without generics. this is also a reason why in java you don't need the extensive type descriptions like you need in dotnet.

one nice thing about this way of handling generics is that newer java code that uses generics can still run on older virtual machines. dunno what is the real value of that but it is a feature that dotnet doesn't have.

"I guess those that develop now are all z80 coders"

After more than 31 years ... What did you expected !?

@LeandroCorreia: No, i found that there is no interest.

For me the initial idea was to make a alike msx-basic compiler, but with some limits, in order to make the source more readable and to achieve speed. Here an example:

- FOR NEXT LOOPS works in a more structured way no things like:

FOR T%=0 TO 100
if INKEY$="" THEN NEXT T% ELSE BEEP
NEXT T%
instead
FORT%=0 TO 100
IF INKEY$<> "" THEN BEEP
NEXT T%

GOSUB RETURN also more structured.

BUT....

1) anyone complained that this is not a true msx-basic compiler because does not support all the msx-basic interpreter features.
Now, if this is seen as another xbasic like language, why waste time to create this? there is also xbasic... and works well.

2) some other proposed to create a sort of bytecode generator (java or .net). But a simililar project is too much demanding from a hw like the msx one.

most people does not know that the vm implementations on more constrained devices (ram, cpu power) does not use jitting. instead they work as a bytecode interpreter. to make an example, see the .NET compact framework 2.

the vm on the constrained device ( costrained? 320mhz arm32 bit processor+64MB of ram ) is a bytecode interpreter. Now the same app in c# runs about 1/10 of the counterpart in native C++.

Now imagine what does it mean to a 'little more constrained hw' as the msx is.

320mhz 32 processor - 3.5Mhz 8 bit processor
64MB linear memory - 256/512/64KB paged memory...

there is no reason to create a similar sw to achieve the same speed ( a little more ) than a msx-basic interpreter.

On the other hand some one has proposed a new basic (totally incompatible with msx-basic). But there is no need. If you want you can work in Pascal, or C.

Well, I got interest. And honestly, I'd like it better if its syntax was more like QBASIC or Blitz Basic, instead of MSX Basic. Why?

MSX BASIC is a powerful language, but from a structured programming language view, it's a nightmare. I myself had many difficulties in learning structured programming thanks to the vices acquired in MSX BASIC (goto and gosub, and almost no loop structures). I'd like it even with declarable variables. As long as I get a high-level language to work, without the vices of MSX BASIC, that can be compiled in a PC and generate ROMs, that would be cool. Recently I tried to use XBASIC. It sucks with DIM commands, it's a hassle to program with a width of 40 characters. Pascal for me sucks, and C cross-compiler alternatives are all commercial.

Too bad news.
Umh, i need to think about. Maybe a new incompatible basic is not soooo bad. Of course, i need to think about the time taken to me to implement, almost from scratch, grammar,code parser & generator, and thinking about datatypes supported.
I think, almost in the first , we need :
int16, byte, string,float (single should be at least what we need). For the last datatype, because z80 has no coprocessor, i need a fast float library. Trebint send me some material, but i do not know if i can use it. the float routines are the CPC basic ones, so maybe there are some legal issues.
About Arrays, i will support them (one dimension, multi dimension require multiplication, -> performance issues on a cpu that does not have IMUL instruction)
Should be a good idea take into consideration paged memory issues, to allow more than 64kb of code or data handled almost transparently.
i think the best option is to make a very thin object code generator that relies on almost everything to external library functions (written in assembly) like z88dk do.

Let me think about, it's possible i give it a chance... of course if i decide to start i need the help of all people of mrc to do a similar project.

Float are not so important, as long as we have fixed point arithmetics (faster, and more than enough for an MSX). Multidimension arrays are nice (and needed). IIRC, in C there were many tricks for faster array indexing. And don't forget functions and procedures.