Name: ARM architecture reference manual
ISBN: 9780201737196

What Hacker News says

imtomtMay 2026

Honestly, just reading existing assembly to get a feel for how it works, and then violently googling everything that goes wrong. The ARM Architecture Reference Manual (aka "The ARM ARM") ended up being really helpful for looking up what specific instructions do and how they're called. Another really helpful tool is writing something in C/C++, and compiling with "gcc -O1 -S file.c" to see the assembly gcc generated. It helps to mess around a lot with smaller programs in gdb or lldb.

thread

pan69Apr 2010

OK. These are the two books you need when you start out programming for ARM chips:

ARM System-on-Chip Architecture (2nd Edition) By Steve Furber (the guy who designed the bloody chip!) http://www.amazon.com/ARM-System-Chip-Architecture-2nd/dp/02...

ARM Architecture Reference Manual (2nd Edition) By David Seal http://www.amazon.com/ARM-Architecture-Reference-Manual-2nd/...

thread

topspinApr 2026

Looks as though ARM is doing ASL for Armv8-M.

"For example, the ASL code published through the A-Profile Arm Architecture Reference Manual, Exploration Tools downloads for A-Profile, or the Armv8-M Architecture Reference Manual."

https://developer.arm.com/architectures/architecture%20speci...

thread

kragenJul 2024

if you want to understand chip architectures, work through the elements of computing systems (aka nand to tetris). it walks you through implementing your own cpu, gate by gate, plus an operating system, compiler, and tetris game, in a way tested to successfully fit inside of a single-semester undergraduate class. their hardware designs are pretty weird (their hdl looks nothing like any hdl you can actually synthesize hardware from, their descriptions of how gates work are oversimplified, and their instruction set architecture is pretty similar to the eclipse that kidder was writing about but completely unlike any current design) but that isn't really important

after completing the work in that book and raising investment capital for your company, you can honestly call yourself a fullstack engineer

— arm —

the best architecture to write assembly for is the arm—the original one, not thumb, which is a bit of a pain—and arm is also only slightly more complex to build than the fake-ass architecture in nand2tetris, and quite a bit faster. if you already know any assembly language, including the nand2tetris one, the best introduction to arm might not actually be any current tutorial but rather the vlsi arm3 datasheet from 01990 https://www.chiark.greenend.org.uk/~theom/riscos/docs/ARM3-d... which has a summary of the instruction set on p.1-7 (9/56) and a fully complete description on pp.3-12 to 3-43 (19/56 to 34/56)

as you probably know, the vast majority of the cpus around you run the arm instruction set or its thumb variant, although amd64 and aarch64 (arm64) are also significant. the current arm architecture reference manual describes all the new instructions that have been added since arm3, as well as thumb, which makes it enormous and intimidating, with a very low signal-to-noise ratio

if you don't know any assembly, the three best actual tutorials for arm that i've found are https://www.coranac.com/tonc/text/asm.htm (aimed at the gameboy advance), https://devblogs.microsoft.com/oldnewthing/20210531-00/?p=10... (aimed at windows 10, thumb-only), and https://azeria-labs.com/writing-arm-assembly-part-1/ (aimed at crackers). these are all much longer than the relevant part of the arm3 datasheet but will guide you through how to actually use the things

— teensy programs —

perhaps the best introduction to writing assembly language in general on current systems is https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht..., which is not really focused on assembly at all, but on understanding how the interface between the operating system (i386 linux in this case) and user programs work, which just happens to be at the assembly-language level

it's also a lot more fun to read than any of these except maybe kidder and levy

— risc-v —

the risc-v architecture is very similar to arm but simpler; however, it's a little more of a pain to program, and there aren't any high-performance implementations of it out there, something that's likely to change in the next few years. the part of the risc-v manual https://riscv.org/wp-content/uploads/2019/12/riscv-spec-2019... that corresponds to the part of the arm3 manual i recommended above is chapter 2, rv32i base integer instruction set, pp.13–29. this reflects an additional 30 years of computer architecture lessons from arm and its successors, and a lot of those lessons are helpfully explained in the italic notes in the text. geohot livecoded a full implementation of risc-v in verilog on his twitch stream a few years ago, so you can literally implement risc-v in an afternoon: https://github.com/geohot/twitchcore

gcc can compile to risc-v and generates decent code, and linux can run on it, but the risc-v that linux runs on is quite a bit hairier to implement than the rv32i isa; you have to implement the risc-v privileged isa

— if what you're interested in is how varied cpu architectures can be —

probably risc-v and arm won't do it for you

the nand2tetris 'hack' is pretty weird, and very similar not only to the dirty genitals nova, but also to chuck thacker's 'tiny computer for teaching' https://www.cl.cam.ac.uk/teaching/1112/ECAD+Arch/files/Thack... which is two pages of vhdl

weird in a different direction is the tera mta, which has 128 hardware threads and context-switches every clock cycle; the 11¢ padauk pmc251 microcontroller does the same thing (but with only two threads; padauk sells parts with up to four threads)

the tera mta was designed to compete in the vector supercomputer field originally defined by the cray-1, which had a very different architecture; the convex https://news.ycombinator.com/item?id=40979684 was very similar to the cray-1

in a sense, though, the cray wasn't really the first supercomputer; the cdc 6600, also designed by seymour cray, was, and it was arguably the first risc, in 01964

unlike all of these, the burroughs 5500 architecture had no registers, just a stack, and that's what smalltalk, java, and c# are based on

