6 Replies Latest reply on Apr 2, 2008 2:14 PM by MicahVillmow

    possible inline literals issue and calclAssembleObject/calclDisassembleObject

    sgratton
      Hi there,

      I've been experimenting with the cal compiler and there seems to be something strange somewhere with inline literals and calclAssembleObject and/or calclDisassembleObject. Following the assembly language format document, I think such literals should be specified as e.g. (287.3f).x. However, when I try this and assemble and then disassemble a simple program, this doesn't seem to be quite working (code at bottom). It looks like the float is being converted to an integer whose bit pattern is then being reinterpreted as a float:

      Original program:

      ;Testing inline literals
      00 ALU: ADDR(32) CNT(5)
      0 x: MOV R0.x, 1.0f
      y: MOV R0.y, 0.0f
      z: MOV R0.z, (4096f).x
      w: MOV R0.w, (8.3f).y
      01 EXP_DONE: PIX0, R0
      END_OF_PROGRAM


      Disassembly:

      ; -------------- PS Disassembly --------------------
      00 ALU: ADDR(32) CNT(5)
      0 x: MOV R0.x, 1.0f
      y: MOV R0.y, 0.0f
      z: MOV R0.z, (0x00001000, 5.739718510e-42f)
      w: MOV R0.w, (0x00000008, 1.121038771e-44f)
      01 EXP_DONE: PIX0, R0
      END_OF_PROGRAM
      ...

      Special select constants seem to work okay though.

      Also, what should be the difference between calclCompile with the language set to CAL_LANGUAGE_ISA and calclAssembleObject? In any case I couldn't get the former to work.

      Thanks,
      Steven.

      ************

      #include <iostream>
      #include "calcl.h"

      using namespace std;

      void disp(const char* msg)
      {
      cout << msg;
      }

      int main()
      {
      const char R600prog[] =
      ";Testing inline literals \n"
      "00 ALU: ADDR(32) CNT(5) \n"
      " 0 x: MOV R0.x, 1.0f \n"
      " y: MOV R0.y, 0.0f \n"
      " z: MOV R0.z, (4096f).x \n"
      " w: MOV R0.w, (8.3f).y \n"
      "01 EXP_DONE: PIX0, R0 \n"
      "END_OF_PROGRAM\n";

      cout << endl << "Original program: " << endl << endl;
      disp(R600prog);

      CALobject object = NULL;
      calclAssembleObject(&object,CAL_PROGRAM_TYPE_PS,R600prog,CAL_TARGET_670);

      cout << endl << endl << "Disassembly: " << endl;
      calclDisassembleObject(&object,disp);
      calclFreeObject(object);

      return 0;
      }
        • possible inline literals issue and calclAssembleObject/calclDisassembleObject
          MicahVillmow
          Steven,
          The problem with the disassembled code that you pass in is that your literals do not follow the specific format that is required for floating point values. 1.0, 0.0 and 0.5 are special values that are treated differently, along with -1, 0 and 1(page 46, section 4.7 of the ISA doc), otherwise floating point constants need to be in hex format. If you only put the value without hex, it is treated as an integer value, as can be seen by converting the hex values.
            • possible inline literals issue and calclAssembleObject/calclDisassembleObject
              sgratton
              Cheers Micah,

              I should have thought to simply try feeding back the disassembly floating format into the program string (I was originally looking at sec. 4.9 of the R600_assembly_language_format.pdf document of the 1.0 beta which didn't mention the hex requirement). But, assuming there are no further problems with the program, I've just noticed another thing about the disassembly output: it lacks the .x and .y suffixes after the (hex,float) pairs and so doesn't reassemble... is this right?

              Did you have any comments the intended use of calclcompile with cal_language_isa by the way?

              Thanks,
              Steven.
            • possible inline literals issue and calclAssembleObject/calclDisassembleObject
              MicahVillmow
              A website you can use to translate between IEEE hex and floating point is located here:
              http://babbage.cs.qc.edu/IEEE-754/
              • possible inline literals issue and calclAssembleObject/calclDisassembleObject
                MicahVillmow
                If the items that were disassembled don't work when trying to reassemble, please let us know through a test case and we can get it fixed. As for the CAL_LANGUAGE_ISA, that seems to be left in from an earlier version before we moved the assembler/disassembler to their own function calls and it might be removed in the future.
                  • possible inline literals issue and calclAssembleObject/calclDisassembleObject
                    sgratton
                    Hi Micah,

                    The above code, although flawed in its handling of floats, exhibits the behaviour; there are no .x's or .y's in the disassembly output. I've copied a new version of the program below which shows things a bit more explicitly by trying to assemble, disassemble, reassemble and redisassemble a program. The program with floating literals doesn't work; the one with only special selects does.

                    It makes sense what you say about calclcompile and isa; it was it's apparent overlap in functionality with calclassemble that was what was puzzling to me.

                    Best,
                    Steven.

                    (PS Should I be posting code here in a different way to just cutting and pasting it in? It seems to be losing all whitespace, sorry.)

                    ********

                    #include <iostream>
                    #include <string>
                    #include "calcl.h"

                    using namespace std;

                    string newprog;

                    void disp(const char* msg)
                    {
                    printf(msg);
                    }

                    void makecode(const char* msg)
                    {
                    printf(msg);
                    newprog+=msg;
                    }

                    int main()
                    {
                    // not reassembling; the disassembly seems to be
                    // missing the .x and .y after the inline literals
                    const char R600prog[] =
                    ";Testing special selects and inline literals \n"
                    "00 ALU: ADDR(32) CNT(5) \n"
                    " 0 x: MOV R0.x, 1.0f \n"
                    " y: MOV R0.y, 0.0f \n"
                    " z: MOV R0.z, (0x40E00000, 7.0f).x \n"
                    " w: MOV R0.w, (0x3f900000,1.125f).y \n"
                    "01 EXP_DONE: PIX0, R0 \n"
                    "END_OF_PROGRAM\n";

                    // this does reassemble...
                    /*
                    const char R600prog[] =
                    ";Testing special selects \n"
                    "00 ALU: ADDR(32) CNT(4) \n"
                    " 0 x: MOV R0.x, 1.0f \n"
                    " y: MOV R0.y, 0.0f \n"
                    " z: MOV R0.z, 0.5f \n"
                    " w: MOV R0.w, -0.5f \n"
                    "01 EXP_DONE: PIX0, R0 \n"
                    "END_OF_PROGRAM\n";
                    */

                    cout << endl << "Original code: " << endl << endl;
                    disp(R600prog);

                    CALobject object = NULL;
                    calclAssembleObject(&object,CAL_PROGRAM_TYPE_PS,R600prog,CAL_TARGET_670);

                    cout << endl << endl << "Disassembly: " << endl;
                    calclDisassembleObject(&object,makecode);
                    calclFreeObject(object);

                    cout << endl << endl << "New code: " << newprog.c_str() << endl;


                    CALobject newobject = NULL;
                    calclAssembleObject(&newobject,CAL_PROGRAM_TYPE_PS,newprog.c_str(),CAL_TARGET_670);


                    cout << endl << endl << "New disassembly: " << endl;
                    calclDisassembleObject(&newobject,disp);
                    calclFreeObject(newobject);

                    return 0;
                    }
                  • possible inline literals issue and calclAssembleObject/calclDisassembleObject
                    MicahVillmow
                    sgratton,
                    Thanks for catching this, I have filed a bug report and this should get fixed before the next release.