Let's Learn x86-64 Assembly (2020)

https://gpfault.net/posts/asm-tut-0.txt.html

by 90s_dev • 1 year ago

420 99 1 year ago

90s_dev4• 1 year ago

I came to the party way to late. A month ago, I found out asmjit was a thing, and now it's happily embedded in my app. But I don't know assembly! I tried to learn a few times since the early 2000s but the timing was never right. But hand written asm as a feature fits perfectly into my upcoming app, so now I am on a roll learning assembly! Here are some more resources I found so far:

https://news.ycombinator.com/item?id=22279051

https://sonictk.github.io/asm_tutorial/#introduction/setting...

https://cs.brown.edu/courses/cs033/docs/guides/x64_cheatshee...

https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...

enjoytheview• 1 year ago

Here's a really good free one:

OpenSecurityTraining2 Architecture 1001: x86-64 Assembly

https://p.ost2.fyi/courses/course-v1:OpenSecurityTraining2+A...

They also have RISC-V and many other for debuggers and reverse engineering tools (ida/ghidra for example)

Razengan• 1 year ago

I wish there were more articles and resources about modern ARM assembly. Not that I ever will or have programmed in Asm, but I like learning about it and imagining I will, and Intelisms feel so archaic and crusty in comparison.

90s_dev4• 1 year ago

The first HN link in my comment addresses that. The short version: learn the earliest asms first, then progressively learn the newer ones until you get to today, and none of the knowledge will be wasted. Kind of like fast-forwarding.

mjevans• 1 year ago

I wouldn't say you are wrong, but I would also postulate.

The smallest, simplest, 'useful' (in terms of useful enough that lots of devs did good work with it and thus it might also be 'popular') ASM sets are probably also sufficient to start with. Provided you've got a good guide to using them, and also ideally a good sheet for why given instructions are packed the way they are in binary.

I do agree you're more likely to find pointers to such resources in more classic architectures. They're also more likely to be easy to find free copies of useful literature.

spauldo• 1 year ago

Any reason for ARM specifically? There are a lot of microcontrollers out there that fairly simple but without Intel's crustiness. Atmel, for instance. And if you decide to actually try experimenting with them you can get yourself set up for it for less than $100.

throwaway311312• 1 year ago

https://shop.elsevier.com/books/computer-organization-and-de...

It's currently 50% off and not only will you learn ARM, and some history about ISAs in general, but you'll learn more about how the computer itself works.

And if ARM isn't a hard requirement, an older edition that uses RISCV as the core ISA is a free download.

https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/books/H...

Highly recommended.

pmxi• 1 year ago

The first link was the textbook I used for my computer architecture course last semester and I concur. This was the first time our professor taught ARM instead of x86_64 because he believes ARM is the future.

slashtom• 1 year ago

I learned on the MIPS processor, computer organization / architecture one of the most challenging CS courses for me. I don't remember much but I definitely remember the mips pipeline...

lauriewired• 1 year ago

This is my own channel, but I made a 10+ part series on modern ARM assembly you may find interesting. I used CPUlator for the demonstrations, which is a nice way to inspect the memory as well as the individual registers as you are running a program.

All runs in the browser:

https://youtube.com/playlist?list=PLn_It163He32Ujm-l_czgEBhb...

breckinloggins3• 1 year ago

Thanks for your work on this. I’ve bookmarked several of these videos and used them as reference.

Learning assembly with a really good visualizer or debugger in hand is highly underrated; just watching numbers move around as you run your code is more fun than it has any right to be.

