The historical reason for this is that ARM32 was directly modeled after the 6502, which in turn was based on the 6800, as was the 6809.
The conditional branch instructions (and set of flags) for all of these are from the PDP-11.
ARM64 and RISC-V I would agree are very different beasts. One of the key differences I feel, is that caching and pipelining become much more important on these systems. Most (not all) ARM32 systems have very simple and short pipelines, and no cache. E.g. Cortex-M3 and -M4.
The instruction set and overall CPU complexity, and the hardware it's running on.
In my view, playing with assembly is best done while also either playing with hardware, or really understanding and having access to said hardware at the "raw metal" level. The distinction being computation, and that's not too much different of an experience, and making things actually happen, which can be a widely different experience!
The simplicity, again in my view, of 8 bit type hardware is very helpful. It's not so large and or complex. People can understand it reasonably well, and with some degree of effort, make things happen.
Back when I was learning assembly language, it was on these kinds of systems. Sometimes the hardware played a lesser role, say a machine that has serial i/o for use with a terminal. Other times, the hardware was far more prominent, like with home computers of the time.
With the terminal, one would typically setup the hardware for serial comms, and once that was all done, basically stuff values, from a buffer, into the designated address or capture them, into a buffer, as they arrived.
On a machine with built in display, the display was typically memory mapped in some fashion. Writing to a specific address in RAM would cause a character to appear on the display screen.
It was common to have a memory map of the computer handy when writing assembly language programs. Put a number here, or set a bit there, and things would happen, like maybe click a speaker, or change the color of the screen, turn a motor on, or make a sound.
Have you looked at the 6502 hardware tutorial kits Ben Eater is doing?
(I mentioned up thread the idea of doing these with the 6809, which is tempting me badly right now...)
They are fantastic! Assembly language + hardware functionality = your program.
And this is the embedded view on things too. Having everything simple and small generally means being able to make good progress and learn a lot without it being too heavy of a lift. And depending on what your interests are, frankly you might be able to do more than you would expect.
Should your interests lie in this direction, a 6809 is an awful lot of fun to program. It's one of the best 8 bit experiences, IMHO. Be warned though! It can be an addiction, and once it starts... you may find yourself with a scope, spiffy new tools, and the need for some space to work, and, and, and! Mine has been life long, first triggered by writing a line of BASIC, pressing carriage return (enter key these days), and seeing a light bulb turn on. :D Soon after that, it was a speaker click, then a loop to make sounds, then one with parameters to make different sounds, and, and, and... There you go.
But, it's not necessary to fixate on this chip either. It's a beautiful CPU, no doubt. But others are also fun, and they have their advantages and there is a wide variety of hardware out there to program in and with.
If this kind of thing does not appeal in some way, then yes! By all means explore assembly language on something newer, bigger and faster.
Or, maybe it is, and or you don't know.
I would suggest emulation. We've got pretty great emulation for all the old machines.
Many of us, who enjoy these older CPUs, work with emulators, because we've got access to modern tools and such that make life a whole lot easier.
While there is something to be said for an authentic experience, to be frank? It's a lot of work, and kind of painful most of the time.
A good emulation smooths away a lot of pain points and "nicer" is a lot less important. Use an older CPU, newer one, freely. And you can save states and all the other good stuff that makes learning less painful and more fun and fruitful.
Right now I've got a little 6502 project in progress for an Apple //e type computer. It's being done in an emulator, and from time to time I move it all onto the real computer just to see it all go and interact with it for real, and or check it out at different clock speeds, or just show off.
But the majority of the time developing is on emulation. I can fire it up, make a little progress, or explore an idea, and then save everything for the next step later. In this way, it's easy to jump in for an hour, have some fun, and get back out again when that hour isn't costly in some way.
Probably more here than you wanted. Hope it helps.
I haven't ever really tried to dig into a lot of details on assembly with the contemporary processors though. I know there are quite a lot of extra capabilities, for example various things for efficient vector math and virtualization, but don't know a lot of details. So I was just wondering what people thought about doing assembly on the latest CPUs compared to the old ones. But I think as you point out, a lot of that depends on what hardware you are interfacing with and how and more generally the application.
I think you are right to point out that the details and capabilities of the hardware interfaces are going to make a huge difference. That is something that is attractive to me about assembly programming, especially olders systems that are designed to be interfaced with assembly, is that hardware capabilities are directly accessible and you can achieve interesting things straight away just by putting some numbers into memory.
So a few years ago I built this thing called Vintage Simulator https://vintagesimulator.com/ and one of the ideas I had was about directly accessing interesting hardware capabilities. For example, the system provides Lua scripting, and I created a way to interface with the RAM on the emulated systems. So I started working on the idea of a virtual 3d spaceship controlled by an onboard C64. I was making it so that I would put things like the elevation of the ship into memory with Lua, and then with C64 assembly I made a read out on the screen. I was planning on making so the assembly program could control the ship, with the Lua program monitoring special memory locations.
Also along those lines, I was dreaming about making a virtual 3d holographic vector display. So it could maybe monitor certain memory locations or something and then to display into the 3d environment from the emulated 8 bit computer, just write to memory. Or maybe write to some kind of output system if that made more sense.
Fun to think about.
Given this context, I have a few thoughts:
Contemporary processors may be interesting when simplified some. Your projects make me think about the Zachtronics games.
http://www.zachtronics.com/tis-100/
That is an assembly language game with surprising depth. People, who play it seriously will learn quite a lot.
Using older hardware in tandem with current is a lot of fun. The terminal, for example, still does exactly what it was designed to do and is still useful today. A C64 has a user port for this kind of thing. Apple 2 computers saw all manner of expansion cards capable of data capture, control, computation... making ones own card with a PIA was a standard type project, just as connecting a circuit to the user port was. BASIC was often enough for many basic controls, say regulating temperature, or turning things off and on based on time, or other data states, assembly language brought more of the speed possible, and with more speed, we get more posibilities.
Take one bit wired to a speaker. That is what the Apple and IBM PC shipped with to make sound. The PC had a spiffy timer to bang out notes, and the Apple had nothing but a toggle. Speaker on, or off.
Here is where the fun part was back in the day:
At first, it seems useless. Access an address and the speaker pops out. Do it again, and the speaker pops in. One can type this right into the computer with a BASIC POKE statement, or the monitor by address and watch the speaker change states.
A loop gets one some clicks rapidly, or maybe a buzz, depending. But in assembly language a lot more is on the table! Suddenly one realizes it is possible to turn the speaker on or off long before it has reached the other state. There are lots of other realizations, such as what a read modify, write instruction does compared to one that does a single read or write.
There are any number of simple, seemingly shallow examples out there, racing the beam, making sounds, cramming more onto a floppy, and so on.
But what happens when the hardware is simple, driven by software gets right at the heart of assembly language, in my view. Hardware may be designed to do something, and if designed reasonably, will do that thing.
But, where it may be simple, or over engineered, has bugs, whatever, all suggest more, and as time passed we saw people get far more out of a lot of hardware than intended. Demoscene comes to mind here.
Maybe four thoughts! You should definitely take a look at this guy:
https://m.youtube.com/watch?v=jmTwlEh8L7g
Here is the assembly programmer mindset modeled well. People generally approach it wanting to get more out of their hardware, or understand what is really happening better, or to help them with subtle program errors.
Some do it for fun too.
This work suggests the ideas evolved during early computing, hacking on hardware, exploiting bugs, design choices, and more continue to play out on modern processors and systems just fine.
Keys to the kingdom for those willing to play.