Code generated by fbc parser: c or assembler? (choice)

[Coolman]

I don't belive "-gen gcc", will be the future. I would suppose something like "-gen llvm" witch makes fbc behaving like a frontend, of the llvm Framework. This supports all important platforms as well and has some additional advantages, e.g.:

- More optimisation possibilities, because no abstraction to C schematics.
- Idiologic Meaning: FBC won't be only a GCC precompiler.
- Possibility to use llvm-Bytcode + jit-Compiler/Interpreter to write platform independent binaries. (If this is configured)
- Possibility to use llvm tools (debugger, libraries etc.)

+1

[marcov]

It occurs to me that this might be easily and (to a certain extent) transparently fixable by having a bunch of #defines to change the names? E.g. "#define ax __ax", .....

Not only _ugly_, but if it works depends on if the preprocessor also substitutes inside asm blocks. Otherwise, an "ax" there also gets substituted.

[counting_pine]

if it works depends on if the preprocessor also substitutes inside asm blocks. Otherwise, an "ax" there also gets substituted.

Good point. If asm is being used, at least. But at the least it (and other reasons that occur to me now) prevents a simple #define-based internal fix in FB due to the possibility of that.

[marcov]

if it works depends on if the preprocessor also substitutes inside asm blocks. Otherwise, an "ax" there also gets substituted.

Good point. If asm is being used, at least. But at the least it (and other reasons that occur to me now) prevents a simple #define-based internal fix in FB due to the possibility of that.

It can be used as a workaround till there is a proper fix yes. But isn't it easier to simply prefix all FB generated symbols with say fbspace or so?

[marcov]

I don't belive "-gen gcc", will be the future. I would suppose something like "-gen llvm" witch makes fbc behaving like a frontend, of the llvm Framework. This supports all important platforms as well and has some additional advantages, e.g.:

- More optimisation possibilities, because no abstraction to C schematics.
- Idiologic Meaning: FBC won't be only a GCC precompiler.
- Possibility to use llvm-Bytcode + jit-Compiler/Interpreter to write platform independent binaries. (If this is configured)
- Possibility to use llvm tools (debugger, libraries etc.)

Unfortunately, also magnitudes more work, and, since LLVM is C++ needs C++ connectivity. So unless you have a can of developers somewhere willing to work on it, extremely unlikely.

[AGS]

@Marco

I read on the FreePASCAL site that The Free Pascal Compiler can generate byte code for a Java Virtual Machine. That's quite impressive.

[marcov]

I read on the FreePASCAL site that The Free Pascal Compiler can generate byte code for a Java Virtual Machine. That's quite impressive.

One of the FPC developers was commissioned to do it. The code is merged in, but not yet used much. The reasons etc are unknown, but it was for server code, not mobile.

Like all native->Java/.NET ports it is only for a subset of the language, you need to be careful with pointer usage. These constraints are now also on parts of the runtime library, potentially slowing it down, and needing developers to take special care on Java issues.

There was some discussion about that, but since the java port only supports a very small of the RTL atm, and isn't developed terribly fast, the status quo persists.

There is no long term decision where this port is going. Of course the Android people are enthusiastic, but as you know, people wanting things and doing things

Currently, discussions are heated about what to do with unicode string types, and how to implement the newer Delphi system for that in a multiplatform way.

[Sannaj]

I don't belive "-gen gcc", will be the future. I would suppose something like "-gen llvm" witch makes fbc behaving like a frontend, of the llvm Framework. This supports all important platforms as well and has some additional advantages, e.g.:

- More optimisation possibilities, because no abstraction to C schematics.
- Idiologic Meaning: FBC won't be only a GCC precompiler.
- Possibility to use llvm-Bytcode + jit-Compiler/Interpreter to write platform independent binaries. (If this is configured)
- Possibility to use llvm tools (debugger, libraries etc.)

Unfortunately, also magnitudes more work, and, since LLVM is C++ needs C++ connectivity. So unless you have a can of developers somewhere willing to work on it, extremely unlikely.

Well, I think this says, you only need a C-Interface.
http://llvm.org/docs/FAQ.html#langirgen

But unfortunately I have no experience with the hole llvm system.

[parkovski]

Yeah, LLVM has a C interface, and I ported the headers to FreeBASIC a while ago. It's a bit tricky to get working though, at least on 64 bit linux (though they say Ubuntu 11.10 has improved 32 bit compatibility). I didn't submit the headers to the fb-headers project just because I never finished fitting everything to 80 columns, but they work, and you can get them here: http://sites.google.com/site/parkersnell/freebasic

