Alternative compilers for golang

[Scott Wilson]

Hey all. What is the state of alternative go compilers? There is go and gccgo. Also found https://code.google.com/p/llgo/. How do they compare? What is the maturity of each? Thanks.

Scott

[Sam Fourman Jr.]

> Hey all. What is the state of alternative go compilers? There is go and gccgo. Also found https://code.google.com/p/llgo/. How do they compare? What is the maturity of each? Thanks.
>
> Scott

Great question, I am also interested to hear if anyone has experience using llgo with golang.

I hope this thread gets some interesting feedback :)

Sam Fourman Jr.

[Ian Lance Taylor]

The gccgo and gc compilers are nearly equivalent. They have different
optimizations, so which one is more efficient depends on your code.
The gc garbage collector is more precise.

A difference that arises in practice is that the gccgo compiler does
not yet build the go tool, so it's much more convenient to use gccgo
if you can build both and use the go tool from gc.

I haven't used llgo but I think it also works well.

Ian

[Andrew Wilkins]

On Friday, 29 August 2014 01:41:28 UTC+8, Scott Wilson wrote:

Hey all. What is the state of alternative go compilers? There is go and gccgo. Also found https://code.google.com/p/llgo/. How do they compare? What is the maturity of each? Thanks.

Original author of llgo here. Sorry, that is not the main repository. See https://github.com/go-llvm/llgo

I've had basically no time to work on llgo for a few months now, but there has been good progress by another contributor. llgo is able to build itself and libgo (the Go standard library used by gccgo). It is currently only known to work on linux/amd64 as far as I'm aware.

There's also:

 - https://github.com/gopherjs/gopherjs (Go -> JS transpiler)

 - https://github.com/tardisgo/tardisgo (Go -> Haxe transpiler)

[⚛]

On Thursday, August 28, 2014 7:41:28 PM UTC+2, Scott Wilson wrote:

Hey all. What is the state of alternative go compilers? There is go and gccgo. Also found https://code.google.com/p/llgo/. How do they compare? What is the maturity of each? Thanks.

An alternative Go compiler under development is Tulgo: https://atom-symbol.rhcloud.com/a/

The state of Tulgo:

• Tulgo is currently under heavy reconstruction
• In short, it is somewhat different compared to gc/gcc/llgo
• The compiler previously used Java as the implementation language, which seems to have been a mediocre choice of an impl. language. The new compiler version under development is going to use an "in-house" concurrent programming language.
  
• The new compiler version under development is open source (previously it was closed source). https://github.com/tul-project/tul-fx contains the source code. I started to seriously work on Tul-FX just moments ago so there is not much to see on GitHub yet. Please checkout past articles (https://atom-symbol.rhcloud.com/a/) about Tulgo to get some idea where it may lead to.
• Working on a project like this all by myself has proved impossible, so Tul-FX (and subsequently Tulgo) are currently in the need of volunteers willing to contribute code (and time) to the project.

I have a hard time to think of what to write about Tul-FX, so if you have questions, please ask them. It may help me to think.

[andrewc...@gmail.com]

How can you get volunteers using an in-house programming language?
Go has an open parser in the ast package which would save you a ton of work.

[Sokolov Yura]

https://github.com/tul-project/tul-fx/blob/master/img/projects/Tulgo/list

Looks like you have Go with generic types :-) interesting!

[⚛]

On Wednesday, September 3, 2014 4:27:18 AM UTC+2, andrewc...@gmail.com wrote:

How can you get volunteers using an in-house programming language?
Go has an open parser in the ast package which would save you a ton of work.

I believe that having a clean slate, and owning the instruction/bytecode design and the VM, makes a difference. You do not need to share my viewpoint of course.

[⚛]

On Wednesday, September 3, 2014 6:11:05 AM UTC+2, Sokolov Yura wrote:

https://github.com/tul-project/tul-fx/blob/master/img/projects/Tulgo/list

Looks like you have Go with generic types :-)  interesting!

Yes, the Tul-FX syntax is inspired by Go syntax in some places. But the language isn't a superset of Go.

Unlike Go, I plan to add a form of subclassing at some point (when the time comes), but I haven't decided how to perform it yet. I only have a foggy feeling that the syntax may have something to do with method dispatching and runtime type resolution.

