[z88dk-dev] zcc: llvm compilation and notemp gone
Posted: Sun Oct 23, 2016 8:47 am
I'm still sitting on this commit until tomorrow when I'll have some more time to make sure compilation isn't broken.
* notemp gone
Intermediate files will always be written to the temp directory. Having the notemp option was complicating the m4 and llvm processing. When processing m4 files, zcc needs to copy the results of macro expansion to the original source directory immediately. This is because any produced .h, .inc, .asm, .c files have to be available from their original directories in order to properly resolve search paths and they have to be moved there right away so that succeeding source files in the current compile can make use of any produced .h and .inc files. Similarly with llvm compilation a new .c source file is produced that must also be immediately written to the original source directory to properly resolve search paths. So with the notemp option there, there could be a mixture of temporary files and newly generated permanent files mixed together in the original source directory which was really annoying. For debugging purposes the temp files can still be found in the temp direc!
tory
when nocleanup is used.
Within zcc there are now three arrays that track filenames for each input source file, which serve essentially the same purposes as before: original_filenames[] contains the original filenames, filelist[] contains the name of the current working file and temporary_names[] contains the root name of temp files returned by tempnam(). Whenever m4 or llvm writes a file back to the original source directory, the original filename is changed to that new file. Also new is input source files are not copied to the temp directory immediately. Instead they are processed from their original locations so that search paths are properly resolved. Previously this was only done for .c files.
* llvm compilation
I've added llvm compilaton to zcc. I have no idea if it will work yet. You can read about it at Philip's page:
http://www.colecovision.eu/llvm+sdcc/
What zcc will do is make is transparent and automatic.
llvm requires headers that are free of any special attributes. So no callee, fastcall, preserve regs, whatever. This was easy to do for the new c library because headers for the new c lib are generated for each compiler from prototypes using a script. So this initial use of llvm will be for the new c lib for now. The set of llvm headers are in cvs already at z88dk/include./_DEVELOPMENT/standard and llvm will have have full access to the entire library.
For input .c files, clang is used to translate to llvm intermediate form .ll. Then llvm and the c-backend is used to optimize and emit a new .cbe.c file (another c file with longer extension to distinguish it from the original .c) This .c file is then compiled using sdcc per normal. At the sdcc step, sdcc is using the new c lib's sdcc headers which means all the fastcall, callee, preserve regs, etc are restored, meaning llvm compilation will not be comparatively impoverished.
The point of this is two-fold: (1) llvm+sdcc might be able to produce better code than sdcc alone. (2) we could start to use llvm to compile other languages to c which would then be compiled to z80 using sdcc.
There are a number of new options added:
-Cg"...." Add options to clang's command line
-Cv"...." Add options to llvm's command line
-clang Stop processing after clang has produced .ll files
-llvm Stop processing after llvm has produced .cbe.c files
zcc also tracks sdcc's --fsigned-char so that clang knows if chars are signed or not. zcc will also properly add include paths to clang via the normal -I option to zcc.
By default if you don't supply any arguments via -Cv to llvm, llvm will be invoked with "opt-3.8 -O2 -disable-simplify-libcalls -S " which turns on some optimization. clang will always have "-target sdcc-z80 -S -emit-llvm " added to its command line and llvm will always get "-disable-simplify-libcalls -S " which are required for things to function.
zcc is invoking the binaries "zclang" and "zllvm-cbe" so that we can avoid any conflicts by using our own private names.
I haven't actually tried it because I have to get these things compiled for windows so there are probably still outstanding problems but we can always cross fingers that it works the first time. If you're running linux it should be straightforward to compile zclang and zllvm-cbe.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
* notemp gone
Intermediate files will always be written to the temp directory. Having the notemp option was complicating the m4 and llvm processing. When processing m4 files, zcc needs to copy the results of macro expansion to the original source directory immediately. This is because any produced .h, .inc, .asm, .c files have to be available from their original directories in order to properly resolve search paths and they have to be moved there right away so that succeeding source files in the current compile can make use of any produced .h and .inc files. Similarly with llvm compilation a new .c source file is produced that must also be immediately written to the original source directory to properly resolve search paths. So with the notemp option there, there could be a mixture of temporary files and newly generated permanent files mixed together in the original source directory which was really annoying. For debugging purposes the temp files can still be found in the temp direc!
tory
when nocleanup is used.
Within zcc there are now three arrays that track filenames for each input source file, which serve essentially the same purposes as before: original_filenames[] contains the original filenames, filelist[] contains the name of the current working file and temporary_names[] contains the root name of temp files returned by tempnam(). Whenever m4 or llvm writes a file back to the original source directory, the original filename is changed to that new file. Also new is input source files are not copied to the temp directory immediately. Instead they are processed from their original locations so that search paths are properly resolved. Previously this was only done for .c files.
* llvm compilation
I've added llvm compilaton to zcc. I have no idea if it will work yet. You can read about it at Philip's page:
http://www.colecovision.eu/llvm+sdcc/
What zcc will do is make is transparent and automatic.
llvm requires headers that are free of any special attributes. So no callee, fastcall, preserve regs, whatever. This was easy to do for the new c library because headers for the new c lib are generated for each compiler from prototypes using a script. So this initial use of llvm will be for the new c lib for now. The set of llvm headers are in cvs already at z88dk/include./_DEVELOPMENT/standard and llvm will have have full access to the entire library.
For input .c files, clang is used to translate to llvm intermediate form .ll. Then llvm and the c-backend is used to optimize and emit a new .cbe.c file (another c file with longer extension to distinguish it from the original .c) This .c file is then compiled using sdcc per normal. At the sdcc step, sdcc is using the new c lib's sdcc headers which means all the fastcall, callee, preserve regs, etc are restored, meaning llvm compilation will not be comparatively impoverished.
The point of this is two-fold: (1) llvm+sdcc might be able to produce better code than sdcc alone. (2) we could start to use llvm to compile other languages to c which would then be compiled to z80 using sdcc.
There are a number of new options added:
-Cg"...." Add options to clang's command line
-Cv"...." Add options to llvm's command line
-clang Stop processing after clang has produced .ll files
-llvm Stop processing after llvm has produced .cbe.c files
zcc also tracks sdcc's --fsigned-char so that clang knows if chars are signed or not. zcc will also properly add include paths to clang via the normal -I option to zcc.
By default if you don't supply any arguments via -Cv to llvm, llvm will be invoked with "opt-3.8 -O2 -disable-simplify-libcalls -S " which turns on some optimization. clang will always have "-target sdcc-z80 -S -emit-llvm " added to its command line and llvm will always get "-disable-simplify-libcalls -S " which are required for things to function.
zcc is invoking the binaries "zclang" and "zllvm-cbe" so that we can avoid any conflicts by using our own private names.
I haven't actually tried it because I have to get these things compiled for windows so there are probably still outstanding problems but we can always cross fingers that it works the first time. If you're running linux it should be straightforward to compile zclang and zllvm-cbe.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot