I'm using Antlr4 to create a language which I then want to generate LLVM IR with. Do I need to hand-write LLVM IR in response to my visitor events? - go

While learning Antlr4, I used Golang as a target language, so a statement in my toy language like:
$myVar = 10
$myVar + 5
Would translate to some Golang code that generates "15" for the result
However, as far as I can see, there isn't an LLVM IR target for ANTLR, so the question is: what are my options?
1) Generate C/C++ and then use it to emit LLVM IR?
2) Try to find a Golang LLVM IR emitter?
3) Keep using the generated Go lexer/parser but hand-write LLVM IR?
I tried to go through the LLVM documentation and watched a few videos on LLVM< but they all seem to generate C/C++ and then communicate with the API that way. Not sure if they do that because that's what they know or if it's because that's the only way.
Thanks in advance for any insights!

While learning Antlr4, I used Golang as a target language, so a statement in my toy language like:
$myVar = 10
$myVar + 5
Would translate to some Golang code that generates "15" for the result
That's not accurate. Your grammar is translated into Go code that parses your language. Your own code can then use that generated parser to translate the above into whatever you want.
there isn't an LLVM IR target for ANTLR
Nor would it help you if there were one. All that would do would be to create a parser written in LLVM instead of Go. You'd still have to write the code to translate your language into LLVM yourself (just like you'd have to write your own code into translate your language to Go).
As to whether to use the LLVM-API to generate LLVM or to generate it as strings, either option would work. There are Go bindings for LLVM, but it's also perfectly possible to just write LLVM assembly into an .ll file and then run that through llc.

Related

Are there any good extensible language cross compilers?

I am working on a project right now, and I would greatly enjoy being able to extend a cross compiler to convert some code into other languages. For example, I might have an AST of some code, and I would like to pass that off to a cross compiler with the intended language and receive some code in the language specified in return.
So to sum it up: is there any extensible cross compiler that I can just give an AST or equivalent and receive code in return?
(I know about Haxe, but the compiler is not very extensible and I would prefer to not transpile)
I have made the decision to use LLVM as the native compiler, and will write my own custom transpilers to other languages, as I could find no other decent option. If you would like to follow my project, head over to Provalang.

LLVM Interoperability (Like JVM or .Net) - Is it possible to do?

I recently played around a bit with different LLVM Frontends like Clang (C Familiy ), LDC2 (D), Terra, ...
All these languages can be compiled into the LLVM IR (somewhat readable) and LLVM IR Bitcode . So at this stage they are all on the same "level" right?
My Question is : Is there some way of language interoperability like the .NET Languages or JVM Languages on "language level" or is it only possible to do it by editing in the IR?
I already looked this question up in Google but didn't find what is was looking for.
If yes how can I do it and can I do it with all frontends or only some specific?
For language X be able to call language Y, it must possess an ability to
Call Y functions (know Y's calling convetions)
Convert data passed to Y into form it expects (called marshalling)
This mostly should be done on front-end level (not middle-end, which LLVM is). C language can be used as common ground for interop, so if two languages can call C and export their own functions to C, they can talk to each other.
Haskell and C++ can serve as example. C++ can export code as C using
extern "C" {
}
block, and Haskell can also export its functions with foreign export ccall keywords. It also features marshalling functions to convert Haskell strings to C string and back.
As you can see, LLVM plays minor role here, but you were right mentioning that with LLVM you can, theoretically, interop any language that compiles to LLVM by manually editing resulting IR.

How to bolt on ANTLR 4 front to GCC Generic/GIMBLE?

I'm writing a DSL front end using ANTLR v4 that I'd like to bolt on to GCC framework. The goal is to have a C language AST to leverage the rest of the GCC framework.
I haven't found any info or preexisting work to use an example of how to proceed. What I'm looking for is how to move the ANTLR 4 AST to GCC Generic/GIMBLE.
ANTLR 4 does not support a C language target, so I'll have to cludge up the C++ target to the GCC C language framework.
Help is appreciated
Gluing a C++ implementation of ANTLR into GCC so that GCC will call it is likely to be the easy step.
[Don't expect to be easy; GCC wants to be GCC, not your pet. You might get some help from GCC Melt, a package for interfacing to GCC machinery.]
The AST produced for an arbitrary (e.g., your custom DSL) language doesn't "just move (easily)" to a C AST or to the GCC Gimple (not GIMBLE) framework.
You will have to build, in essence, your DSL-AST to C-AST translator, or your DSL-AST to Gimple translator. There is no a priori reason to believe that building such a translator is easy; for example, you didn't tell us your DSL was "just like C except ...". So, you're going to have to build a translator. In the absence of evidence this is easy, you'll have to translate your DSL concepts to C concepts. The better ("non C-like") your DSL is, the harder this is going to be.
This SO link discusses the issues behind translation in more detail: What kinds of patterns could I enforce on the code to make it easier to translate to another programming language?

Compiling Pharo to C?

It is said that Pharo's VM (CogVM) is developed, tested, profiled and etc in Smalltalk, but then the Smalltalk code is transcompiled to C, which is then compiled along side with some OS abstraction C code using the default system C compiler.
Well, I'd like to do a similar thing, I wan't to develop, test and profile code using Pharo, but then compile it to C. How can I do it? How the compilation to C works? Does Pharo comes with a Smalltalk to C transcompiler? How can I invoke it? Does it compile the full Smalltalk, or I have to use some kind of a Smalltalk subset? Is there any good documentation about it?
The Pharo VM is hosted on github.
Follow the steps to build it and you'll get a Smalltalk image called "generator.image" which you can run (it's a regular image). Inside of that image you'll find the VMMaker package which is responsible for generating the C code from the special Smalltalk dialect used for this (which is called Slang; it's a subset of Smalltalk). Look at the code in the generator image to get a feel for what it does. There's also some information contained in the workspaces that are open when you first open the image.
As soon as you have the C sources it's basically straight forward C compilation (which we do with Cmake + gcc / clang).
As for documentation: you should probably read the Blue Book.
clarifiation
As #Leandro Caniglia points out in the comment, the purpose of Slang is to generate C source code for the VM. It has been designed to ease translation to C. That does not mean that:
arbitrary Smalltalk code can be translated to C using the generating mechanism
arbitrary Smalltalk code can be rewritten in Slang (at least not "easily")

Extracting the Control Flow Graph from the gcc output

I am trying to extract the Control Flow Graph from the assembly code that gcc produces. I have manage to dump the CFG of several IRs (rtl phases) into .vcg files using the arguments -fdump-rtl-* and -dv. Is there any way to do the same thing but for the final assembly code? I would like a generic, target-independent and easy to be parsed representation (like vcg representation). My source code is in C language (in case that it plays any important role).
Best regards,
Michalis.
Intel PTU and VTune will do it if you can run the app for profiling... not sure if it can generate the graph without having run the code though. Otherwise you might be looking at something like this: http://compilers.cs.ucla.edu/avrora/cfg.html.

Resources