[HN Gopher] Let's Learn x86-64 Assembly (2020)
___________________________________________________________________
Let's Learn x86-64 Assembly (2020)
Author : 90s_dev
Score : 390 points
Date : 2025-07-13 22:22 UTC (1 days ago)
(HTM) web link (gpfault.net)
(TXT) w3m dump (gpfault.net)
| 90s_dev wrote:
| 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 wrote:
| 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 wrote:
| 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_dev wrote:
| 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 wrote:
| 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.
| throwaway31131 wrote:
| I'm not sure how "useful" or "good" the work is. But some
| one instruction computers have a considerable amount of
| tooling already in place.
|
| i.e. https://esolangs.org/wiki/FlipJump
|
| Flip Jump is amazing. I understand the theory and how it
| works but it still amazes me that it does. Things like this
| is why I love the science in computer science.
|
| And subleq even has a c-compiler and operating system, just
| wow. https://en.wikipedia.org/wiki/One-
| instruction_set_computer#S...
| spauldo wrote:
| 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.
| throwaway31131 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| breckinloggins wrote:
| 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 wrote:
| 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 wrote:
| I think AsmGrid has a great overview of X86 and AArch64
| instructions: - https://asmjit.com/asmgrid/
| electroglyph wrote:
| wow, that's great. thanks for sharing!
| __alexander wrote:
| I haven't seen this site before. Thanks for sharing it.
| rfl890 wrote:
| Felix Cloutier's page has always been my go-to
| cylinder714 wrote:
| https://www.felixcloutier.com/x86/
| mananaysiempre wrote:
| For x86 encodings, there's also
| http://ref.x86asm.net/index.html and of course the venerable
| https://sandpile.org/.
| gnabgib wrote:
| (2020) Discussion at the time (180 points, 38 comments)
| https://news.ycombinator.com/item?id=24195627
| nice_byte wrote:
| 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_dev wrote:
| Please do!
| pm2222 wrote:
| >> 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 wrote:
| Those would be the lower 8 bits, no?
| pm2222 wrote:
| ax=ah:al eax=?:ax rax=?:eax
| grg0 wrote:
| 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
| wunused wrote:
| 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 wrote:
| 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.
| wunused wrote:
| 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 wrote:
| 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 wrote:
| AArch64/Arm64 assembly:
|
| https://mariokartwii.com/armv8/ch11.html
| urda wrote:
| 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 wrote:
| 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...
| pjmlp wrote:
| Thankfully Intel syntax.
| Cockbrand wrote:
| Now I'm curious - what other syntaxes are there?
| jabr wrote:
| AT&T
|
| *
| https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm
|
| * https://en.wikipedia.org/wiki/X86_assembly_language
| pjmlp wrote:
| 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.
| ykonstant wrote:
| I think the schizophrenic notation 12(%ebp) is much worse
| than the dest/src switch.
| pjmlp wrote:
| Yes, that is the cherry on top, maybe.
| derdi wrote:
| dest/src order is not a big deal in absolute terms: The
| ISA designer picks an order, documents it, everyone
| follows their documentation, done. Intel picks one order
| for programming Intel, DEC picks another order for
| programming the VAX? Great, just look in the instruction
| set manual and you're set.
|
| The silly thing is importing one order to another
| architecture that uses the opposite order. Now your users
| have to transpose operands for no reason. The really
| silly thing is messing up the operand order of the cmp
| instruction in the process. The VAX assembly language had
| a compare with the sane operand order, BTW.
| vivzkestrel wrote:
| Spectacular post, are you planning to add sections on reverse
| engineering executables because this definitely looks pretty
| close
| nice_byte wrote:
| (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 wrote:
| I wrote one: https://www.nayuki.io/page/a-fundamental-
| introduction-to-x86...
| Centrino wrote:
| 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 wrote:
| The print version is quite nice in Firefox with JS disabled.
| Cheyana wrote:
| Really nice. Love the format, thanks!
| shikaan wrote:
| 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 wrote:
| 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 wrote:
| 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.001C/ 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 wrote:
| 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...
| shikaan wrote:
| Exactly this.
|
| I have been planning on trying to glue up something with
| v86[1] as I did in OSle[2] but I did not get to it yet.
|
| In that case, everything would run locally and sandboxes,
| so you would not have to care.
|
| [1]: https://github.com/copy/v86
|
| [2]: https://github.com/shikaan/osle
| 90s_dev wrote:
| 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?
| breckinloggins wrote:
| 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 wrote:
| 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 wrote:
| 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.
| uticus wrote:
| 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 wrote:
| I'd love to fool around in assembly but I can't think of anything
| interesting to do with it.
| raccomandoo wrote:
| 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.
| archievillain wrote:
| 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.
| blashyrk wrote:
| I second the Shenzhen I/O recommendation, because apart
| from only assembly programming, the game also has other
| constraints in the form of having to spacially arange
| various chips on a limited "enclosure" for the product
| you're building and connect them. It also rewards
| optimization both in terms of assembly and chip usage
| efficiency. Is a wonderful game, really.
| praptak wrote:
| It also has a really cool solitaire game-in-game as an...
| addition? Ornament?
| archievillain wrote:
| I will reveal that I have played far more of Shenzhen
| solitaire than Shenzhen I/O itself. Zachtronics made a
| stand-alone version of the game[1], but there's also a
| fanmade version here:
|
| https://shenzhen-solitaire.tgratzer.com/
|
| Which I find more enjoyable, both because it's online so
| it's easier to reach from anywhere, and also because I
| feel like the version of the solitaire inside the game is
| a bit... heavy feeling. Like there's some sort of input
| delay? Anyhow, I must have around 3000 completed games of
| solitaire across my devices.
|
| [1]https://store.steampowered.com/app/570490/SHENZHEN_SOL
| ITAIRE...
| guenthert wrote:
| 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 wrote:
| 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.
| praptak wrote:
| 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 wrote:
| 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).
| breckinloggins wrote:
| 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.
| wunused wrote:
| 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
| uticus wrote:
| 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.
| timonoko wrote:
| 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 wrote:
| 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.
| timonoko wrote:
| 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_byte wrote:
| 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.
| pjmlp wrote:
| 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.
| specy wrote:
| 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 wrote:
| No Z80 or 6502?
| pjmlp wrote:
| With such a domain name, it should have been Z80 :)
| specy wrote:
| Not yet* https://github.com/Specy/asm-editor/issues/25 And
| 6502 is a bit harder
| fwsgonzo wrote:
| 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_byte wrote:
| 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 wrote:
| > 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.
| ykonstant wrote:
| From the profile picture I thought that was junferno for a
| second.
| hollowonepl wrote:
| 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 wrote:
| 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_one wrote:
| > 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.
| jstarks wrote:
| What about ROL r/m16, 8?
| aleph_minus_one wrote:
| This would indeed work (and is likely the better
| solution), but in opposite to BSWAP and XCHG, it also
| changes flags.
| anthk wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| elzbardico wrote:
| 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.
| kevstev wrote:
| 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.
| elzbardico wrote:
| 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.
| emeraldd wrote:
| There's always arm assembly. It's a differen ISA of course,
| but a lot of the concepts transfer pretty nicely. You could
| also look at something like the Zimaboard or similar
| machines.
| gtirloni wrote:
| If you just want to learn for the fun of it, check out
| RISC-V instead. It might give you that early days feeling.
| kevstev wrote:
| I found using qemu to be quite simple and pretty decent. I
| guess it depends on what you are looking to do- really low
| level bootloader/OS type stuff or actually explore the
| instruction set and maybe build something useful. Learning
| about the BIOS interface was actually quite enlightening,
| but in general ARM and RISC-V is much less complex.
___________________________________________________________________
(page generated 2025-07-14 23:02 UTC)