I also ported the fibonacci example, which I believe originally used the C++ API. It's on that site also.

And lastly, I actually wrote a small BASIC compiler with LLVM several months ago. It was a really awesome framework and I'd be very interested in getting FB to work with it, but I don't have the time to do it all myself. I'd be glad to offer pointers about LLVM though or work with someone, as it'd be great to have a 64 bit FB running on my Mac. Send me an email parkersnell [at] gmail [dot] com if you have some serious interest in getting FB working with LLVM.

[dkl]

I'm still holding on to your llvm headers, wanting to do some experimenting with them someday. The 80-column limit is not a hard requirement by the way, rather a nice-to-have thing, for many headers it's just too much work.

[dkl]

Hello again,

I started a LLVM backend for fbc now, in a new branch. It's a copy of -gen gcc adjusted to emit LLVM IR .ll text files and compile them into .asm using LLVM's llc program. That route doesn't require fbc to use LLVM headers or be linked with LLVM libraries, and as I understood it is equally well supported, so it should work out fine. It still emits much C code, but some parts are changed over to write out LLVM IR already. I added some comments to the todo.txt in that branch, feel free to "git checkout llvm" and take a look.

I wanted to gave LLVM a try for a while now, and figuring out the LLVM IR language will be very interesting... maybe even easier than figuring out the LLVM library API. I'll keep working on the C backend too of course. Maybe -gen llvm can appear in FB 0.25.

I feel like -gen gcc is shaping up quite nicely actually, I'm hoping to have it close to stable for FB 0.24. It is now able to compile fbc itself, and there are few remaining issues that prevent the test suite from working. Also, now it laid a nice foundation for -gen llvm.

[Coolman]

Hello again,

I started a LLVM backend for fbc now, in a new branch. It's a copy of -gen gcc adjusted to emit LLVM IR .ll text files and compile them into .asm using LLVM's llc program. That route doesn't require fbc to use LLVM headers or be linked with LLVM libraries, and as I understood it is equally well supported, so it should work out fine. It still emits much C code, but some parts are changed over to write out LLVM IR already. I added some comments to the todo.txt in that branch, feel free to "git checkout llvm" and take a look.

I wanted to gave LLVM a try for a while now, and figuring out the LLVM IR language will be very interesting... maybe even easier than figuring out the LLVM library API. I'll keep working on the C backend too of course. Maybe -gen llvm can appear in FB 0.25.

I feel like -gen gcc is shaping up quite nicely actually, I'm hoping to have it close to stable for FB 0.24. It is now able to compile fbc itself, and there are few remaining issues that prevent the test suite from working. Also, now it laid a nice foundation for -gen llvm.

This is a very good news, thank you ...
 

[akumadantai]

currently the freebasic compiler, uses gas.
and the compile speeds and execution speed of the finished machine code is verry fast considering that this is a high level programing language.

but woudnt it all slow freebasics programs and compiling speeds to a near halt, if you would generate c code, instead of assembler for further compiling.
and in its own terms, that c code will eventualy have to become a form of assembler itself to compile the finished product.

this frightens me a bit, as i would not want to expierence a freebasic with slower machine code results than the current freebasic.

[codeFoil]

currently the freebasic compiler, uses gas.
and the compile speeds and execution speed of the finished machine code is verry fast considering that this is a high level programing language.

but woudnt it all slow freebasics programs and compiling speeds to a near halt, if you would generate c code, instead of assembler for further compiling.
and in its own terms, that c code will eventualy have to become a form of assembler itself to compile the finished product.

this frightens me a bit, as i would not want to expierence a freebasic with slower machine code results than the current freebasic.

I do not believe that there is any intention of removing the gas back end, but it seems that the work on the gcc back end is intended to piggy back its optimization and portability. I personally have no interest in this feature, as I am happy with the assembly output and am content to be boxed into an x86 world, but I believe the active developers have the right to pursue whatever challenges they find interesting. I would have liked to have seen the compiler targeted to a less byzantine tool chain than the ubiquitous GNU, but that decision was made long ago and for good reasons.

[Richard]

... but woudnt it all slow freebasics programs and compiling speeds to a near halt, if you would generate c code, ...

It takes as much time to generate C as it does to generate assembler. It could only double the compile time.

Both C and FB are of similar speed when compiled normally. But C has optimisers that enable it to outrun FB. If FB emits C then the emitted C can be optimised (using the C optimising compiler) to get the same speed as C. It is easier to use the well developed C optimiser than to write a new optimiser for FB.

Besides the PC, many other platforms have C compilers. If FB emits C it can be used for those platforms also.