Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Art of 64-bit Assembly

nostarch.com

Post reply on HN
Print view View original

21–30 of 122 posts

Re: The Art of 64-bit Assembly

#21

Post by fragmede »

Keyframe wrote: post #14
amelius wrote: post #6

Is anyone still writing assembly in the age of LLMs? Asking seriously because most assembly is just doing one very simple thing very fast and because it's so simple conceptually, an LLM can easily code it without errors.

an LLM can easily code it without errors can't tell if sarcasm or not. Just in case it's not.. in that case why don't we all vibe everything in assembly? No need for abstractions anymore since that's a human concept. LLM can do it without errors, as you say, and we'll reap the benefits of speed!

Because it's not portable. The world we find ourselves in is at least x86 and ARM, and assembly for one isn't good for the other. LLVM has a hardware agnostic intermediate representation (IR) that one could use though.

Re: The Art of 64-bit Assembly

#22

Post by jagged-chisel »

rajeevk wrote: post #17

>> You can ask an AI to explain how vtables work in x86. It will give you something that sounds right. What it won’t give you is what Windows actually expects the vtable to look like, why method dispatch behaves the way it does at the instruction level, or what breaks when you deviate from convention. This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding. O…

But will they prioritize this information over what they have currently, or over their own hallucinations?

Re: The Art of 64-bit Assembly

#23

Post by mdp2021 »

rajeevk wrote: post #17

>> You can ask an AI to explain how vtables work in x86. It will give you something that sounds right. What it won’t give you is what Windows actually expects the vtable to look like, why method dispatch behaves the way it does at the instruction level, or what breaks when you deviate from convention. This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding. O…

> Once LLMs are trained with the content of this book

I strongly believe that the "future" should be LLM+Corpus - something beyond LoRA or RAG or context, but what we need and will have will be a generally strong LLM augmented with the most proper learning from the "selected library of relevant material".

And in parallel, also the reasoner over the corpus will be implemented (something that properly studies, not just reads, and achieves the pinnacle of reflection over the corpus).

Re: The Art of 64-bit Assembly

#24

Post by f3abfeca54812 »

rajeevk wrote: post #17

>> You can ask an AI to explain how vtables work in x86. It will give you something that sounds right. What it won’t give you is what Windows actually expects the vtable to look like, why method dispatch behaves the way it does at the instruction level, or what breaks when you deviate from convention. This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding. O…

But even then your prompt has to be explicit enough to get that answer and not the 'wrong one'. Of course they will prioritize stuff that is more often in the training data. That's why AI will be a dead end long term

Re: The Art of 64-bit Assembly

#25

Post by f3abfeca54812 »

mdp2021 wrote: post #23
rajeevk wrote: post #17

>> You can ask an AI to explain how vtables work in x86. It will give you something that sounds right. What it won’t give you is what Windows actually expects the vtable to look like, why method dispatch behaves the way it does at the instruction level, or what breaks when you deviate from convention. This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding. O…

