Arkos Tracker 2 and MSX Basic compiler

Страница 2/2
1 |

By Manuel

Ascended (19308)

Аватар пользователя Manuel

01-07-2021, 00:26

Try some games you can find on MSXcomputermagazine.nl...

Do use all corresponding BIOS routines in the compiled code? That seems like an obvious first step (go from interpretation to compilation, but do about the same thing).

By Amaury Carvalho

Resident (36)

Аватар пользователя Amaury Carvalho

01-07-2021, 18:17

Manuel, some instructions compiles to a direct BIOS call (example: CLS) and others compiles to a ROM BASIC call (DRAW, PLAY), while anothers compiles directly to assembly (PEEK, POKE, SOUND, OUT...). Also, the use of BIOS routines brings more hardware compatibility to the compiled programs.

About speed, one more thing its important to say. The source of the apparent interpreter slowness are mainly from:

  1. use of BCD numeric format into math computations;
  2. time spend on searching the variables table names;
  3. interpretation process itself.

All items above are covered by the compiler process, eliminating this issues from the compiled binary.

You can use "-s" parameter to generate a symbol file from the compilation process and load it into OpenMSX Debugger to help you see the inner works of the binary code, just like the example below:

msxbas2rom -c -s program.bas

Here you can see a video demonstrating the use of "-s" parameter.

By PingPong

Prophet (4096)

Аватар пользователя PingPong

02-07-2021, 21:24

Amaury Carvalho wrote:

Manuel, some instructions compiles to a direct BIOS call (example: CLS) and others compiles to a ROM BASIC call (DRAW, PLAY), while anothers compiles directly to assembly (PEEK, POKE, SOUND, OUT...). Also, the use of BIOS routines brings more hardware compatibility to the compiled programs.

About speed, one more thing its important to say. The source of the apparent interpreter slowness are mainly from:

  1. use of BCD numeric format into math computations;
  2. time spend on searching the variables table names;
  3. interpretation process itself.

All items above are covered by the compiler process, eliminating this issues from the compiled binary.

You can use "-s" parameter to generate a symbol file from the compilation process and load it into OpenMSX Debugger to help you see the inner works of the binary code, just like the example below:

msxbas2rom -c -s program.bas

Here you can see a video demonstrating the use of "-s" parameter.

hi, great work, a simple for next on integer variable is 6 times faster.
would be great to have a list of asm code generated from basic source code. is there a option to do this?

Страница 2/2
1 |