The Art of 64-bit Assembly

Not bad advice, but the Fasm forums used to be pretty good for asking questions, no clue if they are around and active still, but there were a lot of programs people had written and even a few simple OSs(including KolibriOS) which had a ton of code to read through that mostly was commented. Once you get the basics it is pretty easy to do stuff, and most of learning is doing stuff.

That's weird, GNU as should default to AT&T syntax. Maybe the author switched to Intel syntax by adding the .intel_syntax directive at the beginning of the code?

Edit: i checked. it is for 32 bit. works on Linux. and uses Nasm.

https://pacman128.github.io/pcasm/

At least since UNIX v4.

All good Assemblers have come from Amiga, Atari, PC world.

It's also one of the reasons its insanely popular in ESL countries and frustrating/disliked in English-speaking countries because it makes things easier in one and harder in the other.

It was never the goal, but it is the reality. The same style people call AI, was often called being a pedant or being wordy 10 years ago.

To me, it's all fairly human-ai neutral except for this sentence which is oh-so AI cliche and casts doubt on the rest of it:

> This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding.

"closes the gap" is a favored phrase by our artificial friends and the phrases "plausible explanation" and "genuine understanding" are just... so ... dramatic for the context.

The rest of it is pretty tame in comparison. In my armchair opinion, I'd guess it's mostly a composite of (professional) human-written/ai-revised and/or vice versa. Which is not necessarily a bad thing.

https://www.amazon.com/Art-ARM-Assembly-Randall-Hyde/dp/1718... ?

Mmm nice. Will give it a try since ARM-based Mac is my main working environment nowadays.

Anybody who is even cursorily interested in Assembly Programming knows of Randall Hyde and his works since he has been at it since the 16-bit days. One of the few authors with truly great depth.

Makes me think that most people commenting here know nothing about assembly and are simply posting empty comments for the heck of it. This has been a trend on HN lately of similar meaningless/useless comments on any topic.

In any case, today nasm is mostly equivalent with it, if not better, while being kept much more up-to-date with the Intel-AMD ISA extensions.

For instance, with a C pre-processor, I have a very lean C pre-processor dialect which allows me to assemble simple x86_64 code with... fasmg[12] or nasm(probably yasm) or gas(intel syntax).

A big project which was bitten by specific pre-processor abuse: ffmpeg with nasm (but it is still much less toxic than to start to be hard dependent on advanced and specific C compiler extensions... look a the failure from linux on that matter).

I remember during the DOS era TASM was all the rage; it was wicked fast. Unfortunately didn't get an opportunity to do much assembly programming after moving to Windows/Unix.

When Randall Hyde published his HLA (https://en.wikipedia.org/wiki/High_Level_Assembly) i remember thinking it was a good idea since it allowed many high-level language programmers to easily learn assembly programming as it included all the well-known higher-level programming constructs. It was a proper new language, but the assembly purists were all outraged and Hyde caught a lot of flak which i think was unjustified.

FASM is cool (and still being development), but since it's written in 32-bit x86 asm, let's just say macOS is a 2nd class citizen.

GNU Assembler (GAS) ≥2.45 on x86-64: call and jmp to global labels in Intel syntax cause operand type mismatch errors. RCC emits .intel_syntax noprefix by default, but GAS ≥2.45 rejects direct branches to global symbols in this mode. Local labels (.L.xxx) work fine. Tests with user-defined function calls (bitops-1, fprintf-1, etc.) may fail to assemble under these versions. Root cause: rcc emits lea r11, [rip + sI] but GAS requires AT&T sI(%rip) for globals.

That used to be the case anyway. It's possible they binned the C support in the switch to 64-bit. I haven't looked since.

Sure, they might make all sorts of dumb hypotheses at first, but as long as the results of those stay in their context, they do seem to eventually “run out of ways to be stupid.” (Which is to say, LLMs seem to experience in-context learning even via self-directed trial-and-error, if given a sufficiently-large number of iterations and no way to cheat.)

It also is an excellent radare2/rizin/ghidra driver as well. Maybe it's because its ~cyber~ capabilities (pretty much linked with assembly-level knowledge) aren't guardrailed off?

But assembly? I'm not sure, honestly. Architectures change, and you can easily converge to good code by talking to an LLM.

May I ask why you didn't use LLVM as a target?

Professionally, assembly is the last thing I would let an LLM generate for me. That's because if you need to write something in assembly, it's because it's critical: operating system context switch, interrupt handler, that kind of thing. You don't want to be 99% correct, you need that code to be 100% good.

I can imagine some other professional scenarios that I'm less familiar with, where you want to write a tight numeric loop of NEON64 assembly and let the LLM do it, because it's frankly a pain to do by hand, and you can test it to some degree of confidence.

I really loved this retort, but we have to reply: from that cone of perspective, it would be probably better to "vibecode" in C and not hope that the LLM does a better job than the compiler (for efficiency, not for absence of bugs as per the original). (Edit: for clarity: some compilers of low level languages are specialized in ASM optimization - the LLM will hardly beat them.)

  There are other questions around AI (like what the
  economy of it will actually look like in the end),
  but "is it useful" is no longer one of those
  questions. Anybody who doubts that clearly hasn't
  actually used it.
  
  And no, AI isn't perfect. But Christ, anybody who
  points to the problems at AI had better be looking
  in the mirror and pointing at themselves at the
  same time.