> Once LLMs are trained with the content of this book I strongly believe that the "future" should be LLM+Corpus - something beyond LoRA or RAG or context, but what we need and will have will be a generally strong LLM augmented with the most proper learning from the "selected library of relevant material". And in parallel, also the reasoner over the corpus will be implemented (something that properly studies, not just…

Are you saying that people should then write books for LLMs only so that you can query them to get the summarized answer and not pay for the book?

Re: The Art of 64-bit Assembly

#26

Post by oinoom »

rajeevk wrote: post #17

>> You can ask an AI to explain how vtables work in x86. It will give you something that sounds right. What it won’t give you is what Windows actually expects the vtable to look like, why method dispatch behaves the way it does at the instruction level, or what breaks when you deviate from convention. This volume of The Art of 64-Bit Assembly closes the gap between a plausible explanation and genuine understanding. O…

You also don’t need it to be trained on it specifically, just give it some docs or links to docs or source code as reference

Re: The Art of 64-bit Assembly

#27

Post by norir »

If you need better performance than a higher level language affords you, I would not recommend programming directly in asm. Instead, I would write a compiler. Raw asm is seductive since the start up cost is relatively low. You can get started in an afternoon. The trouble is that writing correct assembly is much harder than high level code. You have to hold in your head the register state at all times. You have to know if the function you are calling will clobber registers that you need after the call and manually save/restore them. This will slow down your velocity and the resulting code will be long and difficult to read. It will also rely on a lot of undocumented information that only resided in your head while writing and has since been evicted. Good luck debugging a program written in assembly that no one has looked at for two months.

On the other hand, if you write your own non optimizing compiler, you can avoid a lot of these problems by, for example, tracking what registers a function writes and ensuring they are saved before a call and restored after. Then you can actually get the raw performance of handwritten asm without the pitfalls (the resulting code would still he harder to read and maintain than equivalent high level code, but at least it would be tractable). Even better, you can write your own high level assembler that is actually portable to other architectures. For example, instead of directly modeling x86_64, your compiler can model a cpu with 16 general purpose registers and a set of instructions that map to x86_64 instructions. An arm port would be straightforward since arm also has 16 general purpose registers and you can model x86_64 instructions as one or more arm instructions (and you have extra registers for x86_64 instructions that must be modeled as multiple arm instructions). Or you could do the reverse and model 32 general purpose registers using arm instructions and use predefined memory slots as virtual registers on x86_64.

Re: The Art of 64-bit Assembly

#28

Post by mdp2021 »

f3abfeca54812 wrote: post #25
mdp2021 wrote: post #23

Earlier quoted context omitted.

> Once LLMs are trained with the content of this book I strongly believe that the "future" should be LLM+Corpus - something beyond LoRA or RAG or context, but what we need and will have will be a generally strong LLM augmented with the most proper learning from the "selected library of relevant material". And in parallel, also the reasoner over the corpus will be implemented (something that properly studies, not just…

Are you saying that people should then write books for LLMs only so that you can query them to get the summarized answer and not pay for the book?

I cannot get a faint idea about how you managed to get such a twisted misunderstanding.

Let us reformulate through the framework: the learned wrote books; the learners read them books, as many as possible in a ranked list; we may one day achieve automated learners; learned learners are our consultants; we benefit from the level of learning of them consultants; we would benefit greatly from the Perfected Learner; I gave a few lines of the general directions towards "thinking of them in view of building them" in the post above...

Re: The Art of 64-bit Assembly

#29

Post by sylware »

I am more curious about how they would cleanly manage hierarchical labels (usually called "namespaces"), register naming, and stack management with deep register spilling, description of the register state on the various entries from the various dominators of a code block.

I am doing all that with a basic C pre-processor in my assembly source code. But the more I think about this, the more I think I should write my own pre-processor, which "should" be much simpler than a C pre-processor in the end and would do a cleaner job since taylored for those usages (the "annoying" thing is the arithmetics expression evaluation).

I would write this pre-processor in assembly, namely design a binary specification (that to be ready for other ISA implementations).

Then, they are the really important things: for all micro-architectures, how to be friendly to conditional branch predicition, how to handle BTB entries layout in a cache line, show how important the "cache line" is ubiquitous, etc.

I remember clearly one of the TheHeavyThing developers telling me than with a basic and naive hand compilation of gzip, he was beating the best compilers, at that time, by a consistent 10/15%. Let me remind people here of something: nobody is supposed to be able to beat a compiler on deep and hairy compilation units. If it is the case, something is wrong in that compiler.

Re: The Art of 64-bit Assembly

#30

Post by slashdave »

sylware wrote: post #29

I am more curious about how they would cleanly manage hierarchical labels (usually called "namespaces"), register naming, and stack management with deep register spilling, description of the register state on the various entries from the various dominators of a code block. I am doing all that with a basic C pre-processor in my assembly source code. But the more I think about this, the more I think I should write my o…

I'm... confused. Don't we use macro assemblers anymore?
Post reply on HN