Whats the most human-friendly instruction set?

[ytropek]

Dear All.

As in the topic, I would like to start a discussion on various instruction sets/architectures, that - in your opinion - are the most suitable for writting Assembly code manually.

Just for fun I've created a poll on that topic, although, considering the name of this forum, the winner is highly predictable (hence the option to pick your TWO favourites) For the same reason I've decided to separate 6502 from 65816 that wouldn't make sense in more generic discussion, but I think in the context of this forum it does. As the poll is limited to 10-answers maximum, I couldn't squeeze more options, like SPARC or OpenRISC, etc.

Regardless the poll and your preferences, I think would be nice to have a more generic conversation on what makes the instruction set and the CPU architecture particularly friendly for writing ASM manually.

Please share your experiences and opinions. I have my own, but let me just open the thread now, and I will add more of my personal thoughts later on.

[barrym95838]

For me, the 6800 (not on the list) is the easiest to learn by a human, but human-friendliness is not quite the same thing, and I'm not sure how to adequately define that.

[ytropek]

Let me start with my personal experience. I probably spent most of my time coding ASM manually on 68000 (Amiga) and, before that, on 6502 (C16, C64). It was way before I gained any decent knowledge in software engineering, so my approach was rather ugly (lots of dissassembling of existing code, trying to figure out "how they did it", etc). Then, later on, working on my never-finished PhD research on compilers and automatic parallelisation I spent quite a deal of time with X86 (mostly 486) and MIPS (on Silicon Graphics), although rarely writing any ASM manually, but often generating or analyzing it. Then for years I stayed rather away from hardware level, with exception to some occasional hobby projects on microcontrollers, until last year when I started working on my 6502 emulator in Rust, found this Forum and sunk in the rabbit hole totally Now I'm probably more on 65816 side, playing a little bit with task schedulling/context switching, etc.

In terms of preferences I quite enjoy the 65816 and the power it gives in comparison to 6502. Tha later one feels a little bit like MC - you allocate all available memory for your project, do static adressing etc. In contrast to that, the 65816 feels more like a proper CPU, that can run OS. Pity there were bit too many compromises made for backward compatibility. I wonder how difficult it would have been to make the three registers general-purpose registers in the native mode, rather then keeping the separation between one poor accumulator and index registers. And I find it rather annoying constantly switching between 8 and 16-bit modes. Comparing that to my old 68000 experience, I think even at that time, when Commodore was working on Amiga, 65816 had to made impression like looking backwards rather than making the progress.

When RISC-V gained its popularity I played a little bit with it to learn someting more about the platform. In many aspects I found it quite comparable to ARM. There is some elegance in the assembly of both: the wide, 32-bit instructions give enough room to sqeeze all conditionals/branching directly in instructions - it feels almost like higher-level language. On the other hand these platforms are rather overwhelming. Multiple instruction sets, the huge number of registers, 64-bit words, it all quickly makes impression that human won't be able to compete here with compilers and that generated code will always be more optimal. I know - this thread is not about optimal code, but human-friendliness, but still - an overwheliming architecture is part of the experience, I think.

So, my conclusion is that human-friendly ASM must be rather limited to small-scale architectures. Dealing manually with a huge number of 64-bit registers makes us feel rather lost, even if we get in hand elegant instruction set. That probably means all modern RISCs are not for humans. X86 then, at least up to Pentium, felt like more human-oriented, with it CISCy approach, many dedicated instructions for specific domains (math, multimedia, etc), yet it never gained any love and it never felt so friendly. I wish I had spent more time with MIPS. In many aspects (again branching, comparisons) it felt quite natural and rather different than other ASMs I experienced.

My final conclusion is rather obvious: if the architecture wasn't designed having in mind that engineers will be implementing them directly, then it's hard to expect human-friendliness. PDP-11, which I never had a chance to deal with, was designed with that in mind, and indeed back then a huge amount of code for that platform was implemented directly in AMS. Same with hobby/home computers like our beloved 6502-based machines. As long as we, developers, can grasp the architecture end-to-end, feel that we control literally every step of the CPU, it makes sense. Switching into GHz+ world, mutlicores, etc makes the entire platform feel a little bit foreign or blackboxy. Perhaps my question from the title is rather wrong then - it's not about the instruction set, but something else...

Curios what are your thoughts.

[BigEd]

I can only really judge the ones I've used. My guess is that simple (regular) is more important than small. ARM is relatively simple, as is 6502. I imagine 6800 is quite similar to 6502 but I've done very little with it. It's possible PDP-11 is quite human-friendly but I wouldn't bet on it. More so than z80, probably!

