MCUs with toolchains that support assembly language programming

[slugrustle]

I'm fond of programming microcontrollers in assembly and have mostly stuck with 8-bit PICs.  I've done an ATtiny AVR once and a Holtek HT48R003 (very PIC-like, excellent IDE).  I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.  Does anyone here have favorites?

Microchip switching from MPASM to PIC-AS was annoying, but I was able to figure it out.

[John Coloccia]

Pretty much everyone.

What's your poison? The arm mcus have a dirt simple assembly. Hard to imagine why this is fun, but if you're looking for simple...

[brucehoult]

I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.

All of them, obviously.

Older ones such as older PIC, 6502, z80 need to be programmed in assembly language unless you're willing to throw away large amounts of ROM space or execution speed or both..

Does anyone here have favorites?

The WCH family of 32 bit RISC-V microcontrollers, but especially the cute little $0.10 CH32V003 with 2k RAM and 16k flash and 48Mhz.

But anything RISC-V or Arm is equally suitable for both asm and C programming. AVR and MSP430 too.

The files attached to the following message contain complete asm source for blinky on CH32V003.

https://www.eevblog.com/forum/microcontrollers/ch32v003-blinky-in-riscv-assembly/msg4976077/#msg4976077

[shabaz]

There's a similar recent thread here, where the OP wished to program in assembler:
https://www.eevblog.com/forum/microcontrollers/suggestions-for-a-microcontroller-(general-purpose)/

[slugrustle]

I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.

All of them, obviously.

Well, if they don't have good documentation of the register set, memory map, or instructions, that would be a hindrance.  If there's no ready made assembler conducive to use by a human, that would also be annoying.  PIC-AS is more like that than MPASM was, for example (but still workable).  The toolchain can sometimes be difficult or annoying to set up for an assembly language project.

I have to say that Holtek's IDE and assembler were just 100% fantastic for this on their 8-bit MCUs.

Thanks for highlighting ARM, RISC-V, AVR, and MSP430.  Those make sense as opposed to something like RL78.

[brucehoult]

something like RL78.

Oh gawd.

I don't know any reason you'd choose that unless you have NEC 78K assembly language code from the 80s you want to port to something newer with as little effort as possible. Or maybe you need some specific interface or certification that you need -- in which case you'll already know you need it.

But even if you're in that kind of field, and love Renesas, they do have lines with modern Arm and RISC-V cores too.

[John Coloccia]

something like RL78.

Oh gawd.

I don't know any reason you'd choose that unless you have NEC 78K assembly language code from the 80s you want to port to something newer with as little effort as possible. Or maybe you need some specific interface or certification that you need -- in which case you'll already know you need it.

But even if you're in that kind of field, and love Renesas, they do have lines with modern Arm and RISC-V cores too.

I had to work with on one of the NEC 4-bit micros, which for some reason I associate with the rl78.

FWIW, I have no particular love for Renesas. RIP NEC, Hitatchi, Mitsubushi....did I leave anyone out? LOL

[brucehoult]

Well, if they don't have good documentation of the register set, memory map, or instructions, that would be a hindrance.

If there are C headers then you can read them and convert the definitions you need to asm.

If there's no ready made assembler conducive to use by a human, that would also be annoying.  [...] The toolchain can sometimes be difficult or annoying to set up for an assembly language project.

All the ISAs I mentioned are supported by both GCC and LLVM [1]. That means uniform support for all modern standard C/C++ features, consistent machine-independent optimisation, and consistent support for most aspects of assembly language, and easy ability to mix C and asm in a project. In fact it's easiest to build even pure asm projects by giving the source files to the gcc or clang driver program and let it call the assembler and linker with the right options for you.

With the GCC toolchain you can just install the binutils assembler / linker / disassembler / library tools if you really want, but it's very convenient to have the C compiler too.

With the LLVM toolchain there is no stand-alone native assembler, assembly to a native .o is done by the clang C compiler, and then linked by lld.

