commit 44a65f8ceb98dd6b7c4692c4808b8944d0523614
author Rupert Swarbrick <rswarbrick@lowrisc.org> Tue Jul 14 11:49:16 2020 +0100
committer Rupert Swarbrick <rswarbrick@gmail.com> Tue Jul 21 11:40:27 2020 +0100
tree 98c30b92392f8674e01be692ea67b4887fb5827e
parent 7a8f53e4bb67a2627ee73aec3820e9c6fce1de9a

[otbn] A simple binutils-based assembler for OTBN

This acts as a sort of frontend for GNU as, transforming its input and
then getting binutils to do the actual assembly. The advantage of this
is that we'll be able to do linking properly (because binutils' as
will generate the relocations etc.).

The reason it's "simple" is that the parsing isn't particularly
clever. We don't support arbitrary immediates for expressions like

    ADDI x8, x0, 1 + 2 + 3

In fact, an operand has to match the regular expression:

    [^ ,+\-]+|[+\-]+

This matches things like:

    1
    x0
    my_weird_symbol
    ++
    --

but (obviously) doesn't match "1 + 2 + 3".

We could theoretically support more complicated immediates, but the
parsing would get rather harder: we'd basically have to put in a
proper context free language and recognise all the usual unary,
binary, ternary operators and so on. For extra pain, this would be in
combination with the user-supplied syntax from insns.yml... and it
looks pretty hard. So we're punting on that for now!

How it works
============

For anyone reviewing the code, or looking at this in the future,
here's a quick run-down of what happens.

  1. In otbn-as's main function, we load up the ISA database from
     insns.yml.

  2. We then iterate over the input files, parsing them in a simple
     fashion to split out the assembly statements. The binutils manual
     actually explains this quite well, but it's rather complicated.
     Any directives (.word, .line etc.) or uses of RV32I instructions
     are passed straight through. On an actual instruction, we end up
     in _end_stmt_line() with the mnemonic in self.key_sym and the
     rest of the line in self.acc.

  3. From each instruction's syntax (in insn.yml) we've derived a regex
     that matches valid assembly lines for that instruction. We match
     the line against that, and generate a map called op_to_val which
     maps operand name to the (string) expression that it got in the
     file.

  4. We then call gen_rve_line or gen_raw_line.

  5. If we're lucky and the instruction encoding looks something like
     a RV32I instruction, we can generate assembly using the .insn
     directive. This is dealt with in gen_rve_line, using some
     pre-computed information that we generated in find_insn_schemes
     at the start.

  6. If not, we have to use gen_raw_line. This actually assembles the
     instruction to a .word. The disadvantage of this is that we can't
     include any symbols in the result, so won't be able to use relocs
     for this instruction.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>