Suggestions for a microcontroller (general-purpose)

[NorthGuy]

There's one place where assembler is head and shoulders about anything else. That is learning. If you want to learn how a CPU works (whether the CPU in general, or your particular CPU) your best bet is to write a few programs in assembler.

Perhaps creating a small CPU from logic ICs (or in FPGA) will teach you even more about CPUs, but that's another story.

[jpanhalt]

I still suffer Assembly, but my excuse is simple. In 70's to 80's, I acquired a TI-99 at home and a very early version an IBM PC at work.  We used IBM Basic at work and got a decent project up and running.  It was finally retired in about 2010.  I didn't do much after that until about 2000 when I wanted to replace some discrete logic with an MCU.  I looked at the PIC12F509.  I was just like flowcharting that I had done my whole professional life, except with a relatively small number of mnemonics that were easy to remember.  Over the years, often when bored, I will pick some computation and try to solve it.  I have lots of code to do stuff PIC's don't do with simple instructions, like bin2dec, division, hourly clocks, BCD addition and subtraction, etc. I wouldn't call them libraries, but they are easily copied and pasted.  I see no reason to change now. 

It's a little like learning to drive with a stick shift.  You never forget the fun of popping the clutch at a stop light or with a girl next to you.  If I had started with MCU's in an academic setting with C, I might feel the same about using C today. 

[brucehoult]

Here today we have an amusing example of someone asking "I hand wrote my tensor product and tensor contraction code in asm ... but it's slower than NumPy .. how can this be??"

ahahaha

https://www.reddit.com/r/asm/comments/1jb80yz/my_code_in_nasm_took_more_time_running_than_numpy/

[Analog Kid]

Heh; so much for the "everything is faster if written in assembly language" misconception.

[brucehoult]

NumPy might well have kernels written in asm, I don't know. It will certainly be using at least x86-specific SIMD intrinsics in C, unrolling, I assume cache blocking. It's state of the art stuff.

[phil from seattle]

PIC 8 bit architecture is horrible for many reasons. The stack to store only 8 addresses in some micros may be another one of them.

In fact C was invented in the early 70's precisely to make Unix portable on machines that then had around 32kbytes up to 256 kbytes of ram memory, which is common today on a mid-range microcontrollers.

Cut my teeth on a Unix V6 system on a PDP-11/45 which maxed out at 256KB RAM. 32 simultaneous users. Those were the days!  Banged a little ASM on it but with C you could do some amazing things.  I wrote a complete compiler in one semester - lex/yacc/code gen all in C. Made me true believe.

Sorry for the diversion, back to the "why would anyone want to use ASM" discussion in progress.

[phil from seattle]

There's one place where assembler is head and shoulders about anything else. That is learning. If you want to learn how a CPU works (whether the CPU in general, or your particular CPU) your best bet is to write a few programs in assembler.

Perhaps creating a small CPU from logic ICs (or in FPGA) will teach you even more about CPUs, but that's another story.

If you want to REALLY understand how a CPU works, write a compiler for it. Talk about drinking from a fire hose.

[brucehoult]

In fact C was invented in the early 70's precisely to make Unix portable on machines that then had around 32kbytes up to 256 kbytes of ram memory, which is common today on a mid-range microcontrollers.

Cut my teeth on a Unix V6 system on a PDP-11/45 which maxed out at 256KB RAM. 32 simultaneous users. Those were the days!  Banged a little ASM on it but with C you could do some amazing things.  I wrote a complete compiler in one semester - lex/yacc/code gen all in C. Made me true believe.

Mine was an 11/34 with the same amount of RAM and 30 users in one room (lab) plus 2 LA120 printers.

The year before me they learned FORTRAN and had an environment where when you submitted your program to compile you were logged off for someone else to use that terminal, and you went to the printers to await your compiler listing and porribly program output.

