Author Topic: FBC -GEN GCC Experience  (Read 4169 times)

0 Members and 1 Guest are viewing this topic.

Mike Lobanovsky

  • Hero Member
  • *****
  • Posts: 1993
FBC -GEN GCC Experience
« on: July 26, 2014, 10:28:11 PM »
Morning Charles,

You will be laughing but FB's gcc emitter does compile the FB version of Toy interpreter cleanly to an executable. The generated C code looks weird and funny enough and there are a lot of rudiments of attempted optimizations (or just translation rubbish) and unnecessary casts but IMO it can be used as a first step towards the main goal, even if it needs heavy manual editing.

The attached binary was compiled without any GCC optimizations but it did work for me OOTB.

My first (rather perfunctory) observations follow:

1. All numeric functions are converted to return floats probably because their return data type isn't specified in the BASIC source code explicitly.

2. All ints are reduced to short ints whenever possible.

3. All block code and loops are built around ifs + gotos.

4. All var names are lost though function names are preserved.

FB v0.90.1 uses gcc v4.7.1 and an associated cc1 dounloadable as an add-on from the FB repository. The forum claims that FB's gcc options support gcc optimizations -O1/2/3. On default, FB's gcc accepts AT&T asm syntax though -asm intel option is also possible to allow for Intel-style inlines.

My command line options to obtain both a C listing and a compiled executable were fbc -lang qb -gen gcc -R -s console.



P.S. Please use a regular primes.toy to test the executable.

.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Aurel

  • Guest
Re: FBC -GEN GCC Experience
« Reply #1 on: July 27, 2014, 12:19:50 AM »
Well interesting...
o2 version take 4 sec for lim=50000
fb_2_c need 6 seconds   

John

  • Hero Member
  • *****
  • Posts: 3646
Re: FBC -GEN GCC Experience
« Reply #2 on: July 27, 2014, 01:08:12 AM »
What does your gcc command line look like for the FB generated C code?


Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4315
    • Oxygen Basic
Re: FBC -GEN GCC Experience
« Reply #3 on: July 27, 2014, 01:59:24 AM »
Thanks Mike,

I see the names are thoroughly decorated. In a high-level emitter, one would try to keep the names close to the original source, and most of the code, except for string stuff, could be translated like a C-BASIC macro.

The run-time in Oxygen, which contains all the core functions, is about 12k of tightly coded binary, mostly from assembly code. This would have to be translated into C, without using Assembler, to include  with every program. Inevitably, the end result will not be as efficient or compact.

Mike Lobanovsky

  • Hero Member
  • *****
  • Posts: 1993
Re: FBC -GEN GCC Experience
« Reply #4 on: July 27, 2014, 08:18:54 AM »
I see the names are thoroughly decorated.

The main tendency seems to be to auto-capitalize BASIC names so that they don't shadow or overload the associated C functions and macros inadvertently.

Quote
In a high-level emitter, one would try to keep the names close to the original source, and most of the code, except for string stuff, could be translated like a C-BASIC macro.

I don't care very much for the quality of their C emission. And clearly enough, their set of string stuff embedded in their custom gcc 4.7.1 and/or cc1 will have to be substituted for a set of equivalent O2 helpers in a separate module/library included in the O2's Code::Blocks project. But the main part of O2 can be converted at once, hehe, and only once if you pardon me this pun, and used henceforth for manual optimization/improvement/development without resorting to FB and/or its gcc emitter ever after.

Of course, BCX translations look much more elegant than this one but BCX would also require that O2 sources be translated to, or rewritten in, BCX first which would add some extra headache to the whole task.

OTOH the Toy interpreter experiment shows that the gcc emitter works in principle and it can generate (some) usable code directly from FB sources, and O2 is currently written in FB.

Quote
The run-time in Oxygen, which contains all the core functions, is about 12k of tightly coded binary, mostly from assembly code. This would have to be translated into C, without using Assembler, to include with every program.

That's correct. But that's an inevitable price of extending O2 to non-Intel platforms (see also below) and relying on the quality of corresponding gcc machine code emitters and optimizers for the other CPU architectures supported by gcc.

Quote
Inevitably, the end result will not be as efficient or compact.

That's correct too. But very low-level and carefully handcoded integer and pointer based C source is usually compiled by gcc to very clean and predictable assembly on at least i386. I understand that your existing i386 assembler is also very valuable, probably as much as Oxygen as a whole. But it will stay valid not only for Windows but also for desktop Linux and Mac OS X that are all currently running on Intel CPU's. The asm sources for these platforms may stay as they are, featuring C wrappers for decoration purposes only.

Again, there are a lot of optimizations that gcc can offer out of the box. Each module of the project can have its own optimization level and some modules less sensitive to speed can also be optimized for smaller size. Believe me, this sort of optimization is also very efficient.

Furthermore, I think the current (quite unreasonable) size of toy2.exe is due to its int functions not having been explicitly declared as integers, which enforced gcc to compile unnecessarily its floating-point paraphernalia into the executable.

And finally, I think such a strategy could compensate at least partially for my miserable failure to fulfill my obligations earlier this year when I let you down due to my illness and subsequent political developments in the neighboring country that happens to be my motherland. :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4315
    • Oxygen Basic
Re: FBC -GEN GCC Experience
« Reply #5 on: July 27, 2014, 07:36:18 PM »

Mike,

I am grateful for the time and effort you were able to put into the early stages of this project. Nothing is wasted and I hope that you are not burdened by any sense of obligation.

I feel that the most productive way lies somewhere between emitted code and manual recoding. It is a good opportunity to develop some simple translation/refactoring tools in the process. Working directly with FB's C output, one runs the risk of brain-damage. Subtle bugs would be hard to trace in such code, and very tedious.

I think the task needs to be broken down into small testable units of code, which could also be available for redeployment in other projects.

Playing open-source economics here :)

Mike Lobanovsky

  • Hero Member
  • *****
  • Posts: 1993
Re: FBC -GEN GCC Experience
« Reply #6 on: July 27, 2014, 09:23:01 PM »
Morning Charles,

... I hope that you are not burdened by any sense of obligation.

Actually I am and have been all that time. Just couldn't find a suitable occasion to confess... :-[

Quote
I think the task needs to be broken down into small testable units of code, which could also be available for redeployment in other projects.

Do you know if fbc is capable of linking precompiled object files with its own code?
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4315
    • Oxygen Basic
Re: FBC -GEN GCC Experience
« Reply #7 on: July 28, 2014, 05:43:33 AM »
I think you can produce object code with FBC, and take charge of the linking process. (all those .A files). It's all Gnu at the back end.

Just found something here:

http://lampiweb.com/help/freebasic/TutUsingLibrariesWithGCC.html

Mike Lobanovsky

  • Hero Member
  • *****
  • Posts: 1993
Re: FBC -GEN GCC Experience
« Reply #8 on: July 28, 2014, 08:50:41 AM »
Thanks a lot Charles,

The trailing paragraphs are exactly what I've been looking for.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)