Hacker News Reader

Comment by kragen | Hacker News Reader

367-page cc-by-nc-sa textbook; though the license permits modification, no source format seems to be provided, just a pdf. it covers mostly introductory userland programming, though there's a chapter on interrupt handling. on skimming the table of contents i don't see anything about page tables, tlbs, atomics, the amd64 memory consistency model, running before sdram is enabled, iommus, mtrrs, or simd. none of those things are necessary to write a compiler or debug most compiled code, except maybe simd

this book also looks like it could be a very solid base for a course that did cover one or more of those additional topics; the course would also include some supplementary material

it probably teaches more than everything i know about amd64 assembly, except the most important thing, which is that arm assembly is much better

View on HN

I'm sure many architectures are nicer than amd64, but that's what the CPU in my laptop uses, as well as my Steam Deck. If I want to get into low-level hacking it's easiest to start with the hardware I have, no?

yup, no use looking for your keys in the rose garden if you know you dropped them in the sewer

This was the thinking behind my https://github.com/akkartik/mu

While in general Arm assembly is much better, there are various niche applications, like computations with big numbers, where Arm still lacks some of the instructions included in the AMD64 ISA, which make the latter much more convenient for those special applications.

Might you know where the topics you listed out are covered?

i don't, sorry

Or RISC-V for that matter.

(while being an order of magnitude simpler)

Yep, RISC-V is supposed to become an heaven for assembly written programs as it is an ISA standard, namely it will "work" on CPUs from many vendors.

The main pitfall while writing assembly is the abuse of a preprocessor. Being dependent on the grotesquely and absurdely complex and massive compilers out there is one thing, but moving that dependency to a complex preprocessor is not that much better. So caution and care about that issue must be kept in mind.

I wish all RISC-V CPU vendors to pay the silicium real estate price for 64bits because writting once a 64bits RISC-V code and to be able to "run-ish" it everywhere, from "embeded" to servers passing thru workstation, wow.

I am writting currently x86_64 assembly, namely the manual "register-ization" of some code paths is done, ready for an easy RISC-V port. Not to mention RISC-V has double the amount of registers, and some code paths will really benefits from this additional register space (intel plans to follow that route).

Ofc, this will be mostly micro-arch agnostic assembly code, as it is the case already for x86_64, with maybe simple or very generic static "optimizations" (cache line, alignment, registerization, leveraging some instruction fusions, etc). Worst case scenario, adapted (not rewritten from scratch) assembly written code paths to fit better on a micro-arch with a runtime switch/installation... if really needed. I guess correct code will become very important, maybe more than fast code ("should" become true for hardware design too, if the performance penalty is not too high).

RISC-V will need compiler support though, that for legacy support, and sometimes, humanization of the assembly output of some compiled programs may be usefull.

All that depends on the success or not of RISC-V, which for that will need ultra-performant implementations all over the board, micro-archs and best silicium process.

RISC-V is not perfect, but a more than good enough modern ISA, and the real risk of fragmentation is 32bits/64bits code paths even though some care was provided to make 32bits<->64bits code adapation easy.

Mistakes will be made (micro-arch with critical bugs), so it won't happen overnight.

dunno, maybe? ch32v003 is rv32e, so rv64 seems out of the question. more likely than supporting rv64 on ch32v003 and its successors would be supporting an rv32i mode on rv64 processors, which only costs a few gates. or, for write-once-runnish-anywhere, as/400-style/android-style compilation to native code at installation time, or nvidia-style compilation to native code at load time, or transmeta-style/qemu-style compilation to native code at i$-miss time

the preprocessor thing depends on what it is that bothers you about the grotesque compilers. a macro preprocessor can be pretty small; gpm (basically unix m6) was reputedly 250 machine instructions

historically 'worse is better' and 'the innovator's dilemma' suggest that adoption of an innovation like risc-v depends more on conquering the low end of the market long before the high end. but then there's the tesla roadster...

risc-v is nicer than amd64, but in between ldm/stm, shifted indexing, postincrement/preincrement, and conditional instructions, arm assembly is just about c

shame about the t bit tho

Reply on news.ycombinator.com