ARM Unified Assembly Language - GNU as does some weird stuff

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

Hello Paul,

we are now implementing ARM inline assembly in TinyCC.

The traditional ARM inline assembler is finished now.  Now we started
implementing the Unified Assembly Language dialect.

I'd like to have some help which constructs are valid and which are not.

(GNU as 2.34 seems to have some bugs with Unified Assembly Language--so I
guess we shouldn't use "do what GNU as does" as a yardstick here)

The questionable--maybe invalid--constructs follow (the "#" are for clarity):

================================================================================

(1) b #60

It seems that GNU as ignores the immediate entirely and just always encodes
#0 (to test, do ".syntax unified" and then "b #60" in GNU as).  WTF?

Likewise with bl, blx.

It seems that the debug info still has the user-specified immediate value--but
the executable object file does not.  So in order to test you should strip the
resulting file--otherwise you are gonna be very confused.

No error or warning messages are printed by GNU as here.

================================================================================

(2) push #4

It works in GNU as--but is it specified by ARM to push the register r2 ?
I think exposing ISA implementation details like that is a leaky abstraction--and
no good can come from it.

Likewise with pop, stm*, ldm*.

No error or warning messages are printed by GNU as here.

================================================================================

(3) and r3, r4, LSL #5

This doesn't work in unified mode--but does work in non-unified mode.
Note that "and r3, r3, r4, LSL #5" always works--both in unified mode and in
non-unified mode.

I would have thought the LSL token would be a dead giveaway for disambiguating
what to do here--but apparently GNU as thinks otherwise.

Likewise with ands, eor, eors, sub, subs, sbc, sbcs, rsc, rscs, rsb, rsbs,
orr, orrs, bic, bics, cmp, cmns, mov, movs, mvn, mvns (all arithmetic
instructions), and with other modifiers (LSR, ASR, ROR, RRX).

GNU as fails to assemble these.

================================================================================

(4) lsl r1, #4, #2

GNU as encodes exactly the same as "lsl r1, #4"--drops the "#2" silently.

Likewise with lsr, lsrs, asr, asrs, orr, rors.

No error or warning messages are printed by GNU as here.

================================================================================

(5) vmov.f32 r2, r3, d1

f32 and two 32 bit ARM registers, and one 64 bit VFP register?  What does this
do?!

Likewise with "vmov.f32 d1, r2, r3".

No error or warning messages are printed by GNU as here.

================================================================================

Which of those are good (and should thus be implemented in the same way)
and which of those are bad (and should thus not be implemented the
same way)?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]