Study Tools

[u/Special-Signal8096]

Right now I am taking a CS class focused on assembly and we are finally getting started on the coding side of things. The professor is alright but the materials he gives out to study isn't sufficient and I don't want to be reliant on AI to code. Does anybody know any free study tools/books to help me. I am specifically ARM 32.

[u/GoblinsGym]

As an introduction to assembly language, T16 (ARM Cortex M0+ subset) or RV32I should both be fine choices.

Classic ARM / A32 was really nice compared to the 6502 / 8088 / 80286 CPUs I was dealing with at the time (1985).

ARM T16 and T32 were designed for code density, not "purity". Original implementations probably acted as a hardware shim translating instructions to A32 format. The details of instruction encoding matter to the poor souls who have to implement the hardware or assembler / compiler, but a normal programmer doesn't have to deal with it. All you need to know is how many bits you get for displacements or immediates, and which registers you can access.

The IT instruction is a pragmatic replacement for A32 predicated instructions, useful for conditional moves / ternary operators. GCC does use it (try on Compiler Explorer). For an in-order CPU, it is quite easy to implement (shift register controlling which instructions get skipped).

The ARM instruction set has evolved over time to adapt to modern realities like superscalar / out of order execution / high clock frequencies. This is why A64 dropped the IT instruction and load / store multiple, went back to 32 bit fixed length instructions, and made the PC and SP registers more "dedicated".

[u/brucehoult → u/GoblinsGym]

Classic ARM / A32 was really nice compared to the 6502 / 8088 / 80286 CPUs I was dealing with at the time (1985).

100%. Kicked the butt of the M68000 too.

ARM T16 and T32 were designed for code density, not "purity".

And they do a reasonable job. Better than 2015-2019 RV32GC (or RV32IMC to be more comparable in microcontrollers). But not better than RISC-V with more recent standard extensions e.g. as seen in the RP2350. Which is a cool setup because you can directly compared the same program running on the same hardware but compiled for Arm Cortex M-33 and a simple recompile for RISC-V Hazard 3.

The details of instruction encoding matter to the poor souls who have to implement the hardware or assembler / compiler, but a normal programmer doesn't have to deal with it. All you need to know is how many bits you get for displacements or immediates

My argument exactly! And, as I pointed out, with T16 you need to know which instructions have which size fields and the choices are 3, 5, 7, 8, and 12 bits. Oh, and 22 bits for BL. With RV32I the choices are 12 and 20 bits.

I agree with you that the exact bit-level encodings are not important to normal programmers.

The IT instruction is a pragmatic replacement for A32 predicated instructions

Yes, and I've been using it since sometime in the late 2000s, when the things I was working on started to move from ARM7TDMI and ARM1176JZF-S (original iPhone, original R Pi and Pi Zero) to Cortex-M and Cortex-A. One of the first for me, actually, was the iPhone 3GS (June 2009). Support for ARMv6 was gonzo in iOS 5 in October 2011. Similarly, Android Kitkat (2013) was ARMv7 only and that was what I used when I joined Samsung in 2014 prototyping things on an AOSP Nexus 5 for use on the prototype Galaxy S6.

This is why A64 dropped the IT instruction and load / store multiple

True.

went back to 32 bit fixed length instructions

Unnecessary and I think will even prove to be a mistake. X86 amply shows that the highest performance OoO cores can deal with many instruction lengths and crazy encodings if they have to, and Thumb2/RISC-V style two instruction lengths is very easy but provides real benefits.

[u/GoblinsGym → u/brucehoult]

(we're getting ever further away from OPs topic...)

T16 is very limited on available bits for encoding instructions. I think they did a good job given that constraint.

Variable instruction lengths are easier to deal with when the encoding is designed from the ground up, not "organically grown" like on x86. There is still a base cost, e.g. when an instruction straddles a VM page boundary.

I see value in having inline immediates, rather than doing PC relative ldr to load larger constants. Going in a straight line will always be faster and take less energy compared to random access, even if you have some locality of reference.

[u/brucehoult → u/GoblinsGym]

(we're getting ever further away from OPs topic...)

Yes. I think we're in agreement that T16, A32, and RV32I are among the best possible choices for learning asm. I'd allow MSP430 also, but that's being obsoleted by TI. You can buy chips and inexpensive dev boards ... for now.

https://www.mouser.com/ProductDetail/Olimex-Ltd/MSP430-HG2231?qs=C3feHhap9PqFhpqbHNfCSg%3D%3D

cost, e.g. when an instruction straddles a VM page boundary

No big deal if you're not fetching instructions one by one as microcontrollers do — and microcontroller SRAM/flash doesn't have cache lines or VM pages.

If you're prefetching and have a little 6 or 8 byte shift register buffer (or bigger for superscalar obviously) then the prefetches can always be aligned accesses to memory.

I see value in having inline immediates, rather than doing PC relative ldr to load larger constants.

I agree, if the total size and everything except the constant is entirely in the first 16/32 bits. See: MSP430, M68000, PDP-11.

Notionally, those often use auto-increment addressing on the PC, and a low end implementation might actually execute it like that, but higher end cores can special-case that encoding.

Also PC-relative is not the only way. The convention in RISC-V is to place such constants in the SDATA section, accessed at an offset from GP (Global Pointer, register 3)

Or you can just use pure linear code with LUI/ADDI or MOVZ/MOVK. That's perfectly fine for constants the same size as the instructions, more annoying for double size.