6502 is fun and neat, especially if you want to program those machines. If you want more modern approach, it's not really all that suitable. Do what we did in the 90's then and start with MIPS if you want to follow the path of glory days or just start out with Neon. I'd even argue Z80 with all its registers and complexities is more similar to what you'll find today (far from it, but let's entertain the connection between past and present as OP does).

There's nothing inherently complicated about modern asm. Take FASM, start. It's not complicated, but it gets complex rather quickly which was and will be always true for such low level approach. Then you start macroing and sooner or later you have your own poor man's C on top.

But again Z80 looks like a very good option too because it has GB/GBC plus ZX Spectrum. The same goes to 68K -- Mac 68K, Sega Genesis and Neogeo are popular hits.

When I was writing my reply to another question (https://news.ycombinator.com/item?id=42891200), I was thinking about a new software engineering education system which starts from a retro platform and goes up from there. Maybe all three can fit the bill. I'm very much against the "elegant/pure" way of teaching.

BTW totally agree 6502 essentially has 3 registers. You don't get to touch the others.

This shouldn't be discounted, since it has great pedagogical value in itself. On the other hand, personal opinion here, is that not many things are transferable to modern ISAs. Even back in the 90's, we were shown to work on MIPS instead. 68k is very nice to read and write, almost feels like higher language, but overall ROI for newer stuff is maybe just jump into Neon, x86_64, or as someone said RV directly. It's not _THAT_ hard. It gets complex as programs grow though.

I need to look into my SDL2/C++ game's assembly code and see how it is done.

Practically anything non-trivial uses those zero page addresses as extra registers.

Of course there is the Atari 2600 where you only have 128 of those bytes with RAM (80-FF) and the stack is set to page 0 instead of 1 (not that you'll use the stack a lot in an Atari 2600 program).

They're not physically connected, other than through the bus. I mean, zero page is part of DRAM.

Of course they all are technically registers, but they really can't be used for anything useful the way the index registers and accumulator can

Learning to hack around the limitations of a tiny machine is a good step toward becoming a seasoned software (and possibly hardware) engineer!

The advantage of tiny systems is that you can understand them completely, from silicon to OS to software.

The 6809 is simpler than the 68K, and more powerful and orthogonal than the 6502, but there isn't the same software base for it. I think Motorola was onto something with the 6809 and 68K instruction sets and programmer-facing architecture. IIRC PDP-11/VAX and NS32K are similarly orthogonal.

https://youtu.be/tfKHBB4vt4c?t=9

It’s a shame that Tandy missed the boat on including coprocessors for game support in their computers, especially that one. If they’d just included decent audio and maybe something for sprite management it would’ve been highly competitive.

Atari 800 featured powerful video processing with display lists and sprites, 4-channel audio, etc., but was much less successful.

As I understand it, Radio Shack did not encourage third-party software and support for its systems, not realizing that it was the key to success.

OS-9, originally a 6809 OS, seems to have survived for quite some time.

https://en.wikipedia.org/wiki/OS-9

C64/128 was what I was thinking of more than anything re 8-bit competition, keeping in mind I’m talking mid-late 80s by this point. I do also remember Atari 800 (and later) doing considerably better than you imply. But you’re right, Apple captured the early-mid 80s gaming market nicely.

(Unless you want to really dive into "how can I work around limitations", and then you pick an F8 and pull your hair as much as you like)

MC68k just has tons of quirks which aren't really going to be relevant in the modern day and age. (About the only thing it has going for it is the huge variety of hardware platforms that happened to make use of it, many of which still have thriving retro communities around them. But that's more of a curiosity as opposed to something genuinely relevant.)

Using RISC-V for executing programs written in high-level programming languages is fine. It should be noted that in the research papers that have coined the name RISC, where there was a list of properties defining what RISC means, one of them was that RISC ISAs were intended to be programmed exclusively in high-level languages and never in assembly language. From this point of view, RISC-V has certainly followed the original definition of the term RISC, by making the programming in assembly language difficult and error prone.

On the other hand, learning assembly programming with RISC-V is a great handicap because it does not expose the programmer to some of the most fundamental features of programming in an assembly language, because RISC-V does not have even many features that existed in Zilog Z80 or in vacuum-tube computers from 70 years ago, like integer overflow detection and indexed addressing.

Someone who has learned only RISC-V has an extremely incomplete image about how a normal instruction set architecture looks like. When faced with almost anyone of the several thousands of different ISAs that have been used during the last three quarters of a century a RISC-V assembly programmer will be puzzled.

6502 is also too quirky and unusual. I agree that among the old ISAs DEC PDP-11 or Motorola MC68000 are better ISAs for someone learning to program in an assembly language from scratch. Writing assembly programs for any of these 2 is much simpler than writing good assembly programs for RISC-V, where things as simple as doing a correct addition are quite difficult (by correct operation I mean an operation where any errors are handled appropriately).

Using instruction fusion of a pair of instructions to achieve the effect of indexed addressing, but in a many times more complex and more inefficient way, is believable even if ugly.

Using instruction fusion to fuse the long sequence needed for checking overflow into a single operation is unbelievable.

Even if that were done, the immense discrepancy in complexity between detecting overflow with one extra XOR gate in a 64-bit adder that may have hundreds of gates, depending on its speed, and an instruction decoder capable of fetching ahead and decoding the corresponding long instruction sequence into one micro-operation is ridiculous.

I also agree the 6502 is not a simple ISA. However after learning 6502 machine code, MIPS, AVR, and ARMv6-M were all easy to learn.

RISC-V is simply the best ISA I've ever used. It's got everything you need, without unnecessary complexity.

> RISC ISAs were intended to be programmed exclusively in high-level languages and never in assembly language.

That's a misunderstanding. RISC was designed to include only the instructions that high level language compilers found useful. There was never any intention to make assembly language programming difficult.

Some early RISC ISAs did make some of the housekeeping difficult for assembly language programmers by for example having branch delay slots, or no hardware interlocks between things such as loads or long-running instructions such as multiple or divide and the instructions that used their result. So if you counted wrong and tried to access the result register too soon you probably silently got the previous value.

That all went completely out the window as soon as there was a second implementation of the same ISA with a different number of pipeline stages, or more of less latency to cache, or a faster or slower divide instruction. And it was just completely untenable as soon as you got CPUs executing 2 or 3 instructions in each clock cycle instead of 1. The compiler could not calculate when it was safe to use a result because it didn't know what CPU version the code would be running on.

Modern RISC -- anything deigned since 1990 -- is completely fine to program in assembly language.

> That's a misunderstanding. RISC was designed to include only the instructions that high level language compilers found useful. There was never any intention to make assembly language programming difficult.

That is no misunderstanding, but almost a quotation of the 4th point in the definition of the term "RISC", in “RISC I: A Reduced Instruction Set VLSI Computer”, David A. Patterson & Carlo H. Sequin (University of California, Berkeley), presented at ISCA '81.

Of course they did not try to make assembly language programming difficult as a goal, but the theory was that no ISA feature should be provided with the purpose of making the assembly programming easy, because it was expected that any inconvenience shall be handled by a compiler for a high-level language.

In practice, only the academic RISC ISAs from Berkeley and Stanford were less convenient to program in assembly language, while those from the industry, like IBM 801 and ARM and their successors did not have any disadvantage for programming in assembly language, on the contrary they were simpler to program than many less orthogonal older processors.

RISC-V has everything needed only in the same way as an UNIVAC from 1950 has everything needed.

As an ISA for didactic hardware implementation, RISC-V is very good. As a target for writing programs it is annoying whenever you are writing non-toy programs.

RISC-V has only one good feature in comparison with x86 or ARM, the combined compare-and-branch instructions, which saves a lot of instruction words in comparison with separate instructions, because branches are very frequent, e.g. one branch to every 6 to 8 instructions.

Except for that, there are too many important features that are missing without absolutely any justification and without any benefit.

Detecting integer overflow in hardware, like in almost all CPUs ever made, with the notable exceptions of Intel 8080, RISC-V and a few other that have never pretended to be suitable for general-purpose computing, is exceedingly simple and cheap. Detecting integer overflow in software is complicate and very expensive.

Implementing indexed addressing in hardware is extremely simple in comparison with implementing instruction fusion or with increasing the number of functional units and increasing the width of all structures to be able to execute more instructions concurrently, in order to reach the same performance for an ISA without indexed addressing.

While the loops of RISC-V usually save an instruction at the loop test, they waste at least one instruction at each memory access, so except for very simple loops RISC-V needs much more instructions for executing an interation than most other ISAs.

The RISC-V proponents have bogus excuses, i.e. the availability of the compressed mode and the possibility of using instruction fusion. These 2 are just workarounds for a bad instruction encoding that requires an excessive number of instructions for encoding any program. They can never be as good as a well designed instruction encoding.

All competing ISAs that are better encoded can also implement a compressed encoding (like ARM, MIPS and POWER also have) and they can implement instruction fusion. They seldom do this only because they seldom need this, unlike RISC-V.

I have programmed in about the same list as ISAs as enumerated by you, over about the same time interval. I agree that for most controller tasks RISC-V is acceptable, even if sub-optimal. When it is cheap enough (due to no royalties) that can overcome any other defects. On the other hand I have also written various programs dominated by complex computations, where the deficiencies in arithmetic and array addressing of RISC-V would have made it clearly unacceptable.

That doesn't say anything about making it difficult to use assembly language. It speaks only to making it UNNECESSARY, to the largest extent practical.

Maybe you weren't around at the time, but I remember very clearly the literature on the software crisis and the VAX being designed to make assembly language programming as productive as possible, EVEN at the expense of raw machine speed (the VAX 11/780 was slower than the PDP 11/70), because no one trusted the performance of high level languages.

The above aim of RISC was to make a machine fast enough and easy enough for compilers to use effectively that there would seldom be a reason to move out of the more productive high level language.

For this purpose, RISC-V is excellent.

The RISC-V ISA has not been designed as an efficient method for encoding computer programs and even less for being easy to program in assembly language.

When programming in assembly language, a complex ISA is bad, because one cannot hold in mind all its peculiarities, but a too simple ISA is even worse, because every simple operation must be implemented by a complex sequence of instructions that is easy to forget and to get wrong.

I wonder if any of those who claim that the RISC-V ISA is simple can remember without searching the documentation how to implement the checks for integer overflow after each arithmetic operation.

The didactic examples of using RISC-V usually do not check for any errors, which is not acceptable in any critical application. I find funny that sometimes the same people who claim that the unsafe RISC-V ISA is good also claim that C and C++ are bad, because with default compilation options they are unsafe in comparison with e.g. Rust.

I mean, I can't give you the Hacker's Delight magic numbers for expressing integer division by a constant via multiplication on AArch64 or x86-64 off the top of my head either, but that's what we have compilers for. The fact that you sometimes have to look up how to do simple things is just part of programming.

Scaled indexed addressing is useful in 80386 and successors only because they lack general support for addressing modes with register update, and also because they have INC/DEC instructions that are one-byte shorter than ADD/SUB, so it is preferable to add/subtract 1 to an index register, instead of adding/subtracting the operand size.

Scaled indexed addressing allows the writing with a minimum number of instructions of some loops where multiple arrays are accessed, even when those arrays have elements with different sizes. When all array elements have the same size, non-scaled indexed addressing is sufficient (because you increment the index register with the common operand size, not with 1).

However there are many loops where scaled index addressing is not enough for executing them with a minimum number of instructions, while using post-incremented/pre-decremented addressing still allows the minimum number of instructions (e.g. for arrays of structures or for multi-dimensional arrays).

Unfortunately not even MC68020 has complete support for auto-incremented addressing modes, because besides auto-incrementing with the operand size there are cases when one needs auto-incrementing with the increment in a register, like provided by CDC 6600, IBM 801, ARM, HP PA-RISC, IBM POWER and their successors (i.e. when the increment is an array stride that is unknown at compile-time).

On x86-64, using scaled indexed addressing is a necessity for efficient programs. On the other hand on ISAs like ARM, which have both scaled indexed addressing and auto-indexed addressing, it is possible to never use scaled indexed addressing without losing anything, so in such ISAs scaled indexed addressing is superfluous.

This said, 65XX on an early Commodore computers was extremely rewarding to use because there was no memory protection and you could write code altering video memory, mess with sprites, fonts, borders, interrupts, write self modifying code etc etc. 68000 assembly on Amiga was more safe and controlled.

https://bitsavers.org/pdf/dec/pdp11/1120/PDP-11_Handbook_Sec...

You scale up the complexity of the programs you need to build with the complexity of the chips. In the 6502 lab it was a lot about learning the basics of how things like an MMU works and building basic ones out of TTL logic gates. In the 68k lab you take an MMU for granted and do more ambitious things with that. There's useful skills both from knowing what the low level hardware is like as intimately as a 6502 can get versus the skills from where it is easier to program because you have more modern advantages and fewer limitations.

The other thing about that order was that breadboarding the 6502 hardware was a lot more complex, but it made up for it in that writing and debugging 6502 assembly was a lot easier. There are a ton of useful software emulators for the 6502 and you can debug your code easily before ever testing it on lab hardware. At one point in that lab I even just wrote my own mini-6502 emulator specific to our (intended) breadboard hardware design. On the other side, there a lot fewer software emulators for the 68k and the debug cycle was a lot rougher. The 68k breadboard hardware was a bit more "off the shelf" so it was easier to find an existing emulator that matched our (intended) hardware design, but emulator itself was buggier and more painful to use and ultimately testing on the real hardware was the only trustworthy way to deal with it. I also wasn't going to try to write my own 68k emulator. (Though some of the complexity there was the realities of hardware labs in that the hardware itself starts to pick up its own localized quirks from being run only on breadboards for years.)

The 68000 instruction set is very C-like (probably because it draws a lot of inspiration from the PDP-11 which was C's first target). Implementing it sucks (I know from experience) because the ISA is on the large side and all the little pragmatic exceptions add up. But because these exceptions are fairly pragmatic, they're not really a big issue when writing code.

As for modern CPUs and OoO etc, that's only about performance. The CPU, no matter sophisticated, must produce exactly the same results as the simplest in-order CPU.

Hardware is never going to spill a register to RAM when you didn't write that. The maximum that is going to happen -- and this is pretty recent -- is that memory at small offsets from the SP might be treated as if it was extra registers, and this renaming can be tracked over smallish adjustments to the SP.

"You can't understand what modern CPUs do" is much overblown. Just write good clean code and it will work well on everything.

You can't do that on modern CPUs, because the nominal ISA has a very distant relationship to what happens inside the hardware.

The code you write gets optimised for you dynamically, and the machine is better at it than you are.

You may as well write in a high-level language, because the combination of optimising compilers with optimising hardware is probably going to be faster than any hand-written assembler. It's certainly going to be quicker to write.

The 68000 is a very nice, clean machine to code for, but the main point of doing it today is historical curiosity. It's quite distant from modern computing.

I write compilers, and I write critical routines by hand when compilers don't do a good job.

- 32 bits

- lack of vectorization and such.

It's still perfect for most embedded stuff, by my estimation.

Well .... there are certain points like: wasn't there some issue with branch displacements on MC68K being confined to 16 bit ranges? If you have large functions, it can be a problem.

I dimly remember a project I was on circa 2001 to port a protocol stack (that we were developing on x86) to a system with some Freescale processor with a 68K instruction set.

I remember having to chop the source file into several translation units, because when it was all in one file, the inlining or static function calls or whatever, were generating PC relative branches that were too large for the opcode.

With today's hugeware, you'd be running into that left and right.

That's just inadequate tools.

With GNU as for RISC-V if I write `beq a1,a2,target` and target is more than 4k away then the assembler just silently emits `bne a1,a2,.+4; j target` instead.

The MC68K has a BRA instruction with an opcode 0110 0000 (0x60). The low byte of the 16 bit opcode word is a displacement. If it is 0, then the next 16 bit word has a 16 bit displacement. If that low byte is 0xFF, then the next two 16 bit words have a 32 bit displacement.

The displacement is PC relative.

This unconditional 0x60 opcode is just a special case of Bcc which ids 0x6N, where N is a condition type to check for a conditional branch. Bcc also has 8, 16 or 32 bit displacement.

So, yeah; that's not a problem. Not sure what the issue was with that GCC target; it somehow just didn't generate the bigger displacements.