about a MSXBASIC compiler?

Página 5/7
1 | 2 | 3 | 4 | | 6 | 7

Por PingPong

Prophet (3898)

imagem de PingPong

19-10-2007, 19:54

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 Tongue )

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...

oO

Por AuroraMSX

Paragon (1902)

imagem de AuroraMSX

20-10-2007, 11:05

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...

Por AuroraMSX

Paragon (1902)

imagem de AuroraMSX

20-10-2007, 11:10

Why not a extended MSX-BASIC?
I mean, Qbasic loops (like while, end...) and better IF-THEN-ELSE structures...
I allways missed conditional loops like them and IF is too slow...
The fun part of MSX BASIC is that it's very easy to extend. Either the more official way by implementing CMDs or CALLs, or somewhat trickier, by e.g. hooking into the syntax-error routine. (IF syntax error THEN check if we've encountered my new command ELSE ok, we *do* have a syntax error)

Por Manuel

Ascended (18864)

imagem de Manuel

20-10-2007, 12:12

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? Smile

Por Trebmint

Champion (294)

imagem de Trebmint

20-10-2007, 13:56

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...

The use of floats is probably pretty useless since most people just want to write games anyway. Plus I found that while Integer math was far faster than interpreted the float routines (stolen from CPC locomotive basic) had around only 2-3 times speed increase probably unsuprisingly. Removing floats would probably see a general improvement in speed and far less complexity required in the compiler.

Not sure people will use a basic 2 c convertor though, as there are just too many steps to go through. I was suprised that nobody seems to have worked with Nerlaskas C SDK for symbos yet, and tbh nobody seemed interested in symbasic either which is why I canned it.

I guess those that develop now are all z80 coders

Por jltursan

Prophet (2619)

imagem de jltursan

20-10-2007, 14:30

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?

Por AuroraMSX

Paragon (1902)

imagem de AuroraMSX

20-10-2007, 15:25

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? As far as I know, it is not PD or freeware, so no downloads available Sad

Por PingPong

Prophet (3898)

imagem de PingPong

20-10-2007, 15:55


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.

Por Sd-Snatcher

Hero (582)

imagem de Sd-Snatcher

20-10-2007, 20:02


I was suprised that nobody seems to have worked with Nerlaskas C SDK for symbos yet,

-No time

I did some testing to see how works.

Por multi

Expert (74)

imagem de multi

21-10-2007, 15:48

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 Tongue )

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...

oO

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.

Página 5/7
1 | 2 | 3 | 4 | | 6 | 7