[1] though LLVM might still be experimental for AVR and MSP430, I'm not too sure. Back-porting to older and <32 bit ISAs such as these (and 6502!) is a relatively recent thing for LLVM

[brucehoult]

I have written assembler code for the MSP430 parts, which are 16-bit Von Neumann MCUs.

They're PDP-11s with twice as many registers (14 [1]) compensated by a few missing addressing modes [2] to keep the instructions at 2-bytes :-)

[1] R2 and R3 don't really exist as GPRs, but are instead used to read/write the status register (R2) or generate common constants -1, 0, +1, +2, +4, +8.

[2] 4 for src operands ... Rn, @Rn, @Rn+, 0xNNNN(Rn) ... and 2 for dst ... Rn and 0xNNNN(Rn) ... plus the same PDP-11 special-casing of the PC to get immediate (@PC+) and relative (0xNNNN(PC)).

[nctnico]

I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.

All of them, obviously.

Older ones such as older PIC, 6502, z80 need to be programmed in assembly language unless you're willing to throw away large amounts of ROM space or execution speed or both..

Sorry but this is plain wrong. What is needed are A) a good C compiler optimised for 8 bit platforms and B) a different coding style (like not using pointers so much). A good 8 bit oriented C compiler will produce better code compared to a skilled assembly programmer. And a whole lot quicker too. Microhip's PIC compiler and Keil's 8051 compiler are good examples of such compilers.

[brucehoult]

I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.

All of them, obviously.

Older ones such as older PIC, 6502, z80 need to be programmed in assembly language unless you're willing to throw away large amounts of ROM space or execution speed or both..

Sorry but this is plain wrong. What is needed are A) a good C compiler optimised for 8 bit platforms and B) a different coding style (like not using pointers so much). A good 8 bit oriented C compiler will produce better code compared to a skilled assembly programmer. And a whole lot quicker too. Microhip's PIC compiler and Keil's 8051 compiler are good examples of such compilers.

Using pointers, recursive functions, etc is an integral part of C programming. If you have to avoid those in order to get efficient code then your compiler is not producing efficient code from C.

I have extensive experience with 6502 and Z80 and know that what I say is true for them.

I have not written much PIC code, but a little, and I've read through the instruction sets for them, and the earlier ones are extremely hostile to high level languages, even to the point of anything before PIC18 (2000) not being able to call functions to an arbitrary depth with inaccessible on-chip return address stacks with 2-8 entries.

I note that PIC16 is still produced and has a maximum of 1K RAM and 28k instructions of flash and run at 32 MHz, which is considerably bigger than the very popular ATTiny85 which is 512 bytes of RAM, 8K bytes of flash (4k instructions), and 20 MHz clock and is a very capable target for arbitrary C code. In fact it's the same RAM as an ATmega168, but more than 3x the amount of program code space. It's more code (but less RAM) than the very popular ATMega328 found in e.g. Arduino Uno.

You simply can not make a conforming C compiler for PIC16 without resorting to interpreting some more sensible instruction set.

Fortunately the interpreter for a simple bytecode stack machine can be pretty small, and you've got a lot of flash anyway, and with 32 MHz you can possibly still end up faster than a 1 MHz 6502.

And don't tell me that no one uses PIC16 now. It's probably still 2/3 of 8 bit PIC unit sales. And unlike the low end AVRs you can't program it in proper C.

[brucehoult]

This looks interesting as a base for writing more arbitrary programs on pre-PIC18.

---

PICoForth is the compiler for PIC12 and PIC16 families of famous Microchip's microcontrollers

CALLING STYLES

there are 3 styles of calling words:

inline - the word is compiled inline. usesful for simple words like dup, drop etc and for words that are called few times. :pic-inline .... ;

simple call - uses call and return instructions to call the word there is hardware limit to 8 levels. Many of library words consumes 1 level of stack. The interrupt consumes 1 level of stack too :pic ..... ;

return stack call there is no limit to 8 levels of stack, the return address is stored in return stack. This method is slower than simple call and consumes 2 bytes of ram (in return stack) :pic-rcall .... ;

[nctnico]

I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.

