Waiver question

Waiver question

[Ken Garlington]

Consider a waiver request to use C++ in a Digital Signal Processing
application. The waiver is based essentially on these arguments:

  *  DSP engineers would rather program in C++ than Ada, since it
     makes them more valuable in the larger commericial marker. As a
     result, there is much higher attrition when DSP engineers are
     required to program in Ada, and so the development cost is higher.

  *  Most DSP tools are for C/C++. The number of DSP tools for Ada
     will shrink, given that the DoD has decided not to mandate Ada
     anymore.

  *  Most existing DSP code is in C/C++. Therefore, reuse is easier
     if the new code is also written in C++.

Anyone have a reason to think this waiver shouldn't be approved?

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Waiver question

[Tom Moran]

> *  DSP engineers would rather program in C++ than Ada, since it
>      makes them more valuable in the larger commericial marker. As a
>      result, there is much higher attrition when DSP engineers are
>      required to program in Ada, and so the development cost is higher.
> 
  But if the C-trained engineers are actually 'more valuable' doesn't
that mean 'higher priced' so the cost of using them is higher - if not
now, then after they are trained?
  Of course if they are mistaken, and the company is saving money by
letting them believe their notions, that's different.

Re: Waiver question

[Robert Dewar]

Ken said

<<  *  DSP engineers would rather program in C++ than Ada, since it
     makes them more valuable in the larger commericial marker. As a
     result, there is much higher attrition when DSP engineers are
     required to program in Ada, and so the development cost is higher.

  *  Most DSP tools are for C/C++. The number of DSP tools for Ada
     will shrink, given that the DoD has decided not to mandate Ada
     anymore.

  *  Most existing DSP code is in C/C++. Therefore, reuse is easier
     if the new code is also written in C++.
>>

The first argument seems pretty bogus to me -- Ken, is this just a guess,
or is it based on informal ancedotal experience (if so I have anecdotes
to refute it), or is it based on hard data -- if the latter, ;et's see
the data.

The second argument is also speculative. From where I sit it seems likely
to be quite wrong. Again, you need data to back his up.

The third argument is the only relevant one to consider, and here the
issue is solely whether there are good Ada tools that can interface
to the existing C/C++ code that is to be reused.

I think that's the only real issue. Rather than make bogus generalizations
about DSP's as a class. The proper issue is to look at the very specific
circcumstances. given the DSP or DSP's to be chosen, what Ada tools are
available, or could be made available, and how well would they work? A
waiver is reasonable or not depending on the answer to this question!

Remember here that TI recently voted with significant $$$ in their 
confidence in the viability and importance of Ada on DSP's. I find
tthat more convincing than Ken's dataless speculations!

Re: Waiver question

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken said
> 
> <<  *  DSP engineers would rather program in C++ than Ada, since it
>      makes them more valuable in the larger commericial marker. As a
>      result, there is much higher attrition when DSP engineers are
>      required to program in Ada, and so the development cost is higher.
> 
>   *  Most DSP tools are for C/C++. The number of DSP tools for Ada
>      will shrink, given that the DoD has decided not to mandate Ada
>      anymore.
> 
>   *  Most existing DSP code is in C/C++. Therefore, reuse is easier
>      if the new code is also written in C++.
> >>
> 
> The first argument seems pretty bogus to me -- Ken, is this just a guess,
> or is it based on informal ancedotal experience (if so I have anecdotes
> to refute it), or is it based on hard data -- if the latter, ;et's see
> the data.

According to the waiver request, this statement is based on 40 exit
interviews
at the company in question. If you know of a significant pool of DSP
programmers
who want to work in Ada, or don't want to work in C++ (or both), that
information
would be useful.

> The second argument is also speculative. From where I sit it seems likely
> to be quite wrong. Again, you need data to back his up.

For the TI DSP family, I know of only one Ada 83 vendor (TI/Tartan) and
no
Ada 95 vendors. The AdaIC databases confirm my understanding. There
appears
to be more than one C/C++ vendor (TI is one) for this family, however.
The
request does not cite a specific number. There does seem to be a lot of
DSP
support tools that are oriented to C/C++; see

   http://www.embedded.com/97/sr9704.htm

This does not make a strong case for Ada for this class of DSPs.
Of course, if someone has data that indicates that Ada support for TI
DSPs
is growing, or that C++ is small/declining, that would be useful
information.

> The third argument is the only relevant one to consider, and here the
> issue is solely whether there are good Ada tools that can interface
> to the existing C/C++ code that is to be reused.

True, however, the NRC report does point out that having to write Ada
wrappers is a disincentive to the use of Ada. Since Ada 83 would have to
be used, these wrappers would not be able to take advantage of Ada 95's
improvements in this area. This might not be a strong argument by
itself,
but it does seem to be a disadvantage.

> I think that's the only real issue. Rather than make bogus generalizations
> about DSP's as a class. The proper issue is to look at the very specific
> circcumstances. given the DSP or DSP's to be chosen, what Ada tools are
> available, or could be made available, and how well would they work? A
> waiver is reasonable or not depending on the answer to this question!
> 
> Remember here that TI recently voted with significant $$$ in their
> confidence in the viability and importance of Ada on DSP's. I find
> tthat more convincing than Ken's dataless speculations!

Of course, I didn't WRITE the waiver; I'm just READING it. No need to
get your blood pressure up.  :)

I hope you're right regarding TI's motives for purchasing Tartan.
However,
I think we'll have to wait and see what TI/Tartan does with all those
$$$s.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Waiver question

[Ken Garlington]

Ken Garlington wrote:
> 
> For the TI DSP family, I know of only one Ada 83 vendor (TI/Tartan) and
> no
> Ada 95 vendors. The AdaIC databases confirm my understanding. There
> appears
> to be more than one C/C++ vendor (TI is one) for this family, however.
> The
> request does not cite a specific number.

I've just been told that for the TI C40 DSP, the following languages are
available:

Ada 83 - TI (Tartan) appears to be the only vendor.
C++    - TI (Tartan) appears to be the only vendor. However, TI (Tartan)
         has announced that they are discontinuing support for this
product.
C      - TI appears to be the only vendor.

Based on this, I would say that the growth in the C++ market for this
target is
not as large as the vendor believes. If anyone has different
information, let
me know.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Waiver question