In my first year we used Pascal. Asking to compile added your program to a batch queue, so there was only one copy of the compiler at a time, but you stayed logged on and could run the binary (if you got one) as much as you wanted and even keep it as long as your total disk usage was under IIRC 32 blocks when you tried to log off. I helped find and fix a bug in the NBS Pascal compiler we were using, where it hallucinated that the PDP-11 had an Add Byte instruction -- it did have bytes versions of CLR, INC, DEC, ADC, SBC, TST, NEG, COM, ROR, ROL, ASR, ASL (all single operand instructions) and MOV, CMP, BIS, BIC, BIT (two operand instructions) but the encoding you'd imagine was ADDB (and the compiler did) was actually SUB.

But that was running, I think , RSX. My introduction to Unix was a couple of years later on a Zilog System 8000 (Z8000 CPU).

[Tation]

NumPy might well have kernels written in asm, I don't know. It will certainly be using at least x86-specific SIMD intrinsics in C, unrolling, I assume cache blocking. It's state of the art stuff.

numpy uses LAPACK and so uses some BLAS incarnation (openBLAS, oneMKL,...). openBLAS definitely contains hand-tuned, cache-aware and friendly, assembly kernels (and I suppose oneMKL also does, as its performance is comparable to that of openBLAS), so not strange at all that some random guy over Internet, not devoting years to the task, cannot beat numpy, no matter if using assembly, C or whatever.

[osmax_br]

I see a lot of these RISC-V MCUs by sipeed , some of them cost 3$ with more performance than esp32 s3 for example
Have anyone tried one of those before?
However the software support seems very little to not existent

[Picuino]

Both LAPACK and BLAS are written in Fortran language.

[NorthGuy]

If you want to REALLY understand how a CPU works, write a compiler for it.

Compiler is a program which writes assembler, most of them anyway.

[phil from seattle]

If you want to REALLY understand how a CPU works, write a compiler for it.

Compiler is a program which writes assembler, most of them anyway.

Some do but, regardless of the intermediary form, you have to understand the underlying architecture completely (which was my point). Then you get to worry about things like out of order execution and others peculiarities.

[Tation]

Both LAPACK and BLAS are written in Fortran language.

LAPACK still is mainly FORTRAN, with some C, but current implementations of BLAS no longer rely so heavily on it and do contain assembly.

[westfw]

Hmm.  I had this thought:

RISC Architectures:

• SPARC: dead.
• PA-RISC: dead.
• ALPHA: dead.
• PPC: mostly dead ("Niched"?).
• MIPS: mostly dead.
• XTensa: barely ever achieved any popularity, from a manufacturer that is now "moving on."
• ARM: mutated nearly beyond recognizability.  (ARM32 was pretty elegant.  Thumb2 with all the bells and whistles added - not so much.  (personally not familiar beyond the microcontrollers, though.))
• RISC-I through RISC-IV: not commercialized?  (SPARC is based on one of them?)

CISC Architectures:

• 8080/Z80: not taking over the world, but arguably doing as well as it ever did.
• 8051: still going strong.
• X86: still going strong (maybe "mutated", like ARM?)
• (8bit)PIC: still going strong.  (they call it "RISC", but the only thing it has in common with modern RISC is "few instructions.")

So it sort-of looks like having really stubborn manufacturers is more important than architectural elegance, if you're looking for longevity...

(although, from a PROGRAMMING PoV, there are a lot more similarities between different RISC architectures than between different CISC architectures.)

(So, are "register windows" pretty much an abandon concept?)

[brucehoult]

I'm not sure your taxonomy holds up.

8080/z80, 8051, PIC are not really either CISC or RISC. More Impoverished Instruction Set Computer. They mostly have quite RISC-like register-to-register instructions, with load/store separated out, except for being able to use the "M" register on 8080 aka "(hl)" on z80 (and "(ix+n)", "(iy+n)" on z80) on a lot of arithmetic instructions. Apart from "M" all memory references are only by LDA/STA (nnnn) and PUSh and POP, they are not mixed with arithmetic. And there is at most one memory operand per instruction.

Even x86 has at most one memory operand per instruction, which separates it from all the dead CISC.

You didn't mention the dead CISC!  VAX. M68000. NS16000/32000. Pr1me. iAPX432. Interdata 7/32. HP3000. Data General Eclipse.

Those are so thoroughly dead that most of them have been memory-holed.

And compared to them, all the "CISC" you list are only a small step from being RISC too.