All of them, obviously.

Older ones such as older PIC, 6502, z80 need to be programmed in assembly language unless you're willing to throw away large amounts of ROM space or execution speed or both..

Sorry but this is plain wrong. What is needed are A) a good C compiler optimised for 8 bit platforms and B) a different coding style (like not using pointers so much). A good 8 bit oriented C compiler will produce better code compared to a skilled assembly programmer. And a whole lot quicker too. Microhip's PIC compiler and Keil's 8051 compiler are good examples of such compilers.

Using pointers, recursive functions, etc is an integral part of C programming. If you have to avoid those in order to get efficient code then your compiler is not producing efficient code from C.

But still, using C is way more efficient compared to using assembly. And that is the whole point. For example, Keil has an extensive document about the best coding strategies for using C in combination with the 8051. If you just dismiss C because you can't use all of it on a platform, then you are throwing out the baby with the bathwater.

[peter-h]

A good 8 bit oriented C compiler will produce better code compared to a skilled assembly programmer.

I did a lot of this in the 1980s, asm and IAR C.

Asm was much faster but now I know a bit more about C I can see a lot of the difference was due to the integer promotion in C.

asm:
add a, c

C:
ld l, a
ld h, 0
ld b, 0
add hl, bc
ld a, l

And a whole lot quicker too

That is true for sure

For many years I sold a C programmable Z180 based RS232/4xx comms box and we sold the Hitech C compiler with it, the compiler going for a cool £450 We bought a load of licenses just as Hitech sold out to Microchip. That compiler was better than the IAR one but only a bit. Its printf library was far better because it used fast non-IEEE floats, whereas IAR's runtimes were pig slow, and lazily written. I wrote a lot of custom comms-related runtimes for the Hitech compiler.

And I think a big part of the reason people say asm is much faster than C is crap runtime libs, often written in C and poorly. IEEE floats, pointless in most embedded work, are up to 10x slower than "hacked" ones. Integer promotion is another part of it which prevents efficient 8 bit algorithm implementation (but you may never be doing that).

ARM32 asm is also pretty horrible.

And finally modern chips are so fast that performance is rarely an issue. But for the low end ones you still need to do asm because of limited flash alone.

[Siwastaja]

Asm was much faster but now I know a bit more about C I can see a lot of the difference was due to the integer promotion in C.

Yeah. C was clearly designed for 16-bit machines. Using it on 8-bit machines requires a bit care; lazy programmers (me included) use a lot of int, and integer promotion rules also promote to int or unsigned int, which are by definition at least 16 bits. Which is inefficient on 8-bit machines.

Some tackle this by compiler options like -mint8 (AVR-GCC) (which makes the compiler non-standard-compliant and modifies int to be 8 bits wide) but to me that seems like horrible idea. Just remember the target you are writing to when performance matters. And on very small MCUs it often does.

[Siwastaja]

ARM32 asm is also pretty horrible.

Why so? I find it pretty nice and simple. Basically the only complaint I have would be inherent lack of loading arbitrary immediate values and instead having to do PC-relative load and put constant pools close-by, but we do have the handy @ syntax to automate that, not too bad?

[brucehoult]

I'm curious which microcontrollers currently in mass production have toolchains and documentation conducive to assembly language programming.

All of them, obviously.

Older ones such as older PIC, 6502, z80 need to be programmed in assembly language unless you're willing to throw away large amounts of ROM space or execution speed or both..

Sorry but this is plain wrong. What is needed are A) a good C compiler optimised for 8 bit platforms and B) a different coding style (like not using pointers so much). A good 8 bit oriented C compiler will produce better code compared to a skilled assembly programmer. And a whole lot quicker too. Microhip's PIC compiler and Keil's 8051 compiler are good examples of such compilers.

Using pointers, recursive functions, etc is an integral part of C programming. If you have to avoid those in order to get efficient code then your compiler is not producing efficient code from C.

But still, using C is way more efficient compared to using assembly. And that is the whole point. For example, Keil has an extensive document about the best coding strategies for using C in combination with the 8051. If you just dismiss C because you can't use all of it on a platform, then you are throwing out the baby with the bathwater.

