Short Article: Cortex-M0 assembly with GDB via a BlackMagicProbe

[techman-001]

Why isn’t Assembly Programming more popular, is it because Assembly is hard, complicated or non productive ?

Are the alternatives better, faster, smaller, easier to write ?

Perhaps Assembly lacks the (false) promises of 'libraries', 'portability'  or 'no hardware knowledge required' ?

I explored Assembly using an equates file transformed from the CMSIS-SVD to make it easy to write maintainable assembly code, my article is below:

https://mecrisp-stellaris-folkdoc.sourceforge.io/projects/blink-f0disco-gdbtui/doc/readme.html

[DiTBho]

Why isn’t Assembly Programming more popular, is it because Assembly is hard, complicated or non productive ?

I was paid (and I am somehow still paid) to program PowerPC 4xx in assembly but only for critical sections of code.

In 90s I was paid to program in assembly a full applications for 68xx and only because the C compiler was too expensive and generated more bloated code.

Nowadays you can download { gcc, sdcc, lcc, llvm/clang, ... } for free, and 90% of time they support the target you need; in the 90s you had free assembly compiler provided with evaluation boards, but you had to pay a lot of money for the C compiler.

This could be one of the reasons 

In the 2000s, although the first R2000 was mostly a demo toy, evaluation boards were released for both R2K and R3K, and companies like IDT also included a CC1 compiler for Windows. It was free. Limited to 1.000 lines per C-module, but it was a step ahead, and here I noticed the difference!

Motorola did something similar with their PPC601 and 604 evaluation boards: free CC1 compiler included! Wow, it was a shock to hear for my boss 

With the IDT-R2000, you have no built-in cache, the cache circuits are external to the CPU and can be turned off turning the "cache" into a fast ram. Awesome! I still love it! As I love there were R2000 cpu modules where the cpu is a "MIPS but without pipeline". It's a "multi-cycles MIPS" with no delayed slot, no hazards, no problems, it was as simple as programming a 68000! I programmed it in C as my first attempt to program a RISC with a high level language!

The central process unit of the first SONY Playstation1 is a MIPS R3000A-compatible 32-bit RISC CPU with 5 KB L1 cache running at ~33 MHz. It has pipeline, and I programmed it in assembly and C with Code-warrior that offers a special debugging channel over a special serial channel released by SONY only for developers. The package contained a special black-colored debugging PlayStation unit, a serial cable for connecting the unit to a PC and a CD containing PlayStation development tools, among other items. A bit expensive, but not too bad, the debugging unit helped a lot, making the experience simpler than a PowerPC.

Here you may wonder, so were Sony-Playstation 1 games written mainly in C or MIPS assembly?

Well, ... talking about my specific experience, which is not a great professional experience at 360 degrees since I've never been a video game writer but rather a simple consultant, however, I can say the vast majority of PS1 demos and code I encountered were written in some variant of C; for example I encountered a lot of "Code-Warrior C" with a lot of "#pragma" and blocks of assembler to allow direct manipulation of the GTE.

I can't say why it was developed this way, I mean I can't talk for my customers' choices, I can speculate on "because this the best compromise" to reduce the time to market. My paid tasks were just testing/fixing that parts.

The R2000 was a personal experience, I paid myself to buy the board as training experience, and it was  for sure the greatest experience with RISCs; for sure a better experience than programming a PowerPC 601! Even though it's been more than 10 years, I still remember my frustration with R4xxx, R5xxx and R10K, and let me say, those RISC-beasts offer better performance, and starting from R10K they also offer superscalar performance (2 instruction launched in parallel), but still after 20 years, they are so complex that when you look at the GCC mailing list you find people claiming there are die-hard issues.

[DiTBho]

smaller

Code: [Select]

  0:0f 8e 01 ff bd 00 bd bd 00 df bd 00 cb 81 63 27 1a 81 67 27 1f 81 73 27 2b 81 6d 27 35 81 70 27
 20:3f 81 75 27 68 81 64 27 6e 20 df bd 00 cb bd 01 35 b7 01 d4 b6 01 d4 bd 01 19 ce 01 da a7 06 bd
 40:01 01 20 c6 bd 00 f0 ce 01 ec bd 01 24 bd 01 01 20 b8 bd 01 5c ce 01 ec bd 01 24 bd 01 01 20 aa
 60:bd 01 9d ce 01 ea bd 01 52 bd 01 01 20 9c 8d 5b bd 01 35 36 bd 01 19 8d 5d 32 c6 fa 3d 05 05 18
 80:8f 8d 1e 8d 7c 86 00 b7 70 00 7e 00 0a 86 01 b7 70 00 ce 01 e2 20 d7 86 02 b7 70 00 ce 01 e6 20
 a0:cd 18 08 18 09 27 11 3c ce 01 48 20 03 ce 01 4c 09 26 fd 18 09 26 f6 38 39 36 4a 32 39 86 30 b7
 c0:10 2b 7f 10 2c 86 0c b7 10 2d 39 b6 10 2e 84 20 27 f9 b6 10 2f 39 7d 10 2e 2a fb b7 10 2f 39 86
 e0:80 b7 10 39 18 ce 00 64 8d b7 86 00 b7 01 d4 39 b6 01 d4 b7 10 30 b6 10 30 84 80 27 f9 b6 10 31