[Corey Minyard]

Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> 
> Ken Garlington wrote:
> > 
> > For the TI DSP family, I know of only one Ada 83 vendor (TI/Tartan) and
> > no
> > Ada 95 vendors. The AdaIC databases confirm my understanding. There
> > appears
> > to be more than one C/C++ vendor (TI is one) for this family, however.
> > The
> > request does not cite a specific number.
> 
> I've just been told that for the TI C40 DSP, the following languages are
> available:
> 
> Ada 83 - TI (Tartan) appears to be the only vendor.
> C++    - TI (Tartan) appears to be the only vendor. However, TI (Tartan)
>          has announced that they are discontinuing support for this
> product.
> C      - TI appears to be the only vendor.

Actually, there is now a GCC port for the C30/C40 DSP.  Theoretically,
a C++ port and a GNAT port should be doable.  The C++ port should be a
matter of libraries.  I'm not sure what the effects of the C40's
minimum addressable unit being 32-bits would be on GNAT, but if that
is not a problem it is a matter of libraries and bindings.

> 
> Based on this, I would say that the growth in the C++ market for this
> target is
> not as large as the vendor believes. If anyone has different
> information, let
> me know.

Since DSP's generally perform very focused tasks that require high
performance, they are generally programmed as close to the hardware as
possible.  The C30/C40 change that since they are more general purpose
than most DSPs, so people want to replace the control processors on
boards with them.  I did a board that did signal processing and
interface control; it was around 40KLOC of C code on the C40.  But the
compiler situation for these processors has never been that great.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: Waiver question

[Richard Kenner]

In article <m2k9luibub.fsf@acm.org> Corey Minyard <minyard@acm.org> writes:
>Actually, there is now a GCC port for the C30/C40 DSP.

I keep hearing rumors of this port, but have not actually ever been
able to track it down.  If you know where it is, I'd appreciate
hearing about it.  The only such port I know was done by a group
inside TI who have made it quite clear that they have no interest in
doing anything to make it generally available.  Note that, contrary
to what some believe, they are under no obligation to do so due to
the GPL.

Re: Waiver question

[Larry Kilgallen]

In article <m2k9luibub.fsf@acm.org>, Corey Minyard <minyard@acm.org> writes:

> Actually, there is now a GCC port for the C30/C40 DSP.  Theoretically,
> a C++ port and a GNAT port should be doable.  The C++ port should be a
> matter of libraries.  I'm not sure what the effects of the C40's
> minimum addressable unit being 32-bits would be on GNAT, but if that

The minimum addressable unit on DEC Alpha is 32 bits, except for the very
latest chip where it was altered for purposes of Intel emulation. GNAT
reportedly "does" DEC Alpha, and I presume that is without relying on
OS traps for every unaligned instruction :-).

Larry Kilgallen

Re: Waiver question

[Corey Minyard]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
> In article <m2k9luibub.fsf@acm.org>, Corey Minyard <minyard@acm.org> writes:
> 
> > Actually, there is now a GCC port for the C30/C40 DSP.  Theoretically,
> > a C++ port and a GNAT port should be doable.  The C++ port should be a
> > matter of libraries.  I'm not sure what the effects of the C40's
> > minimum addressable unit being 32-bits would be on GNAT, but if that
> 
> The minimum addressable unit on DEC Alpha is 32 bits, except for the very
> latest chip where it was altered for purposes of Intel emulation. GNAT
> reportedly "does" DEC Alpha, and I presume that is without relying on
> OS traps for every unaligned instruction :-).
> 

Umm...  No.

The minimum addressable unit on the Alpha is a byte (8 bits).  The
alignment of 32-bit values (and instructions) on the the Alpha is on
32-bit boundaries, but there is no alignment restriction on bytes.
The issue is if you increment a pointer value physically by 1 how many
bits do you skip over?  For instance, the following code (and I hope
the kind readers of the newsgroup excuse me for using C, but it is
more compact for this type of stuff):

int
main()
{
   int a[4];
   char *c;

   a[0] = 0; a[1] = 0; a[2] = 0; a[3] = 0;
   c = (char *) a;
   c[0] = 0x01;
   c[1] = 0x02;
   c[2] = 0x03;
   c[3] = 0x04;
   printf("%x %x %x %x\n", a[0], a[1], a[2], a[3]);
   return 0;
}

on the Alpha will print:
	1020304 0 0 0
and on the C40 will print:
	1 2 3 4
because on the C40 a char and an int are the same size because the
minimum size of any addressable unit is 32-bits.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: Waiver question

[Laurent Guerby]

Corey Minyard <minyard@acm.org> writes:
> [...] For instance, the following code (and I hope
> the kind readers of the newsgroup excuse me for using C, but it is
> more compact for this type of stuff):

   Sacrilege ! See below. ;-)

> int
> main()
> {
>    int a[4];
>    char *c;
> 
>    a[0] = 0; a[1] = 0; a[2] = 0; a[3] = 0;
>    c = (char *) a;
>    c[0] = 0x01;
>    c[1] = 0x02;
>    c[2] = 0x03;
>    c[3] = 0x04;
>    printf("%x %x %x %x\n", a[0], a[1], a[2], a[3]);
>    return 0;
> }

   Here a somewhat equivalent Ada code, people can judge the
"compactness": 

with Ada.Text_IO;         use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
with Interfaces;          use Interfaces;
procedure Main is
   A : array (1..4) of Integer   := (others => 0);
   C : array (1..4) of Integer_8 := (1, 2, 3, 4);   
   for C'Address use A'Address;
begin
   Put (A (1), 12, 16);   Put (A (2), 12, 16);
   Put (A (3), 12, 16);   Put (A (4), 12, 16);
   New_Line;
end Main;           

   Of course in Ada the "with" clauses are mandatory (not the case of
#include in C. If you want to use the C printf, you can also do it, it
removes a few Ada IO with clauses:

procedure printf (Fmt : String; A, B, C, D : Integer);
pragma Import (C, printf);
...
printf ("%x %x %x %x" & ASCII.LF, A (1), A (2), A (3), A (4));

> on the Alpha will print:
> 	1020304 0 0 0
> and on the C40 will print:
> 	1 2 3 4
> because on the C40 a char and an int are the same size because the
> minimum size of any addressable unit is 32-bits.

   On Intel/Linux/GNAT I get

 16#4030201#       16#0#       16#0#       16#0# 

   or

4030201 0 0 0

> Corey Minyard               Internet:  minyard@acm.org
>   Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Waiver question

[Corey Minyard]

Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> writes:

> 
> Corey Minyard <minyard@acm.org> writes:
> > [...] For instance, the following code (and I hope
> > the kind readers of the newsgroup excuse me for using C, but it is
> > more compact for this type of stuff):
> 
>    Sacrilege ! See below. ;-)
> 
> > int
> > main()
> > {
> >    int a[4];
> >    char *c;
> > 
> >    a[0] = 0; a[1] = 0; a[2] = 0; a[3] = 0;
> >    c = (char *) a;
> >    c[0] = 0x01;
> >    c[1] = 0x02;
> >    c[2] = 0x03;
> >    c[3] = 0x04;
> >    printf("%x %x %x %x\n", a[0], a[1], a[2], a[3]);
> >    return 0;
> > }
> 
>    Here a somewhat equivalent Ada code, people can judge the
> "compactness": 
> 
> with Ada.Text_IO;         use Ada.Text_IO;
> with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
> with Interfaces;          use Interfaces;
> procedure Main is
>    A : array (1..4) of Integer   := (others => 0);
>    C : array (1..4) of Integer_8 := (1, 2, 3, 4);   
>    for C'Address use A'Address;
> begin
>    Put (A (1), 12, 16);   Put (A (2), 12, 16);
>    Put (A (3), 12, 16);   Put (A (4), 12, 16);
>    New_Line;
> end Main;           

