GodBolt: Enter C, get Assembly (godbolt.org)

I had a chance to read part of the sources and prepare a patched version with a set of toolchains (m68k, amd64, mips). It's nicely written, it's easy to add toolchains as well as to set default compilation options.

https://github.com/mattgodbolt/gcc-explorer

http://xania.org/201609/how-compiler-explorer-runs-on-amazon

Source: I started writing assembly code in 1968, over the years coding for Sigma 5/7, PDP-10, TI 9900, 6502, 8080, Z80, 8086, 68000, x86, and ARM. I occasionally saw it called assembler language, but less often than assembly language.

Update: As I think about it, there is a bit more nuance to the terminology that I remembered at first. While I do recall "assembler language" and "assembler code" as being infrequently used, "assembler" by itself has often been a common usage:

"I'm writing this in assembly code."

"I'm writing this in assembler."

Those were used fairly interchangeably, even by someone like me to whom "assembler code" sounded a bit off.

So you're definitely not wrong to call it "assembler". Where you're going wrong is claiming that "assembly code" is incorrect.

Assembly is also the result of something that was assembled.

I think most people internally optimise readability and thus size, those who don't generally make unmaintainable mush.

Yes, but once you did you might see how you might improve it.

Your brain, while slower at code translation than gcc, can think of things that gcc never will, and yet things that can beat your brain[1] are still slower.

[1]: https://en.wikipedia.org/wiki/Superoptimization

I would be much more impressed if I hadn't taken a compilers course. I reckon (god alone knows exactly what GCC does) this is just linear induction variable substitution[1] (so `x` gets replace with `i*2`), then associativity of integer multiplication, then some (probably builtin) rule that `n%n` is always 0. From there, it is pretty straightforward.

Don't get me wrong - the devil is in the details and getting optimizations that are both powerful and only applied when they are valid, and at the right time is difficult as hell. That said, I do expect compilers to be at least this smart.

[1]: https://en.wikipedia.org/wiki/Induction_variable#Induction_v...

https://godbolt.org/g/HCifdP

  > Now remove the "!"

Also as pointed out elsewhere clang turns the "!" version into a simple equation in terms of n, so I'm actually kind of disappointed in GCC here.

Now here's a more efficient algorithm which does produce the currect result:

    int square(int num) {
        int a = 0;
        for (int x = 1, n = num; x <= num; x+=x, n+=n) {
          if( num & x) {
              a += n;
          }
       }
       return a;
    }

https://godbolt.org/g/eXLhxH

    square(int):                             # @square(int)
        xor     eax, eax
        ret

One thing that can happen is an integer overflow: if you pass (0x10000, 0x10000), icc's and gcc's versions will calculate 0x10000 * 0x10000 = 0, 0 / 0x10000 = 0, while clang will return 0x10000. But clang's not wrong: signed integer overflow is undefined behavior in C, so compilers are allowed to just assume it never happens when making optimizations.

The division cancels out the multiplication. Just like if you were doing arithmetic on paper as you did in school. There's nothing more to it than that is there? What inputs do you think it's incorrect for in clang?

Overflow is of course undefined.

What arguments do you think it will do the wrong thing with?

  int retNum(int num, int num2) {
        return (num2 * num)/num;
  }

  retNum(int, int):
          mov     eax, esi
          ret

  return (num / num2) * num2;

That is what I get for thinking about this before coffee.

Instead of finding (or worse, building) a compiler or cross compiler locally and doing all the boring steps to compile properly (harder than it sounds) and disassemble the code, you can just splat some code into this and take a peek.

Less about "assembly projects", more about breadth of info available to a developer writing C/C++.

A smart compiler would not use the new SSE version. (perhaps you didn't set the flags right?)

This is why: http://0x80.pl/articles/sse-popcount.html

Most of the optimizing magic happens in the JITs, not javac.

I'd love to see Motorola 68000 support.