about a MSXBASIC compiler?

my goal is:
write your horrible msxbasic program, accepting some 'limitation' such as no tricky for next (that are also poor style programming), test on interpreter, then convert into 'c' and compile in a faster form, without the need of anything to run.
There is an MSX BASIC compiler called MCBC2 which compiles MSX BASIC directly into a binary. I've used it in the past for the games we wrote. Works like a charm: you could even choose whether the compiler would create a plain BLOAD-able binary or one that would give you a CALL command (CALL MB if memory serves me well).

It has some limitations though: no floating point support, no disk or file access. And no support for useless commands like TRON, TROFF, RENUM, LIST...

Heh, is it possible to write some hacker MSX-BASIC program that actually makes use of TRON, TROFF, RENUM and/or LIST?
(Or other commands that are not really basic statements, but only make sense in direct mode...)

Something for NYYRIKKI?

There is an MSX BASIC compiler called MCBC2 which compiles MSX BASIC directly into a binary. I've used it in the past for the games we wrote. Works like a charm: you could even choose whether the compiler would create a plain BLOAD-able binary or one that would give you a CALL command (CALL MB if memory serves me well).

About this MCBC2 compiler, is it freely downloadable?. I know that it cames with the Millennium CD; but can it be found in any other place?

Not sure people will use a basic 2 c convertor though, as there are just too many steps to go through.
this is in middle step, in a final form the compiler will generate true machine code, that will be assembled.

using the basic to 'c' conversion allow the use of sdcc float support.

why not write a very simple Bytecode or MSIL compiler, then add a MSX Framework API as the core of the system. Maybe have a version of the MSX Framework running on the Java or DotNet API.

In case we use MSIL we bring all the languages like: VB.NET, C#, Delphi, Cobol, Java (J#) etc to the MSX platform right. In case we choose Bytecode we can bring Java to the MSX as the main development language.

Might be an idea?

Would be cool, but it's not praticable. think about java or .net and those features:

Multi-threading support.
auto variables
Garbage collector
JITTER!
virtual method dispatching
interfaces & RTTI.
!exception management!
generic types! (SUPPORTED INSIDE THE VM )

All of those have impact not only at the source level, but also at intermediate level.

IMHO, a java VM or CLR VM based on the z80 is simply impossible to make...

1) no bytecode or clr compiler has multithreading support. the api/framework has with classes like "Thread" and "Mutex".
2) auto variables are just stack variables/local variables right? nothing too difficult there i think.
3) MSX Basic has garbage collection, and java on some phones doesn't have garbage collection at all.
4) I have no clue what "jitter!", but if you mean JIT compiler then i think we can on the MSX get away with pre-compiled code, since the target platform is not chaging (all MSX has a simple Z80, unlike PC's that can have all kinds of CPU's). for MSX it's quite easy to optimize before you know the target platform (e.g MSX 2 or MSX 2+ etc). Even the R800 doesn't have too many new optimizations at CPU level that need special compiling tricks.
5) Yes
6) Yes
7) Exception management is actually nothing more then GoTo... You GoTo out of the current method. it's a 2nd way out of a GoSub routine basically. I doubt a Z80 would have a hard time with that, although Stack Frame analisys & Reflection might be a lil tricky. then again they are just an API that we can choose not to implement on the MSX right?
8) Yes it has generics, but on Java it's not supported inside the VM. On MSIL it is supported inside the VM (VM = MSIL Compiler). So MSIL supports generics, but that is just a question of how to compile it. Java compiles the Generics away at Bytecode level, MSIL compilkes them away at Machinecode level of the target system. So when looking at generics, you don't need to deal with them writing a Bytecode compiler, but you do need to deal with them writing an MSIL compiler. Thats more difficult but nothing imposible. Especially when you remember the Generic was already "Proven to be correct" during compilation into MSIL, and therefore you could choose not the check them anymore and just compile them by jumping directly into the correct entry in the methodpointer vector table (please correct me if i am wrong).

Sure it's not the easiest project, but it's doable i think.