I stand corrected.  I actually don't know Ada that well and had
forgotten about what the "for" statement can do.  However, I could
have made the C just as compact, it just would have been harder to
read.

> 
>    Of course in Ada the "with" clauses are mandatory (not the case of
> #include in C. If you want to use the C printf, you can also do it, it
> removes a few Ada IO with clauses:
> 
> procedure printf (Fmt : String; A, B, C, D : Integer);
> pragma Import (C, printf);
> ...
> printf ("%x %x %x %x" & ASCII.LF, A (1), A (2), A (3), A (4));
> 
> > on the Alpha will print:
> > 	1020304 0 0 0
> > and on the C40 will print:
> > 	1 2 3 4
> > because on the C40 a char and an int are the same size because the
> > minimum size of any addressable unit is 32-bits.
> 
>    On Intel/Linux/GNAT I get
> 
>  16#4030201#       16#0#       16#0#       16#0# 
> 
>    or
> 
> 4030201 0 0 0

This is correct for Intel since it is little endian.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: Waiver question

[Kaz Kylheku]

In article <m2zpui69zn.fsf@acm.org>, Corey Minyard  <minyard@acm.org> wrote:

>The minimum addressable unit on the Alpha is a byte (8 bits).  The
>alignment of 32-bit values (and instructions) on the the Alpha is on
>32-bit boundaries, but there is no alignment restriction on bytes.
>The issue is if you increment a pointer value physically by 1 how many
>bits do you skip over?  For instance, the following code (and I hope
>the kind readers of the newsgroup excuse me for using C, but it is
>more compact for this type of stuff):

Stated more compactly, the question is the size of a character with
respect to a long integer.

>on the Alpha will print:
>	1020304 0 0 0
>and on the C40 will print:
>	1 2 3 4
>because on the C40 a char and an int are the same size because the
>minimum size of any addressable unit is 32-bits.

Note that this will cause severe problems for the C standard I/O library.  The
return value of the getc function is 'int'. The library assumes that the range
of unsigned char (0 to UCHAR_MAX) is a subrange of int (INT_MIN to INT_MAX),
and that an EOF value can be placed in the int range such that it doesn't
interfere with the unsigned char subrange. (The values 0 to UCHAR_MAX must be
representable because binary streams must transparently record internal data,
according to the standard, and internal data is composed of bytes. Any byte
value written must read back correctly.)

If sizeof(char) == sizeof(int) == sizeof(unsigned int), getc cannot be properly
implemented, because the range of int is too small to capture all the values of
unsigned char _and_ have room for an EOF. Thus a conforming hosted
implementation of C is not possible. Ha ha. :) That's what you get for
overloading the meaning of a return value.

Re: Waiver question

[Robert Dewar]

Corey said

<<on the Alpha will print:
        1020304 0 0 0
and on the C40 will print:
        1 2 3 4
because on the C40 a char and an int are the same size because the
minimum size of any addressable unit is 32-bits.>>

Of course there is no requirement in C that you put a char in a single
32-bit word, you could perfectly well use a more compact representenation,
with a special form for the (char *) pointer (I believe the Cray C does
this -- rather than putting chars in 64 bits).

Of course it is simpler to put one character/32 bits, and if you make
this choice, (which is what I believe the 1750-A port for GNAT does,
one character per 16 bits), then things are relatively simple.

type String in Ada is packed, which means for example that you cannot
meaningfully get the address of individual elements in the string in
any case and remain portable (i.e. 'Address of two successive characters
in a string may well be the same). 

So it would be attractive to pack characters if you did a C30 GNAT port,
even if the C compiler did not, and it would fall out free, since this kind
of packing is done by the front end anyway in GNAT.

Re: Waiver question

[Robert Dewar]

Larry says

<<The minimum addressable unit on DEC Alpha is 32 bits, except for the very
latest chip where it was altered for purposes of Intel emulation. GNAT
reportedly "does" DEC Alpha, and I presume that is without relying on
OS traps for every unaligned instruction :-).>>


You are confusing addressibility with accesibility. The minimum addressable
unit on the DEC Alpha (all models) is 8-bits, since it has normal byte
addressing. It is true that to *access* a single byte, you need to generate
a couple of extra instructions, but that is easy to handle.

Where the minimum *addressable* unit is 32-bits, things are more complex,
but the 1750-A port of GCC would indicate that this can certainly be done,
and from reports, there are indeed ports of GCC for 32-bit addressable
machines, so it is certainly feasible.

Re: Waiver question

[Richard Kenner]

In article <1997Apr28.151327.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>The minimum addressable unit on DEC Alpha is 32 bits, except for the very
>latest chip where it was altered for purposes of Intel emulation. GNAT
>reportedly "does" DEC Alpha, and I presume that is without relying on
>OS traps for every unaligned instruction :-).

This is quite confused.  The Alpha was very carefully designed with a
set of instructions whose purpose is to allow efficient loading and
storing of 8- and 16-bit objects.  DEC has a nice explanation of these
sequences someplace on their web pages (sorry, but I can't find my
pointer to it at the moment).

The problem with these sequences is that they are not atomic.  That
is that problem that will be remedied on Alpha processors starting
with EV56.

Re: Waiver question

[Robert A Duff]

In article <5k52k2$7v0$1@news.nyu.edu>,
Richard Kenner <kenner@lab.ultra.nyu.edu> wrote:
>The problem with these sequences is that they are not atomic.  That
>is that problem that will be remedied on Alpha processors starting
>with EV56.

Why is that a problem?

- Bob

Re: Waiver question

[Kaz Kylheku]

