Interactive Go source to assembly | Hacker News Reader

Interactive Go source to assembly

go.godbolt.org

58 pointsjdkanani12 comments

This seems to support only gccgo, not the standard gc compiler. Also, I don't see what benefit this has over go tool 6g -S; actually the output from 6g -S is much more readable since it has better symbol names.

Not to deride on author's work, but I just don't see the point of this website at all.

It's useful for sharing snippets and the associated disassembly with others, much like you'd use pastebin. I use it on IRC all the time (for C++). It's also useful to be able to see the codegen for compilers you don't have in front of you, like MSVC or different versions of GCC.

But there's only one compiler supported and that's for a single particular version of gccgo.

Hi!

Site author here. As you probably noticed, this viewer is based on "GCC explorer". Most compilers for most languages (rust, d, c++) have GCC-like modes where their command-line settings and outputs are GCC-like enough that only small modifications are needed to work in GCC Explorer.

6g is very different and its output is decidedly non-GCC-ey. I didn't add 6g for this reason, though I have a hacky patch to try and get something vaguely working that I'll deploy shortly!

Let me know how you get on!

Thanks for the explanation!

No worries. The 6g version is now live but I suspect it doesn't do the code generator justice. It seems 6l also does some kind of optimisation and my hacks version o just running 6g -S isn't showing that up.

Previously, 6l did some pretty significant changes to the code generated by 6g, e.g. the stack split prologue was generated in 6l. Back then, you could use 6l -a to see the final version. More recently (since 1.3) the code generation part of the linker was refactored into a library, liblink, and the compiler links with this library. Now 6g -S is pretty close to the final code, although there still are some things done by 6l. Unfortunately, the -a flag was lost. We have new disassemblers however; go tool objdump will dissasemble Go binaries and will show you the final version of the code. Unlike GNU objdump, the Go objdump understands Go binaries better and can print in normal Plan 9 assembly syntax (well normal for Go, anyway).

Cool! I will give that a go. The rest of the site is pretty geared around annotated assembler from the compiler but I've been meaning to add objdump like support for a while (if only to see things like opcode lengths for I-cache observations). This may be the excuse to support that for both GNU and Plan 9 output.

> This seems to support only gccgo, not the standard gc compiler

Just to clarify, both gccgo and gc are "standard" compilers - Go is intentionally developed with two officially supported compilers. One of the purposes of this is to prevent compiler quirks or bugs from superseding the spec, as has happened in other languages.

When you hear about changes to "the Go compiler" people are usually talking about gc, but that's because gccgo is simply a front-end to gcc (as are many other languages' compilers) - there are no radical architectural changes to be made, the way there are with gc.

The upside of this is that many/most people who have gcc installed or available on their system already have access to a first-class, official Go compiler.

That's not interactive at all. Going by the definition used we can say every compiler is interactive since you can just dump the object code after compiling the source code.

Absolutely: in fact the original "version" of GCC Explorer was inspired by me having a window with 'watch "g++ -O2 -S foo.cpp"' running next to the vi editor I was tweaking code with.

I reckon that's pretty interactive: you make a change and see the result (almost) straight away.

We have different definitions of interactive then. Smalltalk is interactive. Dr. Racket is interactive. This is just a pipeline.

Reply on news.ycombinator.com