I'm not involved in the low level side of things, so Mark or Simon would have to clarify/correct any minor misunderstandings I've picked up, but I believe it goes something like this...
· BlitzMax's bcc generates assembly source code from your BlitzMax source code; see the .s files inside the .bmx folder that's sitting in the same folder as your source code -- open the .s files in Notepad or similar to see the assembly source for your program. On the Mac (and possibly Linux, can't check right now), the .bmx folders are hidden so you have to use the command line and ls -a to find them;
· Blitz also uses gcc to compile the C-based modules if necessary, as well as any C includes you specify. The same goes for other variants of C code, using different compilers. I believe gcc and the other compilers just put out .s assembly source as bcc does;
· fasm is used to assemble the .s code on the PC (as replaces fasm on the Mac) into .o object files, I believe. Object files are basically just chunks of 'raw' assembled code waiting to be stuffed into a working executable;
· I'm a bit vague on this part, but in the case of pre-compiled modules, I think the .o files get turned into .a files (by ar?), effectively archived libraries of object code intended to be linked (roughly = imported) into your executable, again in the .bmx folder for your app. Someone correct me here if I'm wildly off-base;
· the .i files (which you can open in Notepad), found sitting alongside any .a files, are basically declarations of what's in the compiled/archived .a files;
· BlitzMax uses ld (the linker) to stitch all the .o and .a files for a project into a working executable;
· this process is all controlled by bmk, the Blitz 'make' program, which is what the IDE calls when you go to build your program.
Something like that, anyway... feel free to correct!
|