In article <E9G869.CqB@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>In article <5k52k2$7v0$1@news.nyu.edu>,
>Richard Kenner <kenner@lab.ultra.nyu.edu> wrote:
>>The problem with these sequences is that they are not atomic.  That
>>is that problem that will be remedied on Alpha processors starting
>>with EV56.
>
>Why is that a problem?

Because you may wish to code an interrupt service routine for an embedded
system without dropping down to the assembly language level. In that case
it becomes important to know that you can modify some variable atomically;
you suddenly care how the access is compiled into machine code. It's not
practical or desirable to write interrupt service routines in assembly
language.

If access to that object is not atomic, the process that was interrupted could
have been in the middle of trying to read that variable. 

Re: Waiver question

[Robert A Duff]

In article <5kb8ol$18o@bcrkh13.bnr.ca>,
Kaz Kylheku <kaz@vision.crest.nt.com> wrote:
>Because you may wish to code an interrupt service routine for an embedded
>system without dropping down to the assembly language level. In that case
>it becomes important to know that you can modify some variable atomically;
>you suddenly care how the access is compiled into machine code. It's not
>practical or desirable to write interrupt service routines in assembly
>language.
>
>If access to that object is not atomic, the process that was interrupted could
>have been in the middle of trying to read that variable. 

No, I don't buy that.  If you want to modify variables atomically in
Ada, then you use pragma Atomic.  And it's no big deal if that causes an
8-bit thing to take up 32 bits.

The real answer to my question, as Robert Dewar e-mailed to me
privately, is that variables (including components) are independently
addressable by multiple tasks, unless they're part of a pragma-packed
type.  If you have a record containing three booleans, then on a
Pentium, it will fit in three bytes, whereas on an Alpha (early
versions), it will need 12 bytes.  Unless there's a pragma Pack (in
which case it will be three *bits* on both machines).  If task 1 refers
to X.Y, and task 2 refers to X.Z, that's supposed to be OK, unless the
type of X has a pragma Pack.

Strange semantics, IMHO.  Pragma Pack is all about time-vs-space
trade-offs, but it has this weird side-effect on tasking semantics.  We
should have a way to *declare* things independently adressable, but the
default should be that things are not.  Instead of forcing the compiler
to assume that *everything* is independently addressable.

- Bob

Re: Waiver question

[Larry Kilgallen]

In article <E9J2rB.G04@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

> Strange semantics, IMHO.  Pragma Pack is all about time-vs-space
> trade-offs, but it has this weird side-effect on tasking semantics.  We
> should have a way to *declare* things independently adressable, but the
> default should be that things are not.

I do not understand why you feel the default should be task-unsafe.
The general trend in Ada seems to be that safeguards are enabled by
default and disabled by explicit statement.

In addition to multiprocessing considerations, there are also
efficiency reasons for having the compiler put each variable
into a separate Alpha longword (or set thereof).

The only wasted resource is memory, and typical applications on
Alpha have lots.  Others can declare their preference for the
task-unsafe version on particular constructs.

Certainly defaulting to task-safe seems to be a lot more friendly
for those porting programs in from other platforms.

Larry Kilgallen

Re: Waiver question

[Robert A Duff]

In article <1997May2.063334.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>I do not understand why you feel the default should be task-unsafe.
>The general trend in Ada seems to be that safeguards are enabled by
>default and disabled by explicit statement.

I agree with that general language design principle.  Mostly, Ada
follows it, and that's usually good.  In some cases, Ada disobeys this
principle, and that's usually bad.  (For example, Ada requires extra
effort to declare a constant, rather than a variable -- it should be the
other way 'round; that is, "X: Integer := 7;" would be a constant,
whereas "X: var Integer := 7;" would be a variable (or "X: variable
Integer := 7;", if you hate abbreviations).  Interestingly, Ada is
inconsistent on this point -- for a parameter, the default is "in",
which means it's constant.)

Anyway, back to the point:  Independent addressability does not imply
task-safety.  So, if variables are not automatically protected by
locking/synchronization by default, it seems to me that they should not
have to be independently addressable by default.

In keeping with the principle you describe, above, I think I would
prefer a language in which any variable that is potentially shared by
multiple tasks would have to be explicitly declared "shared".  But to do
that, you would need a good deal of extra mechanism.  For example,
subprogram specs would need to be annotated with some syntax that says
"I modify shared variables" or whatever.  In the absence of such
mechanisms, Ada defaults to task-unsafe -- if you want locking of some
sort, you have to say so, and if you don't, you're erroneous.  Any
variable is potentially shared, and any use of shared variables requires
a great deal of care.  Given that, it seems that independent
addressability should also default to the "unsafe" way.

Anyway, my main point was that independent addressability should not be
turned on and off by pragma Pack.  These should be two independent
features.  I don't feel strongly, one way or the other, about what the
default should be, and I'm partly convinced by your argument above.

>The only wasted resource is memory, and typical applications on
>Alpha have lots.

I don't buy this reasoning.  Wasting space will typically cause you to
waste time, too, due to caching and paging.  So it's not true that "Now
that memory is cheap, we can squander it."

- Bob

Re: Waiver question

[Larry Kilgallen]

In article <E9KA78.DxH@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

> Anyway, back to the point:  Independent addressability does not imply
> task-safety.  So, if variables are not automatically protected by
> locking/synchronization by default, it seems to me that they should not
> have to be independently addressable by default.
> 
> In keeping with the principle you describe, above, I think I would
> prefer a language in which any variable that is potentially shared by
> multiple tasks would have to be explicitly declared "shared".  But to do

A casual programmer would presume that if variable A is only modified
by task AA and variable B is only modified by task BB then they are
task-safe.  This is not true if the variables share a longword on
Alpha.  Having variables default to not sharing a longword goes a
long way toward eliminating this exposure.

Regarding Robert Dewar's comment about DEC changing their mind
with regard to byte instructions, I believe that was driven by
the need to emulate code compiled for Intel machines which had
never gotten recompiled specifically for Alpha.  Market realities,
rather than machine efficiency are at play.

Larry Kilgallen

Re: Waiver question

[Robert A Duff]

In article <1997May2.164921.1@eisner>,
Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>A casual programmer would presume that if variable A is only modified
>by task AA and variable B is only modified by task BB then they are
>task-safe.  This is not true if the variables share a longword on
>Alpha.  Having variables default to not sharing a longword goes a
>long way toward eliminating this exposure.

OK, but remember that we're only talking about subcomponents of the same
record or array, here.  Two different object declarations always produce
independently addressable objects -- it's just a question of whether X.A
and X.B are independently addressable (which currently depends on
whether the type of X is packed).

>Regarding Robert Dewar's comment about DEC changing their mind
>with regard to byte instructions, I believe that was driven by
>the need to emulate code compiled for Intel machines which had
>never gotten recompiled specifically for Alpha.  Market realities,
>rather than machine efficiency are at play.

Maybe DEC wanted to be Ada-friendly.  ;-)

