Have you looked at the Go toolchain at all? I don't know much about it, but they implemented their back ends in a manner that is much smaller than LLVM and GCC. And it sounds like the architecture of the compiler is significantly different.
I watched this talk and it was pretty interesting:
If I am understanding right, the claim is that they have a single assembly language for ALL GO architectures, based on something Ken Thompson wrote in the 90's for some National Instruments (?) chip. He actually says that all assembly language looks the same now.
I was sort of surprised by that claim. I would like to hear a critique of this from other compiler writers. Does the fact that Go uses a single assembly language make the code slower? I imagine taking advantage of target-specific knowledge is useful, but I don't know how much.
LLVM has this pretty elaborate TableGen system to express target-specific knowledge.
He also makes the claim that they will be able auto-generate a new backend from the PDF description of the architecture. And he says somewhere that they reduce a lot of the work to simple "text processing" (symbol manipulation) and didn't require opening up any processor manuals.
I can see how arithmetic and bitshifting is the same among all architectures. But I would think that even loads and stores have differences, at least if you want to use the processor efficiently. But he says everything kinda looks the same.
Also, another thought is that compiling to WebAssembly might be simpler than native executables?
I can see how arithmetic and bitshifting is the same among all architectures. But I would think that even loads and stores have differences, at least if you want to use the processor efficiently. But he says everything kinda looks the same.
The basics are the same (and indeed that is why many RISCs resemble MIPS), but you're correct that more advanced (or perhaps I could say, Intel-ligent ;-) architectures have many more interesting instructions that are beyond the subset, and can definitely save on code speed, size, or both when used effectively but are not easy to match nor describe the semantics of. It's easy to match X+Y to an ADD, or even X = 4 * Y + C to an LEA, but at the other extreme, how would you match a whole AES encryption round and replace it with a single AESENC instruction? Currently, no compiler I know of can do that, so you must use intrinsics or pure Asm.
Yeah that's what I would have thought, but I would like to see it quantified. Does all the target-specific info give you 10% or 100% improvement? Maybe they're onto something? The simplification does sound drastic.
He does actually mention the AES instruction in the talk. I think they just have some one-offs to deal with those specific cases. I guess Go is different than C because it comes with a big standard library. They can just make sure that their standard library crypto uses the AESNES instruction, whereas C compilers have no idea what crypto library you're using.
Thanks for that brain dump! The details on Go were fascinating.
I haven't looked more than superficially at any existing compilers outside of small toys. Reading large codebases is hard, and I have a harder time with it than most. (Hence my current project involving compilers: https://lobste.rs/s/n0d3qo/what_are_you_working_on_this_week... ) But let me put Go back on the head of the queue..
If it's a lot smaller and serves their purpose, it's not implemented poorly. And if it compiles 10x as fast, which it probably does (I'm not a heavy Go user.)
Also I think this representation is different architecturally. Go now uses an SSA representation apparently, which would be the equivalent of LLVM IR AFAIK. This assembly language is more toward the backend where as the IR is more like the "middle end".
I watched this talk and it was pretty interesting:
https://www.youtube.com/watch?v=KINIAgRpkDA
https://talks.golang.org/2016/asm.slide#1
If I am understanding right, the claim is that they have a single assembly language for ALL GO architectures, based on something Ken Thompson wrote in the 90's for some National Instruments (?) chip. He actually says that all assembly language looks the same now.
I was sort of surprised by that claim. I would like to hear a critique of this from other compiler writers. Does the fact that Go uses a single assembly language make the code slower? I imagine taking advantage of target-specific knowledge is useful, but I don't know how much.
LLVM has this pretty elaborate TableGen system to express target-specific knowledge.
He also makes the claim that they will be able auto-generate a new backend from the PDF description of the architecture. And he says somewhere that they reduce a lot of the work to simple "text processing" (symbol manipulation) and didn't require opening up any processor manuals.
I can see how arithmetic and bitshifting is the same among all architectures. But I would think that even loads and stores have differences, at least if you want to use the processor efficiently. But he says everything kinda looks the same.
Also, another thought is that compiling to WebAssembly might be simpler than native executables?