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

81–90 of 122 posts

Re: The Art of 64-bit Assembly

#81

Post by anta40 »

agarren wrote: post #63
Someone wrote: post #19

Weird title for a book on assembly - for x64 - on Windows - using MASM There are other 64-bit OSes, CPUs and assemblers for them, and people do use them.

What a weird, low-effort comment. Randell’s got another (large) book on ARM assembly. He’s also got a handful of other great books on software engineering in general - he’s more than aware that “there are other 64-bit OSes, CPUs and assemblers for them, and people do use them.” This particular title, “the art of assembly” has been around for a while. This x64 version is the latest iteration - it’s a great book compar…

You mean this:

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.

Re: The Art of 64-bit Assembly

#82

Post by okanat »

Joker_vD wrote: post #9
invokestatic wrote: post #5

Earlier quoted context omitted.

It’s part of the MSVC x64 ABI, not a part of the kernel ABI. The kernel and user mode (Win32) APIs all use C linkage so vtables are not relevant and the ABI is a convention of the compiler not the OS. Practically speaking though if your software runs on Windows it will probably use the MSVC ABI.

Last time I checked, software compiled with both Cygwin and MSYS2 internally uses SysV calling convention, only switching to WINAPI when calling, well, Win32 API.

It is more complicated than that. MSYS2 isn't just Cygwin. It has different environments.

MSYS environment is just Cygwin and it uses Itanium IIRC for C and C++ non-Win32 calls since it emulates POSIX. If it links with Windows C runtime they use __cdecl. Win32 API calls always use __stdcall convention / ABI.

However, Mingw environments (Mingw64, UCRT, CLANG etc.) are intended for native Windows development, hence, they use normal MSVC __cdecl ABI for C library calls and internal function calls too. Win32 calls are again __stdcall.

Unlike C, for C++ all MSYS environments use Itanium ABI since they link with GNU libstdc++ or Clang libc++. I think it is possible to use MSVC C++ ABI with Clang but it could be complicated since it requires recompilation of at least libc++.

Re: The Art of 64-bit Assembly

#83

Post by anta40 »

mdp2021 wrote: post #16
csense wrote: post #15

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

Some still like FASM. Why NASM or YASM?

Since NASM/YASM is written in C, it's more portable. On my ARM Mac, NASM works fine.

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.

Re: The Art of 64-bit Assembly

#84

Post by tanseydavid »

asibahi wrote: post #68
boondongle wrote: post #58

Earlier quoted context omitted.

We've really gotten to the point that certain styles seem AI generated in many cases because many folks are poor writers and anything past a high school level is difficult for them. I'm not speaking in this case specifically, just in general. 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…

This publisher copy is neither pedantic nor wordy. It is just a market blurb for the book. The thing that frustrates me the most about AI is how every thread in every forum spend half the time arguing whether an article is AI or not, as if bad writing only started to exist with AI. Just fucking don't read it.

It does not even have to be slop, the compulsion to call out AI-involvement in writing is out of control, esp. on HN.

Em-dashes as the signal is the most-upsetting for me. I have been using them properly and frequently for decades.

Slop is slop. If it is AI-slop then fine, go ahead and call it out.

Re: The Art of 64-bit Assembly

#85

Post by okanat »

Keyframe wrote: post #52
slashdave wrote: post #33

Earlier quoted context omitted.

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.

* 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 API surface is big and complicated. For 1% very hot code or very sensitive code due to execution duration / predictability / throughput, humans usually code better than compilers. This is due to specialization and limited DoF problems that can be solved and optimized to hell.

Re: The Art of 64-bit Assembly

#87

Post by abeyer »

lexicality wrote: post #75
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 own volume 1 and when it first arrived I dropped it on my foot and had to go to the doctor. I have not got around to reading it again. His original x86 ASM book was good though. I also read his Write Great Code series and generally found it to have some pretty good advice, but it was also full of things like recommendations to never trust compilers and to write lots of arcane unreadable magic code to unlock ultimat…

Yeah, I'd second a recommendation of at least the first two volumes of Write Great Code. I've long suggested those to juniors who have come out of bootcamps, self-taught, or other backgrounds outside a typical CS degree and didn't have much exposure to lower level machine concepts. I was a bit let down by the third volume... not that it was bad per se, but I feel like the sw engineering process stuff it covered both strayed outside his core strengths and had been done better elsewhere already.

Re: The Art of 64-bit Assembly

#88

Post by gregdaniels421 »

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).

Re: The Art of 64-bit Assembly

#89

Post by gregdaniels421 »

lexicality wrote: post #75
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 own volume 1 and when it first arrived I dropped it on my foot and had to go to the doctor. I have not got around to reading it again. His original x86 ASM book was good though. I also read his Write Great Code series and generally found it to have some pretty good advice, but it was also full of things like recommendations to never trust compilers and to write lots of arcane unreadable magic code to unlock ultimat…

> if you want to learn about ASM in TYOOL 2026 then you could do a lot worse than learning it from someone who doesn't trust compilers and does everything themselves.

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.

Re: The Art of 64-bit Assembly

#90

Post by wasmperson »

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.

Yes the support is still there, although official MS documentation no longer mentions it. Some of those headers rather flagrantly violate C's strict aliasing rules, which I suspect is the reason MSVC never implemented type-based aliasing optimizations.
Post reply on HN