Ada for C30

Ada for C30

[John L. Kollig]

I am looking for any experiences with Ada compilers that target the 
TI C30 processor. Please send any information to my email address if
possible.
Thanks in advance,
JK
 
John L. Kollig
Honeywell
Clearwater, 

Re: Ada for C30

[Gentle]

John L. Kollig (jlkollig@space.honeywell.com) wrote:
: I am looking for any experiences with Ada compilers that target the 
: TI C30 processor. Please send any information to my email address if
: possible.
: Thanks in advance,
: JK
:  
: John L. Kollig
: Honeywell
: Clearwater, 

  Well, I had tried responding to this article once before, but the server
computer crashed and lost my response.  It seems every network and computer
I've been associated with goes down more often than a cheap whore.  THe
only difference is that I get no pleasure out of it. <sigh>

  Anyway, what I was trying to say was that I would love to get an Ada
compiler for the 'C5x (or even 'C3x series) processors.  I'm currently
working with assembly language for the 'C56 here at ITT.  Unfortunately,
this processor chip hasn't even come off the assembly line yet.. It's not
due until sometime in July.  Talk about vaporware...
  So, since ITT will not spend the time or money to look into using a
high-level language (or at least this depertment - the other department I
was in for 5 years used Ada on the 1750 for the GPS Block IIR satellites),
I'd like to take it upon myself to investigate Ada in signal processing and
shove it in their faces.  They wrote memos to the government saying they
investigated the use of high level languages (even C!) and that they
weren't feasible, but no investigation was done.  Basically the line is
"We've always done things in assembly, so therefore we always will."  How
many of you have heard that line before?  Well, if I can provide (at least
for myself) proof of concept of Ada for DSPs, either they could start using
it in future projects, or I could possibly take it somewhere else (one of
those places being my own company - anybody want to join me?)

   Dejectedly,
  (me)

--
=========================================================================
gentle@cnj.digex.net  -  Finger for PGP Public Key
Software Engineer
Edison, NJ

Twink code:
T6 C1 L2w h-(:) d-- av w- e+ g+ f t++(2,4,6,7,8) k++v s- m1 m2 q-

Crime does not pay ... as well as politics.
		-- A. E. Newman
=========================================================================

Re: Ada for C30

[Garlington KE]

Gentle (gentle@cnj.digex.net) wrote:
:   Anyway, what I was trying to say was that I would love to get an Ada
: compiler for the 'C5x (or even 'C3x series) processors.  I'm currently
: working with assembly language for the 'C56 here at ITT.  Unfortunately,
: this processor chip hasn't even come off the assembly line yet.. It's not
: due until sometime in July.  Talk about vaporware...

Contact stare@tartan.com to talk about potential Ada support for these
chips. As he said to me recently: "The first time we find out when TI puts
out a new DSP is when a user calls us about it." He can also help with
your request for data on using Ada for DSPs in general.

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.

Re: Ada for C30

[jfj]

gentle@cnj.digex.net (Gentle) wrote>
>=========================================================================
>gentle@cnj.digex.net  -  Finger for PGP Public Key
>Software Engineer
>Edison, NJ

>=========================================================================
We are in the process of beginning to use Tartan Ada for the C40.  Our experiences have been
VERY limited but interesting.  It appears that, given you compile everything just right, you
can get _close_ to TI's C language output.  By this I mean, you have to turn the correct optimizations
ON AND OFF.  We have not spent much time delving into the supporting packages from Tartan
but our initial peeks imply there is room for improvement.  We also have not gone into the ISR
writing phase at all.  This should prove to be interesting.  Overall, my intuition tells me if I could
do it in C I can do it in Tartan Ada with a little careful construction.  Probably the biggest hurdle
is that C's memory allocation are very easy to predict, while in Ada we are not always sure of what
the compiler will construct and where things will be allocated from.  I know this is mostly due
to our severe lack of experience with Ada, and conversely, with our extensive experience with C
on many platforms/targets.  They have a very nice debugger called Adascope which works
on multiprocessor DSP setups.  The hard part is getting the OS/2 server to talk to both the
Unix machine you are running Adascope on and the target system.

I am looking forward to getting deeper into C40's and Ada.  Has anyone else used Tartan Ada on
the C40 ?  Gotten aroung to implementing the Shared Memory Ada Run Time extensions ?

John Fountain, Jr.
jfj@accessnv.com

Re: Ada for C30

[Michael Hirasuna]

In article <3io711$hs5@bighorn.accessnv.com>, jfj (John Fountain, Jr.) wrote:
> I am looking forward to getting deeper into C40's and Ada.  Has anyone
else used Tartan Ada on
> the C40 ?  Gotten aroung to implementing the Shared Memory Ada Run Time
extensions ?

I've used Tartan for the C40 on my last job, but I have not used the TI C
compiler so I am not sure what your concern is. If you are new to Ada, you
may not be aware of the full power of the language. Before using any
special Tartan extensions, you might check out what you can do directly in
Ada.

-- 
Michael Hirasuna    |  hirasuna@acm.org

Re: Ada for C30

[Larry Kilgallen, LJK Software]

In article <3io711$hs5@bighorn.accessnv.com>, jfj (John Fountain, Jr.) writes:
> gentle@cnj.digex.net (Gentle) wrote>

