It is not only Borland style stuff: it seems to be written in FPC and made compatible with Delphi.
I wonder if some of the llvm code from Jonas was used here.
FPC (the llvm branch) creates llvm ir.AFAIK Free Pascal LLVM backend produces LLVM assembler text not LLVM bitcode, at least it was so some time ago. MSElang on the other hand produces LLVM bitcode directly. The advantage of using LLVM bitcode is that contrary to LLVM assembler text the bitcode format is backwards compatible between LLVM versions.
The advantage of using LLVM bitcode is that contrary to LLVM assembler text the bitcode format is backwards compatible between LLVM versions.
- exceptions (dwarf vs setjmp)
- LLVM assumes globals are non-volatile which would probably break existing FPC/Delphi code.
Setjmp used the way the way FPC uses it is a glaring bit of legacy functionality you won't find in any other language.Except in e.g. plain C and PowerBasic. This use has also C heritage, not necessary Pascal only.
LLVM IR (or as you called it "assembler text") has been a stable format for five or six years now. The last time there was a breaking change was around version 3.9. LLVM is currently at version 8.IIRC I started with 3.0.
In my opinion targeting the lower-level bitcode format in 2018 is just making unnecessary work for yourself.And improves compiling performance. As LLVM is terribly slow that is a good thing IMHO.
And improves compiling performance. As LLVM is terribly slow that is a good thing IMHO.
It's not, though. Using the "llvm-stress" tool to generate a 50,000 line random IR file, then calling "llc thefile.ll -o file.s" and lastly "clang thefile.o -o thefile.exe" is like a 20 second process at most.I would like to hear what you think is slow then. 20 seconds for 50000 lines is an eternity
Keep in mind we're not talking about compiling C or C++ code here.
If FPC would only create LLVM IR rather than assembly, it could be much simpler, would it not?No it would not save a lot of development time, because FPC does support a different set of platforms than LLVM supports (e.g. FPC supports i8086, AVR and m68k), also LLVM is planning to kick out powerpc-darwin support. Not to mention cross compiling: e.g. it is in principle possible to cross compile from m68k-amiga to x86_64-win64, cause we're not using any third party utilities for x86_64-win64 as long as the internal assembler and linker are used (which is the default). With LLVM that would not be possible.
Then you could save a lot of development time. And it would be more stable, since llvm probably has more users, so it is better tested.
It's not, though. Using the "llvm-stress" tool to generate a 50,000 line random IR file, then calling "llc thefile.ll -o file.s" and lastly "clang thefile.o -o thefile.exe" is like a 20 second process at most.I would like to hear what you think is slow then. 20 seconds for 50000 lines is an eternity
Keep in mind we're not talking about compiling C or C++ code here.
What compiler generator would be better in these caseNeither.
or what tradeoff would they involve ?Same tradeoff between RDP and LALR parsers.
Am I missing something else ? This is just for learning how this all works.If you want to learn, do as the author does: do NOT use any generators. Only use them if you really don't have time but needs to make something quickly, they give no lesson in understanding how parser works.
....
Here's an example of some IR output from using it to compile its System unit (with JavaScript code-embedding tags just for the "C-style" syntax highlighting):
Regarding the code above, how did you arrive at the correct syntax for the load statements?
I'm more interested in learning something about LLVM code generation, of which I know nothing.I suggest coding the LLVM IR by hand first, it's not like your usual assembly but it's not far either. Just familiarize yourself with the instruction set first, make a working program using handcoded LLVM IR that covers up to what you want to be able to do later with your own compiler. Only then you should move focus to the compiler.