RISC-I through RISC-IV were student projects. The first two were just experiments to see if the RISC idea worked at all. The last two were testing the RISC idea applied to Smalltalk SOAR (Smalltalk on A RISC) -- instead of the very CISC special purpose LISP and Smalltalk and Prolog machines proposed up to that date -- and SPUR which was a full set of chips to build a 32 bit workstation.

SPARC is in fact based on the RISC I / RISC II ideas.

Dave Patterson himself now says register windows were a bad idea, which they would not have implemented at Berkeley if they had as good compiler technology in the early 80s as Stanford had for MIPS.

XTensa is from what I understand everywhere! You just never see it or hear about it because until Espressif no one who used it ever exposed it to allow the end user to program it. I believe Cadence was not happy about Espressif doing that, and releasing documentation on it.

[rsjsouza]

I suspect you are correct; I vaguely recall that, in the RISC/CISC discussions of the early 1990s, one of the arguments that "x86 will be killed by the modern RISC architectures" was due to the presence of a few multi-cycle instructions that were despised by the RISC initiative. As with everything, "where there is a will there is a way", the x86 was modified to accommodate RISC-like architectural features after some startups came with their "front ends" for x86.

Interesting article:
https://www.extremetech.com/extreme/323245-risc-vs-cisc-why-its-the-wrong-lens-to-compare-modern-x86-arm-cpus

[TomKatt]

If you want to REALLY understand how a CPU works, write a compiler for it. Talk about drinking from a fire hose.

Back in the day, I did just that for my C64.  Not only did I learn asm, but when you get that deep in the weeds you start seeing the relationships between the instructions from their binary bit patterns...  I recall that I could determine things like what type of branch an opcode was using by certain bits in the opcode.   Then you can start to envision how the cpu translates the opcode bits into the various command actions.  Really very interesting.

BUT - been there, done that.  I have better things to do with my time these days lol.  Give me a good high level language so I can get my project done - memory and speed are cheap these days.  That said, I still code many AVR projects in BASIC (Bascom AVR) 

[brucehoult]

I suspect you are correct; I vaguely recall that, in the RISC/CISC discussions of the early 1990s, one of the arguments that "x86 will be killed by the modern RISC architectures" was due to the presence of a few multi-cycle instructions that were despised by the RISC initiative. As with everything, "where there is a will there is a way", the x86 was modified to accommodate RISC-like architectural features after some startups came with their "front ends" for x86.

That's about implementation techniques. RISC/CISC is about the instruction set, which is an immutable property. A statement such as "386 is CISC but Pentium III is RISC" are nonsense since they execute the same instructions.

The x86 has always been close to RISC because all the normal instructions have at most one memory operand and there is no indirect addressing.

As an example, if local variables A, B, and C are pointers to integers and the variables are stored in the stack frame then on the VAX you can do *C = *A + *B as ADDL3 @B(SP),@C(SP),@A(SP)

This instruction is 7 bytes long, and does 5 memory loads and one store. It demonstrates both multiple memory operands and indirect addressing.

Even "CISC" x86_64 needs six instructions (and 24 bytes of code) to do the same thing the VAX can do in one. Arm64 also needs six instructions and 24 bytes of code. RISC-V needs seven instructions but only 14 bytes of code.

Code: [Select]

  2b: 48 8b 44 24 08        mov    0x8(%rsp),%rax
  30: 48 8b 00              mov    (%rax),%rax
  33: 48 8b 54 24 10        mov    0x10(%rsp),%rdx
  38: 48 03 02              add    (%rdx),%rax
  3b: 48 8b 54 24 18        mov    0x18(%rsp),%rdx
  40: 48 89 02              mov    %rax,(%rdx)