- Bob

Re: Waiver question

[Larry Kilgallen]

In article <E9KxAK.IyC@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
> In article <1997May2.164921.1@eisner>,
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote:
>>A casual programmer would presume that if variable A is only modified
>>by task AA and variable B is only modified by task BB then they are
>>task-safe.  This is not true if the variables share a longword on
>>Alpha.  Having variables default to not sharing a longword goes a
>>long way toward eliminating this exposure.
> 
> OK, but remember that we're only talking about subcomponents of the same
> record or array, here.  Two different object declarations always produce
> independently addressable objects -- it's just a question of whether X.A
> and X.B are independently addressable (which currently depends on
> whether the type of X is packed).

Robert Dewar stated earlier in this thread that Alpha was "addressable"
to the byte level even though only "accessible" down to the byte level.
If both of you have the same meaning for the term "addressable",
then the fact that A and B are independently addressable does not
necessarily mean they are in separate longwords.

Larry Kilgallen

Re: Waiver question

[Robert Dewar]

Larry says

<<Robert Dewar stated earlier in this thread that Alpha was "addressable"
to the byte level even though only "accessible" down to the byte level.
If both of you have the same meaning for the term "addressable",
then the fact that A and B are independently addressable does not
necessarily mean they are in separate longwords.>>

Sorry, we are using terminology here without clearly explaining it. The
key term is independent. This was coined by Norman Schulman in his thesis
on shared variables, and later reused by me in my Ada9X report on shared
variables (this was one of the Ada 9X SEI special reports) which was the
basis for some of the thinking in the Ada 9X design

Independent means precisely accessible my multiple simultaneous tasks
in this context.

By the way, a little history here. In the Ada 83 design, the fields of
ALL composite objects were non-independent, i.e. the language of 9.11
was such that two tasks could not work on separate rows of an array.

I always knew the language was like this, and assumed it was intentional,
because although in some cases such independent access is possible, in the
packed case, it is quite impossible on most machines. I knew this problem
well because we had addressed it in Algol-68 (which by the way was one of
the first languages of the Algol class to have built in concurrency, and
so ran into many of these problems first).

However, a change was made in the printer's proof just days before
final publication, with no review by anyone, that chnaged this, and
the final Ada 83 standard requires indepedence for ALL fields and
elements of composites.

Apparently the designers had always intended this, and regarded the
language in 9.11 as a simple typo (it was a matter of the terminology used
to describe variables -- whether it included subfields or not). They
regarded it as important for, e.g. two tasks to be able to work on separate
rows of an array.

BUT, this change had the disastrous effect of requirng full independence
for packed arrays and for packed records. In fact those making the change
at the last minute without review never considered this side effect, and
thus made a huge mistake without realizing it (changes at the last
minute are always dangerous).

In practice, no one implemented this (the only implementation in some
architectures would involve a kernel call for every access to a packed
array, even in non-tasking contexts, because of separate compilation).
Luckily, the ACVC suite did not attempt to enforce this requirement of
Ada 83, so no real harm was done.

But clearly we needed to clean this up. The compromise in Ada 95 is to
require independence in the normal case but not in the packed case.
This seems a reasonable compromise for most machines, but is problematical
on the Alpha and similar machines which do not have independent byte
addressability.

P.S. Please note that a previous post I made here was exactly wrong (must
have been my evil twin brother again). I said that Ada 83 did not require
independence for composites. That, as is clear from the above history,
is wrong (I guess I was indulging in wishful thinking, and thinking about
the standard as approved by the committee, rather than the one that was
printed. Of course it is fine to fix typos in a final printers draft, but
here was a remarkable case in which one persons typo was another persons
major change. A useful cautionary example :-)

Robert Dewar

Re: Waiver question

[Robert Dewar]

Larry said

<<A casual programmer would presume that if variable A is only modified
by task AA and variable B is only modified by task BB then they are
task-safe.  This is not true if the variables share a longword on
Alpha.  Having variables default to not sharing a longword goes a
long way toward eliminating this exposure.
>>

Well of course if you have two separate variables, you have to make sure
they can be indepednetly accessed by tasks, and if the compiler cannot
verify that this might not occur, then of cours they cannot occupy the
same longword.

The more uncomfortable case is one like this:

   type x is array (1 .. 64) of character;

now, it is really uncomfortable to by default allocate one longword
for each character for this declaration, and in practice it is
extremely unlikely that two tasks would access different characters
of this string.

Note that in Ada 83, such access would be erroneous in any case. In Ada 95,
this kind of access is valid, but the consequence of this change is rather
unpleasant for the (old style) Alpha.

Re: Waiver question

[Robert Dewar]

Larry said

<<I do not understand why you feel the default should be task-unsafe.
The general trend in Ada seems to be that safeguards are enabled by
default and disabled by explicit statement.>>

I don't think that's quite the right principle. Ada defaults to unsafe
if for a great majority of implementations, being safe would be too
costly or otherwise infeasible.

I actually think that the decision in Ada 95 is just right, and reflects

this principle.

For unpacked records, on most architectures, it is reasonable to default
to task safe -- yes it costs on the Alpha, but that is because the Alpha
made a bad architectural choice -- and that choice has a penalty here.
The judgment that the choice was a bad one seems to be borne out by the
fact that Digital is "fixing" it.

On the other hand, for packed records, on nearly all architectures,
guaranteeing task safety by default would pretty much wipe out the
effectiveness of packing. This was a major hole in Ada 83 (where
independence was required by the language even for packed records,
but luckily not tested for, and hence entirely ignored except by
language lawyers).

For an in-depth discussion of the independence issue, see Norman
Schulman's Thesis on "Semantics of Shared Variables in Programming
Languages" (or something like that -- from NYU -- I was his advisor).

Little information tidbit: Norman Schulman's wife is the well known
Canadian journalist who recently wrote the book "Red China Blues"
on her experiences in China.

Re: Waiver question

[John M. Mills]

In article <E9J2rB.G04@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:

 > Strange semantics, IMHO.  Pragma Pack is all about time-vs-space
 > trade-offs, but it has this weird side-effect on tasking semantics.  We
 > should have a way to *declare* things independently adressable, but the
 > default should be that things are not.

