Do we have an extended precision lib for sharc today? customer needs 48bit * 48bit. they also want a divide, but I'm trying to talk them out of it.
As per my knowledge, we don't seem to have such libraries. However, I am moving this question to the tools community where I think you can get more definitive reply.
I assume we are talking about fractional data here, or are you asking about 40-bit floats?
FYI, the compiler and runtime libraries has support for 64-bit long longs integers added in VisualDSP++ 5.0 Update 9. They could maybe use that and scale the results to get the right answers. It may not be optimal but might be easier to implement and maintain and more portable.
can you supply the benchmarks? both for 64bit float multiply and 64bit float divide?
You can use 40bit float which has Sharc (You can see the subject with my nick). It's enough for control system.
But the compiler don't full support 40bit float, because it's unusual way for AD's system programmers. So I think that CCES don't full support 40bit float. Also the chip developer when they developed chip forgot about use SIMD with 40 bit float.
I use 40 bit float. My data are located in 48 bit memory. Also I analyse asm code which are compiled by the compiler that the compiler don't use the instruction "Rx = PASS Ry" which fill with zero least significant bits.
I repeat again that it's amazing situation: DSP don't has 64 bit float, but it has 40 bit float, but the compiler don't full support 40 bit float, because it's hard for the compiler programmer because it's out from standart.
Why Sharc has 40 bit float???
I think it's better if Sharc would has 64 bit float (double) as native.
Customer needs minimum of 43 bits to hold the needed precision. Our 64 bit emulation is too slow. Customer will use fpga I expect.
Agree lack of 40 bit compiler support is an issue.
Sent from Tim's iPhone
The SHARC compiler in CCES update 1 will avoid using the problematic PASS instruction optimization when the -extra-precision switch is used. Also, as mentioned previously, there will also be improvements to the double prevision emulation support included too.
The SHARC compiler in CCES 126.96.36.199 didn't solve the problem using the problematic PASS instruction optimization.
So I add in manuak about 40 bit float that the customer use 40 bit float and save data in 40 bit width internal memory he must turn off compiler SIMD support.
add about SIMD
You said that you're using 188.8.131.52. Although this release contained the SHARC tools, the release was intended to provide support for the new Blackfin BF60x family, and the SHARC compiler will have been quite old. SHARC support was added in CrossCore Embedded Studio 1.0.1, which has just been released, and the compiler in that release contains many fixes that were not in 184.108.40.206. Can you try Update 1.0.1 and see if you still see the problem? Please remember that you must use the compiler switch "-extra-precision" to prevent the compiler from performing the PASS optimization. I have tried a few small examples and can confirm that the compiler behaves as expected. If you are still having problems, please report it as a problem to Tools Support and we'll investigate it. As always, it's much easier to identify and fix the problem if you can send us a compileable example.
I make the mistake I mean 1.0.1.
I couldn't find the compiler switch "-extra-precision" in CCES 1.0.1, but a project built with this switch no errors.
That looks like an accidental omission from the IDDE help. I've logged an error report so that this will be fixed in a future update. You said that your project built without errors. Does your application work as expected?
My test application compiled no errors.
Now I try to migrate my VDSP++ projects.
Retrieving data ...