ziutek
commented
6 years ago This project evolved from proof of concept Go to C translator.
The "compiler" related code is in the following directories
gotoc
Contains Go to C translator. It's one of the most horrible and convoluted code I've written in my life. Much worse than the code of my first big Go project from 2010: mymysql.
I was started without any solid knowledge of Go type system and AST. At this time there was no go/type package yet. It evolved rapidly to handle more and more corner cases and still don't handle all well. This is a transitional solution and I prepare to write a real front-end to GCC or LLVM.
egc
The egc (Emgo compiler) uses gotoc to ranslate Go sources to C and uses gcc, ar, ld to compile, archive, link them into packages or executables.
egroot/egc
Contains definitions of basic Go types.
That's all of the strict compiler related code.
There is egroot/src/internal package that is in the middle between compiler and the standard library. It implements basic and architecture dependent things that compiler wants like memcpy, memset, typeinfo, ...
All of the above things are subject to change when real compiler will be created because they are specific to Go to C translation.
There is egroot/runtime that contains things that are architecture and OS dependent. Currently it supports only noos OS. There is also not finished but partially working support for linux.
The code base contains also:
The standard library located in egroot and other packages, examples, etc. located in egpath.
About porting to other targets. I have surprisingly a lot of such proposals from people interested in Emgo and almost any question of using of the current code on supported architectures. It looks a bit like everyone who want to learn and use the real Go will start from porting it to new architecture/OS...
If you are interested in Emgo start to use it, ask concrete question about using it, write something about it and after that you will be more familiar with this project, you will know more its good and weak points and you can start to consider to port it to other targets.
You are absolutely right about the needs of the community. I started to collect things to publish as a wiki page.
I'm waiting for any experience from use of Emgo (these bad and good ones). The link to the article / blog post will be published on Emgo blog. I'm open to articles for the wiki page.
Please analyze the code and ask more questions about Emgo internals. This issue can be used to create the first article about Emgo internals.
First of all, kudos for creating this great project. In the long term, this can be the beginning of something very big for the Go community, allowing the programming of limited resources microcontrollers.
In that sense, do you have any technical, rationale or "how does it work" (internals) documentation. I want to study the system and maybe start a port to another target MCU.
As I see it, you have here a mix of Go compiler and embedded framework. To allow the project to grow coherently, I mean with new targets/ports, without making the codebase too complicated, it'll be interesting to decouple as much as possible the "compiler" from the "embedded framework" part.
Also, if you are interested in creating a small community, I humbly suggest you start creating some wiki pages with basic information and, most important, a TODO list of easy things for others to contribute.
Again, thanks for your work! Jose