I really like Justine Tunney’s blinkenlights program. (https://justine.lol/blinkenlights/)

A version of that for AArch64 / RISC-V would be really cool.

WalterBright• 1 year ago

I'm learning AArch64 assembly in the process of writing a code generator for it. godbolt.org is a great resource for "how do I do this?" Write a short function, run it through godbolt.org, see the instructions generated, lookup the instructions in the spec:

https://www.scs.stanford.edu/~zyedidia/arm64/encodingindex.h...

It'll be my keynote presentation at the D conference next month.

Asm2D• 1 year ago

I think AsmGrid has a great overview of X86 and AArch64 instructions:

  - https://asmjit.com/asmgrid/

electroglyph• 1 year ago

wow, that's great. thanks for sharing!

__alexander• 1 year ago

I haven’t seen this site before. Thanks for sharing it.

rfl890• 1 year ago

Felix Cloutier's page has always been my go-to

cylinder714• 1 year ago

https://www.felixcloutier.com/x86/

mananaysiempre• 1 year ago

For x86 encodings, there’s also http://ref.x86asm.net/index.html and of course the venerable https://sandpile.org/.

gnabgib• 1 year ago

(2020) Discussion at the time (180 points, 38 comments) https://news.ycombinator.com/item?id=24195627

nice_byte4• 1 year ago

Author here. The final part of this series is still sitting in my drafts.

It was nominally supposed to be about flow control instructions, but as it goes with those things, it spiralled and ended up touching on relocations, position-independent code, aslr... One on these days I'll clean it up and post it

90s_dev4• 1 year ago

Please do!

pm22222• 1 year ago

> Additionally, the higher 8 bits of rax, rbx, rcx and rdx can be referred to as ah, bh, ch and dh.

Did you mean “ax, bx, cx, dx”?

anamexis• 1 year ago

Those would be the lower 8 bits, no?

pm22222• 1 year ago

ax=ah:al eax=?:ax rax=?:eax

grg0• 1 year ago

It's neither. al is the lower 8 bits of ax (ah the higher 8 bits). ax is the lower 16 bits of eax. eax the lower 32 bits of rax.

Here's the AMD manual: https://docs.amd.com/v/u/en-US/40332-PUB_4.08

wunused3• 1 year ago

In a 64 bit register, e.g., RAX, AL refers to the lowest 8 bits [0-7] and AH refers to the next 8 bits [8-15].

Together, AX refers to bits [0-15]. EAX refers to [0-31].

It's counterintuitive (or at least, inconsistent) that we have a name for bits [8-15] but not for [16-31] or [32-63]. My fuzzy understanding is that this came about from legacy decisions.

This page has a helpful visualization at the top: https://www.cs.uaf.edu/2017/fall/cs301/lecture/09_11_registe...

ordu• 1 year ago

ax, bx, cx, dx are 16 bit registers referring to the lower 16 bits of rax, rbx, rcx, and rdx respectively. Bits 0..8 can be referred as al/bl/cl/dl, bits 8..16 as ah/bh/ch/dh.

wunused3• 1 year ago

It's ambiguous, but I believe the comment you are replying to suggests that the sentence should read:

> Additionally, the higher 8 bits of ax, bx, cx and dx can be referred to as ah, bh, ch and dh.

mixmastamyk• 1 year ago

Let's learn RISC-V assembly!

- https://en.wikipedia.org/wiki/RISC-V_assembly_language

- https://asm-docs.microagi.org/risc-v/riscv-asm.html

- https://riscv-programming.org/

- https://github.com/riscv-non-isa/riscv-asm-manual

dapperdrake• 1 year ago

AArch64/Arm64 assembly:

https://mariokartwii.com/armv8/ch11.html

urda• 1 year ago

It's always a great way to get a better understanding of things but at least just poking around assembly a bit once. You do not have to make a project or anything big, but do not be afraid to check it out.

chasil• 1 year ago

I would imagine that ARM1 would be more approachable than just about anything else.

I understand that there were only 14 different instructions in the original design.

"The 386 has about 140 different instructions, compared to a couple dozen in the ARM1 (depending how you count)."

https://www.righto.com/2015/12/reverse-engineering-arm1-ance...

pjmlp5• 1 year ago

Thankfully Intel syntax.

Cockbrand• 1 year ago

Now I'm curious - what other syntaxes are there?

jabr• 1 year ago

AT&T

* https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm

* https://en.wikipedia.org/wiki/X86_assembly_language

pjmlp5• 1 year ago

The other one, is a clunky one from UNIX world point of view on x86 CPUs, follow the links on the sibling comment.

Rather clunky and most UNIX Assemblers were never as powerfull as other systems macro assemblers, since after UNIX System V, it was there only as an additional external tool pass for the C compilation steps, and even before that, the assembler was quite minimalist.

Then there is the whole brain twist of being used to op dest, src, and having to switch into op src, dest.

I prefer the Intel approach as it is more similar to dest = src, rather than src -> dest.

Intel's approach is also more common across various assembly languages.

vivzkestrel• 1 year ago

Spectacular post, are you planning to add sections on reverse engineering executables because this definitely looks pretty close

nice_byte4• 1 year ago

(i am the author) not to this series, but the very first post on the blog is an example of a simple reverse-engineering exercise: https://gpfault.net/posts/ripping-sprites-from-super-cyborg....

nayuki• 1 year ago

I wrote one: https://www.nayuki.io/page/a-fundamental-introduction-to-x86...

Centrino• 1 year ago

Please provide a PDF version or make your page printable. Even when clicking your ad bar/banner down, a "print to PDF" in Chrome renders a crippled view with parts of the text covered, because of the remains of that ad bar/banner.

masfuerte• 1 year ago

The print version is quite nice in Firefox with JS disabled.

Cheyana• 1 year ago

Really nice. Love the format, thanks!

shikaan2• 1 year ago

Something similar, but you can play with the examples in the browser without any local setup https://shikaan.github.io/assembly/x86/guide/2024/09/08/x86-...

For full disclosure, I am the author - apologies for the shameless plug

LtdJorge• 1 year ago

It's cool. Do you sanitize the untrusted input? As far as I can see, it directly assembles with NASM and runs the binary.

tialaramex• 1 year ago

It might be similar to Matt Godbolt's experience with his "Compiler Explorer". Most of your users are not trying to set fire to the free system, and when somebody does, on purpose or by accident, you focus on being able to reliably recover, not prevent it. So e.g. maybe Clara T Vandal "cleverly" seizes control of a random Compiler Explorer build box, well, that box is no longer marked OK because of her changes, it gets automatically torn down and replaced, no real problem. Did Clara do 0.001¢ of Bitcoin creation without paying for it? Yeah, maybe, and Clara probably cost Matt 0.1 cents for the data centre fees but it's not a big deal.

norskeld• 1 year ago

Looking at the source code of the code-editor [1], it seems to be embedding https://onecompiler.com via the iframe and delegating code compilation and execution to it. So I guess it's a question to onecompiler, whether they sanitize input or not. :)

[1] https://github.com/shikaan/shikaan.github.io/blob/main/_incl...

90s_dev4• 1 year ago

Thanks, I'll be using this.

What I don't understand is why assembly feels so hard to learn in the first place?

I mean, isn't it just a simple language with a few function calls (instructions) and types (operand sizes) and fixed number of variables (registers) and a small number of control flow operators, and that's it? Why does it feel so mysterious?

breckinloggins3• 1 year ago

I can think of several reasons:

1. You are primed to think that it is mysterious because that’s all you usually hear about assembly. (“Roller Coaster Tycoon was written in 100% hand crafted assembly… what an absolute wizard!!”)

2. The language’s textual format is odd - columns vs nested indentation. Actually really nice once you get used to it, but it’s definitely alien at first.

3. Mnemonics and directives have short, cryptic spellings. x86 in particular has arbitrary looking register names as well. RV, AArch64, m68k etc do better here.

4. Mnemonics are inconsistently overloaded and encode lots of stuff. SIMD instructions tend to look like a cat sat on your keyboard.

5. Manually laying out memory is technically simpler than the abstractions provided by higher level languages (structs and classes, fancy generic types, pointer syntax), but it’s fiddly and you have to deal with alignment.

6. You have to do a lot of bookkeeping yourself. It’s like malloc/free turned to 11.

7. Register allocation is a hard problem for computers. It’s kinda tough for humans, too.

8. Lots of books and online stuff discuss assembly for use with high performance code, tight compute kernels, raw hardware access, and fiddly CPU configuration for OS startup and virtual memory configuration. This requires even more specialized registers, arcane instructions, and bit fiddling. This stuff - along with reverse engineering and security research/attacks - gets lumped into what people think of as “assembly language”. The resulting concept surface therefore looks much larger than it actually is.

I highly recommend making a non-trivial program entirely in assembly at least once. I need to do it occasionally professionally but even when I don’t I usually have a hobby project or two cooking at home.

Becoming as proficient in asm as - say - C or Python is quite the lovely expression of craft. You feel like a wizard (see point 1) while simultaneously learning what’s really going on.

For people with a certain geeky disposition it pays lots of aesthetic, psychological, and professional dividends.

duped• 1 year ago

Simple languages are not necessarily easy languages to understand. See: brainfuck, APL, K, etc.

I think the problem with assemblers in particular is that the canonical definition is the byte code, not the human readable text. x86 is particularly annoying because no one agrees on the syntax of that text, there are hundreds of mnemonics, things are constantly being updated, and the practicing assembly programmer cares deeply about the execution semantics of the microarchitecture more than the specific sequence of instructions. Some of the language is also completely foreign to higher level programmers, like instruction pipelines, uops, instruction latency, and so on.

Rarely do you sit down and write this assembler by hand, you compile some C code and poke at it with vtune/uprof to measure hot sections of the code, break those down, and implement faster versions. It's fundamentally an iterative, experimental process.

ok123456• 1 year ago

x86 assembly has many addressing schemes and a significant amount of historical baggage, even from its inception.

It's up to the compiler/programmer to handle calling conventions.

Modern programmers also don't regularly encounter "unstructured programming" in higher-level languages these days.

All of these, and more, make it feel overwhelming, as anything they examine through their disassembler will contain all of these elements.

uticus2• 1 year ago

It is simple until you need something complex - working on a team, call stack management, memory management (allocate, track, free), working on a team, event handling / non-synchronous interrupts, and working on a team.

For a little 8-bit microprocessor with program size < 8k it can be quite easy and even a joy. Anything else and your compiler will outperform you, better to inline hand-coded assembler as needed.

fracus• 1 year ago

I'd love to fool around in assembly but I can't think of anything interesting to do with it.

raccomandoo• 1 year ago

TIS-100 is a fun little game where you have a sort of pseudo-assembly and solve puzzles with it. I find it can help scratch that itch.

archievillain2• 1 year ago

I would also recommend TIS-100's "sequel", Shenzhen I/O. TIS-100 is a bit 'dry', with the puzzles being entirely abstract. In SI/O, you roleplay as a developer emigrating to China for work, so all the puzzles are framed as real products you are developing for your company. One of the earlier puzzles, for example, is programming the equipment for a lasertag place.

guenthert• 1 year ago

In embedded systems using MCUs with very little memory (AVR comes to mind) assembly might be preferred over high level languages (very generously counting C as HLL here). It might even be fun (for truly launch-and-forget projects -- don't even think about maintaining such code) to forgo structured programming and get creative with control flow and self-modifying code.

As a systems engineer it's good to know _some_ x86-64 assembly as sooner or later you're facing a stack trace / register dump and will have to try to make sense of it. Personally, I would take it only further, if you're interested in building compilers.

As an odd twist to the whole assembly vs. HLL dichotomy, sbcl is used by some as assembly playground: https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-co...

IshKebab• 1 year ago

Yeah I think the only things that really need assembly these days are vector/SIMD (e.g. writing a video codec), really low level stuff for interacting with hardware (writing an OS) or if you're actually working on CPUs (how I learnt).

It's kind of useful for understanding compiler output on godbolt, and occasionally for debugging code without debug info.

But I successfully wrote a ton of C++ for decades without knowing assembly. It's not really necessary.

praptak2• 1 year ago

FFmpeg uses assembly and they use it so extensively that they put up their own assembly tutorial: https://github.com/FFmpeg/asm-lessons

Maybe there is something to do there (I haven't checked).

wrasee• 1 year ago

I've found being able to read assembly more useful than writing it.

For those writing in compiled languages like C/C++ and particularly with an interest in performance it's been very helpful just to be able to read compiler output and see what it's generating. Takes the guesswork out of it, removing the uncertainty by simply being able to see what the compiler is actually doing. You can just write code and see the result, who knew!. It's actually helped my understanding of C++ in seeing the bigger picture.

Of course it's also much easier to learn just to read a little disassembly than actually write the stuff. I'm sure I'm not alone in that for me Compiler Explorer (https://godbolt.org) was my gateway into this. You can get quite far even if just knowing the basics (I'm no expert).

breckinloggins3• 1 year ago

Assembly is one of those things where setting your ambitions higher than is usually advised can be wise.

You could try writing a game (perhaps using Raylib) or a pixel art editor. Or maybe a little web application for your Homelab.

Simple C libraries (Raylib, libcurl, early win32 APIs) tend to be dead simple to use from assembly.

Most asm tutorials are either bare metal / OS or “we will talk directly to the kernel”, but there’s no reason you can’t interface with higher level libraries and make real apps and games. It’s simpler than it sounds because a whole lot of your code will just be moving things around between registers and memory in order to make function calls and bookkeep your program state.

wunused3• 1 year ago

The software security community has a subsection that focuses on the security of compiled binaries, where understanding assembly has many uses. These uses include binary reverse engineering and proof-of-concept exploit development to demonstrate the severity of a vulnerability.

If these do sound interesting to you, I'd recommend looking into capture the flag (CTF) competitions, and trying reverse engineering or binary exploitation (pwn) challenges. PicoCTF [1] is an entry-level platform that hosts challenges and has references to learning resources - I believe there's a sequence on assembly in the learning resources.

Aside, I also find it useful to know assembly when debugging C/C++ code, as others have suggested.

[1] https://play.picoctf.org

uticus2• 1 year ago

Microcontroller and LEDs. And maybe buttons. Keep it to 8-bit and chances are you'll be able to navigate the ISA comfortably pretty quickly.

timonoko2• 1 year ago

I had quite entertaining session with ChatGPT and recursive fibonacci in nasm. We found out that C-version was twice as fast. So no returning back to year 1975.

"Higher language version is easier to optimize, because machine gets better idea what you are aiming at." said Lex Fridman et al.

danielscrubs• 1 year ago

Ive heard this for thirty years and it is as wrong now as it was then.

Yes you need to be good at assembly (especially data oriented architecture), yes it takes forever, but that is no excuse to spew falsehoods.

timonoko2• 1 year ago

What? Did I just give you an example that it is true?

Natural language is the highest of course. We will return to assembly programming eventually, because those intermediate "highlevel" languages are not needed anymore between you and machine.

nice_byte4• 1 year ago

correct, understanding the instruction set architecture you are working with is required for reasoning about the performance of a given algorithm in detail.

you will likely not be writing a lot of assembly by hand, however steering the compiler codegen in the right direction requires an understanding of what the compiler produces.

even outside of enhancing performance, knowledge of instruction sets is instrumental for security research and reverse engineering. for some fun but practical demonstrations, see work by Nathan Baggs on YouTube - it involves staring at a lot of disassembly.

i don't know where this misguided notion that assembly language is "1975" comes from. it's not like Cobol where a few large but important systems keep it alive. this is something that lies at the core of every interaction with computers that you have daily.

pjmlp5• 1 year ago

Why 1975, when high level programming exists since 1958?

Also I should note that until early 1990's, C compilers were quite bad, that is why we wrote what would be now AAA games, in straight Assembly.

specy2• 1 year ago

Thought this was the perfect place to share a project I've been working on for a few years: https://asm-editor.specy.app

It's an interactive online IDE for many assembly languages, currently M68K, MIPS, RISC-V and X86 (I need to improve X86). It has a ton of features that are made to teach assembly programming, and it can be embedded in other websites.

Gormo• 1 year ago

No Z80 or 6502?

pjmlp5• 1 year ago

With such a domain name, it should have been Z80 :)

specy2• 1 year ago

Not yet* https://github.com/Specy/asm-editor/issues/25 And 6502 is a bit harder

pkphilip• 1 year ago

This is really cool! thank you!

fwsgonzo• 1 year ago

I tried optimizing my CPU emulator dispatch in raw assembly to see if I could run a simple fibonacci program faster than C++. And I was not even close. In the end I merged it and made it a default-disabled dispatch option, because ... there has to be a way to make it faster!

If you are daring, you can find my puny attempt here: https://github.com/libriscv/libriscv/blob/master/lib/librisc...

I did manage to improve it once I figured out some of the various modes of accessing memory, and I even managed to cut the jump table down from 64- to 32-bit which should help keep it in memory. I made the jump table part of .text in order to make it RIP-relative. For the fibonacci sequence program, not many bytecodes are needed. I would greatly appreciate some tips on what can be improved there.

nice_byte4• 1 year ago

have you tried actually comparing what you have to what the c++ compiler generates? i don't have a lot of context here but I think it's possible that the difference is less due to the dispatch mechanism (i.e. how the next instruction is fetched) but due to the implementations of the instructions themselves.

one opportunity for optimization is mapping emulated registers to real x86-64 registers and basically never spilling them to memory (so that way if you have to add you don't have to first fetch then add, but just add directly). though that makes writing the emulator a lot more annoying.

secondcoming• 1 year ago

I made the jump table part of .text in order to make it RIP-relative

Did you do this manually?

gcc changed to put jump tables in .rodata always which causes problems when .rodata is stored in ROM.

It does have the `-fno-jump-tables` option but that just disables jump tables rather than allowing you to control where they go.

ykonstant2• 1 year ago

From the profile picture I thought that was junferno for a second.

hollowonepl2• 1 year ago

I did not know that pointer indexing registers had direct low byte access, like `si/esi` (in 16/32bit when I last time used assemblers directly) that comes with `sil` as `ax/eax` analogy to `al`. Are there really opcodes for that that were added in the later evolution of x86_64? Seems I need to double check the specs of the platform again... out of plain curiosity!

kruador• 1 year ago

It wasn't possible on the 386. Ken Shirriff discusses how the Intel 80386's register file was built at https://www.righto.com/2025/05/intel-386-register-circuitry..... Only four of the registers are built to allow 32-, 16- or 8-bit writes. Reads output the entire register onto the bus and the ALU does the appropriate masking. The twist is for the legacy 16-bit upper half-registers - themselves really a legacy of the 8080, and the requirement to be able to directly translate 8080 code opcode-for-opcode. The output of these has to be shifted down 8 bits to be in the right place for the ALU, then these bits have to be selected.

AMD seem to have decided to regularise the instruction set for 64-bit long mode, making all the registers consistently able to operate as 64-bit, 32-bit, 16-bit, and 8-bit, using the lowest bits of each register. This only occurs if using a REX prefix, usually to select one of the 8 additional architectural registers added for 64-bit mode. To achieve this, the bits that are used to select the 'high' part of the legacy 8086 registers in 32- or 16-bit code (and when not using the REX prefix) are used instead to select the lowest 8 bits of the index and pointer registers.

From the "Intel 64 and IA-32 Architectures Software Developer's Manual":

"In 64-bit mode, there are limitations on accessing byte registers. An instruction cannot reference legacy high-bytes (for example: AH, BH, CH, DH) and one of the new byte registers at the same time (for example: the low byte of the RAX register). However, instructions may reference legacy low-bytes (for example: AL, BL, CL, or DL) and new byte registers at the same time (for example: the low byte of the R8 register, or RBP). The architecture enforces this limitation by changing high-byte references (AH, BH, CH, DH) to low byte references (BPL, SPL, DIL, SIL: the low 8 bits for RBP, RSP, RDI, and RSI) for instructions using a REX prefix."

In 64-bit code there is very little reason at all to be using bits 15:8 of a longer register.

This possibly puts another spin on Intel's desire to remove legacy 16- and 32-bit support (termed 'X86S'). It would remove the need to support AH, BH, CH and DH - and therefore some of the complex wiring from the register file to support the shifting. If that's what it currently does.

Actually, looking at Agner Fog's optimisation tables (https://www.agner.org/optimize/instruction_tables.pdf) it appears there is significant extra latency in using AH/BH/CH/DH, which suggests to me that the processor actually implements shifting into and out of the high byte using extra micro-ops.

aleph_minus_one2• 1 year ago

In 64-bit code there is very little reason at all to be using bits 15:8 of a longer register.

I disagree: there only exists BSWAP r32 (and by 64 extension BSWAP r64): https://www.felixcloutier.com/x86/bswap

No BSWAP r16 exists. Why? in 32 bit mode, it was not needed, because you could simply use

XCHG r/m8, r8

with, say, cl and ch (to swap the endianness of cx).

In 64 bit mode, you can thus only the endianness of a 16 bit value for the "old" registers ax, cx, dx, bx using one instruction. If you want to swap the 16 bit part of one of the "new" registers, you add least have to do a 32 bit (logical) right shift (SHL) after a BSWAP r32 (EDIT: jstarks pointed out that you could also use ROL r/m16, 8 to do this in one instruction on x86-64). By the way: this solution has a pitfall over BSWAP: BSWAP preserves the flags register, while SHL does not.

hollowonepl2• 12 months ago

In the meantime I also read somewhere that this feature is only available in the long mode

anthk• 1 year ago

I remember a book on amd64 assembly which used GNU/Linux and NASM as the base. It has exercises to follow your progress:

http://www.egr.unlv.edu/~ed/assembly64.pdf

angelmm• 1 year ago

This is the kind of introduction I was looking for! I'm currently learning a bit more about this instruction set, so that's perfect.

Also, there are so many great resources in the comments.

johnisgood• 1 year ago

For FASM, I really like https://flatassembler.net/docs.php?article=manual.

There are a couple of great books out there as well that I have used. I cannot recall their names right now. :(

Run_DOS_Run• 1 year ago

Great opportunity to share an older project:

https://www.AssemblyArena.com - an educational game for people who would like to learn and/or program in assembly.

It's a (non mobile-optimized) web-based PvP assembly programming game. The syntax is highly inspired by x86 assembly and the game itself by Core War. There is also a small tutorial and a ranked ladder powered by Glicko-2.

Source Code:

https://github.com/m2w4/assembly-arena

elzbardico2• 1 year ago

This article made me realize that, at my home, out of 7 full-fledged computers, that is, notebooks, servers or desktops, there's not a single X86 machine. Maybe there are a couple old dell notebooks somewhere in the garage, but I am not even sure they still boot.

kevstev2• 1 year ago

The silent and really unheralded disappearance of Wintel from my home surprised me a few weeks ago as well. It wasn't a conscious decision, they just got slowly replaced by macbooks, and an ARM based NAS... etc. Kind of like how I also realized I no longer have an optical disc reader... despite still having spindles of very old stuff.

elzbardico2• 1 year ago

And this is kind of sad in the context of this post. Because I have always wanted to dive deeper into assembly, and there are loads of material to study X86 assembly out there.

But being able to run it only in a virtual machine, it is a little bit demotivating.

Well, there are some chinese folks selling newly built PC-XT compatible machines on the internet. Maybe I could go this way. And probably, pure, original 8086 assembly is a lot more fun than overly complicated X86_64 with lots of extensions.

Let's Learn x86-64 Assembly (2020)

Related Stories