[bug-mes] ARM instruction encoding of "halfword data transfer with immediate offset" is difficult in M1

[Jeremiah]

> just a heads-up, there's a strange encoding of some ARM instruction
> that I don't know how to represent in M1
well we know there is a set of instruction encodings that can't be
expressed as hex or octal but there are ugly ways of working around that
in binary.

> It's Halfword data transfer with immediate offset, for example:
>  STRH %r0, [%fp, +#2]
> The immediate offset is split into two parts and the parts encoded in
>  non-consecutive bit blocks.
Depending upon the size one might have to handle the immediate encoding
in the layer above M1 as the immediates need to fit into the
!num/@num/%num pattern.
Sometimes the only answer in M0 is punt via '11001' which is far from
ideal but one can always add in ; Immediate +#2 on everyone of those
lines generated

> I can work around it using a scratch register, but just so we don't
> forget it I write this.
It is actually an old problem from back when people asked when I was
going to port it to RISC-V; Now there is a terriable encoding scheme...

-Jeremiah