You can't be a little bit pregnant.  It's either C -- ALL of it -- or it's just something like Rust or Java or zig that borrow a smaller or larger amount of C syntax.

Yes of course using a compiler will let you churn out code faster than writing in asm. But if you're not using real C then you're in an isolated backwater that can't share code with the rest of the world.

The 8051 is a VERY different animal to PIC16 and lower. You can't compare them. In many way it's not all that different in capability to 8080, just a different twist.

In particular 8051 has a proper SP with stack in RAM, used by call / return / push / pop. You can also transfer SP to a register e.g. R0/R1 and use that to access stack memory (maybe after a few inc/dec), or transfer to A and do arbitrary arithmetic before transferring t R0/R1 for memory access. Arbitrary stack access is not that different to 8080/Z80 where you do "ld hl,offset; add hl,sp; ld r,(hl)" .. 5 bytes of code which is not that horrid. And 2 more instructions/bytes to get an adjacent byte. On 8051 it'll be like "mov a,sp; subb a,#nn; mov r0,a; mov a, @r0" -- again 5 bytes of code. With adjacent bytes again then just "dec r0;mov a,@r0". The only difference is 8051 can only load to A so needs to them mov to another register before loading the next byte. And the offset is 8 bits, not 16 like on 8080 (which is fine .. I wish 8080 could save that byte of code!).

Obviously it is also much more convenient for dealing with pointers including arrays and structs than PIC16 and earlier.

Using all of C on 8051: no problem at all. Code is not that tiny, but you can DO everything.

[nctnico]

You are mistaken. 8051 has no real stack (except for a 7 deep call/return thingy IIRC). It is one of the crappiest microcontrollers to write a C compiler for.

[peter-h]

Why so? I find it pretty nice and simple. Basically the only complaint I have would be inherent lack of loading arbitrary immediate values and instead having to do PC-relative load and put constant pools close-by, but we do have the handy @ syntax to automate that, not too bad?

You are obviously an expert so you know it, but there is a lot to learn about parameter passing conventions in function calls, etc. I've disassembled a lot of my C code, when stepping through into the STM supplied libc.a (no sources provided) you have only the disassembly to work with. I spent many hours tracing through code, to find where it was expecting a mutex function to be implemented, etc.

What we did in the 1980s, with Z180 and IAR C, was to develop most of the product in C, which hugely speeded up productivity (it was a DP8344 based coax/twinax IBM compatible box, so very complex, and had to use the IAR "large model" where each function, no bigger than 4k or so, would be banked-in, so you could have up to 1MB of code on a "Z80" CPU) and then I would write bottlenecks in asm. For example, on another product which parsed HPGL, I would asm code a "sscanf" dedicated to handling only the ddddd.dddd decimal format, for which there is a very efficient hack which loads a float value directly. You could argue the same hacks could have been done in C but asm was still several times faster.

And I would suggest that is the way to do it even today - unless using something like a 168MHz STM 32F4xx + in which case you won't need asm except for special stuff like code which must never be optimised, or coding for a chip with 512 words of FLASH The latter is the only "asm only" case now... yes it does exist, but probably in stuff like toasters!

[cunningfellow]

compared to a skilled assembly programmer.

I am only an average assembly programmer and I think I beat AVR-GCC often enough in time critical parts of my hobby code.

And a whole lot quicker too.

I can't argue that point   I mix C and ASM and only use ASM if the C is too slow.  The C code gets written 10x faster than the ASM.

[westfw]

which microcontrollers [are] conducive to assembly language programming.

All of them, obviously.

