I had never heard of the MC88000, so I lost an hour reading about it, and the IBM 801 which was an influence upon it.

@BillG, unaligned faults make sense from a hardware POV if your addressing units are bytes, but your physical RAM is arranged in terms of words. Basically addressing a word that spans two physical words isn't going to work. But at that point why not address in terms of word units, so there are no unaligned addresses. It just seems like a tease to offer byte granular addressing, and then fault when the program takes the hardware up on it.

Also, the advantage of word addressing is that you expand physical memory while retaining a smaller address space.

well it made sense in the long run (i think) as the 68020 and above allowed for unaligned memory accesses, they were simply a performance loss but no longer caused an exception.

The carry flag on the 68000 is used explicitly for comparison and is therefore modified by all instructions that are usually used in conjunction with a branch instruction, e. g. "CMP <ea>, d0", "TST d0", or "MOVE <ea>, d0". The function of the carry flag on the 6502 as you may know it (e. g. arithmetic overflow) is taken over by the additional x flag on the 68000, hence instructions like ADDX, SUBX, NEGX, ROXR, ROXL etc.


What's the most human-friendly instruction set?
That of my own processor, of course. ^^ (Sorry, couldn't resist.)

What is your processor?

It is a 32 bit risc-like processor (could also be 16 bit, but I prefer 32 bit because of the larger address space) and looks like a mixture of 6502 and 68000. For example, it has processor flags like the 6502, but branch instructions like the 68000. However, it was actually inspired by the 65org16 and, like it, has a 16 bit data bus with 16 bit memory word width. The instruction length is 16 bits with the option of storing constants in a further 16 or 32 bits. There are 16 registers with r15 as a stack pointer. Register 14 acts as a kind of pointer to the zero page for fast loading and saving (but without R-M-W instructions). As r14 is often used for handling objects, it is called the object pointer.
The processor is designed for a) high code density (there are special short forms for many instructions when using an 8-bit constant) and b) simple organisation of the instruction set. This not only facilitates emulation, but also makes it possible to squeeze the processor together with some program code into very small FPGAs.
The instruction set has a special instruction EXT (coded as $00xx). Here, the lower 8 bits can specify 256 new, extended instructions, e.g. all instructions of the 65c02. After adding a separate S register, in emulation the processor behaves exactly like a 65c02, and it is possible to mix 65c02 code and the processor's own instructions as desired. Since my Apple II emulator emulates this processor, I can patch programs such as "Elite" at will, and because of the 32-bit address width, the additional code can lie outside the 64 kb address space (or 128 kb for the Apple //e). Furthermore, an FPGA implementation (without the additional 65c02 core) was also successfully tested. As far as speed is concerned, 1 Mhz is roughly equivalent to a 4 Mhz 68000.
Personally, I like the easy handling of the processor (somewhere between 6502 and 68000) despite some oddities. For example, in contrast to the 68000 or 6502, there are no instructions such as "ADD <ea>, dx" due to the risc nature, and there is no absolute addressing because all programs are designed for relocation. Instead, r13 is usually used as a pointer to global data. If you want to access absolute addresses, e.g. I/O registers, you first load the base address into a register (preferably r14) and then use the addressing mode "<d8>(r14)" or "d32(rx)".
In short, as someone wrote above about the 68000, it's actually fun to program the processor in assembly language.

Sounds great!