LLVM

[DoubleDutch]

Lots of compilers seem to be targeting LLVM. It makes it easier to produce optimised code for a number of real targets (not virtual).

See: http://llvm.org/

Fred: Have you considered using LLVM as the target instead of FASM - then letting it do the optimise and compile to the destination processor?

[Rook Zimbabwe]

This looks fantastically interesting DD!!!
I may have to play with KLEE

[DoubleDutch]

The main benefit (I think) is that the system will allow cross compilation (with optimisation) to various targets - x86, x64, PPC, Arm, JVM, 68k, MIPS, etc without any extra work (other than generating the output in LLVM, then letting it do its thing).

Eg: to generate an OSX program you could let it generate the x86/x64 then the PPC and do the merge the files to make a combined executable - on a Windows version of PB!

Apple are apparently moving to it for x-code, so is 'real studio' to allow iPhone apps to be written.

[Seymour Clufley]

It seems very interesting, for PureBasic's long-term future.

[eesau]

LLVM seems nice but the IR it uses is absolutely horrible. It's simple though, but ugly as hell!

Lots of new projects seem to target LLVM as apparently it produces code that is extremely optimized. What I'd like to see is some comparisons.

[DoubleDutch]

IR?

[eesau]

IR?

Intermediate representation, the assembly-like language LLVM uses. All frontends for LLVM compile first to the LLVM IR. Here's the language reference for the IR: http://llvm.org/docs/LangRef.html

And here's a sample of the ugliness:

Code: Select all

entry:
  %trap = sub nuw i32 0, 1           ; Results in a trap value.
  %still_trap = and i32 %trap, 0     ; Whereas (and i32 undef, 0) would return 0.
  %trap_yet_again = getelementptr i32* @h, i32 %still_trap
  store i32 0, i32* %trap_yet_again  ; undefined behavior

  store i32 %trap, i32* @g           ; Trap value conceptually stored to memory.
  %trap2 = load i32* @g              ; Returns a trap value, not just undef.

  volatile store i32 %trap, i32* @g  ; External observation; undefined behavior.

  %narrowaddr = bitcast i32* @g to i16*
  %wideaddr = bitcast i32* @g to i64*
  %trap3 = load 16* %narrowaddr      ; Returns a trap value.
  %trap4 = load i64* %widaddr        ; Returns a trap value.

  %cmp = icmp i32 slt %trap, 0       ; Returns a trap value.
  %br i1 %cmp, %true, %end           ; Branch to either destination.

true:
  volatile store i32 0, i32* @g      ; This is control-dependent on %cmp, so
                                     ; it has undefined behavior.
  br label %end

end:
  %p = phi i32 [ 0, %entry ], [ 1, %true ]
                                     ; Both edges into this PHI are
                                     ; control-dependent on %cmp, so this
                                     ; always results in a trap value.

  volatile store i32 0, i32* @g      ; %end is control-equivalent to %entry
                                     ; so this is defined (ignoring earlier
                                     ; undefined behavior in this example).

[Fred]

LLVM is an interesting technology and we could use it in the future if we need to support other processor types. That said, it would probably means a slower compilation, due to the extra layer (PB output one very big assembly file, so the assembler has to process it very fast to have decent compile time).

[DoubleDutch]

I think that there is a JIT LLVM 'Player' for debugging that can be used to speed up debug compilations.

With the popularity of Android and iOS, being able to compile to different processor types would give PureBasic a very good advantage over others.

What you need is some kind of speed comparison, it will be slower than FASM - but by how much? Don't forget that with the 'better' optimisation the exe will run faster - it may be worth adding a couple of seconds onto the compile time.

Maybe this is useful:
http://clang.llvm.org/performance.html

codegen: Add generation of assembler files. (converts the llvm to assembler) adds 3% to 30 % the overall compile time in this example

[Thorium]

It's very interessting.
But i dont think the resulting compiled code can be more optimized than a direct compiler can do.
You just can't use CPU specific stuff very smart.

On the website they write it's 3 times faster than GCC but only if compiled in debug mode. I guess it's a lot slower if compiled with optimizations switched on in GCC.

[freak]

I have some experience with LLVM, and while it provides many advantages, i don't think it is for PB (at least not at this time).

- It is a very big package that the user would need to compile and install separately. It not just a single executable like fasm where we have permission to ship it directly with PureBasic. Expecting users to cope with the build system of such a large project and its required dependencies is a problem for a language that tries to aim at beginners as well. People already have trouble getting the Linux version of PB to work.

- Windows support is in its beginnings at best. If we would use LLVM, we would need it to work on all platforms. LLVM is not just another assembler. It is a complete compiler backend. To make full use of it, we would need to make many changes, and keeping the old PB backends around for some platforms would be a headache to maintain.

- The "new platforms are easy" argument sounds nice, but it is only half of the story. PB is more than just a bare compiler. The libraries and debugger have a lot of platform dependent code as well, so a port is still more work than most people think, even if you get the compiler code generation for "free".

- Inline Assembly like it works in PB now would not be possible with LLVM. The LLVM IR is not an assembler language. It is much more strict, and things like types and control flow are represented directly in the code. Sticking a few lines of user written LLVM code in the middle of what the compiler generates would almost certainly fail.

> LLVM seems nice but the IR it uses is absolutely horrible. It's simple though, but ugly as hell!