RISC-V is a whole set of families of options but I'd think the core set should be pretty simple... question is does the lack of flags and a carry bit make it simpler.

[rwiker]

There should probably be separate entries for ARM32 and ARM64... I suspect that ARM32 would be much more human-friendly than ARM64.

[drogon]

I'm not sure assembly coding is ever human friendly - some are easier than others, but it's a means to an end at the end of the day. I do feel we should strive to get the high(er) level compilers to do more work for us - buuuut ... to do that then we still need people who can understand how bits of the underlying architecture work at the machine code level - at least until AI catches up...

Of the list:

• 6502
  I have written lots and lots and lots of 6502/65C02 and will continue to do so.
• 65816
  I've written a fair chunk of 65816 (and do not plan to waste any more braincells on it)
• Z80
  A fair chunk of 8080 using a Z80 assembler and a little bit of pure Z80.
• 68000
  Nope.
• MIPS
  Nope.
• ARM
  A tiny amount of ARM with no plans to write any more.
• RISC-V
  A fair chunk of RISC-V (Actually the same code written in RISC-V as I wrote for the '816 and it was an absolute joy compared to the '816 version, less bytes for the same code too - 16KB of '816 vs. 10KB of RV)
• X86
  No. Nope. Never. No
• PowerPC
  none
• PDP-11
  Enough to wring my name on the console.

There are several other CPUs I've written assembly code for - Sparc, i860, Transputer, Prime, INS8060, PDP-8, Eliot 903.

RISC-V I found to be the easiest. Actually all the RISCs were relatively easy althogh ARM has changed a little since I first wrote code in the beginning to what it is today.

Sparc has their interesting register window thing, i860 is a nightmare if you want to do floating point. Transputer is like nothing else, Prime is best forgotten and the INS8060 (SC/MP, etc.) is nice but takes a lot of work. (Similar for the PDP-8 and Eliot)

The most human friendly? CESIL. Maybe LMC. But they're not real...

I keep telling myself I won't write any more, but there is a certain lure to it all.

After spending a lot of time being frustrated with the '816 (mostly it's 64K banks which I didn't want my applications to know anything about and one particular inefficiency regarding reading an 8-bit value when in 16-bit mode) I re-wrote my entire project (a bytecode/VM to run my multi-tasking OS written in BCPL) in RISC-V which was a delight to do. all I need to do now is find the right RISC-V platform to use which may well end up being an FPGA but that's for another place...

-Gordon

[GARTHWILSON]

Quote:

Perhaps my question from the title is rather wrong then - it's not about the instruction set, but something else...

I would propose that part of it is about the human instruction, meaning the available programming manuals, videos, etc..  After ARM was recommended to me, I went looking for introductory ARM assembly-language programming videos, and what I found was not easy to latch onto at all; but I strongly suspected it was because the presenters did not know how to teach, rather than that ARM was particularly difficult.

It might also depend on what you want to do with the processor.  For example, you say about the '816, "I find it rather annoying constantly switching between 8 and 16-bit modes."  When I wrote my '816 Forth, I left the accumulator size at 16-bit and the index-register size at 8-bit almost full time, and almost never touched the register-size bits in the status register.  Someone else here—it might have been Kevin—said he was working on something with the '816, and for his particular project, he left the accumulator size at 8-bit and index-register size at 16-bit almost full time and almost never touched those register-size bits in the status register.  For the Forth kernel, I definitely found the '816 easier than the '02, primarily since the '816 handles 16-bit quantities so much more gracefully.

I expect most here don't have experience with enough different processors to vote fairly.  [Edit: Gordon kind of invalidated that, above, while I was writing, with so many processors in his experience!]  I think I myself will refrain from voting since I have extensive experience with only three, the '02, '816, and PIC16C/PIC16F (not even PIC16F1's and 16Fxxxx's which are slightly enhanced), and PIC16 is not even on the list.  I started with PIC16 by going to a one-day seminar in 1996 or so.

[ytropek]

drogon wrote:

RISC-V I found to be the easiest. Actually all the RISCs were relatively easy althogh ARM has changed a little since I first wrote code in the beginning to what it is today.
Sparc has their interesting register window thing, i860 is a nightmare if you want to do floating point. Transputer is like nothing else, Prime is best forgotten and the INS8060 (SC/MP, etc.) is nice but takes a lot of work. (Similar for the PDP-8 and Eliot)
The most human friendly? CESIL. Maybe LMC. But they're not real...

I'm deeply and honestly impressed with your enormous experience! I'd be more than curious to listen to your stories about these machines and low-level coding on them. Among all - I am the most curious about your experience with Transputer. I, unfortunately, never had any chance to deal with it, but it was always fascinating me. If I remember correctly, the authors first created the language (Occam) to program Transputer, then the compiler, and based on that they figured out the minimalist instruction set to drive the machine - and only then the processor for it was created. I really liked that design approach. If you don't mind - could you share a little bit more about your Transputer experience? Have you ever had chance to deal with Atari Transputer workstation?

Never heard of CESIL. Could you share what makes it, in your opinion, one of the most human friendly ones?

drogon wrote:

I'm not sure assembly coding is ever human friendly - some are easier than others, but it's a means to an end at the end of the day. I do feel we should strive to get the high(er) level compilers to do more work for us - buuuut ... to do that then we still need people who can understand how bits of the underlying architecture work at the machine code level - at least until AI catches up...

From pragmatic perspective you are absolutely right. This is why RISC took over at some place, as it was easier to produce compiler-generated (and optimised) machine code for such machines - with pletfora of generic-purpose registers and simple instructions. Yet, at least in terms of hobbyist projects, there is some kind of pleasure or even magic to deal on such a low level.

drogon wrote:

After spending a lot of time being frustrated with the '816 (mostly it's 64K banks which I didn't want my applications to know anything about and one particular inefficiency regarding reading an 8-bit value when in 16-bit mode) I re-wrote my entire project (a bytecode/VM to run my multi-tasking OS written in BCPL) in RISC-V which was a delight to do.

I'll take it a warning as it looks like I'm at the beggining of the same path (writing multitasking OS for '816), and perhaps before stepping any deeper I should learn from your experience...

drogon wrote:

all I need to do now is find the right RISC-V platform to use which may well end up being an FPGA but that's for another place...

Have you seen Milk V)? They offer quite interesting designs, from pico-size dual-OS (RTOS + Linux) sticks to workstation.

[barnacle]

I'm not sure there is a simple answer. As others have said, some processors are easier than others but I'm not convinced that any of them are human-friendly per se; that's not what they're for. That's what higher-level languages are for, so how friendly a processor is might be really how well it can implement a higher language.

There's certainly an intellectual challenge in making a processor do just what you want in the minimum time/bytes but I suggest that for most people it's much harder to do it consistently on a larger project. If the processor has lots of generic registers, like an ARM, then you can allocate them consistently, define a protocol to pass parameters and results, and take it from there. If it has fewer, 6502, then you need a different paradigm - though you still need the protocol, it's unlikely to be as simple or as efficient as the ARM (in this case).

On the other hand, familiarity has a lot to do with it. The easiest processor to use is the one I'm using most recently... I prefer a 6502 to a 6800, 8085 to z80, 8086 to 6800, AVR to PIC, because I've used the former most (though the PIC14 is just plain horrible, and the z80 assembly has its operands the wrong way around).

So the question probably comes down to how well you can implement data structures, and move data around between them. If you have a sixteen bit offset mem_last into memory, and you want to write a sixteen bit value there, the same C code will work for anything:

Code: Select all

* (uint16_t *)&mem[mem_last] = val;

But pick your processor and the assembler instructions you'll need will be completely different depending on the programming model thereof. And none of them will be human-friendly.

Neil

[drogon]

ytropek wrote:

drogon wrote:

RISC-V I found to be the easiest. Actually all the RISCs were relatively easy althogh ARM has changed a little since I first wrote code in the beginning to what it is today.
Sparc has their interesting register window thing, i860 is a nightmare if you want to do floating point. Transputer is like nothing else, Prime is best forgotten and the INS8060 (SC/MP, etc.) is nice but takes a lot of work. (Similar for the PDP-8 and Eliot)
The most human friendly? CESIL. Maybe LMC. But they're not real...

Wow - I'm deeply and honestly impressed with your enormous experience!

It's just an age thing...

Quote:

I'd be more than curious to listen to your stories about these machines and low-level coding on them. Among all - I am the most curious about your experience with Transputer. I, unfortunately, never had any chance to deal with it, but it was always fascinating me. If I remember correctly, the authors first created the language (Occam) to program Transputer, then the compiler, and based on that they figured out the minimalist instruction set to drive the machine. I really liked that design approach. If you don't mind - could you share a little bit more about your Transputer experience. Have ever had chance to deal with Atari Transputer workstation?

I worked for a UK supercomputer company 80s/90s - they were founded by some of the people who founded Inmos, so there was a very close connection. The Transputer instruction set - which itself has an uncanny resemblance to the code produced by the BCPL compiler which is unsurprising as they all came from Cambridge where BCPL came from... OCCAM was just one language for the transputer - I coded mostly in C.

The way my task scheduler works in my '816 system is quite similar to that of the Transputer (which has a task scheduler in its microcode).

My work as mostly in the R&B department helping engineers test new boards (I wrote all the test/diags for new transputer boards) then turned that code into drivers an utilities for the applications guys. We did some very custom boards for some weird hardware we were interfacing to...

Quote:

Never heard of CESIL. Could you share what makes it, in your opinion, one of the most human friendly ones?

It's a made-up one (like LMC). Designed for school kids to write programs on coding forms, send them into the local computing centre and have the results passed back a week or 2 later. It was just before the advent of computers in schools (In Scotland at least, so early-mid 70s) I wrote an interpreter and run-time for it in BASIC some years back: https://projects.drogon.net/cesil-contr ... pberry-pi/

Same for LMC: https://projects.drogon.net/lmc/

Quote:

drogon wrote:

I'm not sure assembly coding is ever human friendly - some are easier than others, but it's a means to an end at the end of the day. I do feel we should strive to get the high(er) level compilers to do more work for us - buuuut ... to do that then we still need people who can understand how bits of the underlying architecture work at the machine code level - at least until AI catches up...

From pragmatic perspective you are absolutely right. This is why RISC took ever at some place, as it was easier to produce compiler-generated (and optimised) machine code for such machines. Yet, at least in terms of hobbyist projects, there is some kind of pleasure or even magic to deal on such a low level.

drogon wrote:

After spending a lot of time being frustrated with the '816 (mostly it's 64K banks which I didn't want my applications to know anything about and one particular inefficiency regarding reading an 8-bit value when in 16-bit mode) I re-wrote my entire project (a bytecode/VM to run my multi-tasking OS written in BCPL) in RISC-V which was a delight to do.

I'll take is a warning as it looks like I'm at the beggining of the same path (writing multitasking OS for '816), and perhaps before stepping any deeper I should learn from your experience...

It all depends on what you want - if you want a platform where applications can live inside a 64K bank and access up to 64K of data then its relatively easy - accessing more than 64K starts to get harder, but it's by no means impossible. My aim was for a self-hosting system - something I could run the compiler, editor, etc. directly on without resorting to cross compiling. The way I achieved that was to pick a relatively easy compiler to get going - BCPL - and that compiled into a bytecode, so step 1: Write the bytecode VM. BCPL has no concept of segmented memory, so the VM had to "linearise" the underlying memory so I can allocate an array 100KB long in BCPL and it will "just work".

When I wanted to move on, I wrote a RISC-V (RV-32IM) emulator in BCPL then re-wrote the bytecode interpreter in RV assembler and successfully bootstrapped my BCPL OS under the emulator. It wasn't fast, but it worked well enough to enable me to get it going on an ESP32-C3 system. (Which might fit my needs it if just had a little more RAM)

Quote:

drogon wrote:

all I need to do now is find the right RISC-V platform to use which may well end up being an FPGA but that's for another place...

Have you seen Milk V (https://milkv.io/)? Very interesting platform...

I've seen many - the issue is that broadly speaking they fall into 2 categories: One is the "microcontroller" types - a few 100 KB of flash and a few 10s of K of RAM... OR many MB -> GB of RAM, 64-bit, multi-core designed for Linux. There are very few ones in the range I want for a hobby project - so that same few 100KB of Flash but 0.5 to 1MB of RAM and easy to use peripherals. Everyone wants to cram as much as possible, so you end up with Wi-Fi, AI, Encryption, USB systems on the chip which then makes it as hard to write a bare-metal thing from scratch for as the Raspberry Pi (Which I have done).

Cheers,

-Gordon

[John West]

All of the ones I have experience with have at least one major flaw: the 8 bitters are 8 bitters - it feels like more effort is spent working around the limitations of the CPU than writing code that does something. 68000 has that data/address register split. MIPS has its delay slots (but apart from that, I am very fond of it). ARM just never felt right to me - putting a condition on every instruction was nowhere near as useful as it needed to be to justify the loss of opcode space. 8086 was just all-round hideous, and x64 has grown beyond a reasonable person's ability to comprehend. 80386 wasn't awful, but it had too much baggage to make it good. PowerPC is mostly nice, but my brain could never deal with the backwards bit numbering, and the instruction mnemonics are something only IBM could have come up with. I shouldn't have to look up in the manual every time I want to shift a register.

I have a feeling I'd like RISC-V, but have no experience with it.

And of course my own 65020 is a delight. I'm enjoying it a lot. But I am a little biased there.

Not on the list are VU from Playstation 2, which was ... an interesting experience. I enjoyed the manual pipelining, spending days getting that 10 instruction loop down to as few cycles as possible. Wouldn't want to write anything big on it though. And SPU on Playstation 3 was fun too - shufb is a great instruction.

[ytropek]

John West wrote:

And of course my own 65020 is a delight. I'm enjoying it a lot. But I am a little biased there.

I'm sorry it's not on the list and I absolutely understand your preference. Funny enough what made me to start this thread was actually my experimentation with a hypotetical instruction set that would improve 6502 - good i didn't invest too much time into it before learning about 65020. There is one lesson I need to learn as a relatively new member of 6502.org - whatever idea I'll have in mind I can be 100% sure that someone here has already spent years on it and did some amazing achievements. The amount of knowledge and experience here is enormous...

John West wrote:

Not on the list are VU from Playstation 2, which was ... an interesting experience. I enjoyed the manual pipelining, spending days getting that 10 instruction loop down to as few cycles as possible. Wouldn't want to write anything big on it though. And SPU on Playstation 3 was fun too - shufb is a great instruction.

Very good points. I remember working with some former PS developers who were delighted with that architecture. shufb - will be my lecture for this evening

[GARTHWILSON]

ytropek wrote:

what made me to start this thread was actually my experimentation with a hypothetical instruction set that would improve 6502 - good i didn't invest too much time into it before learning about 65020. There is one lesson I need to learn as a relatively new member of 6502.org - whatever idea I'll have in mind I can be 100% sure that someone here has already spent years on it and did some amazing achievements. The amount of knowledge and experience here is enormous...

I have a list of links to 65xx processors, including some hypothetical, others designed but never made, others made but only in very small volumes, and Ed's roundup, some 16- and 32-bit ones, at http://wilsonminesco.com/links.html#65fam .

[sark02]

My first assembly languages were on 80s home computers: Z80, then 6502, then 68000. Of these, I found the 68000 to be the most easy to write for, and during my university years I wrote a lot of code on the Atari ST. In the mid 90s I dabbled with 6809, but only a little... enough to find I liked it. Around 2002 I wrote some ARMv4 code for the Nintendo Gameboy Advance. That was a lot of fun, but it was only a few hundred lines of code for a sound generator, with most of the program written in 'C'. I learned the instruction set from the ARM System on Chip Architecture book.

In various companies I have written 68000, PIC, MIPS32, (a tiny amount of) x86, and ARM64. MIPS32 was my first practical introduction to the nuts and bolts of virtual memory. Until I had to work on it, I never really understood it... Thought it was mysterious. Being dropped into a project where I was they guy who had to boot a new SoC from nothing meant I had to read the books and figure it out. Great fun.

ARM64 (or ARMv8), bring in more exception levels and TrustZone: secure vs. non-secure domains that extend all the way to the system bus and into peripherals. Building page tables and bouncing between exception levels, traps handlers, and secure worlds is just fun for me... so this (my most recent work) has been very enjoyable.

RISC-V is somewhat similar to MIPS, and WorldGuard is somewhat similar to TrustZone. I haven't had the opportunity to work on it yet, but it does look interesting.

For the instruction sets I have used, then, my order of human friendliness would be (best to worst):

• 68000
  ARM7
  MIPS32
  6809
  Z80
  6502
  ARMv8
  x86
  PIC

I score ARMv8 so low here as, although as a whole it's a great processor architecture to use, the base integer instruction set has a good number of very weird instructions that you really need to use to write real programs. I find it not human friendly at all

The 6502 scores low because of no mul/div, narrow ALU, and weak addressing modes.

x86 is just plain ugly. PIC is just weird (although I've written way more PIC than x86)

The 68000 wins hands-down. It's an easy to learn, easy to use, non-complex instruction set with straightforward instructions, and two operating modes to give you a little taste of a larger system.

[BigDumbDinosaur]

I wouldn’t know how to respond to this survey.  Assembly language of any kind is inherently unfriendly—after all, it has no real resemblance to a human language.  At least in C or FORTRAN, recognizable words are used.  LDA or ROL...what the heck is that? 

I’m very fluent in 6502/65C816 assembly language, fluent but rusty in 68000 assembly language, and in the distant past, was passably fluent on the 6800 and Z80.  I’ve written a tiny bit of x86 assembly language, but have had zero interest in pursuing it.  Even before my first steps in writing a 6800 program nearly 50 years ago, I worked with primitive systems that could only be programmed in raw machine code.  Ergo relative friendliness never really was a factor in my work.

The days when I did professional assembly language development have come and gone.  These days, I jack around in 65C816 assembly language purely for recreation, the goal being to get my POC unit to do something more quickly with smaller code.  At no time have I ever thought of it in terms of “friendliness.”  As Gordon notes, programming languages are a means to an end.