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.

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.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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.

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.

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

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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?



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.




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


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

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:

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

It's just an age thing...



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



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/



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)



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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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.

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


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

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!