Whats the most human-friendly instruction set?

[Martin_H]

DavidL wrote:

In my experience (46+ years) the very best instruction set was the (long-forgotten) Motorola MC88000. It was actually fun to write assembly.

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.

[Proxy]

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.

[Miles J.]

BillG wrote:

A reason the 68000 is not my favorite instruction set.

How do you determine whether a register contains a zero without affecting the carry flag?

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.)

[Martin_H]

Miles J. wrote:

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

What is your processor?

[Miles J.]

Martin_H wrote:

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.

[BigEd]

Sounds great!

[monochrome]

I vote for ARM. Each instruction is 32 bits long and has a condition; the vast majority of them also take three operands. Could it get any more simple than that?

As for the other processors: the 6502 goes right out with its limited register file.
The register specialisation of 16-bit x86 is not intuitive for the beginner. Worse yet, 32-bit x86 resists any attempt to optimise for code size, shoehorning 32-bit immediate values everywhere. x86-64? Kill it with fire.
The 68000 handles this much better, as the operation size is built into each opcode and can be 16-bit as well. That said, I didn't vote for it due to the relative complexity of the instruction set.

[GARTHWILSON]

monochrome wrote:

As for the other processors: the 6502 goes right out with its limited register file.

Welcome.  I hope you've read through the whole topic.  There's a wealth of archives here too.  One thing you'll find in defense of the 6502's way of doing things is that in a sense, all of zero page is 256 bytes of processor registers, with extra addressing and indexing modes, rather efficient.  The 65816 further expands on the instructions and addressing modes, making a lot of operations easier and more efficient.  BigEd (who replied above once wrote, "With 6502, I suspect more than one beginner has wondered why they can't do arithmetic or logic operations on X or Y, or struggled to remember which addressing modes use which of the two.  And then the intermediate 6502 programmer will be loading and saving X and Y, while the expert always seems to have the right values already in place."  The '02 was designed to be inexpensive, yet it outperformed many of its contemporaries which should have done better with their advantage of more and wider registers.

Quote:

The 68000 handles this much better, as the operation size is built into each opcode and can be 16-bit as well. That said, I didn't vote for it due to the relative complexity of the instruction set.

My understanding of the 68K was that it was designed to the wish list of compiler writers.  However, some of the same things that make the 6502 a rather poor target for compilers also make it easy to envision solutions in assembly language.  And while compilers improved, so did assemblers, with great macro capability, effectively raising the level of the language, for anyone who truly knows how to make good and proper use of macros.  For my work, interrupt performance is a must though; and the 6502 absolutely blows the doors off the 68K in interrupt performance.

Of course, things have changed so much in the last two decades that the only real reason for one processor or another is just personal interest, and as another poster wrote above, familiarity.