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

111–120 of 122 posts

Re: The Art of 64-bit Assembly

#111

Post by rramadass »

masfuerte wrote: post #65
jcranmer wrote: post #48

Earlier quoted context omitted.

All of the major kernel ABIs are using C function interfaces as their stable ABI (except Linux, which uses an assembly syscall instruction as the stable interface, although you still rely on a lot of the ancillary C ABI for things like struct layout or stack layout). For C++ ABIs, there are really only 2.5 major ABIs: the MSVC ABI, used by MSVC and clang wanting to be compatible with MSVC, and the Itanium ABI, used f…

Being pedantic, the COM vtable layout is defined independently of C++. The Windows headers used to (and maybe still do) have macros that could declare COM vtables as explicit structs so you could use Windows COM interfaces from C. 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.

COM is still a language-independent binary standard. The first three entries in the vtable must always be IUnknown methods and all methods must use __stdcall calling convention.

The Layout of a COM Object by Raymond Chen - https://devblogs.microsoft.com/oldnewthing/20040205-00/?p=40...

Re: The Art of 64-bit Assembly

#112

Post by rramadass »

rramadass wrote: post #35

Related; 1) All Assembly/C++ books by Daniel Kusswurm. 2) Low-level Programming: C, Assembly, and Program Execution on Intel 64 Architecture by Igor Zhirkov.

3) x86-64 Assembly Language Programming with Ubuntu by Ed Jorgensen - https://open.umn.edu/opentextbooks/textbooks/x86-64-assembly...

Re: The Art of 64-bit Assembly

#113

Post by t-3 »

skippyfish wrote: post #66

I know that we're discouraged from meta-comments, but what is going on in this thread? It's a nearly 800-page book about the art of programming. A huge amount of work on a topic that should be dear to our hearts. News for hackers, right? But somehow, the discussion has three themes. It's 50+ comments of "I don't like the first sentence of the marketing copy", "I don't like the tool the author is using", and "what wou…

I read v1. It's good, but I prefer Ray Seyfarth's book. Not much interest in v2 - I haven't touched Windows in nearly 20 years and this seems much less OS-generic than the previous volume.

Re: The Art of 64-bit Assembly

#114

Post by tmtvl »

gregdaniels421 wrote: post #88
skippyfish wrote: post #66

I know that we're discouraged from meta-comments, but what is going on in this thread? It's a nearly 800-page book about the art of programming. A huge amount of work on a topic that should be dear to our hearts. News for hackers, right? But somehow, the discussion has three themes. It's 50+ comments of "I don't like the first sentence of the marketing copy", "I don't like the tool the author is using", and "what wou…

His earlier 32bit book was pretty decent, but super windows focused, I wish a similar work using a reasonable syntax existed for Linux, but the linux equivalent(some kind of foundations of programming or something similar assembly book) used gas syntax which is like nails on a chalkboard. Fasm is also so much nicer these days to use(masm is neglected by microsoft, but is the tool the author has used for everything).

> gas syntax which is like nails on a chalkboard

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?

Re: The Art of 64-bit Assembly

#115

Post by fuzztester »

gregdaniels421 wrote: post #88
skippyfish wrote: post #66

I know that we're discouraged from meta-comments, but what is going on in this thread? It's a nearly 800-page book about the art of programming. A huge amount of work on a topic that should be dear to our hearts. News for hackers, right? But somehow, the discussion has three themes. It's 50+ comments of "I don't like the first sentence of the marketing copy", "I don't like the tool the author is using", and "what wou…

His earlier 32bit book was pretty decent, but super windows focused, I wish a similar work using a reasonable syntax existed for Linux, but the linux equivalent(some kind of foundations of programming or something similar assembly book) used gas syntax which is like nails on a chalkboard. Fasm is also so much nicer these days to use(masm is neglected by microsoft, but is the tool the author has used for everything).

Have you checked out paul carters assembly language book. it is free online. i'm not sure it has stuff for Linux.But you can check. also , it may be , for sixteen or thirty two bit. since I noticed it online long back. sorry voice typing.

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

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

Re: The Art of 64-bit Assembly

#116

Post by not_a9 »

adrian_b wrote: post #107
Retr0id wrote: post #57

Earlier quoted context omitted.

If you're actually writing software in assembly (as opposed to merely optimizing hot functions in an otherwise high-level codebase), in my experience MASM is the most pleasant tool for the job.

MASM was a decent assembler, but it also had some syntax choices that lead to excessive verbosity. 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.

Out of idle curiosity: can NASM emit Windows unwind information? For the matter, can any assembler do so automatically?

Re: The Art of 64-bit Assembly

#118

Post by rurban »

ndesaulniers wrote: post #38
csense wrote: post #15

I'm sorry, MASM? All the cool kids use NASM or YASM.

The Linux kernel prefers GAS (or clang) w/ the C preprocessor. Luckily most of clang's assembler unit tests (and LLVM's MC layer unit tests) also use GAS style syntax.

Because the Intel syntax is limited, and pretty broken by binutils. I had to change my C compiler rcc to emit AT&T GAS, instead of Intel syntax, even if Intel syntax looks easier on the eye.

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.

Re: The Art of 64-bit Assembly

#119

Post by rurban »

slashdave wrote: post #33
Keyframe wrote: post #14

Earlier quoted context omitted.

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!

Except for some odd corner cases, it is very hard for a good engineer to beat compilers these days (they are very good now). Not to mention, tuning depends on the platform, and often the exact model of chip.

Certainly not. Every hand-optimized tight loop or lookup beats every compiler still. Compilers are extremely stupid, and esp. the language designers.

Re: The Art of 64-bit Assembly

#120

Post by slashdave »

okanat wrote: post #85
Keyframe wrote: post #52

Earlier quoted context omitted.

* it is very hard for a good engineer to beat compilers these days (they are very good now).* I keep hearing this for the last 20 odd years, yet I see evidence to the contrary each and every day. It is hard and honest work though.

A good engineer isn't a godlike entity who knows all. They know when to bring in assembly and when to be satisfied with C / C++ / Rust compilers and steer the compiler. Assembly has unique advantages like guaranteed execution duration for cryptography or exact optimization of hot-loop computation. 99% of the even performance-sensive code doesn't need assembly and compilers beat good engineers in this category since A…

Indeed. Compilers do have to make compromises, and it is not possible from code alone to understand the tradeoffs.
Post reply on HN