As in: 'pragma Volatile( ... );' ??  I have used 'pragma Pack(..);' to buy
space at the expense of CPU time in a mission log kept on a solid-state device
of modest (<100 MBy) capacity.  This had a direct impact on the length of
test our equipment could monitor.  I have more frequently used 'pragma Pack'
for inter-processor communications, such as to load and unload packetized
communications records.  Although I have not had to pack data to conserve
RAM space, I couldn't rule this out for other users.

-- 
John M. Mills, Senior Research Engineer   --   john.m.mills@gtri.gatech.edu
   Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834
        Phone contacts: 404.894.0151 (voice), 404.894.6258 (FAX)
            "Lies, Damned Lies, Statistics, and Simulations"

Re: Waiver question

[Robert Dewar]

Richard Kenner said

<<The problem with these sequences is that they are not atomic.  That
is that problem that will be remedied on Alpha processors starting
with EV56.>>

Of course in Ada they do not *need* to be atomic -- if you waste a bit
of space to make sure stand alone objects are not too close together,
and the same in records.

You don't need to worry about atomic access in any packed structure of
course, and the standard string type is packed (i.e. it is erroneous
for one task to store the 3rd charater of a string while another task
loads the fourth character).

So it is definitely managable.

Re: Waiver question

[Larry Kilgallen]

In article <dewar.862381265@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Richard Kenner said
> 
> <<The problem with these sequences is that they are not atomic.  That
> is that problem that will be remedied on Alpha processors starting
> with EV56.>>
> 
> Of course in Ada they do not *need* to be atomic -- if you waste a bit
> of space to make sure stand alone objects are not too close together,
> and the same in records.
> 
> You don't need to worry about atomic access in any packed structure of
> course, and the standard string type is packed (i.e. it is erroneous
> for one task to store the 3rd charater of a string while another task
> loads the fourth character).

Although a compiler can take care to place separate components
of an unpacked structure into separate quadwords, a programmer
can use representation clauses to bring them back together. If
a programmer uses representation clauses that is an implicit
declaration that they know what they are doing, so compiler
warnings seem inappropriate.

But programmers often do not know what they are doing. Alpha
programs often have code which does not properly handle atomicity,
and until recently even VMS had at least one such piece of code
(not written in Ada) of which I am aware.

Larry KIlgallen

Bad .diff files in gnat-3.09 in Linux

[Benoit Jauvin-Girard]

I couldn't find any help on this in any docs, FAQs or archives, so...

I'm trying to recompile GNAT 3.09 on a i586-unknown-linux system, with
libc-5.4.23 and binutils-2.7.0.9 .  When I try to apply the gcc-272.diff
and linux.diff patches (on gcc-2.7.2.1, as prescribed), both patches fail:
the gcc-272 patch is an inexact fit, and the linux patch just fails.

Needless to say, the compilation then goes wrong.

I figure I'm either using the wrong patches, the wrong switches or the
wrong patch executable - anybody encounter that problem?

(...Alternatively, can somebody e-mail me the patched files?)

--
... Benoit Jauvin-Girard (jhove@cam.org)
-*-* http://www.cam.org/~jhove *-*-
"If a tree falls in the forest ... and we've already sold the tree ... does
it have Quality?"
"How many angels can dance on your head?"
	- The Boss and Ratbert, discussing the Quality Assurance process.

Re: Bad .diff files in gnat-3.09 in Linux

[Albert K. Lee]

On 7 May 1997 09:01:22 -0400, Benoit Jauvin-Girard <jhove@CAM.ORG> wrote:
>
>I couldn't find any help on this in any docs, FAQs or archives, so...
>
>I'm trying to recompile GNAT 3.09 on a i586-unknown-linux system, with
>libc-5.4.23 and binutils-2.7.0.9 .  When I try to apply the gcc-272.diff
>and linux.diff patches (on gcc-2.7.2.1, as prescribed), both patches fail:
>the gcc-272 patch is an inexact fit, and the linux patch just fails.
>
>Needless to say, the compilation then goes wrong.
>
>I figure I'm either using the wrong patches, the wrong switches or the
>wrong patch executable - anybody encounter that problem?
>
>(...Alternatively, can somebody e-mail me the patched files?)

I have exactly the same system.  Untar gcc, untar GNAT, mv the
gnat*/ada/ directory to under the gcc-2.7.2.1 directory, cd into the
gcc directory and apply the gcc-272 patch ("patch -p0 <...>").  The
linux patch is *not* required at all.  Then follow the instructions in
gcc*/INSTALL.

Bottom line: just don't bother using the linux diff.  Also, what
version of GNAT do you have already installed?  If it's too old,
compilation will bomb ...


-Albert K. Lee
 aklee@interport.net

Re: Waiver question

[Tarjei Jensen]

I belive that currently C++ is viewed as unsuitable for DSP work.
If my memory serves me right someone in this group mentioned that the Japanese
are working on a sanitized (scaled down) version of C++ that is supposed to be
suitable for DSP work.



Greetings,
-- 
// Tarjei T. Jensen 
//    tarjeij@ulrik.uio.no || fax +47 51664292  || voice +47 51 85 87 39
//   Support you local rescue centre: GET LOST!
// Working, but not speaking for the Norwegian Hydrographic Service.

Re: Waiver question

[Steve Doiel]

In article <33585385.C8D@lmtas.lmco.com>, GarlingtonKE@lmtas.lmco.com says...
>
>Consider a waiver request to use C++ in a Digital Signal Processing
>application. The waiver is based essentially on these arguments:
>
>  *  DSP engineers would rather program in C++ than Ada, since it
>     makes them more valuable in the larger commericial marker. As a
>     result, there is much higher attrition when DSP engineers are
>     required to program in Ada, and so the development cost is higher.
>
>  *  Most DSP tools are for C/C++. The number of DSP tools for Ada
>     will shrink, given that the DoD has decided not to mandate Ada
>     anymore.
>
>  *  Most existing DSP code is in C/C++. Therefore, reuse is easier
>     if the new code is also written in C++.
>
>Anyone have a reason to think this waiver shouldn't be approved?
>

Yes.  Exactly the same reason I think the waiver shouldn't be approved to
program the system in COBOL.  If I understand correctly the intent of the
mandate was to reduce the divergence tools used for system development, and
thus reduce long term costs.  I believe this has been successful.

Choosing different systems seems contrary to this intent.

There is evidence that Ada is a better choice for the software lifecycle than
C/C++ and this should be reinforced.  In order for Ada to remain the best
choice it requires continued support and use.  This means you!