Code: [Select]

      24: a940a3e9      ldp x9, x8, [sp, #8]
      28: f9400108      ldr x8, [x8]
      2c: f9400129      ldr x9, [x9]
      30: 8b080128      add x8, x9, x8
      34: f85f83a9      ldur x9, [x29, #-8]
      38: f9000128      str x8, [x9]


Code: [Select]

  18: 67c2                ld a5,16(sp)
  1a: 639c                ld a5,0(a5)
  1c: 6722                ld a4,8(sp)
  1e: 6318                ld a4,0(a4)
  20: 97ba                add a5,a5,a4
  22: 6762                ld a4,24(sp)
  24: e31c                sd a5,0(a4)

Only one of the x86 instructions is slightly non-RISC in loading from memory and adding to %rax in one step.  That's why the x86 is fewer instructions than the RISC-V.

Arm64 is one instruction fewer than RISC-V because of the "load pair" instruction to load B and C into registers.

Incidentally RISC-V recently added load pair and store pair instructions as a standard extension for the 32 bit ISA only -- using the opcodes used for load/store double in the 64 bit ISA.

[westfw]

Even x86 has at most one memory operand per instruction

Um.  movsb/movsw/etc.
Many math instructions allow memory as src/dest to be memory, meaning at least RMW memory cycles.  Those include operations with immediate values; nominally also memory references ("addl $0xdeadbeef, (%edi)" or something like that.)
lds/etc loads two words of memory (not a big deal any more, but definitely more than one memory cycle back in the 8086 days. (my "good" knowledge of x86 doesn't go much past 8086.))

You didn't mention the dead CISC!  VAX. M68000. NS16000/32000. Pr1me. iAPX432. Interdata 7/32. HP3000. Data General Eclipse.

Ah.  True.
68k lives (limps) on as "Coldfire" (now at NXP), along with several other old Motorola archs.
I'm not sure that the "highly proprietary" architectures should count?  Mainly I'm talking about those that have been highly touted as "standards" (MIPS, PPC) or become defacto standards (eg 8051)

8080/z80, 8051, PIC are not really either CISC or RISC. ... They mostly have quite RISC-like register-to-register instructions

Except that the registers aren't even close to "general purpose" (which I consider an important aspect of RISC.)  The "Accumulator" architectures are a relatively important subset, at least historically.  A lot of their CISC-ness seems to come from "well, we want to do SOME things without using the AC; what can we actually implement?")

I believe Cadence was not happy about Espressif [publishing the Xtensa instruction set

I'm pretty sure that the first Xtensa instruction set manual I downloaded was direct from Cadence (although also IIRC, not easy to find.)  Copyright 2013, so that might have been reactive rather than "voluntary."

[westfw]

If you want to REALLY understand how a CPU works, write a compiler for it.

I'm not sure about that.  You can write a "pretty good" compiler using only a fraction of the features of a CPU.

In fact, that's part of the anti-CISC argument - designers were adding all sorts of instructions to their architectures that were nearly impossible for compiler writers to use effectively in a program (sure, you could have your aged assembly language programmers use them in libraries, but ... that was less interesting.)
You also see this with the "un-optimized" code that comes out of some compilers (avr-gcc with -O0 and certain versions of the Microchip PIC compiler in "free" mode, for example.)
I was very unhappy when the compiler class I took in college spent so little time on optimization, or even converting generic 3-operand instructions to code for a specific CPU.  But that used to be where a lot of compiler writers stopped.

[TomKatt]

You also see this with the "un-optimized" code that comes out of some compilers (avr-gcc with -O0 and certain versions of the Microchip PIC compiler in "free" mode, for example.)
I was very unhappy when the compiler class I took in college spent so little time on optimization, or even converting generic 3-operand instructions to code for a specific CPU.  But that used to be where a lot of compiler writers stopped.

I'd suggest that compiler optimization is a tenure of it's own compared to simply converting commands into asm opcodes...  It's rather straightforward to match asm and addressing options. but determining the most efficient sequence of instructions is much harder.  Not to mention that 'optimized' doesn't really have a definition...  Speed? Size? Readability?  Writing a good compiler is no easy task.

[brucehoult]

Even x86 has at most one memory operand per instruction

Um.  movsb/movsw/etc.

I specifically said "normal instruction". The string instructions stand apart from the rest of the ISA, and while compact in code they have except in the very first chips usually been microcoded and considerably slower than a loop of normal instructions.

Many math instructions allow memory as src/dest to be memory, meaning at least RMW memory cycles.

That is one memory operand. One address. One use of the page tables or other address translation or access control mechanism.

RISC-V and Arm also have RMW instructions e.g AMO{ADD,AND,OR,XOR,SWAP,MIN,MINU,MAX,MAXU} in RISC-V.

Some implementations actually execute these deep in the memory system not on the CPU e.g. in a cache controller or even in a peripheral on its registers. This is supported in Berkeley's "Tilelink" TL-UH bus's ArithmeticData and LogicalData message types. I believe recent AMBA specs support something similar.

Some implementations trap to M mode and then use LR/SC to implement them e.g. "LR; add; SC; BNE retry"

And some implementations actually execute a RMW in the CPU.

68k lives (limps) on as "Coldfire" (now at NXP), along with several other old Motorola archs.

Essentially the RISCish subset of 68k.

I'm not sure that the "highly proprietary" architectures should count?  Mainly I'm talking about those that have been highly touted as "standards" (MIPS, PPC) or become defacto standards (eg 8051)

x86 is highly proprietary.

MIPs and PPC were highly proprietary until they got into trouble.

Others copy successful ISAs, whether they are proprietary or not, sometimes leaving out the patented parts (Loongson) or simply waiting for any patents to expire (8051).

8080/z80, 8051, PIC are not really either CISC or RISC. ... They mostly have quite RISC-like register-to-register instructions

Except that the registers aren't even close to "general purpose" (which I consider an important aspect of RISC.)

Register-rich accumulator ISAs are certainly RISC, just a less convenient subset of it. Sure it's nice to be able to do "A += B" or "A = B + C" for arbitrary choices of registers, but saying "the dst can only be A" in order to reduce the number of bits in an instruction is a valid choice within RISC, and a further restriction not a violation.

[NorthGuy]

I was very unhappy when the compiler class I took in college spent so little time on optimization ...

Some basic things which may seem easy, such as optimizing register assignments, are not that easy to implement. You can communicate some ideas on what can be done and where to start, but going into details is way too much for a compiler class.

[brucehoult]

If you want to REALLY understand how a CPU works, write a compiler for it.

I'm not sure about that.  You can write a "pretty good" compiler using only a fraction of the features of a CPU.

That depends on the CPU!

RV32I is a nice fit for compiling all of C/C++ [1] and similar languages, with just 37 instructions, every one of which is used by the compiler, given suitable source code. Of course if your program doesn't do any XORs then the XOR instruction won't get used etc.

In fact, that's part of the anti-CISC argument - designers were adding all sorts of instructions to their architectures that were nearly impossible for compiler writers to use effectively in a program (sure, you could have your aged assembly language programmers use them in libraries, but ... that was less interesting.)

That is true, but it's even worse than that -- those instructions were often just convenience for assembly language programmers, but actually executed slower than using several simpler instructions.  Patterson found many examples of this for VAX 11/780, and Cocke for IBM System/370.

Your aged assembly language programmers should not even use them in libraries, only in quickly written application code where programmer productivity was more important than machine efficiency.

I was very unhappy when the compiler class I took in college spent so little time on optimization, or even converting generic 3-operand instructions to code for a specific CPU.  But that used to be where a lot of compiler writers stopped.

I took compiler classes at university in 1983/4 and actually worked on back-ends for VAX and M6809.

We certainly covered .. and implemented .. the most important optimisations such as constant expression evaluation, strength reduction, common subexpression elimination, code motion out of loops.

We studied and implemented register allocation but the algorithms at the time were pretty crude. Patterson has said that RISC-I and RISC-II would never have used register windows if they'd known a good register allocation algorithm for their compiler.

One of the largest amounts of time spent was on trying to match address calculation DAGs to all the crazy addressing modes, and figuring out when to use arithmetic rather and an addressing mode, and when to bail out of trying to match the whole address calculation DAG to an addressing mode and just emit an LEA with what you had, and then start again from that.

And using complex addressing modes was at odds with common subexpression elimination (and still is today with x86 and Arm scaled indexed addressing).

Pure RISC with no more than base+offset addressing is SO MUCH easier to generate code for. You just need a few more instructions and a few more temporary values in registers. But those are easily subjected to all the normal optimisations -- common subexpression elimination, moving some of it out of loops, etc.


[1] with soft float used if the program uses FP, you can add F or D extensions if this is performance-critical.