Wednesday, 6 July 2011

Using Functions within VFP/SIMD instructions

Having reviewed the documentation supplied with the 0.01 release, one thing that isn't clear is the way in which expressions are supported within the VFP/SIMD syntax.   This will be corrected in the next release.

Register Numbers
Register numbers are a special case where the register type must be specified.   So where an ARM register can be simply specified as a number from 0-15, a Single/Double/Quad register must be prefixed by S,D or Q, and then a # followed by the expression.    For example Q#FNregister or D#(A%+B%)

Immediate constants
The same as for the standard ARM assembler, subject to encoding limitations as specified in ARM.   For a full 32bit or 64bit number, an 8bit constant can be shifted around and duplicated in 9 different ways.   For example #&FF, #&FF00, and #&FF00FF00  will encode for VMOV where as #&10F will not.

Immediate floating point or 64bit integers
The special constructors take a number from 0-255 from <expression> and pass it through in raw form to the instruction encoding.   This is not particularly useful but completes the syntax.  We would recommend using other methods to define constants of these types.

Scalar Offsets

Hopefully that helps to explain how things work.   Good luck to anyone who is testing the assembler and we look forward to some feedback in due course.


  1. Hi Alan, great work ! I'm closing in to translate my code from ExtASM to your implementation.

    One thing. The following produces a syntax error. Is the handling of labels different, or I missed something in the docs ?

    VLDR S1,single_precision_number
    DCFS 1.23456

  2. Yes this is an oversight which I am fixing. This is one of many assembler directives (as you know) and I suspect there will be others I haven't picked up yet due to limited testing time.

    You are brave using my logic as this is the first go at writing an assembler for a very long time. Best of luck with that...!

  3. Okay, I stay tuned for an update! I hope your good work will really help people coming back to code for Risc OS, as it lift a high hurdle regarding using VFP/NEON.

    Despite the VLDR my Mandelbrot VFP code assembles correctly. Though I can only prove success when that's working. I'll try my NEON version today and see if there are other obstacles.

  4. ...I found just two more syntax errors:
    -> VDPL.I32 Q2,R12 (I changed VDUP as you proposed to VDPL, but still I got a syntax error)
    -> VSUB.U32 Q2,Q2,Q14
    ...any other instruction I use within my fractal NEON code assembles without error :-)

  5. VDPL.I32 - p907 of ARM shows the size as specified without the I

    VSUB.U32 - p1101 of ARM shows the size for VSUB as I8-I64 not supporting U32

    Not sure if there are syntax options in play here that we don't support - currently our tables are rather literal to what's in the ARM on each instruction.

  6. Hm, you're right. I checked it also. The ARM ARM should be the bible...those I mentioned are supported by ExtASM. May be Terje, the author implemented the options for convenience, while assembling those to the same Opcode. Thanks for the fast fix of the VLDR. Did you also fix VSTR ? It has got the same problem, as far as I see.

    By the way, I use more often the RealView Compilation Tools Assembler Guide. The VFP/NEON command explanations in chapter 5 are a bit more easy to read, I think ->

    ...more testing hopefully tomorrow.

  7. Yes VSTR is fixed as well, just updated the note on the blog.

    Thanks for pointing out the other guide to VFP/NEON. We know a lot more about encoding the instructions than actually using them!

  8. Let's have a second go at this comment.

    ARM p285 gives a table of variations for the data-type specifier.

    With Ix you can use Sx and Ux instead

    With x you can use any valid prefix (ISUPF) followed by x. It also suggests that F can be used for F32 and D for F64.

    It seems a bit confusing to have all these options but anyway I will alter the code to allow all of those shortly.

  9. Release 0.03 today should fix the data-type issue and a few other minor things

    Hopefully that helps us get a bit closer to the syntax in ExtASM