The immediate plan for Tul-FX is to parse a version of mandelbrot.go that does not import any packages. This is a classic step for me.

[andrewc...@gmail.com]

Sorry for being offtopic to the thread, but I have to question you on one thing

If you failed using java to implement a go compiler, what makes you think you can use C++ to implement a new language just so you can implement a second go compiler? it doesn't make sense at all to me. Hopefully you can prove me wrong though. I'm just advising you that I doubt java is the cause of any real technical problems, plenty of compilers for languages more complicated than Go have been written in java.

[mortdeus]

Are you familiar with the inferno distributed operating system?

[mortdeus]

That's comment is directed at the guy writing tulgo.

If not, I really think you should take some time and study it before you continue down the path you laid out for tulgo.

Glancing over you blog posts that describe your project, I notice you are re-reinventing many solutions for your new Go compiler when the guys who wrote the old go compiler already reinvented the same solutions to the problems you are trying to solve years ago.

And honestly, bell labs didn't just reinvent the wheel when they defected away from Unix and wrote plan9 and inferno instead. They made sure this time the wheel came with a chrome 22 inch rim.

[⚛]

On Thursday, September 4, 2014 1:30:02 AM UTC+2, andrewc...@gmail.com wrote:

Sorry for being offtopic to the thread, but I have to question you on one thing

If you failed using java to implement a go compiler, what makes you think you can use C++ to implement a new language just so you can implement a second go compiler?

It isn't the second Go compiler, the number is a bit higher.

 

it doesn't make sense at all to me.

Two days ago I watched a video presentation about two guys writing a translator/emulator for the x86 instruction set (McSema - Static Translation of x86 Instruction Semantics to LLVM). It doesn't make sense to me why would anybody be interested in such a thing since binary translation and emulation are known to be solved problems. Also the translated code was running slower than the original. An unsolved problem from my viewpoint is to attach an optimizer to a running x86 application and make it run noticeably faster - I don't understand why they didn't focus on this problem instead.

 

Hopefully you can prove me wrong though. I'm just advising you that I doubt java is the cause of any real technical problems, plenty of compilers for languages more complicated than Go have been written in java.

Tul-FX is open source, so if the source of failures was the lack of manpower it is possible (at least in theory) to remove this issue now.

[⚛]

On Thursday, September 4, 2014 4:45:04 AM UTC+2, mortdeus wrote:

That's comment is directed at the guy writing tulgo.

If not, I really think you should take some time and study it before you continue down the path you laid out for tulgo.

Glancing over you blog posts that describe your project, I notice you are re-reinventing many solutions for your new Go compiler when the guys who wrote the old go compiler already reinvented the same solutions to the problems you are trying to solve years ago.

I not sure how Inferno OS could be related to Tul-FX or Tulgo:

• It doesn't have persistence.
• It isn't trying to achieve high efficiency in lexical analysis.
• Can Inferno's compiler efficiently use the IDIV instruction?
• Is Inferno eliding reference counting instructions?
• Can Inferno avoid generating instructions that are related to language safety costs in non-trivial cases?

[⚛]

On Thursday, September 4, 2014 1:30:02 AM UTC+2, andrewc...@gmail.com wrote:

Sorry for being offtopic to the thread, but I have to question you on one thing

If you failed using java to implement a go compiler, what makes you think you can use C++ to implement a new language just so you can implement a second go compiler? it doesn't make sense at all to me. Hopefully you can prove me wrong though. I'm just advising you that I doubt java is the cause of any real technical problems, plenty of compilers for languages more complicated than Go have been written in java.

I forgot to mention that the new compiler will primarily target amd64 CPUs. The previous compiler targeted i386 only because I didn't have an amd64 CPU. i386-only CPUs have a very low market share, so it definitely was a problem.

[⚛]

On Thursday, September 4, 2014 1:30:02 AM UTC+2, andrewc...@gmail.com wrote:

Sorry for being offtopic to the thread, but I have to question you on one thing

If you failed using java to implement a go compiler, what makes you think you can use C++ to implement a new language just so you can implement a second go compiler? it doesn't make sense at all to me. Hopefully you can prove me wrong though. I'm just advising you that I doubt java is the cause of any real technical problems, plenty of compilers for languages more complicated than Go have been written in java.

In the days passed I have implemented a lexer for mandelbrot.go, the code largely being copied from the previous version of Tulgo.