Personally I'm tired of having systems that are technically superior die
out because inferior systems have an advantage in marketing.  But then
history does have a way of repeating itself.

Steve Doiel

Re: Waiver question

[Dean Runzel]

Ken Garlington wrote:
> 
> Consider a waiver request to use C++ in a Digital Signal Processing
> application. The waiver is based essentially on these arguments:
> 
>   *  DSP engineers would rather program in C++ than Ada, since it
>      makes them more valuable in the larger commericial marker. As a
>      result, there is much higher attrition when DSP engineers are
>      required to program in Ada, and so the development cost is higher.
> 
>   *  Most DSP tools are for C/C++. The number of DSP tools for Ada
>      will shrink, given that the DoD has decided not to mandate Ada
>      anymore.
> 
>   *  Most existing DSP code is in C/C++. Therefore, reuse is easier
>      if the new code is also written in C++.
> 
> Anyone have a reason to think this waiver shouldn't be approved?
> 
> --
> LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
> For job listings, other info: http://www.lmtas.com or
> http://www.lmco.com


Here's a very simple survey you can try. Since you're at
Lockheed-Martin, I'm sure you can find several software engineers who
have used either C/C++ or Ada. Just ask them this question:
If you had to maintain the system 20 years into the future, would you
rather review someone else's C/C++ or someone else's Ada code?

As most texts state, maintenance comsumes 80% of the _lifecycle_ costs
of the project. Ususally, the government lets large contractors off the
hook by not requiring full lifecycle support from the developer. What
would LMCO charge to maintain the code for 20 years? Thus, the developer
has no inherent interest in considering the _lifecycle_ costs of a
project. I saw nothing in the original post related to lifecycle
maintenance costs.


All opinions are my own and do not represent an official government
position on any topic.

