5 ms·

i hear compilers are pretty good at generating assembly these days.

snvzz 3y ago
I recommend reading the forward[0] of The Art of Assembly. Or to just look at the output of your favorite compiler. Nobody has ever looked at the output of a compiler and thought it was good. 0. http://flint.cs.yale.edu/cs421/papers/art-of-asm/pdf/FORWARD.PDF http://flint.cs.yale.edu/cs421/papers/art-of-asm/pdf/FORWARD...
- homarp 3y ago
  What are the chances that compiler assisted by GPT can match human-generated Assembly?
  - topspin 3y ago
    That's a compelling question. So much so that I imagine someone has already investigated this. I might go seek out such work, but whatever I find is likely to already be out of date... Interesting times.
    - sylware 3y ago
      Some assembly fellows did ask chatGPT for a vectorized quicksort (avx2/avx512...). Fixing it may be more painful than writing from scratch. But I think it was with chatGPT 3, not 4, and we would have to think about a neural net trained to write assembly.
      - topspin 3y ago
        I'm starting from the assumption that the vast bulk of hand optimized assembly does not elaborate on the thinking behind the implementation in a way that can be processed through training. Certainly not assembly obtained by reverse engineering. Assuming I'm correct, does this mean there is a dearth of training material available for building such a model? It would seem that first one would need a model that could consume arbitrary assembly and somehow discover it's intent, generate 'labels' (apologies if I'm misusing terms here,) and they feed the output into another model.
  - ffgjgf1 3y ago
    Why do you think humans can generate ‘better’ assembly than compilers (aside from some very ‘simple’ cases)? I thought the inverse has been the case for many years now..
    - sylware 3y ago
      Weird, I will never presume it, only suspect it would. I tend not to be over confident in compilers: what I presume is that compilers inject "convenient bugs" into machine code, which are not in the compiled language but it the end can be exploited. We all know that "software security audits" is about finding "holes" in some machine code, then propagate the fix into the compilers (and often the compiled language). If the machine code does change, the audit must be done all over again. But, where assembly is better: near zero planned obsolescence from compilers (since there are none), which is really a pain on the medium/long run, REALLY! Writting assembly is not really about speed anymore nowdays, it is more about independence from those grotesquely and absurdely massive and complex compilers.
    - camel-cdr 3y ago
      > Why do you think humans can generate ‘better’ assembly than compilers (aside from some very ‘simple’ cases)? I think that compilers + human supervision results on the best assembly code gen. Compilers are great at vectorization, but they can fail at very trivial examples, e.g.: typedef struct { char a, b; } S; void zeroB(S *s, size_t n) { for (; --n; ++s) s->b = 0; }
      - sylware 3y ago
        https://godbolt.org/noscript https://godbolt.org/noscript Since I am more and more comfy at writing assembly, it is usually kind of less of a pain to write directly assembly than to refactor and comment compiler assembly output.
        camel-cdr 3y ago
        You botched the link. (I had the same problem btw, otherwise I would've included a godbolt link as well, but idk how to create one with noscript)
- bee_rider 3y ago
  I’ve rarely looked at the output of a compiler and thought “that’s great!” but on the other hand, the fact that I’ve rarely looked at the output of a compiler at all seems to indicate that they’ve got their priorities straight.
- sylware 3y ago
  It seems that major compilers, gcc and clang are now suffering some sort of "planned obsolescence": ISO C is always adding stuff, then somebody will manage to use the new stuff in some critical system components and will force everbody to upgrade. It is even more accute with gcc extensions and linux for instance. It seems ISO C planned obsolescence does happen on a longer time cycle than gcc extensions for linux code for instance (or the glibc, or gcc but even worse: c++11 c++14 c++17 c++489374892347892374238, c++ is orders of magnitude more planned obsolesence troubles than C). Then actually, they could generate amazing code, I would not care less: I am so much angry because of this manic and systemic planned obsolescence, I now try to code everything in assembly (avoiding grotesque assembly code generators and absurd usage of the macro preprocessor). I write x86_64 assembly code, but I am confident porting to risc-v should be brutal but not that hard... and I kind of know, it will happen.
yjftsjthsd-h 3y ago
I'm slightly out of the loop, but don't modern compilers often actually skip real assembly and go from source code to an intermediate representation (which is like asm but not quite the same) to binary? Or is that aside your point?
- sylware 3y ago
  You can have a look at cproc + qbe (I tend to favor that instead of tinycc, ofc clang and gcc are pure evil).
- inconceivable 3y ago
  asm can be the input and/or the output. https://stackoverflow.com/questions/10990018/how-to-generate-assembly-code-with-clang-in-intel-syntax https://stackoverflow.com/questions/10990018/how-to-generate...
- resoluteteeth 3y ago
  Machine code and assembly are basically interchangeable so they mean disassembled compiler output and it doesn't really make a difference
- Taniwha 3y ago
  There have always been compilers that skip the "make assembly source" and go straight to object files - in fact the first time I saw unix V6 cc I was a bit scandalised (but it made sense for a system where programs had to be <= 64k in size)

I recommend reading the forward[0] of The Art of Assembly. Or to just look at the output of your favorite compiler. Nobody has ever looked at the output of a compiler and thought it was good. 0. http://flint.cs.yale.edu/cs421/papers/art-of-asm/pdf/FORWARD.PDF http://flint.cs.yale.edu/cs421/papers/art-of-asm/pdf/FORWARD...

homarp 3y ago
What are the chances that compiler assisted by GPT can match human-generated Assembly?
- topspin 3y ago
  That's a compelling question. So much so that I imagine someone has already investigated this. I might go seek out such work, but whatever I find is likely to already be out of date... Interesting times.
  - sylware 3y ago
    Some assembly fellows did ask chatGPT for a vectorized quicksort (avx2/avx512...). Fixing it may be more painful than writing from scratch. But I think it was with chatGPT 3, not 4, and we would have to think about a neural net trained to write assembly.
    - topspin 3y ago
      I'm starting from the assumption that the vast bulk of hand optimized assembly does not elaborate on the thinking behind the implementation in a way that can be processed through training. Certainly not assembly obtained by reverse engineering. Assuming I'm correct, does this mean there is a dearth of training material available for building such a model? It would seem that first one would need a model that could consume arbitrary assembly and somehow discover it's intent, generate 'labels' (apologies if I'm misusing terms here,) and they feed the output into another model.
