CODECOMPOSER: TI ARM CLANG 4.0.3.LTS Release?

Eugene K said:

TI Arm Clang Compiler Tools User Guide v4.0.0.LTS link doesn't work

Thank you for letting us know.  I informed the relevant team.  In the meantime, this link always goes to the latest version.

Eugene K said:

Under "What's new" what does "Support for MSP M0/M0+Math Accelerator" mean for compiler? Will it auto map some math logic to MATHACL

Yes.  Most of the difference is in the RTS functions the compiler calls to implement those operations.  According to this document from TI, the following operations are affected:

divide, square root, multiply-accumulate and trigonometry (sine, cosine, arctangent of x, arctangent of y/x)

Thanks and regards,

-George

Hi George,

Could you please give an example of what compiler will do for MATHACL? AFAIU, MATHACL is on-chip peripheral, and it needs to be powered up, initialized etc. How would TI ARM Clang compiler do all of that and yet still stay in the context of C standard? Is there an example of what is required during C run-time initialization or what header file(s) and libraries to be included? I can't see any of that in the compiler manual ... unless I am confused and missing something...

Regards,

Eugene

I think this video about the MSPM0 math accelerator, plus all the material it references, will answer your questions.

Thanks and regards,

-George

Hi George,

FYI, links in presentation from that video do not work.

The video explains how to use MATHACL as external independent library from SDK. Isn't "Support for MSP M0/M0+Math Accelerator" a misleading statement then?  The code below is not native to C compiler but rather uses external SDK calls:

/* Setup unsigned multiply operation, OP1 = 0.5, OP2 = 0.3 */
DL_MathACL_startMpyOperation(MATHACL, &gMpyConfig, OP1_Q31, OP2_Q31);
DL_MathACL_waitForOperation(MATHACL);

/* Get result -- floating point Q31 equivalent of 0.15 = 0x1333 3333 */
mpyRes = DL_MathACL_getResultOne(MATHACL);

In the other hand, for devices with FP HW support compiler will generate instructions for FP co-processor when built-in float/double types are used. That does not seem be the case for MATHACL. What built-in C construct or CLI option (like -mfloat-abi) causes compiler to generate calls to MATHACL SDK APIs?

Regards,

Eugene

I apologize for my first reply.  It is a bit misleading.

Eugene K said:

Under "What's new" what does "Support for MSP M0/M0+Math Accelerator" mean for compiler? Will it auto map some math logic to MATHACL

I should have said only integer division uses the math accelerator.  For other operations supported by the math accelerator, you have to call functions supplied in libraries from the relevant SDK.

The compiler manual does not describe -mmathacl.  The entry EXT_EP-12626 has been filed to have the manual changed.  You are welcome to follow it with that link.  In the meantime, the compiler --help summary shows ...

$ tiarmclang --help | findstr mathacl
  -mmathacl             Enable hardware integer division routines (only available for cortex-m0plus)

Thanks and regards,

-George

Hi George,

Now that makes sense. AFAIU, MATHACL has to be powered up before it can be used. That brings the follow up questions:

1. How MATHACL initialization (power up, reset) is handled by compiler itself with -mmathacl option?
2. How interaction between compiler use of MATHACL with -mmathcal options and use of SDK MATHACL library is handled or to be handled in application SW?

Regards,

Eugene

Eugene K said:

How MATHACL initialization (power up, reset) is handled by compiler itself with -mmathacl option?

Please run this build only experiment.

C:\examples>type file.c
volatile int a, b;
int main()
{
    return a / b;
}

C:\examples>tiarmclang -mcpu=cortex-m0plus file.c -o no_math.out -Wl,-c,-m=no_math.map

C:\examples>tiarmclang -mcpu=cortex-m0plus -mmathacl file.c -o with_math.out -Wl,-c,-m=with_math.map

Then compare the map files.  In with_math.map you'll see a reference to an object file from the compiler RTS library named mathacl_init.c.obj.  That means there must be a source file named mathacl_init.c.  It is located in the directory compiler_install_root/lib/src.  It contains the code for initializing the math accelerator.

Eugene K said:

How interaction between compiler use of MATHACL with -mmathcal options and use of SDK MATHACL library is handled or to be handled in application SW?

Please consult the documentation and examples that come with the SDK library.  But it is my understanding the libraries and the use of the option -mmathacl are independent.  That said, it still makes sense to use -mmathacl when the CPU supports it.  That way, you get a performance boost for any integer divides in your code.

Thanks and regards,

-George

Hi George,

Thank you for clarifying initialization. Absolutely, -mmatchacl option is the useful one.

Still, I am not clear on how -mmathacl, Sysconfig and SDK MATHACL library work together. I'm not sure if SDK library has anything about -mmathacl and I do not want to get into hard-to-debug situation if there are conflicts. Could someone please clarify the interactions if there are any?

Regards,

Eugene

Hi Eugene,

I'm going to look into some of these nuances for you with regards to the total linkup. On the DriverLib/SDK side, we will reset and enable the MATHACL peripheral if you add it to SYSCONFIG.

In general this won't cause any problems unless you reset the peripheral then the compiler does a math operation before you repower the MATHACL. For using the MATHACL, I recommend checking the busy flag if you're doing a multiply/divide operation then into a SDK MATHACL function call.

Hi Luke,

Yes, this is of a concern because it is very hard to control what compiler do whereas library is explicit. One can easily write code that might not work here. Some guidelines need to be published. I wonder if is safer to state that -mmathacl is mutually exclusive to MATHACL SDK library?

Regards,

Eugene

Hi Eugene,

When enabled via the compiler, the MATHACL is enabled at the beginning of the boot routine (this is done by setting the PWREN bit). The SDK doesn't have any context on the compiler flags for the MATHACL. The only concerning case is resetting the MATHACL then doing a divide operation when you have the compiler flag enabled.

I'll work to get a code comment around the DL_MathACL_reset(MATHACL); function to detail the compiler consideration and a similar comment in the SDK  User's guide. I'll pass onto the compiler team when they add the --mathacl into the user's guide, to mention if you reset the MATHACL then do a division you can cause a fault if the MATHACL is not reenabled.

The compiler isn't going to any other math operation aside form division (as of the time of this post), so I think you would still need to use both the MATHACL and compiler version. Alternatively, you could not have the compiler version enabled if you want full manual control over the divisions and other math operations.

Regards,
Luke

Hi Luke,

Are you saying that there are no conflicts between compiler using MATHACL for integer divide outside of user control and user using MATHACL for any other operation except integer divide? Is this assumption correct? Is there parallelism of different operations in MATHACL?

What about thread protection of MATHACL registers? What would one save/restore for any of the use cases above?

Regards,

Eugene

Hi Luke,

Thank you for detailed explanation. Do you think that including busy check into MATHACL SDK library functions would be beneficial to users? That will make it more robust with presence of -mmathacl compile option and will ease user integration. 

Regards,

Eugene

Hi Eugene,

I can look into if we can do that, but it might break compatibility with current users, even if it could be a QoL update.

Hi Luke,

Would it though? Existing users are linked to older version and checking BUSY bit should not break anything (theoretically)... Maybe adding builtin compiler define for the case of -mmathacl be helpful?

Regards,

Eugene

... but isn't this the same problem with -mmathacl?

Hi Eugene,

Yes this is the consideration needed with Math ACL, I wanted to make sure that point was clear to prevent any future debug efforts.

With all of the above I would question the usefulness of -mmathacl flag. There seems to be to many issues with using it at compiler level @George Mock. -mmathacl creates more issues that it solves.