What is the Go language compiled to? Nobody seems to want to write it anywhere on the net. I am searching for the target language. I am thinking it's probably assembly, C, or relocatable machine code?
The reference implementation compiles Go to native machine code. The code is generated to be not relocateable.
The language has been designed to allow other target platforms as well. For instance, there are implementations that compile Go code into Javascript and PHP.
It is not possible to use Go code in a shared library.
Related
https://webassembly.studio/ allows inspection of WebAssembly (WASM) files and the corresponding SpiderMonkey-generated x86 code. I'd like to similarly inspect instructions generated by V8's WASM compilers (Liftoff and TurboFan).
I'm entirely unfamiliar with V8's codebase/API (I compiled & linked it and followed some tutorials, though). There seems to be a v8::CompiledWasmModule class available, but it does not seem to expose access to generated x86/x64 instructions by either Liftoff or TurboFan.
WebAssembly - adding a new opcode describes the process of adding a WASM opcode to V8. Seemingly appropriate functions for WASM compilation/execution are available in the mentioned classes. Though, these seem rather deeply layered within the V8 codebase and would be difficult to access were I to link V8 as a library. Also, I'm unsure if this corresponds to Liftoff or TurboFan.
Could anybody familiar with the V8 codebase give me some pointers as to how I can access Liftoff and/or TurboFan's WebAssembly compilation module, as to obtain x86/x64 code?
To inspect generated code, you can run the d8 shell with the --print-wasm-code flag. You'll need either a debug build, or a release build with the v8_enable_disassembler = true GN arg.
There's no existing way to retrieve generated code via V8's API; so if that's what you want, then you'd have to add it. Keep in mind that V8 is not designed to be a standalone compiler, which means generated code assumes that it's going to run "inside V8", so if you wanted to use it for anything else, you'd have to make significant modifications.
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
Is there a way of doing this?
Develop a library L1 written in Golang. L1 exports functions for C language.
Build L1 and generate .lib file for Visual C++.
Use L1 from Visual C++ code by calling C functions in L1.
I've never tried, and I'm using linux, but here is what I know:
According to the golang documentation you can compile go code into shared library (see go help buildmode also).
To be able to call go function from c code, go function shall be exported.
In order to compile your go code into a shared library, you need to get the go standard library into a shared one too:
go install -buildmode=shared std
This will compile all the go standard code into libstd.so (on linux, the name might change on windows).
And finally, you can use the following command to get your shared library:
go install -buildmode=shared -linkshared [packages]
The standard shared library can be found in:
GOROOT/pkg/GOOS_GOARCH_dylink/
and your shared library under:
GOPATH/pkg/GOOS_GOARCH_dylink/
That is for the go part.
Now, if you want to call this code from a C++ project, you'll need to create the C library that wraps the go library. You can use some tool for that (I've heard about SWIG, but never tried).
EDIT: You can do something similar with static go library, but since you did not specify the library type and you will use it from C++ code, I suppose you need a shared library.
I've found a ton of information about how to use cgo to call C libraries from Go, but I'm interested in the opposite: writing a library in Go, and linking/using it in various C programs.
Is this possible? Any good resources for this? Thanks.
This can not be done currently. Go has to be the entry point and without the use of gccgo, you can't compile Go into a shared library.
There is a proposal to change this, so it may or may not be an option at some point. Refer to this document for details.
I understand it is somehow making a connection so that a compiler when envokes connects a source code to whatever libraries that it needs to.
But what is going on a more technical level, or better put what do I need to know in order to confidentally compile code.
I'm working with C++ and MinGW, and have started to look into build files and stuff for Sublime Text 2 (Have learned mostly under unix, or Java + eclipse so far). But what I don't understand what is adding a compiler to your path do for you?
Do I need to add it for every folder I want to compile from? Or is it system wide? I'm really learning this stuff for the first time, we we're never showed how to set up development environments or even deploy code on other systems.
You probably mean include paths and library paths in the compiler:
include paths: where the compiler will look for headers; and
library paths: where the linker, invoked by the compiler, will look for binary libraries to finish building your project.
If that is the case, look here for a gentle explanation.
Basically, what is happening is that the compiler looks in certain places for symbols defined by the operating system and other libraries installed system-wide.
In addition to those paths, you need to tell the compiler where to find the symbols defined in your own project.
You may also mean something related to installing the compiler itself or configuring the editor to use it.
In that case, what is happening is that you need to tell the build system where to find the executable for the compiler.
Basically, what is probably happening is that your editor wants to know where the compiler is so that it can provide real time feedback on your code. Adding the compiler to the system path will usually, but not always, solve your problem.
In more detail:
A C++ build is a rather complex tool chain, involving determining dependencies, preprocessing, compiling, and linking. There are tools that automate that tool chain, and those tools are in turn wrapped into the functionality of modern IDEs like Eclipse, Visual C++, or Sublime Text 2. You many need to tell your editor where to find the tools it uses to provide you with those services.