On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw <rearn...@arm.com> wrote: > On 30/09/14 21:30, Eric Christopher wrote: >> On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft >> <marcus.shawcr...@gmail.com> wrote: >>> On 22 September 2014 19:41, Carrot Wei <car...@google.com> wrote: >>>> Hi >>>> >>>> The extended register width in add/adds/sub/subs/cmp instructions is >>>> not always the same as target register, it depends on both target >>>> register width and extension type. But in current implementation the >>>> extended register width is always the same as target register. We have >>>> noticed it can generate following wrong assembler code when compiled >>>> an internal application, >>>> >>>> add x2, x20, x0, sxtw 3 >>>> >>>> The correct assembler should be >>>> >>>> add x2, x20, w0, sxtw 3 >>> >> >> Hi Marcus, >> >>> Hi, >>> >>> The assembler deliberately accepts the first form as a programmer >>> convenience. Given the above example: >>> >> >> I've been doing some reading of the ARM-v8 ARM and the language the >> ARM uses here for this instruction matches the "shall" and not >> "should" language it uses in other locations: >> >> "Is the 32-bit name of the second general-purpose source register, >> encoded in the "Rm" field." >> >> This seems to say that a conforming assembler should error on a >> non-32bit named register here. As I said, same sort of verbiage used >> elsewhere for shall, in "should" cases the ARM is very careful to >> spell it out. >> >> Now if we want to change the ARM philosophy here I'm not opposed, but >> I think we'd want some more explicit documentation about how/where >> things should be more relaxed versus a bunch of "this is convenient to >> accept here" stuff. That kind of thing has a tendency to end up in >> some pretty fun context sensitive parsing madness. >> > > Agreed. We're already working on it... >
To be clear here I think the current language is exactly what it should be in this case and that the explicit w register requirement is a good thing for the assembly language. -eric
