On Tue, 15 Apr 1997, Edward Colbert wrote:
> Does anyone know of an Ada or Ada 95 compiler for the DSP 21020 or
> 21060? Thanks in advance.
The only Ada compiler I am aware of for the 21060 DSP is from Tartan.
Since they have been purchased by TI, I doubt that they will be developing
new or enhancing old compilers for non-TI DSPs. But for the one version
of the compiler that does exist, I did evaluate it. My report to my
management (slightly modified for public viewing) is included below.
On Thursday, 16 May 1996, I visited with Tartan in Monroeville, PA to
evaluate their newest Ada compiler targeted for the ADSP-2106x (Sharc)
Digital Signal Processor (DSP).
I took two sets of Ada code with me. The first set of code was the
[project name deleted] sources, which we currently compile on a VaxStation
6000 Model 90 running VMS version 5.5-2 using Tartan's Ada compiler
targeted for the TI320C31 DSP. The second set of code was code under
development, targeted for the Motorolla 68k CPU with which we are
currently using the Alsys Ada compilation system on a HP 9000 Model
735/125 running HP-UX version 9.05.
When compiling our code several observations were made. The current
version of their compiler for the Sharc does not support any floating-
point numbers other than single-precision (type T is digits 6). Both
sets of code that I tried to compile contained types requiring greater
precision, typically between digits 9 and digits 15. The Sharc
processor does natively support extended-precision floating-point but
the compiler does not support it at this time. Tartan staff informed
me that greater precision may be implemented (no promises) as an Ada
package (still not native to the Sharc) in the second release of the
compilation system (hopefully 12/96). If we need greater precision
than digits 6 in our code, we would have to normalize the values and
perform integer operations. When attempting to port and reuse
existing code the level of complexity increases.
Another problem with the floating-point types in the Tartan compiler
is that it does not allow values of 'SMALL that are not a power of
two. This too, can be overcome using normalization of the numbers and
has the same cost disadvantage as mentioned in the previous paragraph.
Another restriction is placed on the floating-point numbers in that
the attribute 'SIZE can not be used. This would make mapping these
numbers into specific fields (as in [reference deleted]) difficult and
a solution would be needed on a case-by-case basis.
A problem exists with interrupt latency of the new compilation system.
Currently, the response to an interrupt is as slow as a full context
switch. Better performance (no details) is anticipated in the next
revision. One possible alternative is to write assembly code
interrupt handlers which would then perform Ada callbacks. Care must
be taken to ensure that state of the CPU is saved and restored at the
assembly code level, and that no exceptions get propagated out of the
Some further code changes were needed when attempting to compile the
68k code, but these were just minor differences in the vendors'
(Tartan vs Alsys) implementation of some LRM Appendix F features. In
my opinion, these changes are minor and should be considered
insignificant, at best.
Currently, the new Tartan Ada compilation system runs only on a Sun
workstation; with the exception of the debugger which is also available
for a PC. This would preclude us from using our existing Ada development
facilities for [project name deleted] and require that we invest in
additional hardware. I did discuss with Tartan personnel the possibility
of porting the system to an HP environment; while we all agreed that it
shouldn't be an earth-shattering effort, there are no plans to effect such
a port in the foreseeable future.
I have returned with some of the code that Tartan has used for
benchmarking the Sharc so that we can run it on the TI and Motorolla
CPUs to get a better comparison of the performance in each
environment. It should be noted that Tartan has clearly stated that
the current (first) release of the compilation system was intended to
be feature-rich rather than performance enhanced and that the next
release will have better optimizations of the compiled code.
= Joseph V. Spinetti mailto:[log in to unmask]
= Principal Engineer W3 URL: http://www.systems.gec.com
= GEC-Marconi Hazeltine Voice: +1-201-305-2662
= 150 Parish Drive Fax: +1-201-633-6103
= CN 932 GNET Voice: 311-2662
= Mail Stop 18A45 GNET Fax: 310-6103
= Wayne, New Jersey 07474-0932 Pager: +1-201-470-4276