It's been a while since we have caught up last and I hope everything is going well. I
was wondering if you know someone that I can ask a generic DSP compiler question to.
We are aware of some DSPs that have a 16-bit architecture such that an ANSI byte is
16-bit.
The C5000 DSP compilers do use 16-bit units as the smallest data type (char). C6000 DSPs, including the one in the OMAP3, are byte-addressable.
As far as we know, 8-bit byte streams would not be supported. However, I
would imagine that these DSPs must support shift and logical AND operations so that
an intelligent compiler could take legacy ANSI 'C' code with 8-bit bytes and produce
code for this type of DSPs that would still run correctly. Since I have limited DSP
compiler knowledge, I guess my question is whether or not such compilers already
exist? Any idea? If not, do you know who I can ask?
I believe that is certainly possible, but I haven't seen any implementations of byte data-types on 16-bit DSP compilers. Since most of the questions I get are related to OMAP3, I'm making the assumption that you are likely asking about the C6000 DSPs, which are 32-bit devices (with 8 VLIW instruction units) that include byte addressing and 8-bit data types, so none of this would be an issue. What DSP family are you considering?
Thanks,
Hope you don't mind me sending this to the BeagleBoard mailing list. I am trying to start copying mailing lists in all my support responses.
Thanks for the reply. We are not considering any DSP in particular. Rather, we are looking at portability issues pertaining to
ANSI 'C' source code when run on DSPs that have 16-bit char data types. For example, whether or not we could port our TCP-IP stack
to this type of device given the obvious data type limitation. It would seem reasonable that the compiler vendors who write
compilers for these devices should be responsible for providing an ABI to indirectly handle byte accesses such that 8-bit char ANSI
'C' code still runs correctly. However, due to lack of experience (and device availability), we are unable to test first hand.
OK, this is starting to sound very non-BeagleBoard related.
I just assume that most e-mail messages coming across my desk are related to OMAP3/Beagle.
Thanks for the reply. We are not considering any DSP in particular.
Rather, we are looking at portability issues pertaining to
ANSI 'C' source code when run on DSPs that have 16-bit char data types.
Yeah, this sort of portability can certainly be new to some code.
For example, whether or not we could port our TCP-IP stack
to this type of device given the obvious data type limitation. It
would seem reasonable that the compiler vendors who write
compilers for these devices should be responsible for providing an ABI
to indirectly handle byte accesses such that 8-bit char ANSI
'C' code still runs correctly. However, due to lack of experience (and
device availability), we are unable to test first hand.
There is a $50 C5000 development platform:
Also, you can just download CCSv4 and use the C5000 simulator for free.
@all: this thing can also be ordered from digikey. If you order in
euro country it'll be about eur 38.
Shipping is another eur 18 but if you order is > eur 65 shipping is
free (so perhaps order 2 )
Frans.
PS: since we are offtopic anyway: anyone knows an inexpensive platform
for FPGA experiments?
)