This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Stack alignment on C66xx ISA models

Hi All,

   I have a question on stack alignment for C code compiled for C66xx devices. I need to have 16 byte aligned data structures for local storage (stack) within functions. According to the "cl6x compiler guide":

This statement is a bit confusing in that it is claiming that the C6600 stack alignment is 16 bytes but the C6400/C6400+/C6740/C6600 ISAs align the stack to 8 bytes. I'm seeing the simulation results of the C6670 ISS model align the stack on 8 byte boundaries on function calls even when I use the __x128_t type for a local variable. The executable module I'm building is composed of all C6600  objects compiled with the -mv6600 option. How do I enforce a 16 byte stack boundary?

Thanks,

Mark Brown

 

 

  • Mark Brown said:
    This statement is a bit confusing in that it is claiming that the C6600 stack alignment is 16 bytes but the C6400/C6400+/C6740/C6600 ISAs align the stack to 8 bytes.

    I agree that's a bit confusing.  It would be more clear if it stated that C6400+/C6740 (not C6600) ISA's require 8-byte stack alignment.  C6600 always requires 16-byte stack alignment.  C6600 code can link with libraries that contain C6400+ or C6740 code that only uses 8-byte stack alignment provided one unusual case involving variadic functions (like printf) does not occur.  And that unusual case can be detected at link time.  Even this explanation is unfortunately dense.  But, when things get this detailed, it is unavoidable.

    Mark Brown said:
    I'm seeing the simulation results of the C6670 ISS model align the stack on 8 byte boundaries

    Have you found the exact point where the alignment is no longer 16-bytes?  I'd like to see the C source for that function.

    Thanks and regards,

    -George

  • George,

       I've cooked up a small testcase to illustrate the problem:

    The result I get from running the C6670 functional simulator is as follows:

    Notice the address of the 128 bit local for the first level call is on a 16 byte boundary. The 128 bit locals for the lower-level calls are on an 8 byte boundary. These should all be on 16 byte boundaries.

    Thanks,

    Mark Brown

  • Thank you for the test case.  I can reproduce your results.  I filed SDSCM00042415 in the SDOWP system to get this addressed.  Feel free to track it with the SDOWP link below in my sig.

    Thanks and regards,

    -George

  • I need to consult this with other engineers of our team for a final closure on this issue.

    Just my own options:

    1) the document is wrong. C66 does not need 128 bit alignment. C66 does not have 128 bit read/write instruction. Any 128 bit data is accessed by D-load/store instruction which only need 64 bit alignment.

    2) from the compatibility point of view, C66 code should be able to link C64+/C67 code seamlessly. The C64+/C67 code are 64 bit alignment, so I think the C66 core should also be 64 bit aligned.

    I need more time to confirm all these and will get back to you soon. At the meantime, I thik the document is wrong.

  • Wei Zhao,

    Do you have a response on this? Is the document wrong, meaning that the C66x does not require 128-bit alignment?

    Is there any way to enforce or achieve 128-bit stack alignment. It is desirable for this situation.

    Regards,
    RandyP

  • 128 bit alignment on C66 is a document error.

    We’re not going to have 128-bit alignment for C66 and lower.  On C66, any 128 bit data type access is decomposed into two 64 bit data accesses, There is no need for 128-bit stack alignment.

    So CQ42415 is rejected.

  • Hi,

    Wei Zhao said:
    128 bit alignment on C66 is a document error.

    This documentation error still exists in the latest compiler user's guide SPRU187T: http://www.ti.com/lit/ug/spru187t/spru187t.pdf

    When will it be fixed?

    This is causing a lot of confusion at customers currently.

    -Matti

  • As Wei said, this is a documentation error.