Writing an ARMv2 assembler in Forth

Introduction

See sources.

This article is about a Gforth implementation of a simple ARMv2 macro assembler. It is loosely related to a series of articles about an ARM Forth dialect. (part 1 / part 2)

My idea for this assembler was to approach the conventional ARM syntax in a Forth way (all words) that directly assemble into the current word, side idea was to make it as simple as possible so it can be compiled by a very light Forth (e.g. ARM-ForthLite) with few primitives.

Generating opcodes into words is useful as a way to extend low level Forth primitives, they can be comfortably defined with the assembler in some sort of inline mode. (note : this feature apply less to "high level" multi platform Forth such as Gforth though)

This assembler was sketched out while i was making my ARM based Forth as some sort of side exploration, i later took the opportunity to redo it from scratch as i felt it would be a fun project that may be useful for Acorn computers stuff / my next ARM based Forth.

Note : Gforth is a standardized Forth that works well on Linux, it has many features, the assembler code can be pasted in the Gforth command line interpreter to test it.

Mainly due to my fondness for this subset (RISC, elegance with pragmatic quirkiness etc.) + associated interest of early Acorn computers, ARMv2 is a subset of late 80s up to now 32 bits ARM (ARMv2 up to ARMv7), it works mostly unchanged along 30+ years of history and is still widely used although slowly replaced by 64 bits ARM. The instruction set is very small.

Some of the resources i used to build this :

• ARMv1 documentation is impressively to the point (only 8 pages for all the instructions !)
• ARMv2 documentation for more details and multiply instructions

Here is a syntax comparison between the Forth ARMv2 assembler and a conventional assembler (BBC BASIC inline assembly) for the same program :

The assembly code is directly inserted (inlining) into ARCHISMALL_ARMv2_CODE word, the last line mark the end of the assembly code so the content can be retrieved later on through the ARCHISMALL_ARMv2_CODE_END constant.

The ARM code looks close to the conventional syntax albeit with some differences :

• it looks reversed due to Reverse Polish Notation, this is due to Forth syntax, there would be parenthesis if it was LISP !
• there is no commas
• some immediate values are followed by the imm word as a way to distinguish them from register operands
• labels use variables so they require a definition, most annoying part of the assembler perhaps although fixable in various ways (see conclusion)
• data transfer instructions use a [] word as a way to distinguish between pre-indexed and post-indexed, doesn't differ much as it still use the same elements

Raw Opcode output

The implementation map ARMv2 mnemonic to a Forth word (a mnemonic = a word) so it looks quite close to the conventional syntax, some of the mnemonics definition only differ by a word for mnemonics that just flip some bits. (e.g. andeq vs andeqs)

90% of the assembler code is code duplication and merging bits together with OR !

Words

Mnemonics

Mnemonics definition are very short and looks like this :

They all end up with l, which emit the computed opcode into the current definition then advance by 4 bytes :

Most "heavy" computation of the assembler happen in the encoding of data transfer instructions through ARM2_SDT (especially) and ARM2_MDT words (also immediate value encoding), single data transfer instructions have many options / different arguments length to support either an immediate operand or a register which can also be shifted.

Here is four type of single data transfer instruction :

The block data transfer word consume a list of registers as operand :

Here ARM2_MDT word (that is used by stmia) consume stack values until 16 values are consumed or a value isn't in the [0,15] range. (this is the case of what is left on stack by {} which act as an exit condition)

Some implementation quirks as my goal was to keep it pragmatic / straightforward :

• had to define my own and because it collide with the corresponding assembly mnemonics
• no ARM supervisor stuff support (don't need it), missing bits are easy to add though
• lots of redundancy on some instructions definition, could have been avoided by generating them, still okay as the ARMv2 set is tiny
• didn't go for individual square brackets as it may collide with some predefined words, also use one more argument
• i don't support range syntax for block data transfer although easy to add
• no errors handling at all, even for immediate value encoding (will produce an underflow)
• many pseudo instructions are unsupported yet such as using a label with regular instructions
• some symbols such as imm does not map to the expected symbol # due to collisions again (same issue as and but less critical and an easy fix if needed)
• didn't implement data definitions yet (i use l, directly instead), an easy change though (define .word or dcd that map to l, for example)

This approach probably dates back to early Forth assemblers (Gforth ARMv4 assembler looks similar) and demonstrate how useful Forth can be as a way to quickly get a nice and powerful macro assembler working with minimal amount of effort from a tiny Forth core with near zero amount of parsing, the assembler can then be used to extend the lower level Forth primitives in a comfy way.

Also quite cool that the assembler syntax doesn't depart much from conventional syntax, it still looks readable (in a RPN way) although a bit verbose. (more optional arguments may be a quick way to fix this)

It also show the elegance of the ARMv2 subset, a simple but working subset for most tasks with powerful bits !

Only gotcha is that i couldn't find a way to make labels looks like conventional labels in Gforth (shouldn't require variable definition) as the label name will get compiled into a new word and thus break the inlining, it is certainly doable (could use a buffer instead of putting opcodes into a definition) but it departed too much from the simplicity goal, may be easier with a custom Forth by hacking it such as allowing multiple dictionary space.