Once you understand how it works, it is actually a lot more readable and understandable than the assembler output you get for a large program by a C compiler. You can much better relate the generated code to the concepts of the original language, even though it is quite low level. This is a very important factor when trying to debug a compiler.

> But i dont think the resulting compiled code can be more optimized than a direct compiler can do.
> You just can't use CPU specific stuff very smart.

Why not? The CPU specific optimizations are done by the code-generator for the target platform. This comes after the general optimizations are applied to code in IR. Also, LLVM can do a lot of things that ordinary compilers can't do. It can run all its optimizers even after link-time, so things like inter-procedural optimizations become much more effective than applying them to each compiled module separately. Link-time optimization is something that only few compilers/linkers do well and even then they do it only for a few kinds of optimizations. In LLVM, this is part of the basic design from the beginning.

[DoubleDutch]

Thorium: See this for an example of llvm vs gcc
http://donsbot.wordpress.com/2010/02/21 ... m-codegen/

Freak: I understand where you are coming from. It just would be great to use PB for also compiling for iOS and Android.

Edit: I think that over the next year or so LLVM's total package size will come down because you shouldn't need gcc - it will have a built in 'integrated' assember rather than using something like gcc gas:
http://www.mail-archive.com/svn-src-hea ... 06802.html

[Coolman]

Je viens de voir le site de LLVM, le projet a l'air exceptionnel , mieux que gcc, multiplateforme, generation de code optimisé, pour le reste voir ici :

http://fr.wikipedia.org/wiki/Low_Level_Virtual_Machine
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine

Si purebasic evolue et permet de generer directement un code C++ directement compilable par LLVM, ce serait exceptionnel car il serait alors possible de generer des executables pour differents architectures (x86, x64, arm...)

Maintenant, il faut voir ce que veulent les utilisateurs de purebasic :

1/ plus question d'avoir un executable de quelques ko, mais ce n'est plus essentiel de nos jours, la plupart des ordinateurs sont aujourd'hui equipe d'enorme quantite de memoire vive et physique...

2/ alors que purebasic est tres peu connu comparé aux autres basic (visual basic), cette evolution pourrait agrandir enormement la communauté et l'interet de nombreux developpeurs...

3/ le marché d'un tel language est enorme et internationnal, l'auteur pourra surement en faire son activite principal...

4/ si en plus purebasic permettait d'inserer directement du code c c++ comme le fait bcx par exemple, ce serait un plus :

$CCODE
/** insertion du code c c++ ici */
$CCODE

5/ si en plus il devenait possible d'utiliser directement l'impressionant quantite de librairie c c++...

6/ l'auteur devrait regarder du cote de Ultimate++ (http://www.ultimatepp.org/index.html), la licence bsd est tres permissive, generer du code multiplateforme pour cette environnement en utilisant LLVM me semble une bonne approche...

7/ un tel projet attirera surement des gens tres competents en c c++ pour pallier aux insuffisances de purebasic (3d, base de donnee...)

8/ les utilisateurs de purebasic actuel doivent accepter de renouveler l'achat de la licence de purebasic a un prix plus eleve qu'actuellement et a faire des dons plus souvent a l'auteur pour l'encourager dans cette voie...

Personnellement, pour un language base sur la syntaxe du basic et multiplateforme, je serais preneur tout de suite...

La balle est dans votre camp...

----------------------------------------------------------------

I just saw the site of LLVM, the project looks fantastic , better than gcc, multiplatform generation of optimized code for the rest see here:

http://fr.wikipedia.org/wiki/Low_Level_Virtual_Machine
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine

If purebasic evolved and can directly generate C code directly compilable by LLVM, it would be exceptional because it would be possible to generate executables for different architectures (x86, x64, arm ...)

Now we have to see what users want purebasic:

1 / no question of having an executable from a few kb, but it is more essential today, most computers today are equipped with huge amount of RAM and physical ...

2 / while purebasic is very little known compared to other basic (visual basic), this evolution could enormously expand the community and the interest of many developers ...

3 / the market of such language is huge and internationnal, the author will surely make it his principal activity ...

4 / purebasic if in addition to insert code directly as does DC BCX example, it would be a plus:

$ CCODE
/ ** Insert code here * c c /
$ CCODE

5 / if in addition it became possible to directly use the impressive amount of library DC ...

6 / author should check out Ultimate (http://www.ultimatepp.org/index.html), the BSD license is very permissive, generate code for this multiplatform environment using LLVM seems a good approach. ..

7 / such a project surely will attract very good people in DC to address the shortcomings of purebasic (3d, database ...)

8 / purebasic current users must agree to renew the license purchase of purebasic a higher price than at present and has to donate more often to the author to encourage him in this way ...

Personally, for a language based on syntax and basic platform, I'd taker right away ...

The ball is in your court ...

[DoubleDutch]

If purebasic evolved and can directly generate C code directly compilable by LLVM, it would be exceptional because it would be possible to generate executables for different architectures (x86, x64, arm ...)

Shouldn't that read:

If purebasic evolved and can directly generate 'll' code directly compilable by LLVM, it would be exceptional because it would be possible to generate executables for different architectures (x86, x64, arm ...)

?

[Trond]

As has been explained many times, having code generation for arm wouldn't mean much as all pb libraries (which provide most of PB's functionality) would have to be ported as well.