the 12-bit pdp-8 was the first really mass-produced computer, with over 50000 units sold, and its architecture is interestingly different from all of these, too; intersil produced a 4000-gate single-chip version, and the family was popular enough that there are pdp-8 hobbyists even today

most current numerical computation is being done on gpus, and i don't know what to recommend as reading material on gpus, which have bizarrely different instruction set architectures that use a model called 'simt', single instruction, multiple thread. if anyone does, let me know

finally, chuck moore's line of two-stack processors based on forth are a sadly underdeveloped branch of the genealogical tree; koopman's stack computers: the new wave https://users.ece.cmu.edu/~koopman/stack_computers/index.htm... goes into their historical development a bit. they had some significant success in the 80s (the novix nc4000 and the harris rtx2000) but the later members of the family (the sh-boom, the mup21, the stillborn f21, the intellasys seaforth 40c18, and the greenarrays ga4 and ga144 chips) have no real users, in part due to malfeasance—after losing a protracted lawsuit with moore, intellasys head dan leckrone now goes by 'mac leckrone', perhaps as a result

there are lots of other interestingly different instruction set architectures out there: s/360, 6502, amd64, pic16, the erim cytocomputer, the thinking machines cm4, the em-4 dataflow machine, the maxim maxq, the as/400, webassembly, vulkan spir-v, the hp 9825 desk calculator, saturn (used in the hp 48gx), etc.

i hope this is helpful!

thread

gpmJun 2024

Qualcomm's case goes beyond "we have a valid license agreement" as to the destruction of Nuvia's design. They're arguing that they do have a valid license agreement, but also that even if they didn't they would still be the lawful owners of the IP and would not be required to destroy it. They might not be able to use it, but they could hold onto it, because nothing in Nuvia's contract with ARM requires it be destroyed by Nuvia.

> 5. Even putting aside Qualcomm’s broad license rights, ARM’s reading of the termination obligations in the NUVIA Architecture License Agreement (“ALA”) is wrong. To the extent any destruction obligation exists, it explicitly applies only to ARM Confidential Information.1 But ARM again omits important facts: (1) under the NUVIA ALA, information in the public domain is not subject to confidentiality obligations, and (2) ARM publishes its instruction set without confidentiality restrictions. Anyone is free to go to the ARM website and download the 10,000+ page ARM Architecture Reference Manual.2 In this case, Qualcomm’s CPU cores are designed to be compatible with the publicly-available ARM Architecture version <redacted>.

> 36. Moreover, even though ARM demanded destruction of Confidential Information obtained under NUVIA’s ALA, NUVIA had implemented ARM Architecture <redacted>, which had been publicly available on ARM’s website for anyone to download since at least around January 2021—over a year before the destruction request. <Redacted sentence>. Therefore, ARM Architecture was not Confidential Information, not subject to any restrictions, and not subject to any destruction obligation. For the same reasons, the NUVIA core design did not contain ARM Confidential Information.

...

> It's also quite a visible move just to delay the proceedings.

I really don't agree. It looks like a bog standard discovery dispute.

(cites are paragraph numbers in https://storage.courtlistener.com/recap/gov.uscourts.ded.798...)

thread

gchadwickOct 2023

My RISC-V experience is all based around the low-end (no MMUs, hypervisors, indeed mostly no caches) so it's hard for me to give a full informed comparison but my feeling is the Arm ISA is better specified and RISC-V won't necessarily be a simpler architecture in the end anyway. There is an explosion of extensions in RISC-V right now, lots of tiny ones along with some bigger ones. Whilst the size of the ISA manual between the two is often highlighted (the Arm architecture reference manual is almost 13'000 pages in the PDF I just downloaded) those pages are there for reason. It's no surprise now there are multiple well-funded startups trying to build high end RISC-V cores that there's also a massive push to add a lot more stuff to the RISC-V architecture.

My feeling, as it's a bunch of different companies all with a commercial pressure to get things shipped, is we'll end up in a rather chaotic place with the RISC-V ISA, though hopefully that can be improved with time.

I do get frustrated with the loose specification of the RISC-V ISA. The Arm ARM for instance has a precise description of its exception model (see section D1.3 'Exceptions') the RISC-V ISA in contrast never explicitly defines what an exception is and to find out what the exception model is you need to read through the definitions of a few system CSRs (control and status registers) and join the dots yourself. It's seemingly written with the idea that everyone knows what an exception is in the context of computer architecture so no need to give a long formal definition, plus everyone will agree on what the 'obvious' right answer is where the spec isn't precise. However the devil, as ever, is in the details and the details are often lacking.

I also note there's no complete RISC-V conformance test suite and indeed even building such a thing could be intractable look at PMP, physical memory protection, you could do all kinds of odd implementations of this that would be spec compliant (e.g. only region 12 is allowed to have execute permissions set and cannot be read/write/execute) but would be a total nightmare to support in a conformance test suite. So such a suite, when it does hopefully emerge, will actually only conform compliance with a subset of compliant CPUs. There are some obvious stupid design decisions it's reasonable to rule out but I'm sure there will be some other less clear cut things where the spec allows multiple behaviours, the compliance suite will only work with one or two and they'll be some shipping implementation which went with another one. People will either spend lots of time arguing about how the compliance suite should work, or just ignore it altogether. A lot of these difficulties stem from the loose specification of RISC-V.

thread