On 4 February 2016 at 12:24, Brantley Coile <brantleycoile@me.com> wrote:

> Which plan 9 assembler uses right to left argument assignments, or compare
> argument order


For example, the ARM's MCR and MRC instructions are unchanged from the
manufacturer's order.
Partly that's because the "instructions" are really just encoding a set of
fields that happen to include one or two processor
registers that might or might not be accessed. Those are the only ones I
can think of off-hand, but there might be others.
On PowerPC, even LWAR ("load") and STWCCC keep to the data-flow order,
though.

CMP on some RISC architectures keeps the order of the underlying
subtract-discarding-result that it represents.
Perhaps they all do it. When I've done a new architecture, I try to keep
the feel of similar architectures (RISC or CISC).

The typed registers vs typed instructions was originally easy: integer
operations used the same register names (eg, typically Rn, but also AX, DX,
...) and the instruction was byte/word/long, instead of encoding lengths as
in %ax vs %eax (but of course x86 has to have AL, AH, etc for compatibility
with 8086). Floating point registers had their own name, but the
instructions still had a type, so it was ADDF or FADD not
just ADD F0, ... . Then vectors and logical registers nested inside
physical ones or aliasing them appeared, and now even the RISCs
have instructions with a result type but possibly different types for each
operand.

Note though that although the terms "assembler" and "loader" are used,
the whole scheme starts with the use of an abstract syntax of a given
architecture for use by the compilers.
The assembler is just a readable version of that abstract syntax, that's
vaguely like a conventional assembler
including the funky upper case names. It could be S-expressions.

I still quite like the distribution of work, for the reasons Aram just gave.
Latterly, I've been making the things a little smaller and perhaps simpler,
by continuing some changes that
Russ made (eg, pgen.c pswt.c) to reduce the amount of almost identical code
that's replicated across the suites.