I also implemented context-dependent static (compile-time) function resolution. Other languages call it method calls with static binding. Examples:

https://github.com/tul-project/tul-fx/blob/288016c437469858b194e818fe00ce747a3f70b1/img/projects/Tulgo/list

https://github.com/tul-project/tul-fx/blob/288016c437469858b194e818fe00ce747a3f70b1/img/projects/Tulgo/slice

[⚛]

My take on dynamic dispatch:

https://github.com/tul-project/tul-fx/blob/065c68fe08767acf446c6bdde206f7b8f8a45d6e/img/projects/Tests/recognizers

My intention is to use it in Tulgo's parser and later compilation passes.

Wikipedia http://en.wikipedia.org/wiki/Dynamic_dispatch doesn't mention this kind of dynamic dispatch, but I am sure I only reinvented the wheel.

[adon...@google.com]

On Sunday, 14 September 2014 19:59:17 UTC-4, ⚛ wrote:

My take on dynamic dispatch:

https://github.com/tul-project/tul-fx/blob/065c68fe08767acf446c6bdde206f7b8f8a45d6e/img/projects/Tests/recognizers

What's up with the colons (and semicolons) everywhere?  This is not Go as we know it...

[⚛]

I don't see semicolons as an issue when writing code. I am inserting them automatically without thinking about it. It slows down writing by 1% or so, but that is a cost too small to be considered an issue.

The colons are there because they simplify the parser. I forget to write them down sometimes, but let's hope this isn't a permanent issue.

Last, it isn't Go. It is Tul-FX, inspired by Go in some places. The only Go source code is mandelbrot.go (a somewhat crude version), albeit the syntax is extended to allow C-style types in Go's type system. I like type systems that are precise about other type systems, and clearly Go's *C.int isn't the same as C's *int, so I introduced a new pointer type that will match the semantics of C pointers.

[Michael Jones]

Sorry...I was seeing the semicolons.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[⚛]

On Monday, September 15, 2014 8:40:12 PM UTC+2, ⚛ wrote:

... Go's *C.int isn't the same as C's *int ...

Correction: C's int*.

 

[⚛]

On Monday, September 15, 2014 8:43:13 PM UTC+2, Michael Jones wrote:

Sorry...I was seeing the semicolons.

I am afraid I don't understand this. You were seeing the semicolons, then what?

[Michael Jones]

though often omitted, the semicolons are consistent with Go syntax

the colons are not, and make clear the Tul-FX difference.

nothing more.

thank you for your efforts no matter what punctuation you like. ;-)

Michael

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[tomwilde]

Hello atom-symbol. So good to see you again!

I think I understand most of the code. Could you elaborate a little on what the following declaration is/does:

type R recognizer {   

*A;

B;

func describe();

}

- Tom

[⚛]

A recognizer is a data type that recognizes/distinguishes among the types specified in its declaration. In the following case:

type R recognizer {   

*A;

B;

func describe();

}

the recognizer distinguishes among two types and can either hold a value of type *A or a value of type B. The list of types is explicit, unlike Go interfaces where the list of types satisfying an interface is implicit.

The compiler checks that there exists function (*A).describe() and function B.describe(). The function describe() is a property that is common to both types.

If r is of type R, then r.describe() performs a method call in Go sense. In C++ sense, r.describe() performs a virtual method call.

An instance of an interface in Go holds a value and a type information  Likewise, an instance of a recognizer holds a value and a type information.

[⚛]

Tulgo (implemented in Tul-FX) can now parse mandelbrot.go.

The parser isn't going to handle other source codes any time soon, my intention is to focus on the Mandelbrot benchmark for the time being.

The next steps will be type checking and intermediate code generation.

On Monday, September 15, 2014 1:59:17 AM UTC+2, ⚛ wrote:

[⚛]

https://github.com/tul-project/tul-fx can now compile mandelbrot.go into intermediate assembly code.

I am now going to attempt auto-threading and auto-vectorization of the intermediate code. This may take some time.

[⚛]

As a prerequisite step to auto-threading, http://github.com/tul-project/tul-fx can now generate an instruction scheduling graph for mandelbrot.go

PDF containing the graph: http://github.com/tul-project/tul-fx/blob/8a1a8de561a2733f14e3ab66513533623398438d/main-opt-sched.pdf