EIEIO...

Indeed.

Similarly, why is there no (programmer visible) carry stored/used in C? There are times when it would be really handy

Neil

For me, it really comes down to instruction scheduling. Being able to hold most of the instruction set and cycle counts in my head (harder and harder the older I get!) is key to "human friendly" assembly programming. I think the 6502 is tops in that category. But other 8 bitters fall into line pretty well. Really like the 6809, even the 8051, especially modernized cores, are fun. The 8086/8088 offer some interesting pipeline challenges but still manageable. One can claim the architecture is a mess, but I don't find it all that much different than the 65816's approach to 16 bit-ness. The 68000 and 80386 (in flat 32 bit mode) are pretty straight forward to program efficiently. I wrote a significant amount of MIPS R3000 code and could pound out optimized code like no tomorrow - probably my favorite ISA.

But this was all before super-scalar became mainstream. Now it becomes a game of trying to figure out the underlying hardware scheduler and avoiding stalls. No longer is it a matter of writing compact and efficient code which will often run *slower* than seemingly randomized code. So many second and third order effects one has to contend with place a real burden on the human. Really, only a few routines can be focused on to extract the highest performance in assembly. All the rest, meh, I'll program it in C.

Below my quick comments/questions related to few different posts from this thread. Btw - it looks like my poll definitely misses 6800/6809, as these architectures were mentioned number of times here.

The story


Thanks so much for quoting this story, Barry. I found it touching and poetic and it just proves that being a nerd does not necessarily mean (as some may think) being unhumanistic. Btw - do you have an idea what book that story may be referring to? 

68k and PDP-11

Oh - I didn't know about that inspiration and you made me curious about it, although a quick search didn't give me many details, aparat a short statement on Wikipedia. I found, though, one interesting comment (by Antron Argaiv) on Hackaday under A PDP-11 on A Chip article (interesting on its own):


Based on this thread I see there are some on this Forum with hands-on experience on both platforms. I'm curious your opinions.

Instruction schedulling

I see the point and it makes lot of sense to me. I'd also add number of registers that fit in "cognitive capacity" of a human being. But 65xx family, with a single usable rigister drives into ZP trickery and - in my opinion - reduces the friendliness of that (overal friendly) architecture. I remember moving from 65xx to 68k and the feeling of "freedom" it gave me.

RISC-V


I'm getting the point, especially in the context od moving your '816 project to RISC-V platform. Some little, simple computer (not a microcontroller) would make a lot of sense here. I'm curious whether you've found something that matches your criteria. Looks like some of the Forum members are interested in that architecture, so would be good to know about some good platform to try (a topic for a separate thread, though).

I've found a couple of devices that are almost, but not quite what I'd like. They are the ESP32-C3 and ESP32-C6 devices. They have 400KB of usable RAM (or 512 in the C6, I think). They are also bloated with much additional hardware, some of which needs binary blobs to run but that's neither here nor there right now, however I did boot my BCPL OS in a C3 device (an M5 Stamp unit - the size of a small USB memory stick...)

Another route I started down, but stalled was FPGA. I have an FPGA that will run the RISC-V core I want (RV32IM) and have up to 1MB of RAM and be able to drive an HDMI or local LCD... But getting my head round the FPGA is proving problematic in both learning curve and my own time & energy.

-Gordon

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

ISBN 0-672-21805-4

The Z8000 was in there too. I still have the book buried somewhere in my attic.

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

Thank you, Barry. Luckily I found it on ebay - and it's already on the way to me

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 only language which does that is PL/M which allows specifying add with carry.

And they warn about using that feature because the flags are so easy to disturb.

I'd like to nominate the VAX as the most human friendly instruction set. It was a 32 bit extension to the PDP-11 architecture with the explicit goal of bridging the gap between high level languages and assembly. While successful, by the end of the 80s the design's performance began to lag other processors.

Specifically, the MIPS used in the DECstation line which supported an instruction pipeline and dual issue. Those features made MIPS assembly explicitly unfriendly to humans because of squirrelly behaviors like the instruction after a taken branch still getting executed.

The branch delay slot was definitely a black eye on MIPS (see also SPARC and some others).

_________________
Machine room: http://www.floodgap.com/etc/machines.html

I lost touch with the whole RISC versus CISC sometime in the 90's. But I haven't heard gripes about this recently, so I assume modern RISC chips don't do this anymore?

MIPS also had the unaligned address fault which made porting code from byte-oriented machines a real headache. The C compiler could pad your structures to align elements to their native boundaries, but some code would break if it expected packed structures. With the coding I did it was usually code trying to squeeze code onto a single virtual memory page to avoid a page table fault during an interrupt.

I did a Google search and unaligned address faults are still a thing, so I guess people have gotten used to those now.

Not at all...it just requires one to pay attention. Just drop a NOP and replace that later if needed.

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

The 88000 was yet another demonstration in this industry that the very best ideas don't always rise above.

I think you misunderstand me. Certainly you can compensate for the delay slot and there are technical reasons why it existed. But it's not an intuitive concept for people to program with and therefore not very human-friendly, especially since not every RISC required it - not even every RISC of the era (POWER1 and PowerPC, for example, have never required a delay slot).

_________________
Machine room: http://www.floodgap.com/etc/machines.html

The MIPS designers should have defined two varieties of branching instructions: the normal one for which the assembler automatically and silently inserts a nop into the delay slot and a special bonus form which allowed specifying a "free" slot instruction.

I'm posting this again because it was apparently missed the first time.

"Everybody's favorite", the 68000 also trapped on odd addresses.

The 486 and the original Pentium were fun for optimizing code. The 486 was "RISClike" in that simple instructions took only a single cycle when in the pipeline. So avoid unnecessary branching and some well documented "cycle eaters" and the code flies.

The original Pentium had two integer execution units. The second can only execute a subset of the instruction set, but if there were no data dependencies, can operate in parallel with the primary one. My fast code looked like two interdigitated threads because that was what it was.