You might take a look at the FTDI "VNC2" USB Microcontroller.
About the worst assembly language documentation I've ever seen, and I've been unable to find ANY description of the actual CPU architecture that might make it more understandable :-(  They assume that you'll be using their kernel, their libraries, and their C.

A lot of architectures are supported by the Gnu assembler, which is sort-of nice since you get common directives and macro language and such.  But it's an assembler aimed more at supporting their compilers, so it's not always the most pleasant assembler to use.  And the syntax it implements for a given CPU may not match the CPU vendor's syntax.

I guess you want the vendor assembly-language toolchain to be free?  That's common, but not universal.  (Eliminates the x86 family, I think.  Except that there are alternatives to the Intel/Microsoft tools.  I remember having to shell out for MASM...)

A bunch of the modern microcontrollers won't document the CPU in the chip vendor documentation.  They just refer you to the CPU IP vendor documentation.  This includes ARM, MIPS, ESP (tensilica), and RISC-V.  This CAN lead to a frustrating exercise in figuring out exactly what subset and/or extensions your particular chip can use, which what limitations might exist.  (I find the ARM Cortex-M0 particularly annoying - any orthogonality was discarded to "compress" the instructions into 16 bits, and you're left wondering "which data processing instructions support an immediate operand and what was the range of those operands?")

[brucehoult]

You are mistaken. 8051 has no real stack (except for a 7 deep call/return thingy IIRC). It is one of the crappiest microcontrollers to write a C compiler for.

That's not what the references available to me say.

The SP is located at internal address 0x81 and points to another internal address (RAM). Things stored on the stack, whether by PUSH or by function call, are accessible using normal memory reference instructions, as I showed in my previous message.

The main limitation is that the stack size is limited to the 128 bytes of internal memory that don't have another purpose, shared with global variables. However the contents are accessible and can, for example, be copied to/from a larger stack in the 64k external memory space.

Not mentioned by me previously: there is no direct way to call a function via a pointer, but this can be done (with a little fiddling) by pushing the function address on to the stack using PUSH and then doing a RET. This is most conveniently done with the aid of a small helper function stub which receives the return address on the top of the stack and the desired function address under it. Pop both values, push them back in the opposite order, and do a RET. Alternatively the indirect function address can be passed in some other way (registers or some other internal memory location) and then simply pushed on top of the return address and do a RET to the desired function.

You can also do this via "JMP @A+DPTR", which will be faster, but it once again requires a helper stub to turn the JMP into a CALL and it also means you can't use A or DPTR for argument-passing purposes.

This document is quite explicit about how it all hangs together:

https://www.silabs.com/documents/public/presentations/8051_Instruction_Set.pdf

e.g. "PUSH Direct"

----

- This instruction increments the stack pointer (SP) by 1

- The contents of Direct, which is an internal memory location or a SFR,
are copied into the internal RAM location addressed by the stack pointer

- Example:

Code: [Select]

PUSH 22H
PUSH 23H

- Initially the SP points to memory location 4FH and the contents of memory locations 22H and 23H are 11H and 12H respectively. After the above instructions, SP=51H, and the internal RAM locations 50H and 51H will store 11H and 12H respectively.

----

Similarly see the descriptions of ACALL and LCALL which prove examples very similar to those for PUSH, explicitly showing the return address saved into RAM, not some --as you say -- "7 deep call/return thingy".

And also the description of RET:

----

- Suppose SP=0BH originally and internal RAM locations 0AH and 0BH contain the values 30H and 02H respectively. The instruction leaves SP=09H and program execution will continue at location 0230H.

----

It all seems very clear to me, and contrary to what you say.

[brucehoult]

which microcontrollers [are] conducive to assembly language programming.

All of them, obviously.