100:39 8d 06 ce 01 ef 8d 01 39 a6 00 27 0b 8d c7 08 20 f7 18 ce 00 64 8d 89 39 84 0f 8b 30 81 39 23
120:02 8b 07 39 36 44 44 44 44 8d ee a7 00 32 84 0f 8d e7 a7 01 39 81 30 25 16 81 39 22 04 80 30 20
140:e2 81 41 25 0a 81 46 22 06 80 41 8b 0a 20 d4 86 00 39 8d d0 08 08 17 8d cb 09 09 39 4f b7 01 d6
160:b7 01 d7 8d 8b b7 01 d5 86 01 b7 01 d7 8d 81 b0 01 d5 bb 01 d6 25 e5 b7 01 d6 b6 01 d7 4c b7 01
180:d7 81 08 26 e8 b6 01 d6 16 4f ce 00 08 02 8f 17 b7 01 d6 b6 01 d5 bb 01 d6 b7 01 d5 39 cc 12 34
1a0:39 ce 10 00 86 01 c6 01 a7 21 86 01 a7 23 1f 23 01 fc 1a ee 14 e7 21 86 01 a7 23 1f 23 01 fc ec
1c0:14 18 ff 01 d8 b3 01 d8 fd 01 d8 39 00 00 00 00 00 00 00 00 01 de ad 00 00 00 61 64 63 5f 63 68
1e0:40 00 20 75 70 00 20 64 77 00 48 49 4c 4f 00 0d 0a 00 00 00 00 00 00 00 2d 2d 73 74 61 63 6b 2d

With CISC-ish stack machine like 6800, you can write very "high code density" programs in assembly.
You can't do it with RISCs.

In the above example I don't need to respect any ABI, so I don't need to assure that a function needs to save the inner used registers and restore them on return to the caller. This saves a lot of instruction and makes the program smaller. But it's a dirty trick that you do when you have limited RAM. In the above example the ram is 512 byte for code, variables and stack.

It's somehow like playing "Tetris" 

I've done a lot of "dirty stuff" like that for data-loggers at many oil companies and never questioned anything, neither why they charge a lot of money for a barrel of oil and they want a single-chip system rather than the same chip in expaneded mode which would allow to have more ram. Probably because ... expanded mode requires more integrated circuit chips, the more things you have, the higher the probability that something will break. But I don't know. I did what I was paid for without questioning. Just it. 

[DiTBho]

(false) promises of 'libraries'

During my recent job experience I learned one simple lesson: I am not an expert of any assembly, I am someone who has some skills and none of my colleagues is willing to deal with assembly code, but in terms of modern quality of the code, you need to do some analysis on the code, and this requires you to describe each module in terms of interfaces, error propagation, etc.

I have some recent job experiences on that, things that requires you concepts from university courses like "software engineering" and "software design", "software life-cycles", etc, things for which you cannot do any analysis in pure assembly in any practical way, even because assembly code does not even has the notation of "data type", which makes analysis impossible to be done automatically, so here you need to allocate more human resources.

Practically, someone who instruments the code for a debugger and uses gdb or similar like you showed in your article but with more complex code and under all the constraints required by a "test report".

I assure you: for my job I do isolate all the critical parts and write them and only them in assembly, but when I have to test and verify these parts ... well, it's not a pleasant experience, especially when you are under pressure.

So here my answer is: no, they are not "false" promises, practically they are true! "false" promises, since C or high-level languages (like Ada) here make a big difference 

[westfw]

Or, you know, you could start with the .h files (for C) provided by most vendors, and do some minor and mostly automateable text-editing to make them assembly-language compatible.  Like we did ~6 years ago as part of this thread: https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg506574/#msg506574
https://github.com/WestfW/Minimal-ARM

That way you'd have assembler code that has approximately the same symbols as the C code that many people are used to...

I've said before that the biggest impediment to Assembly Language programming these days is the lack of an standardized environment used by a significant community.  Back when I programmed assembly language for a living, there was standard syntax (I mean, only your computer vendor would bother writing an assembler.  Maybe some universities, but they'd be pretty compatible by necessity... (Macro-10, FAIL, MIDAS))  There were standard macro packages and even standard register naming conventions, and most people used them.

Microcomputers pretty much changed all that. 8080 vs Z80 mnemonics for the same instructions.  The idea that a company that didn't sell hardware could write an assembler and SELL it.   Hopelessly complex instruction set syntax (x86!) that was only implemented by expensive assemblers, with others offering "simplified" versions (MIT x86 cross-assembler for PCC.)
Heh - the idea of Cross Assemblers in general, and/or the need for them is a bit harmful,  Essentially unlimited horsepower to process the code for the tiny little chip...


If one believes that assembly language development is a good thing (jury is out), the current state of affairs where you download half-a-dozen obscure tools from nearly as many separate sites, do weird magic, and wind up with tools that don't quite match the chip-vendor's documentation, or the "other guy's" code ... just isn't going to cut it.  :-(