> writing phase at all.  This should prove to be interesting.
> Overall, my intuition tells me if I could do it in C I can
> do it in Tartan Ada with a little careful construction.
> Probably the biggest hurdle is that C's memory allocation
> are very easy to predict, while in Ada we are not always
> sure of what the compiler will construct and where things
> will be allocated from.

There have always been problems with people writing a Fortran
program in some other language, such that no matter what language
they use it comes out looking like Fortran.

If you need to know how C or Ada is going to allocate the memory,
and depend on undocumented (and therefore non-guaranteed) compiler
behavior, you may be in for a rude awakening with the next version
of any language compiler from any vendor.

If you require a particular memory layout, you should depend on
documented features of the language.  In Ada the Representation
Clauses are the major mechanism for accomplishing this. In some
cases Address Clauses may also be relevant.

Whatever your language, you should rely on documented (and therefore
guaranteed) compiler features to produce particular memory usage.

Larry Kilgallen
whose representation clauses
"just worked" when DEC released Alpha AXP :-)

Re: Ada for C30

[Bill Priest]

I have been using the Tartan Ada compiler for the TI C31 processor (similar to C30).  The
current latest version has some problems.

1) Separates don't always work (the compiler at least on SUNOS can get in an infinite loop).

We have a tool to create a single file from a bunch of separates.

2) If use locate variables w/ for <var> use at the compiler likes to initialize the data for you
   unless you meet a certain criteria
   a) If the variable is a record it must have all bits rep-claused (even unused bits).
   b) If the variable is a packed array of boolean (if you put it in a record).
   c) The variable must be declared at a package or procedure level.
   d) If the variable is an integer (or a type built off of one) and is rep-claused to a size (< 32)
      then the variable will not be masked unless it is assigned to another variable (i.e it must
      not be used in an if or while condition directly).
   e) A rep-claused boolean of a single bit is not masked.
3) The runtime changes the stack address to a negative number (it sets the most sig. bit) after
   entering an interrupt handler.
4) The extensions to the runtime have timing/race condition bugs; we don't use them but other
   groups have seen them.

The code produced is pretty efficient if most of the checking is turned off.

The adascope debugger has problems also.
1) It only works w/ X11R4 (not X11R5).
2) When running in X11 mode it can get confused (mouse/button wise) and lock up.
3) It doesn't always let you source debug generics (dependent upon where you instantiate
   the generic).
4) When it dumps memory where breakpoints are located it shows the data that would be
   there if the breakpoints were not active (WYSINWYG).

FYI,

Bill
PS. Most problems can be worked around; however, it takes some time to learn the
compilers deficiencies.

Re: Ada for C30

[jfj]

kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) wrote:
>In article <3io711$hs5@bighorn.accessnv.com>, jfj (John Fountain, Jr.) writes:
>
>> writing phase at all.  This should prove to be interesting.
>> Overall, my intuition tells me if I could do it in C I can
>> do it in Tartan Ada with a little careful construction.
This is a refernce to CODE GENERATION AND OPTIMIZATION.
>> Probably the biggest hurdle is that C's memory allocation
>> are very easy to predict, while in Ada we are not always
>> sure of what the compiler will construct and where things
>> will be allocated from.
THIS IS A REFERENCE TO STACK USAGE.
>
>There have always been problems with people writing a Fortran
>program in some other language, such that no matter what language
>they use it comes out looking like Fortran.
Pretty rude.  Where is the reference to FORTRAN?  I like it.  Used it
for years.  Beats Pabst Blue Ribbon.
>
>If you need to know how C or Ada is going to allocate the memory,
>and depend on undocumented (and therefore non-guaranteed) compiler
>behavior, you may be in for a rude awakening with the next version
>of any language compiler from any vendor.
YES. I NEED TO KNOW.  I ALWAYS WANT TO KNOW.
I am new to Ada. I do not know if the LRM states that static objects
(static is a C'ism for never moves) in the declarative section of a
package, will be allocated off the stack when the package is
elaborated at run time.

This is what Tartan does.  Being caught off guard by this, I was just
stating that I needed to be CAREFUL as to where I assume objects
will be allocated from...
>
>If you require a particular memory layout, you should depend on
>documented features of the language.  In Ada the Representation
>Clauses are the major mechanism for accomplishing this. In some
>cases Address Clauses may also be relevant.
I am well aware of the FOR USE AT clause.  This is very useful for
those objects like UARTS, but I think it would be un-Ada to use
this to overcome stack allocations.
>
>Whatever your language, you should rely on documented (and therefore
>guaranteed) compiler features to produce particular memory usage.
I always strive to use every undocumented feature of every OS and
language I come by, as evidenced by my posting.  In fact, I have
written a letter to Mr. Bill Gates stating that I would be the premier
Windows programmer since I am so good at doing this. (Novell
has made an offer but they don't do it like Windoze does.)
>
>Larry Kilgallen
>whose representation clauses
>"just worked" when DEC released Alpha AXP :-)

Nice machine.  Try it on a DSP with local/global/cache that change
size from board to board and change wait state just to aggravate you.

pleasently insulted,

John Fountain, Jr.
jfj@accessnv.com

*************************************************************************

This is just filler.  I hope you don't bother reading it.



**************************************************************************