Dean Runzel
Software Engineer 
US Army STRICOM (http://www.stricom.army.mil)

Re: Waiver question

[Ken Garlington]

Dean Runzel wrote:
> 
> Ken Garlington wrote:
> >
> > Consider a waiver request to use C++ in a Digital Signal Processing
> > application. The waiver is based essentially on these arguments:
> >
> >   *  DSP engineers would rather program in C++ than Ada, since it
> >      makes them more valuable in the larger commericial marker. As a
> >      result, there is much higher attrition when DSP engineers are
> >      required to program in Ada, and so the development cost is higher.
> >
> >   *  Most DSP tools are for C/C++. The number of DSP tools for Ada
> >      will shrink, given that the DoD has decided not to mandate Ada
> >      anymore.
> >
> >   *  Most existing DSP code is in C/C++. Therefore, reuse is easier
> >      if the new code is also written in C++.
> >
> > Anyone have a reason to think this waiver shouldn't be approved?
> >
> > --
> > LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
> > For job listings, other info: http://www.lmtas.com or
> > http://www.lmco.com
> 
> Here's a very simple survey you can try. Since you're at
> Lockheed-Martin, I'm sure you can find several software engineers who
> have used either C/C++ or Ada. Just ask them this question:
> If you had to maintain the system 20 years into the future, would you
> rather review someone else's C/C++ or someone else's Ada code?

If I ask C++ programmers, they say C++. If I ask Ada programmers, they
say Ada. Of course, such programmers usually have not had to maintain
code in either lanuguage for 20 years, nor do they understand both
languages well enough to compare them, so it's difficult to get an
authoritative opinion at that level.

I did have the "pleasure" in the early 1908's of maintaining assembly
code written in the late 60's, but that's the closest I've ever come
to such a scenario. Unfortunately, that experience doesn't really
answer your question.

> 
> As most texts state, maintenance comsumes 80% of the _lifecycle_ costs
> of the project. Ususally, the government lets large contractors off the
> hook by not requiring full lifecycle support from the developer. What
> would LMCO charge to maintain the code for 20 years? Thus, the developer
> has no inherent interest in considering the _lifecycle_ costs of a
> project. I saw nothing in the original post related to lifecycle
> maintenance costs.

That's because that section was TBD. However, lifecycle costs are
required to be addressed before the waiver is processed.

OTOH, it is oftentimes difficult to provide specific data for a 20
year period, when it comes to lifecycle costs. Therefore, this section
tends to be somewhat subjective.

> 
> All opinions are my own and do not represent an official government
> position on any topic.
> 
> Dean Runzel
> Software Engineer
> US Army STRICOM (http://www.stricom.army.mil)

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Waiver question

[Robert I. Eachus]

In article <33585385.C8D@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:

   >  *  Most existing DSP code is in C/C++. Therefore, reuse is easier
   >	if the new code is also written in C++.

   >    Anyone have a reason to think this waiver shouldn't be approved?

   Sure, the first quoted statement indicates the author has no clue.

   Reuse of C is much easier from Ada than from C.

   Reuse of C is much, much easier from Ada than from C++.

   Reuse of C++ is all but impossible if the code requires any other
compiler, whether for C, Ada, C++, or COBOL.  Note that this is a
compiler issue--using g++ and gcc or even g++ and gnat is
significantly easier than using a different underlying technology.

   Therefore if there is a significant amount of C++ to be reused, you
need to use one specific compiler, otherwise you are better off with
Ada 95.

    This was to some extent true with Ada 83, but with Ada 95 the
advantage of using Ada for interfacing to foreign code has
substantially improved, and not just because there exists a tool for
creating Ada package specifications from .h files.

    The real advantage from using Ada comes at link time.  If you have
two C based products you have to interface to, and they have
conflicting names in them, you are going to be climbing the wall in C
or C++.  In Ada 95 you can decide to link your program as separate
partitions, play compiler specific games in the library structure, or
actually go into one of the C programs and make changes.  That second
choice sounds confusing so watch a real example: I have two COTS C
libraries I want to use in a Windows NT environment.  I can build two
DLLs, one for the Ada binding to each COTS product, then write the
rest in Ada.  At this point I don't need to care if there are
conflicts in the C names used.  (Or it may be the case that one or
both of the DLLs are provided, and all I have to do is construct the
corresponding package spec.)

    In theory, I can do the same thing in C, or for that matter in
Visual C++, if I am very careful never to require include files from
the two COTS packages in the same C source file.  But there are other
gotchas, and I have been got several times.  For example, if the C
code for one product replaces a standard c library operation, such as
malloc, getting things to link properly can be a horror.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Waiver question

[Robert Dewar]

iRobert Eachus says

<<   Reuse of C++ is all but impossible if the code requires any other
compiler, whether for C, Ada, C++, or COBOL.  Note that this is a
compiler issue--using g++ and gcc or even g++ and gnat is
significantly easier than using a different underlying technology.>>

Actually the GNAT interface to C++ is designed to be easily portable to
any C++ compiler. In particular, a major important example of reusing
C++ code from Ada is in the context of SGI Irix systems, with GNAT
interfaced to the SGI C++ compiler.

Re: Waiver question

[Robert I. Eachus]

In article <dewar.861656765@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > Actually the GNAT interface to C++ is designed to be easily portable to
  > any C++ compiler. In particular, a major important example of reusing
  > C++ code from Ada is in the context of SGI Irix systems, with GNAT
  > interfaced to the SGI C++ compiler.

   I knew about the SGI case, but thought it was special.  You are
saying that there is a GNAT to C++ interface that can be re-targeted
by the user?  Neat.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Waiver question

[Robert Dewar]

Robert Eachus said

<<   I knew about the SGI case, but thought it was special.  You are
saying that there is a GNAT to C++ interface that can be re-targeted
by the user?  Neat.>>

Absolutely! All compiler dependent stuff (including the layout of the
vtables etc) is defined in a procedural manner by a runtime routine
which can be reprogrammed. 

Re: Waiver question

[Ken Garlington]

Robert I. Eachus wrote:
> 
> In article <33585385.C8D@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> 
>    >  *  Most existing DSP code is in C/C++. Therefore, reuse is easier
>    >    if the new code is also written in C++.
> 
>    >    Anyone have a reason to think this waiver shouldn't be approved?
> 
>    Sure, the first quoted statement indicates the author has no clue.
> 
>    Reuse of C is much easier from Ada than from C.
> 
>    Reuse of C is much, much easier from Ada than from C++.
> 
>    Reuse of C++ is all but impossible if the code requires any other
> compiler, whether for C, Ada, C++, or COBOL.  Note that this is a
> compiler issue--using g++ and gcc or even g++ and gnat is
> significantly easier than using a different underlying technology.
> 
>    Therefore if there is a significant amount of C++ to be reused, you
> need to use one specific compiler, otherwise you are better off with
> Ada 95.

I believe the vendor is proposing using the same compiler used to
develop the existing C++ code, although that's not explicit in the
waiver.

As for Ada 95, there is no such compiler for the TI DSP target
in question, only an Ada 83 compiler.

> 
>     This was to some extent true with Ada 83, but with Ada 95 the
> advantage of using Ada for interfacing to foreign code has
> substantially improved, and not just because there exists a tool for
> creating Ada package specifications from .h files.
> 
>     The real advantage from using Ada comes at link time.  If you have
> two C based products you have to interface to, and they have
> conflicting names in them, you are going to be climbing the wall in C
> or C++.  In Ada 95 you can decide to link your program as separate
> partitions, play compiler specific games in the library structure, or
> actually go into one of the C programs and make changes.  That second
> choice sounds confusing so watch a real example: I have two COTS C
> libraries I want to use in a Windows NT environment.  I can build two
> DLLs, one for the Ada binding to each COTS product, then write the
> rest in Ada.  At this point I don't need to care if there are
> conflicts in the C names used.  (Or it may be the case that one or
> both of the DLLs are provided, and all I have to do is construct the
> corresponding package spec.)

Since the existing C/C++ code was developed by the same vendor, this
should not be an issue.

> 
>     In theory, I can do the same thing in C, or for that matter in
> Visual C++, if I am very careful never to require include files from
> the two COTS packages in the same C source file.  But there are other
> gotchas, and I have been got several times.  For example, if the C
> code for one product replaces a standard c library operation, such as
> malloc, getting things to link properly can be a horror.
> 
> --
> 
>                                         Robert I. Eachus
> 
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Waiver question

[Robert S. White]

In article <335D0E73.4E92@lmtas.lmco.com>, GarlingtonKE@lmtas.lmco.com says...

>As for Ada 95, there is no such compiler for the TI DSP target
>in question, only an Ada 83 compiler.

  True, it is only validated as an Ada 83 compiler (Tartan Ada v5.2 ?)
but when you throw the -9x switch (/9x in VMS) you get some Ada 95 
functionality.  Enough to make migrating the code back to pure Ada 83 
a royal pain.  Speaking from experience with the c3x and Tartan Ada.
_____________________________________________________________________
Robert S. White                  -- an embedded sys software engineer

Re: Waiver question

[Robert Dewar]

<<As for Ada 95, there is no such compiler for the TI DSP target
in question, only an Ada 83 compiler.>>

True, right now, but if an Ada 95 compiler was needed, it would not be
that hard for one to appear. It is often the case using the GNAT
technology that an entire new Ada 95 port can be built at a price
comparable to what was charged for many "off the shelf" Ada 83
technologies.

Robert Dewar
Ada Core Technologies

Re: Waiver question

[Steve Vestal]

> <<As for Ada 95, there is no such compiler for the TI DSP target
> in question, only an Ada 83 compiler.>>

After searching in this area a little, let me ask if anyone knows of
any available Ada toolset (83 or 95, validated or not) for any DSP
beyond the Tartan/C40 combination?

Steve Vestal
Mail: Honeywell Technology Center, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 951-7049      Fax: 7438     Email: vestal_steve@htc.honeywell.com

Re: Waiver question

[Ken Garlington]

Steve Vestal wrote:
> 
> > <<As for Ada 95, there is no such compiler for the TI DSP target
> > in question, only an Ada 83 compiler.>>
> 
> After searching in this area a little, let me ask if anyone knows of
> any available Ada toolset (83 or 95, validated or not) for any DSP
> beyond the Tartan/C40 combination?

I believe TI (Tartan) also has an Ada83 compiler for the SHARC DSP.

> 
> Steve Vestal
> Mail: Honeywell Technology Center, 3660 Technology Drive, Minneapolis MN 55418
> Phone: (612) 951-7049      Fax: 7438     Email: vestal_steve@htc.honeywell.com

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Waiver question

[Robert I. Eachus]

In article <vc5iv1c8ev8.fsf@porcini.htc.honeywell.com> Steve Vestal <vestal@porcini.htc.honeywell.com> writes:

  > After searching in this area a little, let me ask if anyone knows of
  > any available Ada toolset (83 or 95, validated or not) for any DSP
  > beyond the Tartan/C40 combination?

   Mercury did/does market an Ada 83 compiler for their Intel 860
boards.  (But they are now encouraging users to buy either SHARC or
PowerPC configurations.  Ada 95 for the PowerPC is not that difficult
to find, but no one has yet AFAIK targeted Mercury's environment with
a cross compiler.)


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...