| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
Basic Compilers (Help!)
Hi there,
I have got a basic program lying here that I would really like to compile. It is the basic part of my game "Advanced Space Battle".
Unfortunately, compiling this thing has turned out to be rather difficult. It seems that none of the available compilers is able to produce code that really works, because the basic part calls Asm routines via extended syntax (this happens about 600 times in the whole program). Everything below $0800 and above $a000 is crammed with machine code and other data. The Asm parts call various ROM routines, but I have patched them to leave the 0page ("virtually") untouched.
At the first sight, good old Austro-Compiler (and "Blitz!") seems to work fine, and the compiled code is even shorter than the uncompiled program. The problem is that the compiled code crashes at unpredictable places without any apparent reason.
The "Basic 64" compiler does not seem to make it either.
After a looong time of debugging, I have managed to compile a *part* of my program with the "Basic Boss". It was not possible to compile the whole program because the object file would have been way too large. I had to patch my Asm routines at various places, and in the end, everything worked fine.
OK, and now my question is: Does anybody of you have any kind of documentation or detailed information on one or more basic compilers? Docs, Manuals, Etexts? (Project64 does not have something like that, and 2 days of Google searches did not reveal them anywhere else).
About the "Basic Boss" I think I don't need anything more beyond what I already have, but what about the Austro? Why the heck doesn't it work?
Thanks a lot. |
|
... 12 posts hidden. Click here to view all posts....
|
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
Nah, just put the whole program in the main function, and you can use goto as much as you like. :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
hehe i've actually attempted writing a basicv2=>C converter once.... its a true nightmare really... it will work for simple stuff, but basic-v2 allows some really weirdo constructs which are kinda hard to translate to C, atleast automatically :)
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Simple things like
10 i=0
20 print"hello!":i=i+1:ifi<10then20
can be translated to
int main(void) {
float F_i;
L10:
F_i = 0;
L20:
puts("hello!");
F_i = F_i + 1;
if (F_i < 10) {
goto L20;
}
}
Not exactly pretty code :) Automatic translation is bound to be very hard, but simple machine translation that requires manual fixes to work would be possible. The question is it's worth it :)
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
*if* it's worth it.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
in this case (translating from cbm-basic v2 to ansi-c) it most probably would indeed be worth it... think of the typeless math in basic-v2 (all calculations are done in floating point, aka slowass). this is however also the point that will make it hard to machine translate. (actually it will make it *very* hard to translate to code that doesnt appear to work but fails for wrong results in the end).... the way you can mix strings and numbers and other expressions in basic v2 is a hard nut to crack here. (some of them cant be translated to sprintf etc easily).
uhmz owell
i'd either look for a decent basic compiler, or consider writing it all from scratch (in either C or asm, depending on what it actually is)
|
| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
Writing it all from scratch is not exactly what I would like to do... I mean I *could* try to do it in Asm, but I did half of the game in Basic precisely because I wanted to be flexible with floating-point math. Converting floatingpoint formulae with 8 opening and 8 closing parantheses in pure assembler code is not particularly easy ;-)
Basic Boss *is* decent (for example, you can define variable types like byte, integer, real), the only problem that remains is the size of the object code. Optimization of details is still possible, but there is nothing that would easily save me 16k ;-)
Maybe I will have to reduce the amount of strings I use heavily, so that the code gets shorter, and/or I will have to pick out program details that are not vitally important... Although I really would like to avoid this type of "castration" of the program.
By the way, I could get hold of a documentation of that Input64 Speedcompiler... Got it via the library system of universities. I´m still not very optimistic about that one, though... |
| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
OK... It seems that Austro Speed is a good candidate, it's only that the object code needs some patches. I just added two PLAs to the P-code interpreter, and now a small test program runs correctly! *eg*
Maybe there is more to patch, though... |
| |
Richard
Registered: Dec 2001
Posts: 619 |
Here's my solution.
First of all you need to think where you are going to place your music, graphics, and additional assembly code. Write you BASIC program and then compile just the basic program, load the rest of the datas and then use a cruncher, such as Time V5.0 or Abuze V3.71 to compress your production and use $081c as jump start as Austrospeed and Blitz uses that particular jump address.
If you have any problems, just ask :) |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Richard, I'm sure MorGorr has thought of all memory locations, and quite extensively.. |
| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
Quote: Here's my solution.
First of all you need to think where you are going to place your music, graphics, and additional assembly code. Write you BASIC program and then compile just the basic program, load the rest of the datas and then use a cruncher, such as Time V5.0 or Abuze V3.71 to compress your production and use $081c as jump start as Austrospeed and Blitz uses that particular jump address.
If you have any problems, just ask :)
Richard... Please!
There is no reason why crunching everything should solve any problems. It is quite obvious that the SYS address of the Austro-Comp object code is a good jump-in address, but that hasn't got anything to do with the problems I was talking about.
And Cadaver is right that I examined this type of thing quite extensively... I spent entire days in single-step trace mode ;-)
Basically, the solution involved only three ingredients:
(1) The Austro-Speed compiler
(2) The double PLA patch I was talking about
(3) Removal of all "FN" calls from within the parameter lists of my handmade Basic commands. (E.g., "<Ox,y,10,10" correctly opens a window both in the compiled and in the uncompiled version. In contrast to that, "<Ofnx(1),fny(1),10,10" works only in the uncompiled version, so I simply removed that. If you know what I mean.)
The game is actually almost ready now!! It's only that I have very little time left to work on it so that I need weeks for even very small amendments. It's a shame...
There are only 2 features left to install:
- Savegame/Loadgame option
- Logfile writer and logfile displayer (the latter one will be a little extra program that displays line charts to visualize how a match has progressed in a "historical/statistical" overview)
And then everything has to be linked correctly and the last cosmetic changes have to be made... I don't promise anything, but it MUST be possible to complete everything this year! |
| Previous - 1 | 2 | 3 - Next |