- ffgjgf1 3y ago
  Why do you think humans can generate ‘better’ assembly than compilers (aside from some very ‘simple’ cases)? I thought the inverse has been the case for many years now..
  - sylware 3y ago
    Weird, I will never presume it, only suspect it would. I tend not to be over confident in compilers: what I presume is that compilers inject "convenient bugs" into machine code, which are not in the compiled language but it the end can be exploited. We all know that "software security audits" is about finding "holes" in some machine code, then propagate the fix into the compilers (and often the compiled language). If the machine code does change, the audit must be done all over again. But, where assembly is better: near zero planned obsolescence from compilers (since there are none), which is really a pain on the medium/long run, REALLY! Writting assembly is not really about speed anymore nowdays, it is more about independence from those grotesquely and absurdely massive and complex compilers.
  - camel-cdr 3y ago
    > Why do you think humans can generate ‘better’ assembly than compilers (aside from some very ‘simple’ cases)? I think that compilers + human supervision results on the best assembly code gen. Compilers are great at vectorization, but they can fail at very trivial examples, e.g.: typedef struct { char a, b; } S; void zeroB(S *s, size_t n) { for (; --n; ++s) s->b = 0; }
    - sylware 3y ago
      https://godbolt.org/noscript https://godbolt.org/noscript Since I am more and more comfy at writing assembly, it is usually kind of less of a pain to write directly assembly than to refactor and comment compiler assembly output.
      - camel-cdr 3y ago
        You botched the link. (I had the same problem btw, otherwise I would've included a godbolt link as well, but idk how to create one with noscript)
bee_rider 3y ago
I’ve rarely looked at the output of a compiler and thought “that’s great!” but on the other hand, the fact that I’ve rarely looked at the output of a compiler at all seems to indicate that they’ve got their priorities straight.
sylware 3y ago
It seems that major compilers, gcc and clang are now suffering some sort of "planned obsolescence": ISO C is always adding stuff, then somebody will manage to use the new stuff in some critical system components and will force everbody to upgrade. It is even more accute with gcc extensions and linux for instance. It seems ISO C planned obsolescence does happen on a longer time cycle than gcc extensions for linux code for instance (or the glibc, or gcc but even worse: c++11 c++14 c++17 c++489374892347892374238, c++ is orders of magnitude more planned obsolesence troubles than C). Then actually, they could generate amazing code, I would not care less: I am so much angry because of this manic and systemic planned obsolescence, I now try to code everything in assembly (avoiding grotesque assembly code generators and absurd usage of the macro preprocessor). I write x86_64 assembly code, but I am confident porting to risc-v should be brutal but not that hard... and I kind of know, it will happen.

yjftsjthsd-h 3y ago

I'm slightly out of the loop, but don't modern compilers often actually skip real assembly and go from source code to an intermediate representation (which is like asm but not quite the same) to binary? Or is that aside your point?

sylware 3y ago
You can have a look at cproc + qbe (I tend to favor that instead of tinycc, ofc clang and gcc are pure evil).
inconceivable 3y ago
asm can be the input and/or the output. https://stackoverflow.com/questions/10990018/how-to-generate-assembly-code-with-clang-in-intel-syntax https://stackoverflow.com/questions/10990018/how-to-generate...
resoluteteeth 3y ago
Machine code and assembly are basically interchangeable so they mean disassembled compiler output and it doesn't really make a difference
Taniwha 3y ago
There have always been compilers that skip the "make assembly source" and go straight to object files - in fact the first time I saw unix V6 cc I was a bit scandalised (but it made sense for a system where programs had to be <= 64k in size)