Restructuring TARDIS Go into a 2-stage process

130 views
Skip to first unread message

Elliott Stoneham

unread,
Sep 5, 2015, 2:55:44 AM9/5/15
to tardisgo
The current Go->Haxe code generation process actually contains two components:
1. Modelling Go-specific language features (go, chan, slice, map etc); and 
2. Generating Haxe code (the big issue being modelling pointers in an OOP environment).

My proposal is to split the compilation process into these two parts, with the first phase common to all target languages and the second phase targeting more languages than just Haxe.

The intermediate format between the two phases will be an executable Go program, which will significantly simplify testing. However that transpiled intermediate Go program will not contain any language constructs that cannot be directly translated into C (as a simplicity benchmark). 

My hope is that this approach will make generating code for new languages much simpler than at present, possibly simply a matter of walking the AST of the generated Go, rather than requiring a full SSA re-compilation.

In terms of optimisations, most effort can concentrate on getting the intermediate Go program as efficient as possible.

I would hope to target C, C#, Java and Haxe (the latter two being more complex because pointers must be simulated). 

The generated intermediate format Go program may also be useful in other contexts, for example where called code should be sandboxed from the rest of the system and not allowed to use goroutines.

There is a great deal of detail to be worked through here, and I'm not yet even at the prototype stage, but at least the objective is clear. 

Elliott Stoneham

unread,
Sep 5, 2015, 4:19:51 AM9/5/15
to tardisgo
The first phase of the process would probably also implement the NaCl OS, as the Haxe target does now.

Andrew Chambers

unread,
Sep 6, 2015, 5:53:15 AM9/6/15
to tardisgo
Cool stuff, My C compiler in Go has been ported into C, but I am still interested in Go to C compilation regardless.

Elliott Stoneham

unread,
Sep 6, 2015, 6:19:25 AM9/6/15
to tardisgo
Many thanks Andrew, it would be great to find a way to collaborate.

goran....@gmail.com

unread,
Sep 7, 2015, 4:06:30 AM9/7/15
to tardisgo
So essentially if I understand correct:

1. model Go specific language constructs
2. generate HAXE code

I didn't understand part of generating executable Go program - you mean .exe file or Go code that runs with "go run"?
Or you mean Go assembler? https://golang.org/doc/asm


Elliott Stoneham

unread,
Sep 7, 2015, 5:50:22 AM9/7/15
to tardisgo
Yes Goran (copy post),

The first phase would generate a new Go program which could be executed with go run. However that new Go program would not contain any go-specific language constructs (like go, chan, slice, map etc.), instead these would be modelled using lower-level go constructs like pointer and array.

The second stage would take this new Go program and generate target-language code from it. This could be Haxe, C, C#, Java...

By moving the modelling of go constructs into the first phase, the second phase becomes simpler - very important if multiple languages are to be targeted.
Reply all
Reply to author
Forward
0 new messages