You might take a look at the FTDI "VNC2" USB Microcontroller.
About the worst assembly language documentation I've ever seen, and I've been unable to find ANY description of the actual CPU architecture that might make it more understandable :-(

Dude!  You've stolen my go-to "awful ISA" example!

Perhaps you'll be interested in what I've written about it.

https://www.reddit.com/r/RISCV/comments/w5nduu/comment/ih9o9e2/

A lot of architectures are supported by the Gnu assembler, which is sort-of nice since you get common directives and macro language and such.  But it's an assembler aimed more at supporting their compilers, so it's not always the most pleasant assembler to use.  And the syntax it implements for a given CPU may not match the CPU vendor's syntax.

Right. It's not the best for writing large amounts of asm as a result. Even something as simple as assigning symbolic names to registers in a function isn't possible except by using the C preprocessor and #define (and #undef after the function).

The Arm (ONLY!) version adds a directive for this:

Code: [Select]

foo     .req r0
        add foo,#1
         .unreq foo

I don't know why that isn't propagated into the generic codebase.

A bunch of the modern microcontrollers won't document the CPU in the chip vendor documentation.  They just refer you to the CPU IP vendor documentation.  This includes ARM, MIPS, ESP (tensilica), and RISC-V.  This CAN lead to a frustrating exercise in figuring out exactly what subset and/or extensions your particular chip can use, which what limitations might exist.

I actually prefer that, as long as they give you a good pointer to it.

It's far better KNOWING they used a standard core than having to pore through the entire document to see if they made any little changes.

They certainly should tell you exactly which core and what set of extensions are used.

I find the ARM Cortex-M0 particularly annoying - any orthogonality was discarded to "compress" the instructions into 16 bits, and you're left wondering "which data processing instructions support an immediate operand and what was the range of those operands?"

Yes. This is what makes me hesitant to recommend C-M0 (Thumb1 in general) as the first asm for a beginner to learn. The actual operations provided are good, and there is a nice limited and documented set of them, well supported by compilers and other tools, but there are something like TWENTY different instruction formats with different sets of registers that can be used, different sizes of constants/offsets, and some are signed and some are unsigned.

It's a real shame because the RP2040 is a pretty nice chip, and on the lower end you have the Puya 10c chip too (PY32F002A), and also the SAMD21 family with a number of boards including Arduinos the Seeeduino XIAO etc.

Full Thumb2 is just TOO complex, too many instructions, no well-defined subsets.

Same for Arm64. H&P tried to simplify it with LEGv8 but other than a GUI simulator there is no tool support (e.g. GCC or LLVM).

Original ARMv2 or ARMv4 or something is perhaps the best option (for beginners) in the Arm ISA family. The number of instructions and instruction formats is small. But the individual instructions are complex, with conditional execution of everything and the "flexible 2nd argument".

This is where I think RV32I or RV32E or even RV64I are so great. Just 40ish instructions in four basic formats, all registers are usable by every instruction, all immediate/offsets are signed with all normal instructions having 12 bits, with a couple of special instructions with 20 bit immediate. Documented in a single cohesive (for RV32I) chapter I think 18 pages long. Well supported by tools and libraries.

And while the C extension formats are a bit more complicated and irregular -- similar to Thumb1 -- you can tell the compiler/assembler not to use them, or if it is allowed to use them then it's transparent to the programmer. You just write the full, general, instruction and the tool uses the compact one when it can. Thumb2 works in the same way, but it's a considerably larger instruction set, even in the C-M3.

Well, ok, maybe C-M3 (ARMv7-M, without FP) is the best beginner's Arm ISA.

[westfw]

A bunch of the modern microcontrollers won't document the CPU in the chip vendor documentation.  They just refer you to the CPU IP vendor documentation.

I actually prefer that, as long as they give you a good pointer to it.

It's not too bad now, depending on whether there is further indirection.
I looked at ARM earlier on (ARM7TDMI, or maybe the original CM-3 chips?) and I remember finding an ARM32 reference with "except Thumb2 doesn't have x, y, and z."  (Maybe just poor search skills or bad links.  Now, there are nice separate manuals for ARMv6m and ARMv7m (although ARMv8m was still pretty messy?)

RISC-V is a bit like that too.  You get linked to a manual and have to manually subtract from it depending on subset/etc.

(And the new AVR chips no longer have the "instruction set summary" section, cause I guess they wanted to eliminate 3 pages from their datasheets.  Instead, you get referred to a generalized "avr instruction set" manual, and ... have to subtract out the ones that don't apply to your chip (identified by mysterious designator that requires another level of indirection.  Sigh.))

[peter-h]

Yes exactly, the 32F4 is Thumb instruction set. Not trivial to pick up.