Ada to C++ translator

Ada to C++ translator

[zangnew]

I am looking for an Ada to C++ translator.  The converter will only be
used as an intermediate step and not used on sections of code we will
be re-architecting to make use of C++ functionality.

Thanks You.

Re: Ada to C++ translator

[Jeffrey R. Carter]

zangnew@gmail.com wrote:

> I am looking for an Ada to C++ translator.  The converter will only be
> used as an intermediate step and not used on sections of code we will
> be re-architecting to make use of C++ functionality.

Such a beast is impossible, since there is no translation for tasks and 
protected objects.

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: Ada to C++ translator

[David Emery]

Jeffrey R. Carter wrote:
> zangnew@gmail.com wrote:
> 
>> I am looking for an Ada to C++ translator.  The converter will only be
>> used as an intermediate step and not used on sections of code we will
>> be re-architecting to make use of C++ functionality.
> 
> Such a beast is impossible, since there is no translation for tasks and 
> protected objects.
> 

That's not true.  There's no 1-1 translation, bu a POSIX-based runtime certainly can show how to translate Ada tasking to a sequence of C/POSIX primitives (Mutexes, Semaphores, etc).  It's certainly non-trivial, but it can be done.

A good recent paper on sequential Ada is:

   Audsen, Howard & Nyberg, "Using ASIS to Generate C++ Bindings", Proc SIGAda 2005

For tasking constructs, search for papers by Ted Baker and/or Ted Giering.

If you're a SIGAda member, it's in the proceedings you got last month :-)

    dave

Re: Ada to C++ translator

[Jeffrey R. Carter]

David Emery wrote:

> That's not true.  There's no 1-1 translation, bu a POSIX-based runtime 
> certainly can show how to translate Ada tasking to a sequence of C/POSIX 
> primitives (Mutexes, Semaphores, etc).  It's certainly non-trivial, but 
> it can be done.

That's a translator to C++ + POSIX, not a translator to C++.

One could write a tasking runtime in C++ and translate Ada tasking to calls to 
it, but then one is getting into the area of writing an Ada compiler that uses 
C++ as an intermediate language.

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: Ada to C++ translator

[Gautier Write-only]

zangnew@gmail.com wrote:

> I am looking for an Ada to C++ translator.  The converter will only be
> used as an intermediate step and not used on sections of code we will
> be re-architecting to make use of C++ functionality.
> 
> Thanks You.

As Jeffrey pointed out, it is per se impossible. I can be possible
that also basic Ada things like unconstrained array types cannot be
translated without some OO overhead in C++. Any expert here ?

It seems you are indeed looking for an Ada compiler producing
C or C++ code (since you mention that the converter is an intermediate),
and such tools exist. By googling a bit I found that one for instance:
  http://www.sofcheck.com/products/adamagic.html
HTH
_______________________________________________________________ 
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm 
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm 

NB: For a direct answer, e-mail address on the Web site!

Re: Ada to C++ translator

[REH]

"Gautier Write-only" <gautier@fakeaddress.nil> wrote in message 
news:43D6B75B.A006CC1A@fakeaddress.nil...
> zangnew@gmail.com wrote:
> As Jeffrey pointed out, it is per se impossible. I can be possible
> that also basic Ada things like unconstrained array types cannot be
> translated without some OO overhead in C++. Any expert here ?
>
A vector can easily fit that bill.

Re: Ada to C++ translator

[Martin Krischik]

REH wrote:

> 
> "Gautier Write-only" <gautier@fakeaddress.nil> wrote in message
> news:43D6B75B.A006CC1A@fakeaddress.nil...
>> zangnew@gmail.com wrote:
>> As Jeffrey pointed out, it is per se impossible. I can be possible
>> that also basic Ada things like unconstrained array types cannot be
>> translated without some OO overhead in C++. Any expert here ?

> A vector can easily fit that bill.

Vector uses heap memory
Vector has unbounded

Remove the "easy" part.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada to C++ translator

[REH]

Martin Krischik wrote:
> REH wrote:
>
> >
> > "Gautier Write-only" <gautier@fakeaddress.nil> wrote in message
> > news:43D6B75B.A006CC1A@fakeaddress.nil...
> >> zangnew@gmail.com wrote:
> >> As Jeffrey pointed out, it is per se impossible. I can be possible
> >> that also basic Ada things like unconstrained array types cannot be
> >> translated without some OO overhead in C++. Any expert here ?
>
> > A vector can easily fit that bill.
>
> Vector uses heap memory
> Vector has unbounded
>
> Remove the "easy" part.
>
1) vectors only use heap if you want them to.  The allocators for C++
standard containers can be easily replaced.  When I use them in
embedded systems, I have a deterministic allocator I used.
2) Whether or not a vector is bounded or not is immaterial.  It's
bounds are under the control of the user.  If I need a 10 element
vector, I create one.  What does it matter that I could add more?

Re: Ada to C++ translator

[Maciej Sobczak]

Gautier Write-only wrote:

> I can be possible
> that also basic Ada things like unconstrained array types cannot be
> translated without some OO overhead in C++.

my_super_tools::unconstrained_array<int> a(10);

I don't see any "OO" overhead here. What is exactly the problem?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ada to C++ translator

[Bobby D. Bryant]

On Tue, 24 Jan 2006, zangnew@gmail.com wrote:

> I am looking for an Ada to C++ translator.  The converter will only be
> used as an intermediate step and not used on sections of code we will
> be re-architecting to make use of C++ functionality.

What is "C++ functionality"?

-- 
Bobby Bryant
Austin, Texas

Re: Ada to C++ translator

[Florian Weimer]

* Bobby D. Bryant:

>> I am looking for an Ada to C++ translator.  The converter will only be
>> used as an intermediate step and not used on sections of code we will
>> be re-architecting to make use of C++ functionality.
>
> What is "C++ functionality"?

Implicit instantiation of templates, for example.  Low-overhead
destructors, parameterized exceptions and multiple inheritance come to
my mind, too.  And there is wild pointer arithmetic, of course.

Re: Ada to C++ translator

[Martin Dowie]

Florian Weimer wrote:
> * Bobby D. Bryant:
> 
> 
>>>I am looking for an Ada to C++ translator.  The converter will only be
>>>used as an intermediate step and not used on sections of code we will
>>>be re-architecting to make use of C++ functionality.
>>
>>What is "C++ functionality"?
> 
> 
> Implicit instantiation of templates, for example.  Low-overhead
> destructors, parameterized exceptions and multiple inheritance come to
> my mind, too.  And there is wild pointer arithmetic, of course.

What's "high-overhead" about Ada finalization?

-- Martin

Re: Ada to C++ translator

[Florian Weimer]

* Martin Dowie:

>> Implicit instantiation of templates, for example.  Low-overhead
>> destructors, parameterized exceptions and multiple inheritance come to
>> my mind, too.  And there is wild pointer arithmetic, of course.
>
> What's "high-overhead" about Ada finalization?

It's an abort-deferred operation (like assignment, which I should have
mentioned as well).

Re: Ada to C++ translator

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:877j8oow1r.fsf@mid.deneb.enyo.de...
...
> It's an abort-deferred operation (like assignment, which I should have
> mentioned as well).

That's expensive how? Abort-deferral is (or should be) just toggling a bit
in the TCB. Abort is expensive (it has to check whether the bit is set, be
able to be deferred, etc.), abort-deferral is not. (For Janus/Ada, if there
isn't any significant use of tasking in the program, even the bit-toggling
is left out.) Abort-deferral is too common to make it expensive!

                              Randy.

Re: Ada to C++ translator

[Florian Weimer]

* Randy Brukardt:

> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> news:877j8oow1r.fsf@mid.deneb.enyo.de...
> ...
>> It's an abort-deferred operation (like assignment, which I should have
>> mentioned as well).
>
> That's expensive how? Abort-deferral is (or should be) just toggling a bit
> in the TCB.

You need to find the TCB first, and you need to check for abortion
once deferral has ended.  Especially the first part probably prevents
inlining on some POSIX platforms.

Re: Ada to C++ translator

[Martin Krischik]

Florian Weimer wrote:

> * Randy Brukardt:
> 
>> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
>> news:877j8oow1r.fsf@mid.deneb.enyo.de...
>> ...
>>> It's an abort-deferred operation (like assignment, which I should have
>>> mentioned as well).
>>
>> That's expensive how? Abort-deferral is (or should be) just toggling a
>> bit in the TCB.
> 
> You need to find the TCB first, and you need to check for abortion
> once deferral has ended.  Especially the first part probably prevents
> inlining on some POSIX platforms.

Well any good destructor in virtual anyway - and as such not to be inlined.
Yes C++ supports virtual inline - but virtual inline make linking an
interesting experience.

Please no toy programs to prove me wrong! I am talking dozens of DLLs,
hundreds of modules, thousends of functions and then:

Linker Error: Function _v_Whatever_Wherever_fg7IStringiil not found.

or worse:

Linker Error: Duplicate Function _v_Whatever_Wherever_fg7IStringiil 

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada to C++ translator

[Alex R. Mosteo]

Martin Krischik wrote:
> Florian Weimer wrote:
> 
> 
>>* Randy Brukardt:
>>
>>
>>>"Florian Weimer" <fw@deneb.enyo.de> wrote in message
>>>news:877j8oow1r.fsf@mid.deneb.enyo.de...
>>>...
>>>
>>>>It's an abort-deferred operation (like assignment, which I should have
>>>>mentioned as well).
>>>
>>>That's expensive how? Abort-deferral is (or should be) just toggling a
>>>bit in the TCB.
>>
>>You need to find the TCB first, and you need to check for abortion
>>once deferral has ended.  Especially the first part probably prevents
>>inlining on some POSIX platforms.
> 
> 
> Well any good destructor in virtual anyway - and as such not to be inlined.
> Yes C++ supports virtual inline - but virtual inline make linking an
> interesting experience.
> 
> Please no toy programs to prove me wrong! I am talking dozens of DLLs,
> hundreds of modules, thousends of functions and then:
> 
> Linker Error: Function _v_Whatever_Wherever_fg7IStringiil not found.
> 
> or worse:
> 
> Linker Error: Duplicate Function _v_Whatever_Wherever_fg7IStringiil 

Haha :D This brings back some memories... VC++ can be so fun sometimes...

Re: Ada to C++ translator

[REH]

Martin Krischik wrote:
> Florian Weimer wrote:
>
> > * Randy Brukardt:
> >
> >> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> >> news:877j8oow1r.fsf@mid.deneb.enyo.de...
> >> ...
> >>> It's an abort-deferred operation (like assignment, which I should have
> >>> mentioned as well).
> >>
> >> That's expensive how? Abort-deferral is (or should be) just toggling a
> >> bit in the TCB.
> >
> > You need to find the TCB first, and you need to check for abortion
> > once deferral has ended.  Especially the first part probably prevents
> > inlining on some POSIX platforms.
>
> Well any good destructor in virtual anyway - and as such not to be inlined.
> Yes C++ supports virtual inline - but virtual inline make linking an
> interesting experience.
>
> Please no toy programs to prove me wrong! I am talking dozens of DLLs,
> hundreds of modules, thousends of functions and then:
>
> Linker Error: Function _v_Whatever_Wherever_fg7IStringiil not found.
>
> or worse:
>
> Linker Error: Duplicate Function _v_Whatever_Wherever_fg7IStringiil
>
> Martin
> --
> mailto://krischik@users.sourceforge.net
> Ada programming at: http://ada.krischik.com

I don't think your wrong.  Linker errors can be frustating, especially
with large projects.  I disagree, though, that all "good" destructors
are necessarily virtual.  None of the destructors for standard
containers are virtual, nor do I think they need to be.  Not all
classes need to be polymorphic.

Re: Ada to C++ translator

[Martin Krischik]

REH wrote:

> I disagree, though, that all "good" destructors
> are necessarily virtual. ï¿œNone of the destructors for standard
> containers are virtual, nor do I think they need to be. ï¿œNot all
> classes need to be polymorphic.

Well true. However non polymorphic classes would normally implemented in Ada
as

type X is private;

So in public view you would not know they are classes.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada to C++ translator

[Florian Weimer]

* Martin Krischik:

>> You need to find the TCB first, and you need to check for abortion
>> once deferral has ended.  Especially the first part probably prevents
>> inlining on some POSIX platforms.
>
> Well any good destructor in virtual anyway - and as such not to be
> inlined.

It doesn't matter because destructors of stack-allocated objects are
known at compile time.

(Apart from that, I doubt it's true.  Classes used in generic
programming tend to have no virtual methods.)

Re: Ada to C++ translator

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:877j8ngrnx.fsf@mid.deneb.enyo.de...
> * Randy Brukardt:
>
> > "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> > news:877j8oow1r.fsf@mid.deneb.enyo.de...
> > ...
> >> It's an abort-deferred operation (like assignment, which I should have
> >> mentioned as well).
> >
> > That's expensive how? Abort-deferral is (or should be) just toggling a
bit
> > in the TCB.
>
> You need to find the TCB first, and you need to check for abortion
> once deferral has ended.  Especially the first part probably prevents
> inlining on some POSIX platforms.

Huh? The TCB has to be readily accessible, or the whole program isn't going
to work at anything faster than a crawl. And the abortion check is just a
check for an empty list (i.e. compare against null): it's only expensive if
in fact there is a task on the list. But having abort be expensive is
irrelevent.

The TCB contains the heads of the exception and finalization chains (which
also contains the temporary storage pools on Janus/Ada),  the display
registers (for up-level access), some temporaries for expressions (since the
80x86 architecture is register-poor), along with all of the tasking stuff.
Essentially, it contains everything in Ada semantics that is task-specific.
You have to have cheap access to that, or *everything* is bogged down (most
subprogram calls have to do operations on the exception and finalization
chains and with the display registers). On our never-quite-finished 68K
compiler, we allocated a register permanently to the TCB. Our MS-DOS
compilers used a global block for this stuff (and copied it each time a task
switch happened - great for non-tasking programs, not so hot for tasking
ones).

I haven't studied the details of POSIX threads (they didn't exist when I
last seriously worked on UNIX systems), but there is *always* a way to have
easy access to thread-specific data. At worst, you'd have to allocate a
register to finding it.

There is a persistent myth that finalization, and particularly Ada
finalization is expensive. But I've never seen any real evidence of that --
particularly in apples-to-apples comparisons. (No fair comparing an Ada
program full of tasks with a C++ one that contains none, for instance.)
Surely the cases where its tiny overhead really matters are very few in
number. (OTOH, I'll grant that there is a space cost for it, and that can
make a difference in some situations.)

                               Randy.

Re: Ada to C++ translator

[Bobby D. Bryant]

On Wed, 25 Jan 2006, Florian Weimer <fw@deneb.enyo.de> wrote:

> * Bobby D. Bryant:
> 
>>> I am looking for an Ada to C++ translator.  The converter will only be
>>> used as an intermediate step and not used on sections of code we will
>>> be re-architecting to make use of C++ functionality.
>>
>> What is "C++ functionality"?
> 
> Implicit instantiation of templates, for example.  Low-overhead
> destructors, parameterized exceptions and multiple inheritance come to
> my mind, too.  And there is wild pointer arithmetic, of course.

Is any of that a reason to re-architect working code?

-- 
Bobby Bryant
Austin, Texas

Re: Ada to C++ translator

[Florian Weimer]

* Bobby D. Bryant:

>> Implicit instantiation of templates, for example.  Low-overhead
>> destructors, parameterized exceptions and multiple inheritance come to
>> my mind, too.  And there is wild pointer arithmetic, of course.
>
> Is any of that a reason to re-architect working code?

Depends.  RAII can be quite an advantage.

Of course, rewriting code is almost always a mistake, even if the code
quality is less than stellar.  But I can understand companies
(especially those with smaller development teams) which migrate away
from Ada for lack of commercial *and* community support on their
favorite platforms.

Re: Ada to C++ translator

[Martin Krischik]

Florian Weimer wrote:

> * Bobby D. Bryant:
> 
>>> I am looking for an Ada to C++ translator.  The converter will only be
>>> used as an intermediate step and not used on sections of code we will
>>> be re-architecting to make use of C++ functionality.
>>
>> What is "C++ functionality"?

> Implicit instantiation of templates, for example.  Low-overhead
> destructors, parameterized exceptions and multiple inheritance come to
> my mind, too.  And there is wild pointer arithmetic, of course.

After 10 years of C++ I am unsure if those fine features really make
programming any easier.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada to C++ translator

[Florian Weimer]

* Martin Krischik:

>> Implicit instantiation of templates, for example.  Low-overhead
>> destructors, parameterized exceptions and multiple inheritance come to
>> my mind, too.  And there is wild pointer arithmetic, of course.
>
> After 10 years of C++ I am unsure if those fine features really make
> programming any easier.

RAII (which really needs cheap destructors in some cases) does make
programming easier.  The rest, well -- it depends.  Pointer arithmetic
has no place except in allocators (or some high-performance numerical
code), but parameterized exceptions are neat, and template
metaprogramming can be quite helpful, too.

Of course, C++ has also a fair number of truly obnoxious properties.

Re: Ada to C++ translator

[Pascal Obry]

zangnew@gmail.com a �crit :
> I am looking for an Ada to C++ translator.  The converter will only be
> used as an intermediate step and not used on sections of code we will
> be re-architecting to make use of C++ functionality.

This is often a mistake. I can't comment in your case but what about
compiling the Ada code, build an archive with the code and interface it
with the C++ code. This also avoid introducing bugs during the
conversion which most probably can't be 100% automatic for reasons
already exposed by others here. I always prefer interfacing (C++ to Ada,
or Ada to C++) than rewriting/converting code that is tested and known
to work well.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada to C++ translator

[Gautier Write-only]

Also, one point where a translation could look more like a
compilation is Ada's possibility of nesting subprograms or
packages into other subprograms or packages.
E.g. what is the C++ equivalent of the following (silly,
but correct) code ?

with Ada.Text_IO;

procedure Nest_Test is

  procedure P1(s1: String) is
  
    procedure P2(s2: String) is
    begin
      if s2'Length > 0 then
        declare
          generic
            content: String;
          package K1 is
            procedure Spit;
          end K1;
          package body K1 is
            procedure Spit is
            begin
              Ada.Text_IO.Put(content(content'First));
              P1(content(content'First+1..content'Last));
            end Spit;
          end K1;
          package my_K1 is new K1( content=> s2 );
        begin
          my_K1.Spit;
        end;
      end if;
    end P2;

  begin
    P2(s1);
  end P1;
  
begin
  P1("A very silly way to display a string!");
end Nest_Test;
_______________________________________________________________ 
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm 
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm 
GLOBE_3D        -- http://www.mysunrise.ch/users/gdm/g3d.htm 

NB: For a direct answer, e-mail address on the Web site!

Re: Ada to C++ translator

[REH]

Gautier Write-only wrote:
> Also, one point where a translation could look more like a
> compilation is Ada's possibility of nesting subprograms or
> packages into other subprograms or packages.
> E.g. what is the C++ equivalent of the following (silly,
> but correct) code ?
>
> with Ada.Text_IO;
>
> procedure Nest_Test is
>
>   procedure P1(s1: String) is
>
>     procedure P2(s2: String) is
>     begin
>       if s2'Length > 0 then
>         declare
>           generic
>             content: String;
>           package K1 is
>             procedure Spit;
>           end K1;
>           package body K1 is
>             procedure Spit is
>             begin
>               Ada.Text_IO.Put(content(content'First));
>               P1(content(content'First+1..content'Last));
>             end Spit;
>           end K1;
>           package my_K1 is new K1( content=> s2 );
>         begin
>           my_K1.Spit;
>         end;
>       end if;
>     end P2;
>
>   begin
>     P2(s1);
>   end P1;
>
> begin
>   P1("A very silly way to display a string!");
> end Nest_Test;


These are great features of Ada, ones that I wish C++ had.  The closed
I could come to the above is:

#include <string>
#include <iostream>

void Nest_Test() {

    struct P1 {
        P1(const std::string& s1)
        {
            struct P2 {
                P2(const std::string& s2)
                {
                    struct Spit {
                        Spit(const std::string& s2)
                        {
                            std::cout << s2[0];
                            P1(s2.substr(1));
                        }
                    };

                    if (!s2.empty())
                    {
                        Spit s(s2);
                    }
                }
            };

            P2 p(s1);
        }
    };

    P1 p("A very silly way to display a string!");
}

But it definitely is not as nice.  And there is no way to define local
templates, nor instantiate them with dynamic data.

Re: Ada to C++ translator

[Maciej Sobczak]

Gautier Write-only wrote:

> E.g. what is the C++ equivalent of the following (silly,
> but correct) code ?
> 
> with Ada.Text_IO;
> 
> procedure Nest_Test is
> 
>   procedure P1(s1: String) is
>   
>     procedure P2(s2: String) is
>     begin
>       if s2'Length > 0 then
>         declare
>           generic
>             content: String;
>           package K1 is
>             procedure Spit;
>           end K1;
>           package body K1 is
>             procedure Spit is
>             begin
>               Ada.Text_IO.Put(content(content'First));
>               P1(content(content'First+1..content'Last));
>             end Spit;
>           end K1;
>           package my_K1 is new K1( content=> s2 );
>         begin
>           my_K1.Spit;
>         end;
>       end if;
>     end P2;
> 
>   begin
>     P2(s1);
>   end P1;
>   
> begin
>   P1("A very silly way to display a string!");
> end Nest_Test;


#include <iostream>
#include <ostream>
#include <string>

namespace P1
{
     namespace P2
     {
         template <class Content>
         struct K1
         {
             K1(Content const &c) : content(c) {}
             void Spit();
             Content content;
         };

         template <class Content>
         void K1<Content>::Spit()
         {
             std::cout << content[0];
             ::P1::execute(Content(content.begin() + 1, content.end()));
         }

         void execute(std::string const &s2)
         {
             if (s2.size() > 0)
             {
                 K1<std::string> my_K1(s2);
                 my_K1.Spit();
             }
         }
     }

     void execute(std::string const &s1)
     {
         P2::execute(s1);
     }
}

int main()
{
     P1::execute("Indeed a very silly way!");
     std::cout << '\n';
}


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ada to C++ translator

[James Alan Farrell]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

zangnew@gmail.com wrote:
> I am looking for an Ada to C++ translator.  The converter will only be
> used as an intermediate step and not used on sections of code we will
> be re-architecting to make use of C++ functionality.
> 
> Thanks You.
> 
I used such a tool on a previous project (which proves it can be done). 
  I would say if it could not be done (because of tasking or other 
considerations) then Ada probably could not be compiled or run.  Since 
it obviously can be, why can it not be compiled to another language such 
as C++?  (To my mind, compiling means to a specific runtime environment, 
  such as to Linux on a PC, so I do not buy the argument that converting 
to C++/posix is different somehow from converting to C++)

Unfortunately I do not recall the name of the tool we used.

I do recall that after converting a substantial amount of Ada code, a 
number of programmers were employed full time for six months fixing up 
the C++ to make it readable.  My office mate was one of them.  It is 
also possible that they were making corrections to mistranslated code, 
but the majority of the effort was simply to make it readable.




[-- Attachment #2: jfarrell.vcf --]
[-- Type: text/x-vcard, Size: 88 bytes --]

begin:vcard
fn:James Alan Farrell
n:Farrell;James
org:GrammaTech
version:2.1
end:vcard

Re: Ada to C++ translator

[Charlie McCutcheon]

> I am looking for an Ada to C++ translator.  The converter will only be
> used as an intermediate step and not used on sections of code we will
> be re-architecting to make use of C++ functionality.

Recently, I'd heard of such a thing, seems to be at:
http://www.softresint.com/expe.htm .

I'm skeptical that the translation would be very good.  I'd predict lots of
cost for hand fixing problems.  They do at least acknowlege that Ada and C++
are "different".

Charlie

Re: Ada to C++ translator

[Marco]

> Recently, I'd heard of such a thing, seems to be at:
> http://www.softresint.com/expe.htm .
>
> I'm skeptical that the translation would be very good.  I'd predict lots of
> cost for hand fixing problems.  They do at least acknowlege that Ada and C++
> are "different".

  You always have to suspect any company using the term "ADA" instead
of Ada. Obviously they have little actual experience with using the
language.

Re: Ada to C++ translator

[Dmitry A. Kazakov]

On 29 Jan 2006 06:02:09 -0800, Marco wrote:

>> Recently, I'd heard of such a thing, seems to be at:
>> http://www.softresint.com/expe.htm .
>>
>> I'm skeptical that the translation would be very good.  I'd predict lots of
>> cost for hand fixing problems.  They do at least acknowlege that Ada and C++
>> are "different".
> 
>   You always have to suspect any company using the term "ADA" instead
> of Ada. Obviously they have little actual experience with using the
> language.

Maybe they don't read much comp.lang.ada, which is slightly obsessed with
capitalizing issues... (:-))

Seriously, the data sheet 

http://www.softresint.com/pub/SPD/01-04-004.pdf

does not look as if they didn't know what Ada is, rather the opposite.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada to C++ translator

[jimmaureenrogers]

Marco wrote:
> > Recently, I'd heard of such a thing, seems to be at:
> > http://www.softresint.com/expe.htm .
> >
> > I'm skeptical that the translation would be very good.  I'd predict lots of
> > cost for hand fixing problems.  They do at least acknowlege that Ada and C++
> > are "different".
>
>   You always have to suspect any company using the term "ADA" instead
> of Ada. Obviously they have little actual experience with using the
> language.

The data sheet focuses on type conversions between Ada and C++.
It completely ignores conversions of Ada run-time and compile-time
error
checking.

It claims to make a conversion from Ada strings to the C++ primitive
string
type, which is the same as the C string type. This eliminates all
bounds
checking, all string slicing, and all direct assignment of string
objects.
A better conversion would be to the C++ String class, which is not a
primitive type.

The data sheet does not indicate how nested subprograms or packages
are translated. It also does not indicate how elaboration issues are
converted
to C++.

I see no indication that they understand Ada sufficiently to properly
translate
sequential programs.

There is also no indication they can translate concurrent programs.

Jim Rogers

Re: Ada to C++ translator

[Hyman Rosen]

jimmaureenrogers@worldnet.att.net wrote:
> The data sheet does not indicate how nested subprograms or packages
> are translated.

Back in the day, I wrote a translator between two hardware
description languages. The source has nested subprograms
and the target did not. I did it by wrapping all the local
variables of subprograms into a record and maintaining a
display as an array of pointers to these records.

Ada to C Translator

[Mike K]

Question to the group:

I have a requirment to convert and application written in ada to c. Can anyone
provide me insight as to any ada to c translators available?

Mike

Re: Ada to C Translator

[Ted Dennison]

In article <92fk1v0cou@drn.newsguy.com>,
  Mike K <Mike_member@newsguy.com> wrote:
> Question to the group:
>
> I have a requirment to convert and application written in ada to c.
> Can anyone provide me insight as to any ada to c translators
> available?

I believe Averstar has a service to do that, but you will have to
contact them directly.

If you try to do it yourself, its not a trivial task. C operates at a
much lower conceptual level than Ada, so you will have to write a large
amount of C code to emulate parts of the Ada runtime. Depending on what
OS you use, you could luck out and can get your OS to do some of the
work for you. But then it won't be as portable as the Ada version was.
Either way, you are in for a great deal of work. You will certinaly add
new bugs to the system when you write the new code, and you will quite
likely also mechanicly port all the system's existing bugs into C. Plus,
the end result will not be very C-like, which will make it a nightmare
to maintain.

Honestly, you'd be better off just writing the system from scratch
rather than trying to hand-port it.

All this expenditure could be justified if your platform doesn't have an
Ada compiler. Otherwise its just a plain silly thing to want to do. You
might as well take all your C code and rewrite it in Assembler while you
are at it.

I wonder if other walks of life have this problem... Do civil engineers
rip down a perfectly funtional and stable bridge and rebuild it with the
same carrying capcity using different materials? Do automobile owners
pay mechanics to take their cars completely apart and reassemble them
just becuse the orginial assemblers used different kinds of tools?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Ira D. Baxter]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:92fqlt$h8d$1@nnrp1.deja.com...
> In article <92fk1v0cou@drn.newsguy.com>,
>   Mike K <Mike_member@newsguy.com> wrote:
> > Question to the group:
> >
> > I have a requirment to convert and application written in ada to c.
> > Can anyone provide me insight as to any ada to c translators
> > available?
>
> I believe Averstar has a service to do that,

We offer tools and services to carry out custom analyses,
source modifications, and  code ports, using generalized
compiler technology.     Caveat: this isn't easy or cheap.
See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.
DMS can parse Ada83/95.


> If you try to do it yourself, its not a trivial task. ..

.> Honestly, you'd be better off just writing the system from scratch
> rather than trying to hand-port it.

If the amount of source code is small, a hand port is frankly much
more economical than automated conversion.

If the amount of source code is big, a hand port is simply unthinkably
expensive
in comparison.

> All this expenditure could be justified if your platform doesn't have an
> Ada compiler.

Or your management, for better or worse, insists on getting out.
This isn't always a rational decision, and not always chosen by the company.
When the customer insists....

> I wonder if other walks of life have this problem... Do civil engineers
> rip down a perfectly funtional and stable bridge and rebuild it with the
> same carrying capcity using different materials? Do automobile owners
> pay mechanics to take their cars completely apart and reassemble them
> just becuse the orginial assemblers used different kinds of tools?

No, but then civil engineers aren't usually called back to add serious
new functionality to bridges, or to port the bridge to cross a different
river.


--
Ira D. Baxter, Ph.D.,CTO           email: idbaxter@semdesigns.com
Semantic Designs, Inc.              web: http://www.semdesigns.com
12636 Research Blvd. C-214    voice: (512) 250-1018 x140
Austin, TX 78759-2200             fax: (512) 250-1191

Re: Ada to C Translator

[gdemont]

TED:

> You might as well take all your C code and rewrite it in Assembler
> while you are at it.

Beside the question of downgrading all modern software to the old
PDP-7 macro-assembler, tranlslating directly to assembler can be the
best solution (price, time) in some cases. Some Ada compilers can
output assembler, so you can wrap the procedures in ASM statements
and send the fresh new C code in time.
The main difficulty people find in the exercise is the name visibility.
Even with a C++ compiler, with working namespaces it seems very
difficult to transform the easy unambiguous name visibility into
a pre-Pascalian context.

Good luck


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Dr Adrian Wrigley]

Ted Dennison wrote:
...
> I wonder if other walks of life have this problem... Do civil engineers
> rip down a perfectly funtional and stable bridge and rebuild it with the
> same carrying capcity using different materials?
...

Yes!  Here in Cambridge (England), civil engineers pulled down a very
well constructed bridge (The Victoria Avenue Bridge), made of stone
and iron, to replace it with something visually similar of steel.
The cost (IIRC) was several million pounds, and a lot of inconvenience.

The reason was that the original bridge could not be proved to be strong
enough for the modern traffic load, because inspection of key structures
was not possible, and the plans were not available.

Only once the project was well under way, and the bridge was in pieces
was it possible to tell that the work was unnecessary.  The work
completed as planned. (corrections to my memory of this welcome!)

To switch back to the underlying topic...

I agree with those who say that Ada to C porting of source code
is of extremely limited value.

If Ada were prohibited for the project, you might find it useful to
generate C source files as part of a multi-stage compilation process,
and then tweak or replace certain C files as necessary.

I imagine that such an approach might be useful with 'end of life'
applications, when someone suddenly offers lots of money for it to run on
a machine with no Ada compiler (Alpha Linux? Macintosh? ARM?), and a
short timescale.  Or maybe the customer demands C source in the contract.
Or maybe the management doesn't have a sufficient supply of willing
Ada programmers to maintain the project, but doesn't like the thought
of a total rewrite.

just a thought...
--
Adrian Wrigley

Re: Ada to C Translator

[gdemont]

Dr Adrian Wrigley:

> Yes!  Here in Cambridge (England), civil engineers pulled down a very
> well constructed bridge (The Victoria Avenue Bridge), made of stone
> and iron, to replace it with something visually similar of steel.
> The cost (IIRC) was several million pounds, and a lot of
> inconvenience.

> The reason was that the original bridge could not be proved to be
> strong enough for the modern traffic load, because inspection of key
> structures was not possible, and the plans were not available.

Translating Ada to C would mean that you replace expensively the bridge
of steel with a bridge where inspection of key structures is not
possible...

_____________________________________________
Gautier  --  http://members.nbci.com/gdemont/


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Dave Ptacek]

An interesting viewpoint.  While I been using Ada for the better share of 13
years, and do see several benefits when comparing it to C/C++, I'm currently
in a project that is considering the porting of approx. 100k Ada sloc to
C++.

Over the years (15), this particular application became very domain
specific, was designed to run on DOS (real mode and later protected mode),
and is now heading to WinNT 4.0.  Try finding people with Ada, assembler,
DOS, Windows, MFC, various communication buses, an appreciation for creating
test applications for factory test and lastly willing to re-locate to a
"small" midwestern town.  We usually end up training inexperienced people
and hope they will stay.

Not that Ada is the limiting factor in all of this, but most new college
grads will have a C/C++ background and realize that Windows programming in
C/C++ looks pretty good on a resume.  Throw in the integrated programming
environment (Visual Studio) and several educational houses providing
immediate Windows training programs (Learning Tree), the idea of porting the
source code from Ada to C/C++ becomes an attractive option.  Is it
technically the best design choice?  For this particular application
mentioned above, probably due to the OS choice and development toolsets
available, but I certainly wouldn't make a general statement that it's the
best choice for every situation.

Dave

Re: Ada to C Translator

[Marin David Condic]

If you're translating the Ada to C++ so that it can now be maintained by garden
variety C++ programmers, then I'd suggest you'd absolutely want to avoid a
machine translation. The time the programmers will spend trying to figure out
the translated code will be way more than the time it would take them to learn
Ada. You'd be better off declaring the system "Finished" and start working on
the "Version II" of it in whatever language makes the most sense. A human
translation would likely take about as long as a redesign and a redesign allows
you to fix anything you didn't like about the original system. The economics of
any other choice aren't likely to be good.

Of course, if you'd like to outsource the job, I'm sure we could talk about
it...

MDC


Dave Ptacek wrote:

> Not that Ada is the limiting factor in all of this, but most new college
> grads will have a C/C++ background and realize that Windows programming in
> C/C++ looks pretty good on a resume.  Throw in the integrated programming
> environment (Visual Studio) and several educational houses providing
> immediate Windows training programs (Learning Tree), the idea of porting the
> source code from Ada to C/C++ becomes an attractive option.  Is it
> technically the best design choice?  For this particular application
> mentioned above, probably due to the OS choice and development toolsets
> available, but I certainly wouldn't make a general statement that it's the
> best choice for every situation.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Ada to C Translator

[Frode Tennebø]

Dave Ptacek wrote:

> An interesting viewpoint.  While I been using Ada for the better share
> of 13 years, and do see several benefits when comparing it to C/C++,
> I'm currently in a project that is considering the porting of approx.
> 100k Ada sloc to C++.
> 
> Over the years (15), this particular application became very domain
> specific, was designed to run on DOS (real mode and later protected
> mode),
> and is now heading to WinNT 4.0.  Try finding people with Ada,
> assembler, DOS, Windows, MFC, various communication buses, an
> appreciation for creating test applications for factory test and
> lastly willing to re-locate to a
> "small" midwestern town.  We usually end up training inexperienced
> people and hope they will stay.
> 
> Not that Ada is the limiting factor in all of this, but most new
> college grads will have a C/C++ background and realize that Windows
> programming in
> C/C++ looks pretty good on a resume.

True, C++ was very hot in college a few years back. However, my bet is 
that C/C++ is not very common for new college grads these days. Java is 
probably the most tought language today, with Visual Basic as a good 
contender (I don't have any hard numbers - if someone have, please 
arrest me). Tomorrow it will most likely be C# or something else.

I'm not sure what type of application you have, however 15 years ago 
there were a lot fewer languages than today. C++ was not even thought 
of. How many of those languages are alive today? Can you get an 
actively maintained compiler for Cobol on a modern platform? What about 
Forth? The only laguage I can think of other than Ada and C which has a 
active compiler support is Fortran - even Pascal is struggeling.

My point is that with Ada, you will most likely get a maintained 
compiler for a current platform in 15 years. Will this be true for C++?

Also, you are switching to NT 4 NOW? NT has already reached EOL.  If 
you had written any legacy application with C++ on Windows 3.11 five 
years ago - how easy would it be to port it to any platform today? How 
about in 10 years?

>  Throw in the integrated
> programming environment (Visual Studio) and several educational houses
> providing immediate Windows training programs (Learning Tree), the
> idea of porting the
> source code from Ada to C/C++ becomes an attractive option.  Is it
> technically the best design choice?  For this particular application
> mentioned above, probably due to the OS choice and development
> toolsets available, but I certainly wouldn't make a general statement
> that it's the best choice for every situation.

Again, without the knowledge of your system I don't have all the 
answers. However, I would get your application running on an older 
version of GNAT for DOS (if you don't require later versions' added 
bonuses) and then port it to most operating sytem of your choice. 
Depending on the cost structure of your system, a W2K license can be 
significant compared to eg. Linux or BSD or even Solaris these days.

I performed the major part of 'porting' a 200K SLOC (sic) of code from 
SunAda 3 running on Solaris 2.5.1 to GNAT on Solaris 8 in less than 200 
hours. Appart from some socket code I have identified, I'm pretty 
confident that everything will compile on Linux without changes when we 
get there.

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Ted Dennison]

In article <alpl29.aph.ln@leia>,
  Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:

> My point is that with Ada, you will most likely get a maintained
> compiler for a current platform in 15 years. Will this be true for
> C++?

That's a good point. If you keep an ear to the ground, you may have
noticed some faint movement away from C++ already beginning. What are
you going to do in 2-3 years when Micro$oft abandons C++ for their own
C# (or whatever's hip then)? Are you going to port your code again
(increasing its buggyness each time) whenever the "universal center of
hipness" moves on to a new language?

> Also, you are switching to NT 4 NOW? NT has already reached EOL.  If

Yup. The IOS on our project was bid for NT4. During the course of the
project, they were forced to move to Win2K because the newest wifty
features they needed (dual-monitor 3D support) were no longer being
worked on for NT4. Nevermind that this forced us to upgrade our entire
software development toolsuite as well...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Tarjei T. Jensen]

Frode Tenneb� wrote
I'm not sure what type of application you have, however 15 years ago
there were a lot fewer languages than today. C++ was not even thought
of. How many of those languages are alive today? Can you get an
actively maintained compiler for Cobol on a modern platform? What about
Forth? The only laguage I can think of other than Ada and C which has a
active compiler support is Fortran - even Pascal is struggeling.

I don't think Cobol is a problem. There is simply too much legacy code and if I
remember correct, there is a lot of tools which generate cobol code.

Cobol is not very visible outside its user community. It is a fate it shares
with fortran. It does not mean that the language is dead.

C++ is definitely a worry. Especially since it is a language with a tradition
of change.


Greetings,

Re: Ada to C Translator

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

In article <92plgm$ktl13@news.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
> 
> Frode Tenneb� wrote
> I'm not sure what type of application you have, however 15 years ago
> there were a lot fewer languages than today. C++ was not even thought
> of. How many of those languages are alive today? Can you get an
> actively maintained compiler for Cobol on a modern platform? What about

Compaq Cobol on VMS is actively supported.

> Forth? The only laguage I can think of other than Ada and C which has a
> active compiler support is Fortran - even Pascal is struggeling.

as are Compaq Fortran and Compaq Pascal.  I am not sure about Cobol,
but in the case of Fortran and Pascal the developers also follow the
relevant newsgroups to provide beyond-the-contract advice.

Re: Ada to C Translator

[Robert Dewar]

In article <alpl29.aph.ln@leia>,
  Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:

> I'm not sure what type of application you have, however 15
> years ago  there were a lot fewer languages than today.

That seems clearly false. What is your authority for this
statement/guess. Perhaps you mean that there are fewer
languages with which you are familiar (given the rest of
the message that seems a possibility).

> How many of those languages are alive today?

Virtually all of them. Nothing is more discouraging than seeing
supposedly knowledgable Ada folks decide with no evidence that
other languages have disappeared from sight. It is indeed a
common malady to assume that any language you do not bump into
every day has disappeared (for example, I often meet people who
think that PL/1 has disappeared). But surely Ada folks should
try to avoid this mistake, of all people!

> Can you get an actively maintained compiler for Cobol on a
> modern platform?

A staggeringly ignorant question :-) Yes, of COURSE you can,
and the amount of legacy COBOL out there is huge. Furthermore,
new applications are being generated in COBOL all the time
(that should not be surprising, COBOL is still the most
suitable language for fiscal applications -- yes, you can make
a reasonable technical argument for Ada-95, but most of the
people making language decisions assume that Ada has
disappeared -- see paragraph one above). As for active
maintenance, yes, there are certainly active COBOL compiler
maintenance groups around (e.g. for Computer Associates Realia
COBOL for IBM PC's, or don't these count as modern platforms in
your lexicon? :-)

> What about Forth?

Again, just because you do not bump into it every day, does not
mean it is dead, especially when you have made ZERO attempt to
find out facts. Of *course* Forth is alive and well, and is
used in many applications areas. There is by the way a VERY
nice Forth interpretor for the Palm Pilot, which has been used
to generate a number of Palm applications.

> The only laguage I can think of other than Ada and C which
> has a active compiler support is Fortran - even Pascal is
> struggeling.

Again, the lack of awareness in this statement is remarkably
parochial -- even peculiar, given its inclusion of Ada as one
of three languages still in use -- that would surprise a LOT of
people:-) There are hundreds of languages for which there is
active compiler support, and active application communities,
especially if you use Ada as a standard for what these terms
mean!

By far the most widely used language for PC development is
Visual Basic (although almost never taught in universities,
contrary to other claims you made). And for sure there will
be compiler support for this for a long long time.

> My point is that with Ada, you will most likely get a
> maintained compiler for a current platform in 15 years. Will
> this be true for C++?

Yes, of course it will. Ada advocacy is not helped by FUD like
this which is clearly unfounded. I agree that Ada compilers
will be maintained for 15 years, but that is because I know the
business strategy and plans of Ada Core Technologies. The fact
of the matter is that in terms of future maintenance of
compilers, C++ is in a VERY secure position (as is COBOL
incidentally :-)

> Also, you are switching to NT 4 NOW? NT has already reached
> EOL.

Again, that is unsupported FUD. I am the last person to write
strong words of support for NT, but to say that NT has reached
end of life is absurd.

> If  you had written any legacy application with C++ on
> Windows 3.11 five  years ago - how easy would it be to port
> it to any platform today?

It would vary on how well it was written, because you were
using a non-standardized language, still in flux, on an
obsolescent operating system, yes, you may have more troubles,
but the difficulty in porting programs is often more related to
quality of code than operating environment.

> How about in 10 years?

I don't think it would be any harder to do this port ten
years from now than now, probably easier, because more tools
will be around to help.

Of course I agree that porting Ada code to C++ just for the
sake of porting it seldom makes sense, but let's try to keep
the arguments real. Ada advocacy is not helped by extreme
statements about other languages that are insupportable.

> However, I would get your application running on an older
> version of GNAT for DOS

That seems a poor suggestion, this is a bad environment for the
port, and will make the job much harder (I speak from the point
of view of our experience in helping customers port millions of
lines of legacy code to GNAT).

> Depending on the cost structure of your system, a W2K license
> can be  significant compared to eg. Linux or BSD or even
> Solaris these days.

Indeed, and a Linux license is cheaper than a DOS license, so
the conclusion here should be that Linux is an obvious target.
It also supports development work much more reliably than any
of the Microsoft operating systems in our experience.

> I performed the major part of 'porting' a 200K SLOC (sic) of
> code from  SunAda 3 running on Solaris 2.5.1 to GNAT on
> Solaris 8 in less than 200
> hours.

One hour per thousand lines of code is actually rather slow
as a porting rate from our experience, especially for a fairly
small program (we have frequently helped with porting very
large applications in much less time than this on an absolute
basis, let alone a relative basis). But milage can vary, we
have at this stage a LOT of experience in such porting, which
can make things much more efficient, and as I said earlier,
difficulty in porting can reflect poor coding of the original
(the big issue being whether implementation dependent and
system dependent code is properly isolated).

Robert Dewar


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Tarjei Tj�stheim Jensen]

Robert Dewar wrote:
> 
> Again, that is unsupported FUD. I am the last person to write
> strong words of support for NT, but to say that NT has reached
> end of life is absurd.

Actually it is not. Microsoft will try its best to discourage both new
and old NT users and try to direct them to windows 2000. Their plan to
phase out NT 4 from the product line is rather agressive.

Whether this plan will work as intended and in the time frame they hope
for is an open question. However they will try.


Greetings,

Re: Ada to C Translator

[Robert Dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

In article <3A50EFE2.7DA62AD4@online.no>,
  "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote:
> Robert Dewar wrote:
> >
> > Again, that is unsupported FUD. I am the last person to
write
> > strong words of support for NT, but to say that NT has
reached
> > end of life is absurd.
>
> Actually it is not. Microsoft will try its best to discourage
both new
> and old NT users and try to direct them to windows 2000.
Their plan to
> phase out NT 4 from the product line is rather agressive.
>
> Whether this plan will work as intended and in the time frame
they hope
> for is an open question. However they will try.
>
> Greetings,

OK, If you are making this big a differentiation between NT
and Win2K, then that's fine, but basically I simply regard
Win2K as a renaming of NT 5, so I don't make this distinction.

Sure, the *name* NT is at end of life :-)

I would not count on the *name* Win2000 being used for the
next version of the OS, so this name is also at EOL :-)




Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Marin David Condic]

But Win2k is still riding on top of an NT kernel. Everytime my machine
boots up it tells me on one of the screens that W2k is based on NT
technology. So in that sense, W2K really is just the next version of NT.

MDC

"Tarjei Tj�stheim Jensen" wrote:

> Actually it is not. Microsoft will try its best to discourage both new
> and old NT users and try to direct them to windows 2000. Their plan to
> phase out NT 4 from the product line is rather agressive.
>
> Whether this plan will work as intended and in the time frame they hope
> for is an open question. However they will try.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Ada to C Translator

[Lao Xiao Hai]

Good reply Robert.   I have a few notes to augment your comments.

Robert Dewar wrote:

> A staggeringly ignorant question :-) Yes, of COURSE you can,
> and the amount of legacy COBOL out there is huge. Furthermore,
> new applications are being generated in COBOL all the time
> (that should not be surprising, COBOL is still the most
> suitable language for fiscal applications ...

I have a friend whose company generates a very considerable revenue
stream each year with products, training, and consulting support to
users
of COBOL, especially ANSI-85 COBOL and the new Object COBOL.
His income from COBOL is far greater than my company's income from Ada.

As noted by Robert, certain constructs in COBOL are more expressive for
financial applications than other languages.   In addition, contemporary

COBOL has rectified many of the problems associated with earlier
versions of the language.   Of course, who bothers to keep up with the
changes once they have made their choice for some other language --
often a of language inferior quality when targeted to some particular
application domain.  For example, C++ is a horrid language for
administrative
and financial software but its popularity makes it the choice of
otherwise
intelligent people.

> > What about Forth?
>
> Of *course* Forth is alive and well, and is
> used in many applications areas. There is by the way a VERY
> nice Forth interpretor for the Palm Pilot, which has been used
> to generate a number of Palm applications.

The largest Forth Interest Group (not called Forth User Group for
obvious reasons) is in St. Petersburg, Russia.  The language is still
excellent for eight-bit microprocessors such as the I-8051 and used
widely in that domain.   Moreover, one might consider Forth's
relationship to another language we rarely encounter which affects
our daily lives: Postscript.

> > The only laguage I can think of other than Ada and C which
> > has a active compiler support is Fortran - even Pascal is
> > struggeling.
>
> Again, the lack of awareness in this statement is remarkably
> parochial -- even peculiar, given its inclusion of Ada as one
> of three languages still in use -- that would surprise a LOT of
> people:-)

Until recently, I attended a lot of conferences each year.   My name
badge would identify my company as AdaWorks.    "Ada?!!!  I thought
that language was dead a long time ago."    The majority of people I
meet in the computing industry are under the impression that no one
uses Ada anymore, not even the military.    I also get to meet a lot
of military people.   A huge percentage of them believe Ada is no
longer relevant.    This is the perception many of us have been trying
to change for the last ten years.   I am sad that we have not made more
progress.

Advocates of other minor players in the languages and tools game are
under the same cloud.   It is the old argument that the best product
does
not necessarily gain the greatest market share.

> By far the most widely used language for PC development is
> Visual Basic (although almost never taught in universities,
> contrary to other claims you made).

It is, however, widely taught in various vocational schools and
community
colleges.   Places such as DeVry, Heald, and others like it certainly
include
Visual BASIC.   Vocational schools keep a sharp eye on the marketplace
and
develop their curriculum to meet the demand.    Some of you would be
quite
surprised to discover how many students with a BA or MA in English,
Psychology,
Biology, or Music are studying Visual Basic and HTML at some nearby
vocational school.   Oh, and they are getting jobs when they graduate
too.

> > My point is that with Ada, you will most likely get a
> > maintained compiler for a current platform in 15 years. Will
> > this be true for C++?
>
> Yes, of course it will. Ada advocacy is not helped by FUD like
> this which is clearly unfounded.

In a recent conversation with someone from IBM Santa Theresa labs
I learned that even PL/I is undergoing a rework to object technology.
He did not know the status of this effort, but it will be fascinating to

see if it becomes a reality in the marketplace.    Also, IBM continues
to sell and support APL.   There is apparently a user base for APL
in the financial analysis industry.

As Robert Dewar noted, these languages do not necessarily go away.
Thankfully, some do.   In the late 1970's I was working for consulting
firm when a request came from a U.S. Army client to teach a class to
one of their remote sites in IBM 1401/1460 Autocoder.   To the best
of my knowledge, that is one language no longer in use, but I could be
wrong.   We did sell a lot of our old DoD computing equipment to former
Eastern Block nations.   I recall Herb Grosch saying we should ensure
that they never be able to actually use any of it by also supplying the
manufacturer's documentation.  Some poor soul in Azerbaijian is,
at this moment, trying to discover how to interpret the virgule
character
in a core memory dump.

Richard Riehle

Re: Ada to C Translator

[Robert Dewar]

In article <3A50F03D.3D56E9E2@ix.netcom.com>,
  Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:
> IBM 1401/1460 Autocoder.   To the best
> of my knowledge, that is one language no longer in use

OK, but processor specific languages going away when the
processor in questin goes away is really a rather special
case :-)

It would be more interesting to find an example of a processor
independent high level language that has gone away completely.


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Frode Tennebø]

Robert Dewar wrote:

> It would be more interesting to find an example of a processor
> independent high level language that has gone away completely.

B? :)

 -Frode
-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Robert Dewar]

In article <7kht29.gc2.ln@leia>,
  Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> Robert Dewar wrote:
>
> > It would be more interesting to find an example of a
processor
> > independent high level language that has gone away
completely.
>
> B? :)

There is more than one language that has been called B (e.g.
ABC is one such language), but I don't know of any that once
had an established compiler technology and real commercial use
that have gone away. Please give more details. of course there
are lots of languages generated for the purposes of academic
research (e.g. getting a PhD thesis), that have gone away
(GYVE is one of the more interesting languages in this
category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's)


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Frode Tennebø]

Robert Dewar wrote:

> In article <7kht29.gc2.ln@leia>,
>   Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> > Robert Dewar wrote:
>
> There is more than one language that has been called B (e.g.
> ABC is one such language), but I don't know of any that once
> had an established compiler technology and real commercial use
> that have gone away. Please give more details. 

I was not aware that ABC was referred to as B. I was thinking of the 
design of Thompson and Ritchie - now predated by C. I'm unsure about 
the commercial value though.

> of course there
> are lots of languages generated for the purposes of academic
> research (e.g. getting a PhD thesis), that have gone away
> (GYVE is one of the more interesting languages in this
> category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's)

If you are interested in obscure languages, you should take a look at 
Erlang (www.erlang.org).

 -Frode
-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1313 bytes --]

On Wed, 3 Jan 2001, Frode [ISO-8859-1] Tennebø wrote:
> Robert Dewar wrote:
> > There is more than one language that has been called B (e.g.
> > ABC is one such language), but I don't know of any that once
> > had an established compiler technology and real commercial use
> > that have gone away. Please give more details. 
> 
> I was not aware that ABC was referred to as B. I was thinking of the 
> design of Thompson and Ritchie - now predated by C. I'm unsure about 
                                       ^^^^^^^^

I think you aren't a native speaker of English. You mean "B predates C". 
One could argue that B evolved directly into C. 

> > of course there
> > are lots of languages generated for the purposes of academic
> > research (e.g. getting a PhD thesis), that have gone away
> > (GYVE is one of the more interesting languages in this
> > category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's)
> 
> If you are interested in obscure languages, you should take a look at 
> Erlang (www.erlang.org).

Erlang is hardly "obscure"; it is used at Ericsson and Bluetail/Alteon, 
amongst others. I'd say it is thriving. I still prefer languages with
static type systems though, though I understand why the Erlang designers 
went with dynamic types. 

-- Brian

Re: Ada to C Translator

[Larry Kilgallen]

In article <Pine.BSF.4.21.0101031549200.12612-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:
> On Wed, 3 Jan 2001, Frode [ISO-8859-1] Tenneb=F8 wrote:
>> Robert Dewar wrote:
>> > There is more than one language that has been called B (e.g.
>> > ABC is one such language), but I don't know of any that once
>> > had an established compiler technology and real commercial use
>> > that have gone away. Please give more details.=20
>>=20
>> I was not aware that ABC was referred to as B. I was thinking of the=20
>> design of Thompson and Ritchie - now predated by C. I'm unsure about=20
>                                        ^^^^^^^^
> 
> I think you aren't a native speaker of English. You mean "B predates C".=20
> One could argue that B evolved directly into C.=20

I thought the predecessor to C was called BCPL.

Re: Ada to C Translator

[Brian Rogoff]

On 3 Jan 2001, Larry Kilgallen wrote:
> In article <Pine.BSF.4.21.0101031549200.12612-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > On Wed, 3 Jan 2001, Frode [ISO-8859-1] Tenneb=F8 wrote:
> >> Robert Dewar wrote:
> >> > There is more than one language that has been called B (e.g.
> >> > ABC is one such language), but I don't know of any that once
> >> > had an established compiler technology and real commercial use
> >> > that have gone away. Please give more details.=20
> >>=20
> >> I was not aware that ABC was referred to as B. I was thinking of the=20
> >> design of Thompson and Ritchie - now predated by C. I'm unsure about=20
> >                                        ^^^^^^^^
> > 
> > I think you aren't a native speaker of English. You mean "B predates C".=20
> > One could argue that B evolved directly into C.=20
> 
> I thought the predecessor to C was called BCPL.

Logically true, but the *immediate* predecessor to C was B, which was
derived from BCPL. Don't take my word for it though,

http://www.lysator.liu.se/c/

has a link to this paper

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

I quote Dennis M. Ritchie

" For the sake of brevity, I omit full descriptions of C itself, its
parent B [Johnson 73] and its grandparent BCPL [Richards 79]..."

-- Brian

Re: Ada to C Translator

[Ken Garlington]

JOVIAL hasn't gone away completely, but I suspect that it's fairly close to
qualifying...

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:92vqe7$f7a$1@nnrp1.deja.com...
: In article <7kht29.gc2.ln@leia>,
:   Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
: > Robert Dewar wrote:
: >
: > > It would be more interesting to find an example of a
: processor
: > > independent high level language that has gone away
: completely.
: >
: > B? :)
:
: There is more than one language that has been called B (e.g.
: ABC is one such language), but I don't know of any that once
: had an established compiler technology and real commercial use
: that have gone away. Please give more details. of course there
: are lots of languages generated for the purposes of academic
: research (e.g. getting a PhD thesis), that have gone away
: (GYVE is one of the more interesting languages in this
: category, Phil Shaw : NYU PhD, advisor Jack Schwartz, mid 70's)
:
:
: Sent via Deja.com
: http://www.deja.com/

Re: Ada to C Translator

[Lao Xiao Hai]

Robert Dewar wrote:

> In article <3A50F03D.3D56E9E2@ix.netcom.com>,
>   Lao Xiao Hai <laoxhai@ix.netcom.com> wrote:
> > IBM 1401/1460 Autocoder.   To the best
> > of my knowledge, that is one language no longer in use
>
> OK, but processor specific languages going away when the
> processor in questin goes away is really a rather special
> case :-)
>
> It would be more interesting to find an example of a processor
> independent high level language that has gone away completely.

The first one that springs to mind is NELIAC.   It was a pretty good
Algol-based language used by the Navy.   I don't think there is anyone
still using NELIAC.

Richard Riehle

Re: Ada to C Translator

[Frode Tennebø]

Robert Dewar wrote:

> In article <alpl29.aph.ln@leia>,
>   Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> 
> > I'm not sure what type of application you have, however 15
> > years ago  there were a lot fewer languages than today.
> 
> That seems clearly false. What is your authority for this
> statement/guess. Perhaps you mean that there are fewer
> languages with which you are familiar (given the rest of
> the message that seems a possibility).

MMmmmm....not. If you take the languages you had 15 years ago, add up 
the numbers of languages invented in the last 15 years, you get more 
languages today than 15 years ago. :)

> > How many of those languages are alive today?
> 
> Virtually all of them. Nothing is more discouraging than seeing
> supposedly knowledgable Ada folks decide with no evidence that
> other languages have disappeared from sight. It is indeed a
> common malady to assume that any language you do not bump into
> every day has disappeared (for example, I often meet people who
> think that PL/1 has disappeared). But surely Ada folks should
> try to avoid this mistake, of all people!

I realise that this was a rather misleading statement and you are of 
course totally correct, Robert. But, let me rephrase the statement:
Of all the languages available for general programming, which ones 
would these older than say, 5 years, would you choose for a current 
programming task?

There will always exist code for any language ever conceived, but is it 
practical to select PL/1 now if you are considering ports to both Linux 
and Windows?

> 
> > Can you get an actively maintained compiler for Cobol on a
> > modern platform?
> 
> A staggeringly ignorant question :-) Yes, of COURSE you can,
> and the amount of legacy COBOL out there is huge. Furthermore,
> new applications are being generated in COBOL all the time
> (that should not be surprising, COBOL is still the most
> suitable language for fiscal applications -- yes, you can make
> a reasonable technical argument for Ada-95, but most of the
> people making language decisions assume that Ada has
> disappeared -- see paragraph one above). As for active
> maintenance, yes, there are certainly active COBOL compiler
> maintenance groups around (e.g. for Computer Associates Realia
> COBOL for IBM PC's, or don't these count as modern platforms in
> your lexicon? :-)

IBM PC's modern? Let me think... :)

Well, again it I spoke before I thought. COBOL might very well be the 
one language with most lines (or whatever unit one counts) in 
existance, but I was not aware of efforts to maintain it. I was not 
aware of IBM's effort here. I should have research more - will I learn? 
I DID learned of: http://cobolforgcc.sourceforge.net/ which looks 
rather cool. :)

> 
> > What about Forth?
> 
> Again, just because you do not bump into it every day, does not
> mean it is dead, especially when you have made ZERO attempt to
> find out facts. Of *course* Forth is alive and well, and is
> used in many applications areas. There is by the way a VERY
> nice Forth interpretor for the Palm Pilot, which has been used
> to generate a number of Palm applications.

http://www.forth.org/ - say no more.

> 
> > The only laguage I can think of other than Ada and C which
> > has a active compiler support is Fortran - even Pascal is
> > struggeling.
> 
> Again, the lack of awareness in this statement is remarkably
> parochial -- even peculiar, given its inclusion of Ada as one
> of three languages still in use -- that would surprise a LOT of
> people:-) There are hundreds of languages for which there is
> active compiler support, and active application communities,
> especially if you use Ada as a standard for what these terms
> mean!

*sigh*

modula2/3, rexx, pascal, basic, etc.....I'm ashamed. 
*Argh* Can I please delete my previous posting? Does the time of 
posting give ANY leniancy? :)

> By far the most widely used language for PC development is
> Visual Basic (although almost never taught in universities,
> contrary to other claims you made). And for sure there will
> be compiler support for this for a long long time.

*puh* I think I had a reference to that one in my first post. However, 
compiler support is limited to ONE vendor and one (set of) platform.

> 
> > My point is that with Ada, you will most likely get a
> > maintained compiler for a current platform in 15 years. Will
> > this be true for C++?
> 
> Yes, of course it will. Ada advocacy is not helped by FUD like
> this which is clearly unfounded. I agree that Ada compilers
> will be maintained for 15 years, but that is because I know the
> business strategy and plans of Ada Core Technologies. The fact
> of the matter is that in terms of future maintenance of
> compilers, C++ is in a VERY secure position (as is COBOL
> incidentally :-)

I would guess that COBOL is more so than C++. The way C++ compilers 
refuses to cooperate with each other and the way standards seems to be 
broken gives me a rather dim view on the survival of C++. My own 
experiences with Sun C++ (various version), egcs, gcc and various 
libaries which refuses to compile code the other compiler excepts, etc. 
It's a jungle out there....

However, I do agree that FUD is not helping any case anywhere. And I 
was not intensionally trying to spread FUD, even though in retrospect 
it might have been perceived as such.

> 
> > Also, you are switching to NT 4 NOW? NT has already reached
> > EOL.
> 
> Again, that is unsupported FUD. I am the last person to write
> strong words of support for NT, but to say that NT has reached
> end of life is absurd.

True, I can't support it by hard facts (how do one present personal 
opinions about anything without it becoming FUD)? MS will never 
publicly discontinue such a high-volume product!

However, juging by the rather abrupt lack of support from MS on NT 
issues, the lack of updated drivers and new drivers for new hardware 
for NT - again, this is a personal opinion based on perosnal experieces 
(take a look at ATI Radeon VE, MS Media Player, etc) - and the way MS 
previously has dealt with 'technology changes', ie. the rather abrupt 
termination of MS DOS, Windows 3, NT 3.51 and W95 for that matter, 
leads me to deduce that this will also be the case for NT4.

If I were to move to any MS platform now (heaven forbids!) NT4 would 
not be a preferred choice for myself.

> 
> > If  you had written any legacy application with C++ on
> > Windows 3.11 five  years ago - how easy would it be to port
> > it to any platform today?
> 
> It would vary on how well it was written, because you were
> using a non-standardized language, still in flux, on an
> obsolescent operating system, yes, you may have more troubles,
> but the difficulty in porting programs is often more related to
> quality of code than operating environment.

Quality of code is a very important factor, but the lack of standards 
(including OS calls, graphics libraries AND programming language) 
should not be dismissed.

> 
> > How about in 10 years?
> 
> I don't think it would be any harder to do this port ten
> years from now than now, probably easier, because more tools
> will be around to help.

I dissagree. I don't believe relevant tools will be available for any 
15 year old technology. Technology change, and those responsible for 
the change are very often more focused on the change itself than the 
implication it has for the past or the future.

I'm speaking from experience. Working for a company with a high 
level of old technology, I see on a regular basis that we have to open 
back-doors, perform compromsises or otherwise do some black magic to 
allow for upgrades of legacy software. The only time this went rather 
smoothly was with Ada.

In '85 I wrote a rather simple, but lengthy script (then it would be 
called a program :) in MS DOS batch language using ED. I'm sure I can 
find a 5.25" drive, load the file and edit it somewhere. But how do I 
port it to run on NT? I wont! I'll write it from scratch.

Just think about the trouble I would be in if you had the entire set of 
source code on 8" floppies. :)

> 
> Of course I agree that porting Ada code to C++ just for the
> sake of porting it seldom makes sense, but let's try to keep
> the arguments real. Ada advocacy is not helped by extreme
> statements about other languages that are insupportable.

I'll put my act together.

> 
> > However, I would get your application running on an older
> > version of GNAT for DOS
> 
> That seems a poor suggestion, this is a bad environment for the
> port, and will make the job much harder (I speak from the point
> of view of our experience in helping customers port millions of
> lines of legacy code to GNAT).

You are the authority here. I'm not familiar with the DOS port of GNAT 
at all. However, from experience, it usually reduces the complexity to 
do one step at a time, ie. legacy Ada/DOS -> GNAT/DOS -> GNAT/other os.
But since there is no current DOS port of GNAT, the reduction in 
complexity might (as for this case)  be outweighed by the old age.

> 
> > Depending on the cost structure of your system, a W2K license
> > can be  significant compared to eg. Linux or BSD or even
> > Solaris these days.
> 
> Indeed, and a Linux license is cheaper than a DOS license, so
> the conclusion here should be that Linux is an obvious target.
> It also supports development work much more reliably than any
> of the Microsoft operating systems in our experience.

:)

> > I performed the major part of 'porting' a 200K SLOC (sic) of
> > code from  SunAda 3 running on Solaris 2.5.1 to GNAT on
> > Solaris 8 in less than 200
> > hours.
> 
> One hour per thousand lines of code is actually rather slow
> as a porting rate from our experience, especially for a fairly
> small program (we have frequently helped with porting very
> large applications in much less time than this on an absolute
> basis, let alone a relative basis). 

*stab-in-the-hearth* Actually, half the time was spent on two 
part-systems (out of app. 30) with rather nasty circular dependencies.

> But milage can vary, we
> have at this stage a LOT of experience in such porting, which
> can make things much more efficient, and as I said earlier,
> difficulty in porting can reflect poor coding of the original
> (the big issue being whether implementation dependent and
> system dependent code is properly isolated).

Which was true (circular deps). But without the excellent Ada83->Ada95 
portability I might still have been hard at work. I might add that 
another ~200 hours were spent converting ~2000 lines of C in the same 
project, and my guess is that this will have to be redone for Linux or 
whatever.

I have great respect for all other programming languages. Ada was not 
my first (nor second or third - heck - I didn't even like it at first:) 
language, and I learned most of the others before Ada. I still program 
the occasional Basic or Pascal and enjoy it. :)

Again, no FUD was intended. And my point was to emphasise the absurdity 
of porting from a perfectly viable source for a portable Ada port to a 
entirely different language on a specific platform. The stab at the 
other languages was ill-conceived and is herby retraced (However: If 
the original platform was Fig Forth/Dos 4 I'm not so sure my advice 
would be the same. :)

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Robert Dewar]

In article <n12r29.qrv.ln@leia>,
  Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> Does the time of posting give ANY leniancy? :)

Sure, we will count it as a post from last year, and start the
new year afresh :-)

> Actually, half the time was spent on two
> part-systems (out of app. 30) with rather nasty circular
> dependencies.

Well you probably don't mean circular dependencies, since these
are illegal in Ada 83 and Ada 95, but more likely you mean code
where the elaboration is in a mess, due to serious bugs of
missing pragma Elaborate's. This is not uncommon, and can
indeed be a pain.

That's why we recommend that all new Ada applications use the
GNAT static elaboration approach to avoid this in the future
(and why we make it the default, so incompetent programmers who
don't know what they are doing in this area will accidentally
do the right thing :-)

But of course for many existing legacy applications with
confused elaboration situations, the use of the default static
elaboration mechanism is infeasible.

It is amazing how much of our support effort is spent in
helping people navigate around elaboration problems that are
really bugs in the original code. This is definitely a weak
spot in the design of Ada, I am sorry we could not fix it for
Ada 95, but there just was not enough time.


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Frode Tennebø]

Robert Dewar wrote:

> > Actually, half the time was spent on two
> > part-systems (out of app. 30) with rather nasty circular
> > dependencies.
> 
> Well you probably don't mean circular dependencies, since these
> are illegal in Ada 83 and Ada 95, but more likely you mean code
> where the elaboration is in a mess, due to serious bugs of
> missing pragma Elaborate's. This is not uncommon, and can
> indeed be a pain.

This is indeed what I meant, circular elaboration. Circular 
dependencies is something completely different.

[snip]

> This is definitely a weak
> spot in the design of Ada, I am sorry we could not fix it for
> Ada 95, but there just was not enough time.

How would you suggest go about fixing this? And more importantly; will 
it get fixed in Ada 0x?

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Robert Dewar]

In article <1rht29.gc2.ln@leia>,
  Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> Robert Dewar wrote:

> This is indeed what I meant, circular elaboration. Circular
> dependencies is something completely different.

But circular elaboration cannot happen with a properly written
Ada program.


> > This is definitely a weak
> > spot in the design of Ada, I am sorry we could not fix it
for
> > Ada 95, but there just was not enough time.
>
> How would you suggest go about fixing this?

In general, the answer is simple "fix the bugs in your
program". Specific answers to this are very dependent on
the exact code in question -- as I mentioned before, a
significant part of our support effort is in helping people
get around these problems, so if you are a GNAT Professional
User, by all means ask us for help on such issues.

> And more importantly, will it be fixed in Ada 0X.

If there is an Ada 0X, and if it addresses these issues, it
most likely will do something similar to what GNAT does in
this area (as I assume you know, GNAT goes far beyond the
RM in terms of elaboration capabilities).

Robert Dewar
Ada Core Technologies


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Larry Kilgallen]

In article <92vqkn$fi9$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:

> If there is an Ada 0X, and if it addresses these issues, it
> most likely will do something similar to what GNAT does in
> this area (as I assume you know, GNAT goes far beyond the
> RM in terms of elaboration capabilities).

So what does DEC Ada do, or are the problems different for Ada 95 ?

I don't recall every having an elaboration problem.

Re: Ada to C Translator

[Ted Dennison]

In article <YEoB2CiGNPjL@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> So what does DEC Ada do, or are the problems different for Ada 95 ?
>
> I don't recall every having an elaboration problem.

I remember having some rather nasty ones using DEC Ada (in other
people's code, of course). It was about 13 years ago, so please forgive
me if I can't come up with details.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Frode Tennebø]

Robert Dewar wrote:

> In article <1rht29.gc2.ln@leia>,
>   Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> > Robert Dewar wrote:
> 
> > This is indeed what I meant, circular elaboration. Circular
> > dependencies is something completely different.
> 
> But circular elaboration cannot happen with a properly written
> Ada program.

Indeed it can't, but nasty non the less _when_ it occurs. :)
There will always be legacy code out there which is not properly 
written. 

> In general, the answer is simple "fix the bugs in your
> program". Specific answers to this are very dependent on
> the exact code in question -- as I mentioned before, a
> significant part of our support effort is in helping people
> get around these problems, so if you are a GNAT Professional
> User, by all means ask us for help on such issues.

:) I was more thinking about how this can be solved in the language 
itself. How much of this is done in languages like Java or C++?

> > And more importantly, will it be fixed in Ada 0X.
> 
> If there is an Ada 0X, and if it addresses these issues, it
> most likely will do something similar to what GNAT does in
> this area (as I assume you know, GNAT goes far beyond the
> RM in terms of elaboration capabilities).

GNAT does an excellent job and one of the reasons I have confidence in 
Ada is the strong compiler technology supplied by GNAT.

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Frode Tennebø]

Robert Dewar wrote:

> In article <alpl29.aph.ln@leia>,
>   Frode =?ISO-8859-1?Q?Tenneb=F8?= <frodet@nvg.org> wrote:
> 
> > I'm not sure what type of application you have, however 15
> > years ago  there were a lot fewer languages than today.
> 
> That seems clearly false. What is your authority for this
> statement/guess. Perhaps you mean that there are fewer
> languages with which you are familiar (given the rest of
> the message that seems a possibility).

MMmmmm....not. If you take the languages you had 15 years ago, add up 
the numbers of languages invented in the last 15 years, you get more 
languages today than 15 years ago. :)

> > How many of those languages are alive today?
> 
> Virtually all of them. Nothing is more discouraging than seeing
> supposedly knowledgable Ada folks decide with no evidence that
> other languages have disappeared from sight. It is indeed a
> common malady to assume that any language you do not bump into
> every day has disappeared (for example, I often meet people who
> think that PL/1 has disappeared). But surely Ada folks should
> try to avoid this mistake, of all people!

I realise that this was a rather misleading statement and you are of 
course totally correct, Robert. But, let me rephrase the statement:
Of all the languages available for general programming, which ones 
would these older than say, 5 years, would you choose for a current 
programming task?

There will always exist code for any language ever conceived, but is it 
practical to select PL/1 now if you are considering ports to both Linux 
and Windows?

> 
> > Can you get an actively maintained compiler for Cobol on a
> > modern platform?
> 
> A staggeringly ignorant question :-) Yes, of COURSE you can,
> and the amount of legacy COBOL out there is huge. Furthermore,
> new applications are being generated in COBOL all the time
> (that should not be surprising, COBOL is still the most
> suitable language for fiscal applications -- yes, you can make
> a reasonable technical argument for Ada-95, but most of the
> people making language decisions assume that Ada has
> disappeared -- see paragraph one above). As for active
> maintenance, yes, there are certainly active COBOL compiler
> maintenance groups around (e.g. for Computer Associates Realia
> COBOL for IBM PC's, or don't these count as modern platforms in
> your lexicon? :-)

IBM PC's modern? Let me think... :)

Well, again it I spoke before I thought. COBOL might very well be the 
one language with most lines (or whatever unit one counts) in 
existance, but I was not aware of efforts to maintain it. I was not 
aware of IBM's effort here. I should have research more - will I learn? 
I DID learned of: http://cobolforgcc.sourceforge.net/ which looks 
rather cool. :)

> 
> > What about Forth?
> 
> Again, just because you do not bump into it every day, does not
> mean it is dead, especially when you have made ZERO attempt to
> find out facts. Of *course* Forth is alive and well, and is
> used in many applications areas. There is by the way a VERY
> nice Forth interpretor for the Palm Pilot, which has been used
> to generate a number of Palm applications.

http://www.forth.org/ - say no more.

> 
> > The only laguage I can think of other than Ada and C which
> > has a active compiler support is Fortran - even Pascal is
> > struggeling.
> 
> Again, the lack of awareness in this statement is remarkably
> parochial -- even peculiar, given its inclusion of Ada as one
> of three languages still in use -- that would surprise a LOT of
> people:-) There are hundreds of languages for which there is
> active compiler support, and active application communities,
> especially if you use Ada as a standard for what these terms
> mean!

*sigh*

modula2/3, rexx, pascal, basic, etc.....I'm ashamed. 
*Argh* Can I please delete my previous posting? Does the time of 
posting give ANY leniancy? :)

> By far the most widely used language for PC development is
> Visual Basic (although almost never taught in universities,
> contrary to other claims you made). And for sure there will
> be compiler support for this for a long long time.

Perhaps not in Universities in the US, but certainly VB is tought in 
colleges both in the US (I believe) and here in Norway. However, 
compiler support is limited to ONE vendor and one (set of) platform.

> 
> > My point is that with Ada, you will most likely get a
> > maintained compiler for a current platform in 15 years. Will
> > this be true for C++?
> 
> Yes, of course it will. Ada advocacy is not helped by FUD like
> this which is clearly unfounded. I agree that Ada compilers
> will be maintained for 15 years, but that is because I know the
> business strategy and plans of Ada Core Technologies. The fact
> of the matter is that in terms of future maintenance of
> compilers, C++ is in a VERY secure position (as is COBOL
> incidentally :-)

I would guess that COBOL is more so than C++. The way C++ compilers 
refuses to cooperate with each other and the way standards seems to be 
broken gives me a rather dim view on the survival of C++. My own 
experiences with Sun C++ (various version), egcs, gcc and various 
libaries which refuses to compile code the other compiler excepts, etc. 
It's a jungle out there....

However, I do agree that FUD is not helping any case anywhere. And I 
was not intensionally trying to spread FUD, even though in retrospect 
it might have been perceived as such.

> 
> > Also, you are switching to NT 4 NOW? NT has already reached
> > EOL.
> 
> Again, that is unsupported FUD. I am the last person to write
> strong words of support for NT, but to say that NT has reached
> end of life is absurd.

True, I can't support it by hard facts (how do one present personal 
opinions about anything without it becoming FUD)? MS will never 
publicly discontinue such a high-volume product!

However, juging by the rather abrupt lack of support from MS on NT 
issues, the lack of updated drivers and new drivers for new hardware 
for NT - again, this is a personal opinion based on perosnal experieces 
(take a look at ATI Radeon VE, MS Media Player, etc) - and the way MS 
previously has dealt with 'technology changes', ie. the rather abrupt 
termination of MS DOS, Windows 3, NT 3.51 and W95 for that matter, 
leads me to deduce that this will also be the case for NT4.

If I were to move to any MS platform now (heaven forbids!) NT4 would 
not be a preferred choice for myself.

> 
> > If  you had written any legacy application with C++ on
> > Windows 3.11 five  years ago - how easy would it be to port
> > it to any platform today?
> 
> It would vary on how well it was written, because you were
> using a non-standardized language, still in flux, on an
> obsolescent operating system, yes, you may have more troubles,
> but the difficulty in porting programs is often more related to
> quality of code than operating environment.

Quality of code is a very important factor, but the lack of standards 
(including OS calls, graphics libraries AND programming language) 
should not be dismissed.

> 
> > How about in 10 years?
> 
> I don't think it would be any harder to do this port ten
> years from now than now, probably easier, because more tools
> will be around to help.

I dissagree. I don't believe relevant tools will be available for any 
15 year old technology. Technology change, and those responsible for 
the change are very often more focused on the change itself than the 
implication it has for the past or the future.

I'm speaking from experience. Working for a company with a high 
level of old technology, I see on a regular basis that we have to open 
back-doors, perform compromsises or otherwise do some black magic to 
allow for upgrades of legacy software. The only time this went rather 
smoothly was with Ada.

In '85 I wrote a rather simple, but lengthy script (then it would be 
called a program :) in MS DOS batch language using ED. I'm sure I can 
find a 5.25" drive, load the file and edit it somewhere. But how do I 
port it to run on NT? I wont! I'll write it from scratch.

Just think about the trouble I would be in if you had the entire set of 
source code on 8" floppies. :)

> 
> Of course I agree that porting Ada code to C++ just for the
> sake of porting it seldom makes sense, but let's try to keep
> the arguments real. Ada advocacy is not helped by extreme
> statements about other languages that are insupportable.

I'll put my act together.

> 
> > However, I would get your application running on an older
> > version of GNAT for DOS
> 
> That seems a poor suggestion, this is a bad environment for the
> port, and will make the job much harder (I speak from the point
> of view of our experience in helping customers port millions of
> lines of legacy code to GNAT).

You are the authority here. I'm not familiar with the DOS port of GNAT 
at all. However, from experience, it usually reduces the complexity to 
do one step at a time, ie. legacy Ada/DOS -> GNAT/DOS -> GNAT/other os.
But since there is no current DOS port of GNAT, the reduction in 
complexity might (as for this case)  be outweighed by the old age.

> 
> > Depending on the cost structure of your system, a W2K license
> > can be  significant compared to eg. Linux or BSD or even
> > Solaris these days.
> 
> Indeed, and a Linux license is cheaper than a DOS license, so
> the conclusion here should be that Linux is an obvious target.
> It also supports development work much more reliably than any
> of the Microsoft operating systems in our experience.

:)

> > I performed the major part of 'porting' a 200K SLOC (sic) of
> > code from  SunAda 3 running on Solaris 2.5.1 to GNAT on
> > Solaris 8 in less than 200
> > hours.
> 
> One hour per thousand lines of code is actually rather slow
> as a porting rate from our experience, especially for a fairly
> small program (we have frequently helped with porting very
> large applications in much less time than this on an absolute
> basis, let alone a relative basis). 

*stab-in-the-hearth* Actually, half the time was spent on two 
part-systems (out of app. 30) with rather nasty circular dependencies.

> But milage can vary, we
> have at this stage a LOT of experience in such porting, which
> can make things much more efficient, and as I said earlier,
> difficulty in porting can reflect poor coding of the original
> (the big issue being whether implementation dependent and
> system dependent code is properly isolated).

Which was true (circular deps). But without the excellent Ada83->Ada95 
portability I might still have been hard at work. I might add that 
another ~200 hours were spent converting ~2000 lines of C in the same 
project, and my guess is that this will have to be redone for Linux or 
whatever.

I have great respect for all other programming languages. Ada was not 
my first (nor second or third - heck - I didn't even like it at first:) 
language, and I learned most of the others before Ada. I still program 
the occasional Basic or Pascal and enjoy it. :)

Again, no FUD was intended. And my point was to emphasise the absurdity 
of porting from a perfectly viable source for a portable Ada port to a 
entirely different language on a specific platform. The stab at the 
other languages was ill-conceived and is herby retraced (However: If 
the original platform was Fig Forth/Dos 4 I'm not so sure my advice 
would be the same. :)

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Tarjei Tj�stheim Jensen]

Frode Tenneb� wrote:
> Perhaps not in Universities in the US, but certainly VB is tought in
> colleges both in the US (I believe) and here in Norway. However,
> compiler support is limited to ONE vendor and one (set of) platform.

Not entirely true. There is a project connected to the Gnome project
which attempts to rectify this situation. I think their first target is
to provide macro support for gnumeric (the excel clone).

I quite like gnumeric. It loads faster on my Indigo 2 than excel on the
PC (both at work). The reason is probably that I have a rotten network
connection. It is the network equivalent of the bermuda triangle; nobody
knows why things work or don't work.


Greetings,

Re: Ada to C Translator

[Dave Ptacek]

Wow, I guessed I really stepped in to delicate topic here.  All of the
replies had good information and points that should really be addressed
before starting an Ada to C/C++ port.  By the way Robert, thanks for
putting on the unbiased hat and defending some of the rather opinionated
views.  I knew that I was approaching blasphemy with my post considering
it was to a bunch of Ada people, but was hoping I worded it tactfully
enough so that I wouldn't step into a religious war.  I think I
succeeded on that one although maybe the group took pity on a relative
"newbie" to the group, I certainly did not mean to offend anyone.

I will once again emphasize that finding perspective new employees to
help us with our legacy Ada test equipment application is indeed a
problem (now I'm NOT speaking for the rest of the products developed
here, nor for the company in general).  Considering our test solutions
have a lifespan of 20-25 (maybe more) years, selecting a language and
lineage of toolsets has a large impact on future costs.

We started with Ada because the companies commitment to it in the
mid-80's, and even then our group bucked the trend and chose the Alsys
Ada compiler over the companies preferred toolset.  As most of you know,
Alsys essentially left the market in the early 90's and we've been
running with an unsupported, possibly obsolete, compiler ever since.  We
did have 4-5 years of support prior to them leaving which gave us a good
indication of what could be done and shouldn't be done in Ada while
using Alsys.  We certainly couldn't have achieved the level of success
without the Alsys Ada compiler.

However, we now find ourselves in the middle of the technology evolution
that seems to change every 3-6 months depending on the particular
technology of interest.  Contrary to the belief of some people, DOS is
not dead and you can still buy licenses for DOS today.  The same cannot
be said for Win3.1, Win3.11, and soon Win95.  It would be foolish to not
acknowledge the writing on the wall and stay with DOS, and considering
the widespread usage of WinNT, it seems to be the best offering from
Microsoft at this time.  I do believe Microsoft will always provide some
"upgrade" path from NT 4.0 to 2000 to etc. as there are just too many
Microsoft apps that need will need to be "upgraded" as well.  Jumping on
that bandwagon appears to have some merit.

I personally have considered a Linux solution, but the logistics haven't
been worked yet.  We have well over 200 test stations around the world
in service centers and customer facilities, coordinating a PC swap,
getting the station running and connecting it up to the internal
network(s) available appears to be a rather large effort.  And yes, most
of the networks are using NT servers.

I would be interested in some suggestions as to what languages and
toolsets would be viable alternatives for maintaining a program 15 - 20
years into the future.  Please try to take the Ada hat off before you
respond, it still might be your choice, attempt to rationalize it with
reasonable statements, consider the logistical situation noted above and
lastly this is not a "deep pocket" program so funds are limited.

I'm rambling again and have probably stepped into yet another delicate
topic...

thanks,

Dave

Re: Ada to C Translator

[Ted Dennison]

In article <3A5218FB.41FDD@collins.rockwell.com>,
  Dave Ptacek <drptaceknospam@collins.rockwell.com> wrote:

> I would be interested in some suggestions as to what languages and
> toolsets would be viable alternatives for maintaining a program 15 -
> 20 years into the future.  Please try to take the Ada hat off before
> you respond, it still might be your choice, attempt to rationalize it
> with reasonable statements, consider the logistical situation noted
> above and lastly this is not a "deep pocket" program so funds are
> limited.

If you want our "Ada" hats off, you are in the wrong place. You might as
well ask the same question to passerby in a soup kitchen. :-)

What OSes are technially best depends a lot on your application. Is it
real-time? Is it embedded, and you have to deliver lots of units? Is it
an office application?

Generally, I'd argue that if you use an OS for which you have all the
source code, then that would insulate you from a lot of worries about
vendors discontinuing support. For instance, if some vendor makes a new
device that you'd like to stick on your system 5 years from now, you
could just write up a driver for it yourself if worse comes to worse.
This logic would clearly point to Linux or one of the free (liberated)
alternatives. Of course of those, Linux is probably the best supported
right now. Its also the most enthusiasticly hyped, which seems to matter
a great deal to you folks for some reason. (Sorry for the cheap dig, I
couldn't resist). If you want to jump onto a hype train, you might as
well catch one that's just getting up to steam, so you don't have to
jump again quite so soon.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Tarjei Tj�stheim Jensen]

Dave Ptacek wrote:
>I do believe Microsoft will always provide some
> "upgrade" path from NT 4.0 to 2000 to etc. as there are just too many
> Microsoft apps that need will need to be "upgraded" as well.  Jumping on
> that bandwagon appears to have some merit.

It all depends. NT is an unreliable platform as far as being a server is
concerned. The worst case scenario is having to re-install windows NT.
And I'm not talking about a hardware crash. The "must have all servers
on NT" wave has passed. Not completely, but now it is acceptable to have
something else.

My favourites for something which is placed at another site would be
either a VMS, Irix 6.5 or one of the BSD varieties. VMS because few know
it and it would be a real challenge to break into. An industrial
strength OS on cheap hardware. Irix because it has good tools for
patching and upgrades. It also has the best volume manager I have seen
to date. The various BSDs has been easier to install than any of the
Linuxes I have tried on the PCs I have available.

The best Linux to place outside ones own control would probably be
Debian. It seems to be the only one with a really good upgrade tool.
That upgrade tool seems to be better than the ones that come with the
BSD versions.

> I would be interested in some suggestions as to what languages and
> toolsets would be viable alternatives for maintaining a program 15 - 20
> years into the future.  Please try to take the Ada hat off before you
> respond, it still might be your choice, attempt to rationalize it with
> reasonable statements, consider the logistical situation noted above and
> lastly this is not a "deep pocket" program so funds are limited.
> 

As far as technical computing is concerned, Ada and/or plain C would be
my choice. Ada has by far the best process for updating the language. I
might not agree that all choices are the best, but it is a really strong
language which fosters the right attitude for long term software
development. And it has the right customers which understands that they
are in for more than a short ride.

To me C/C++/Java/C# seems slightly risky as the language seems to
disintegrate into a number of dialects. Once they have started that, who
knows where it ends. Only C seems to have an eye to previous art. The
rest of the languages seems to be evolving and that means that anybody
who hitches a ride might get stranded in an inconvenient place. Getting
along with the rest might become expensive (read: you have to rewrite
code).

With regard to compiler availability: The same consolidation which have
occured with Ada is also occuring with C and C++. It is no accident that
Borland have made their C/C++ compiler available for free (you pay for
the development environment).

In the windows environment, I would not be surprised if there were more
Ada compiler vendors selling compilers than there are C++ vendors
selling C/C++ compilers. I think we for all intents and purposes have
one left; microsoft. That single vendor dependency would be a compelling
reason to use an other programming language.

Have you read the COTS Journal article on Ada? If you have, re-read
table 1. If not search for it in this newsgroup and visit!


Greetings,

Re: Ada to C Translator

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

In article <3A525C16.5C444ADD@online.no>,
  "Tarjei Tj�stheim Jensen" <tarjei@online.no> wrote:

> My favourites for something which is placed at another site would be
> either a VMS, Irix 6.5 or one of the BSD varieties. VMS because few
> know it and it would be a real challenge to break into. An industrial

I've heard that some folks prefer MacOS-based servers for security,
since the OS has no command shell whatsoever. Sort of "security through
disability". :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Ada to C Translator

[Frode Tennebø]

Dave Ptacek wrote:

> Wow, I guessed I really stepped in to delicate topic here.  All of the
> replies had good information and points that should really be
> addressed
> before starting an Ada to C/C++ port.  By the way Robert, thanks for
> putting on the unbiased hat and defending some of the rather
> opinionated
> views.  

That would be me. :)

[snip]

> I personally have considered a Linux solution, but the logistics
> haven't
> been worked yet.  We have well over 200 test stations around the world
> in service centers and customer facilities, coordinating a PC swap,
> getting the station running and connecting it up to the internal
> network(s) available appears to be a rather large effort.  And yes,
> most of the networks are using NT servers.

I don't see the any problem here...Shuffeling boxes through the mail 
will be the same whatever OS/Software is on them. Linux/BSD has 
built-in support for remote administration. Doing this on NT/W2K is 
inherently more difficult, but it can be done. The solution(s) are not 
as robust (disclaimer: the solutions I have encountered).

> I would be interested in some suggestions as to what languages and
> toolsets would be viable alternatives for maintaining a program 15 -
> 20
> years into the future.  

Before you start considering the programming language and/or toolset, I 
trust that you have considered what HW platform you are going to use? 
Considered how long time into the future you have spare parts, the 
operating environment, etc.

Then you will need to take a look on what you have; is it good quality 
code worth saving or scrap it, redesign and move over completely? Make 
an estimate on how much it would cost to port from you Alsys compiler 
to eg. GNAT (or any of the other commercial Ada compiler vendors - I'm 
sure any of the companies will help getting a good estimate) and 
compare that to the cost of a rewrite. Remeber to take into account all 
the costs: retraining of existing personel, seting up and running the 
new enviornment, etc.

> Please try to take the Ada hat off before you
> respond, it still might be your choice, attempt to rationalize it with
> reasonable statements, consider the logistical situation noted above
> and lastly this is not a "deep pocket" program so funds are limited.

If funds are limited, consider again the Linux/GNAT alternative. If you 
consider yourself to have enough Ada/GNU competence in-house, fairly 
up-to-date releases of GNAT is available for free - however, I'm sure 
Robert will discurage this if you are selling a commercial product, and 
depending on your needs this might be correct. If nothing else, the 
public release of GNAT can be used in a pre-study phase to locate 
problem areas in your current code base.

The GNU GCC C/C++/Fortran77 is also free if you decide for any of those 
languages.

I won't recomend any particular toolset or language as I am biased 
toward the open arena of software development. But I have not yet used 
a RAD/IDE tool which outperforms my Emacs setup (which in no way is 
optimal). My only concerne is the lack of a really slick debugger. 
DDD/GDB is not yet there. The new debugger from (people from) ACT 
Europe looks nice, but I have not had the chance to try it yet.

> I'm rambling again and have probably stepped into yet another delicate
> topic...

Not at all - just makre sure you take all advice for what it is. It 
might not even be good advice. :)

 -Frode

-- 
^ Frode Tenneb� | email: frodet@nvg.org | Frode@IRC  ^
| with Standard.Disclaimer; use Standard.Disclaimer; |

Re: Ada to C Translator

[Marin David Condic]

Speaking as someone who has worked on projects with a similarly long or
longer lifecycle, I'll throw this in: Nobody has a crystal ball with enough
magnifying power to see that far ahead. Example: The F119 engine for the
Advanced Tactical Fighter was in various stages of development for over ten
years before it went into production. In that ten years, the engine control
went from running 68000 processors to 68040 processors (with stops in
between). Before it got to production, Motorola decided that they weren't
going to make a Mil packaged version of the chip anymore no matter how much
whining and snivveling we did. The box will ultimately go into production
using PowerPC chips. The project had frozen a version of the XD-Ada compiler
for a long time and kept VAX/VMS systems around to run it on in spite of
everyone else at the company going to Sun/Unix platforms. Eventually the
project was forced to move on to the Aonix Ada95 compiler for the PowerPC
chip. All that meant major rewriting of the system level software and
reverification of the control. No small task.

Since projects like this can't possibly forsee what will happen 20 years
from now (new charged particle phased plasma fluidic computational devices?
or maybe total economic colapse followed by a meteor impact that throws us
all back to the stone age?) the powers that be on the project have to have a
plan to deal with the inevitable changes. If you were to, for example, pick
Ada as your programming language and Linux as your OS, what you would want
to do is design the software to isolate machine/OS specific features so they
could easily be replaced and develop your software so that it is clear,
easily understood and readily translated if that need should arise. Ada
shines in these areas for lots of reasons such as readily understood syntax,
modular construction, etc. Ada was designed specifically to support large
projects with a long lifespan. If you write it in Ada, at least your
grandson can come along 20..30 years from now and maybe understand what you
did and translate it into C** or F# or whatever is the new, hip computer
language  at that time. (Personally, I'm predicting a resurgence in the use
of Jovial. :-)

What was it they said in The Mythical Man-Month? When you develop software,
plan to write it twice because you will anyway.

MDC

Dave Ptacek wrote:

> I would be interested in some suggestions as to what languages and
> toolsets would be viable alternatives for maintaining a program 15 - 20
> years into the future.  Please try to take the Ada hat off before you
> respond, it still might be your choice, attempt to rationalize it with
> reasonable statements, consider the logistical situation noted above and
> lastly this is not a "deep pocket" program so funds are limited.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Ada to C Translator

[Ken Garlington]

Your mentioning the F119 raises a question in my mind that I probably should
have asked a long time ago. IIRC, the Pratt & Whitney gang used Pictures to
Code extensively for the engine control. Did the advantages you describe
below (easy to read, etc.) really matter in that case, given that Ada
essentially became an intermediate language? Now that the rest of the world
seems to be catching on to this idea (automatic code generation from UML,
etc.), I wonder if that trend is going to make other attributes of
text-based languages more important - portability, availability and
robustness of associated compilers, etc. No one extols the readability of
J-code, do they?


"Marin David Condic" <mcondic.nospam@acm.org> wrote in message
news:3A531C4D.7AB64631@acm.org...
: Speaking as someone who has worked on projects with a similarly long or
: longer lifecycle, I'll throw this in: Nobody has a crystal ball with
enough
: magnifying power to see that far ahead. Example: The F119 engine for the
: Advanced Tactical Fighter was in various stages of development for over
ten
: years before it went into production. In that ten years, the engine
control
: went from running 68000 processors to 68040 processors (with stops in
: between). Before it got to production, Motorola decided that they weren't
: going to make a Mil packaged version of the chip anymore no matter how
much
: whining and snivveling we did. The box will ultimately go into production
: using PowerPC chips. The project had frozen a version of the XD-Ada
compiler
: for a long time and kept VAX/VMS systems around to run it on in spite of
: everyone else at the company going to Sun/Unix platforms. Eventually the
: project was forced to move on to the Aonix Ada95 compiler for the PowerPC
: chip. All that meant major rewriting of the system level software and
: reverification of the control. No small task.
:
: Since projects like this can't possibly forsee what will happen 20 years
: from now (new charged particle phased plasma fluidic computational
devices?
: or maybe total economic colapse followed by a meteor impact that throws us
: all back to the stone age?) the powers that be on the project have to have
a
: plan to deal with the inevitable changes. If you were to, for example,
pick
: Ada as your programming language and Linux as your OS, what you would want
: to do is design the software to isolate machine/OS specific features so
they
: could easily be replaced and develop your software so that it is clear,
: easily understood and readily translated if that need should arise. Ada
: shines in these areas for lots of reasons such as readily understood
syntax,
: modular construction, etc. Ada was designed specifically to support large
: projects with a long lifespan. If you write it in Ada, at least your
: grandson can come along 20..30 years from now and maybe understand what
you
: did and translate it into C** or F# or whatever is the new, hip computer
: language  at that time. (Personally, I'm predicting a resurgence in the
use
: of Jovial. :-)
:
: What was it they said in The Mythical Man-Month? When you develop
software,
: plan to write it twice because you will anyway.
:
: MDC
:
: Dave Ptacek wrote:
:
: > I would be interested in some suggestions as to what languages and
: > toolsets would be viable alternatives for maintaining a program 15 - 20
: > years into the future.  Please try to take the Ada hat off before you
: > respond, it still might be your choice, attempt to rationalize it with
: > reasonable statements, consider the logistical situation noted above and
: > lastly this is not a "deep pocket" program so funds are limited.
:
: --
: ======================================================================
: Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
: Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
: Visit my web site at:  http://www.mcondic.com/
:
:     "Giving money and power to Government is like giving whiskey
:     and car keys to teenage boys."
:
:         --   P. J. O'Rourke
: ======================================================================
:
:

Re: Ada to C Translator

[Marin David Condic]

An excellent point. PtC was actually capable of generating code in a handful of
different languages so in a sense, it became its own "programming language".
Most of the Ada that was generated was essentially viewed as a "high level
assembly language" and so readability was not as much of a concern. However, it
still produced reasonably readable code and there were reasons why it
periodically needed to be looked at. (Verification and hand modification were
two big reasons.)

In an environment where you have something like PtC, the advantage you get is a
kind of lower level documentation that helps you to understand the system. I
think the actual source code starts becoming less of an issue in this case.
However, I don't think that something like PtC would be useful for any and all
applications. It worked well for us because we had a very narrow usage, so the
diagrams could become really specialized. I'd doubt that for more general kinds
of things it would work as well. UML seems to be too high an abstraction to get
code from unless you are somehow hand-coding part of it. Then the same rules for
readability would apply to the code.

Obviously, the benefits you cite are equally important considerations for
long-lived systems.

MDC

Ken Garlington wrote:

> Your mentioning the F119 raises a question in my mind that I probably should
> have asked a long time ago. IIRC, the Pratt & Whitney gang used Pictures to
> Code extensively for the engine control. Did the advantages you describe
> below (easy to read, etc.) really matter in that case, given that Ada
> essentially became an intermediate language? Now that the rest of the world
> seems to be catching on to this idea (automatic code generation from UML,
> etc.), I wonder if that trend is going to make other attributes of
> text-based languages more important - portability, availability and
> robustness of associated compilers, etc. No one extols the readability of
> J-code, do they?

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Ada to C Translator

[Ehud Lamm]

Mike K <Mike_member@newsguy.com> wrote in message
news:92fk1v0cou@drn.newsguy.com...
> Question to the group:
>
> I have a requirment to convert and application written in ada to c. Can
anyone
> provide me insight as to any ada to c translators available?
>
> Mike
>

You may want to check out http://www.ada2cpp.co.il/
The target is C++ (as the URL implies), though.


--
Ehud Lamm   mslamm@mscc.huji.ac.il

Re: Ada to C Translator

[tmoran]

>I have a requirment to convert and application written in ada to c.
>Can anyone provide me insight as to any ada to c translators available?
  Averstar has an Ada compiler that generates C.  Look at
www.averstar.com/services/IT_consulting.html#ada

Re: Ada to C Translator

[Tarjei T. Jensen]

Mike K wrote in message <92fk1v0cou@drn.newsguy.com>...
>Question to the group:
>
>I have a requirment to convert and application written in ada to c. Can anyone
>provide me insight as to any ada to c translators available?

If your target does not have an Ada compiler then there are at least two
vendors (Averstar and Irvine Compiler Corporation) who has compilers which emit
C code.

I don't think you can maintain the C code, but as with the f2c compiler
(compile fortran with C as intermediate) you are supposed to maintain the
original source and get it to compile through your chosen C compiler.


Greetings,

Re: Ada to C Translator

[Tucker Taft]

Mike K wrote:
> 
> Question to the group:
> 
> I have a requirment to convert and application written in ada to c. Can anyone
> provide me insight as to any ada to c translators available?

AverStar has a variant of our AdaMagic front end that uses
optimized ANSI C as its intermediate representation.  We make
this technology available in 2 ways:

   1) As an Ada compiler for a target that has a reasonable ANSI C
      compiler, where you maintain the Ada source code, and the
      fact that it generates C as an intermediate is not terribly
      important, though it may allow you to use a C debugger to
      debug pretty much at the Ada source code level (we generate
      appropriate "#line" directives for this purpose).

   2) As a translator from Ada to C, where the generated C source
      carries over the structure, comments, names, etc. from the Ada
      program in so far as possible.  This is available only as a service
      on a per-line basis, primarily for packaging reasons, but in part
      also for business reasons.  We can take advantage of certain C++
      features (e.g. namespaces) if desired.

      The intent in this approach is that the translation is essentially
      a one-time process, and you edit and maintain the generated C source.
      Note that although we can retain all the run-time checks in
      the generated source, most users request we turn this off so the C code
      is more "typical."  Furthermore, once you start editing the C
      code, you are definitely sacrificing all the compile-time and
      run-time checking provided by Ada.  So you need a pretty
      compelling justification to take this second route if you care
      at all about the kind of automatic consistency checks that Ada
      provides.

Please contact us if either of these approaches would be of interest to
you.

> 
> Mike

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Ada to C++ Translator

[Brad Crabtree]

This request is probably in poor taste for this discussion group, but
here goes ...

I am looking options in converting Ada to C/C++ beyond the GNAT
translator.  Commerical products OK.

Thanks for any info in advance.

Please no lectures on why this can't or shouldn't be done, or Ada or C++

bashing unless you just can't help youself.  The tool will only be used
as an intermediate step and
not used on sections of code we will be re-architecting to make use of
C++ functionality   :-)
--
Bradley D. Crabtree, Software Design Engineer
b-crabtree@raytheon.com

Re: Ada to C++ Translator

[David Starner]

On Wed, 12 Apr 2000 15:56:51 -0500, Brad Crabtree <b-crabtree@raytheon.com> wrote:
>I am looking options in converting Ada to C/C++ beyond the GNAT
>translator.  Commerical products OK.

GNAT's not a Ada->C translator. It merely uses a multilanguage, multitarget
backend that happens to have a C frontend. Intermetrics has an Ada->C 
translator, last time I heard.

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: Ada to C++ Translator

[Gautier]

Brad Crabtree wrote:

> The tool will only be used as an intermediate step and
> not used on sections of code we will be re-architecting to make use of
> C++ functionality   :-)

Fortunately - since some Ada constructs like nested procedures or visibility
of type and var definitions may render poor C (or other pre-Pascalian language,
even ++ised).

Another possibility would be to bind C++ and Ada. IIRC recent
GNAT (3.12 ? 3.13 ?) offers features in that direction. It could
be much simpler and safer than a translator.

______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm

Re: Ada to C++ Translator

[Tucker Taft]

Brad Crabtree wrote:
> 
> This request is probably in poor taste for this discussion group, but
> here goes ...
> 
> I am looking options in converting Ada to C/C++ beyond the GNAT
> translator.  Commerical products OK.

We have two (related) technologies that might be relevant:

1) We have a validated Ada 95 compiler that uses C as its
intermediate language.  With this, you keep writing and maintaining
your program at the Ada level, but use the C compiler to get the
code onto your target.  The C we generate is quite portable, and
is generally debuggable using a C debugger.  It is also easily
interfacable with other parts of the system written in C.

2) We have adapted the above product to produce C (or C with a bit
of C++) in a more human readable format, with Ada comments carried
over to the generated C/C++, names as close as possible to the original
Ada, etc.  This technology is currently only available as a service,
where we charge on a per-line basis to translate Ada to C/C++.
The expectation here is that this is a one-time process, with future
maintenance performed on the C/C++ code rather than the Ada code.

Both technologies are in use in production environments, but neither
is "shrink wrapped."  We (or you) need to do some tailoring for
the particular target machine, host machine, and C compiler of interest.
Let us know if you would like to pursue use of either technology.

> 
> Thanks for any info in advance.
> 
> Please no lectures on why this can't or shouldn't be done, or Ada or C++
> 
> bashing unless you just can't help youself.  The tool will only be used
> as an intermediate step and
> not used on sections of code we will be re-architecting to make use of
> C++ functionality   :-)
> --
> Bradley D. Crabtree, Software Design Engineer
> b-crabtree@raytheon.com

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Ada To c translator

[wisniew]

	I've got a client for which I might need an Ada(83) to C
translator. Any ideas?

Thanx

Joe

Re: Ada To c translator

[Jerry van Dijk]

In article <33b831cc.7365607@news.primenet.com> wisniew@primenet.com writes:

>        I've got a client for which I might need an Ada(83) to C
>translator. Any ideas?

Yes, convince them to switch to Ada(95)...

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Ada to C translator

[Richard Kenner]

In article <5d90qq$ka7@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>kenner@lab.ultra.nyu.edu (Richard Kenner) writes:
>>That's true, but it's not a hard optimization to only handle variables
>>that are actually *used* in the inner subprogram in a special way (or to
>>special-case a one-element structure).  If a variable is used in an
>>inner subprogram, it probably has to be in memory anyway.
>
>If it's so easy, how come gcc doesn't do it?   ;-)

It does.  The only variables in an outer function that are forced into
memory due to the presence of inner functions are those that are actually
referenced in the inner functions.

Re: Ada to C translator

[Fergus Henderson]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>>kenner@lab.ultra.nyu.edu (Richard Kenner) writes:
>>>That's true, but it's not a hard optimization to only handle variables
>>>that are actually *used* in the inner subprogram in a special way (or to
>>>special-case a one-element structure).  If a variable is used in an
>>>inner subprogram, it probably has to be in memory anyway.
>>
>>If it's so easy, how come gcc doesn't do it?   ;-)
>
>It does.

Oh, right you are.  My apologies.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Ada to C translator

[AlinP]

Hi Richard,

I'm looking for an Ada to C translator (I like Ada but due to the
processor we have selected for a project, there is only a C compiler
available).  Do you know where I might find such an animal?

Thanks!

Alin Pilkington
AlinP@aol.com

Re: Ada to C translator

[Robert Dewar]

Alin says

<<I'm looking for an Ada to C translator (I like Ada but due to the
processor we have selected for a project, there is only a C compiler
available).  Do you know where I might find such an animal?>>

Nope, no such beast is available, and none is likely to be available!
What processor are you using, it is quite surprising if your statement
about only a C compiler being available is correct. There are some
processors with no Ada compiler, but not many, and almost none with
no GCC, and thus no GNAT port in reach. 

Depending on the size of the project, it may be less work and less
expense to acquire an Ada compiler for your processor, than to persue
the translation approach.

Re: Ada to C translator

[Keith Allan Shillington]

Robert!  Honestly.  I'd heard a rumor that you were such a beast yourself!' 
:-) Of course, I suppose that pointing you at a C source and expecting a
translation to Ada would be a very expensive operation.....

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.856967455@merv>...
> Alin says
> 
> <<I'm looking for an Ada to C translator?...>>
> 
> Nope, no such beast is available, and none is likely to be available! ...
> 

Re: Ada to C translator

[Geert Bosch]

Keith Allan Shillington (keith@sd.aonix.com) wrote:  Robert!
   Honestly.  I'd heard a rumor that you were such a beast yourself!' :-) 
   Of course, I suppose that pointing you at a C source and
   expecting a translation to Ada would be a very expensive
   operation.....

Note that this is from C to Ada and besides that I think Robert Dewar
has argued more than once that it is more useful to use pragma Import
instead of translating C code.  Even a few GNAT tools (gnatbl and
gnatchp) still are C programs.

In general an automatic conversion does not make a lot of sense and
manual translation is expensive indeed.

Regards,
   Geert

PS. One of the nice properties of compilers is that when you feed them
    some source, they won't object but try to compile it anyway.  Never
    encountered a compiler that said: "It doesn't make sense even
    trying to compile this code. First fix the layout, use descriptive
    identifiers and add comments where appropriate."

Re: Ada to C translator

[Tom Moran]

Has anyone tried compiling Ada to machine code then decompiling to C?
#.#

Re: Ada to C translator

[Robert Dewar]

Tom Moran said

<<Has anyone tried compiling Ada to machine code then decompiling to C>>

This would definitely not get you far, not only would the C be completely
junky (with a lot of names, and all comments lost), but also it would
tend to be highly target specific. You can only tell something is an
8-bit quantity at that level, you can't tell it was a char.

Re: Ada to C translator

[Robert Dewar]

John Walker said

<<There's also:
2a. You want to use C as an intermediate language to be compiled for a
platform that doesn't currently have an Ada compiler targeted to it.
(All maintenance, etc., would be done on the original Ada.)
>>

First, there are not many such targets these days, given GNAT being
around. 

Second, it is probably easier to do a port of GCC to a new machine in
this case than mess with a C translation. Remember that if you decide
to use C, you are committing yourself to a significantly inefficient
translation (for things like nested procedures, overflow checking,
exception handling), so to compete with this you don't need a super
high quality GCC/GNAT port, just something that works.

Ada to C translator

[Gabriel Rouzaut]

Does anybody knows any tool to translate Ada source files to
C/C++ source files?. I was looking for it on the net, but I
couldn't find any.

I was told that some Ada compilers use C as intermediate language
before compilation. Does anybody know one?.

Thanks

Re: Ada to C translator

[Larry Kilgallen]

In article <32E4C115.55BD@iies.es>, Gabriel Rouzaut <gabmrou@iies.es> writes:
> Does anybody knows any tool to translate Ada source files to
> C/C++ source files?. I was looking for it on the net, but I
> couldn't find any.

The consensus in comp.lang.ada from the _many_ times this has been
addressed in the past is that no general purpose translator could
be built since the semantics of Ada are a superset of the semantics
of C or C++ (no tasking for example).  Please read archives of the
comp.lang.ada rather than starting the discussion up from scratch.

> I was told that some Ada compilers use C as intermediate language
> before compilation. Does anybody know one?.

I don't know of any, but sometimes such reports are confused due
to the fact that Ada compilers and C compilers use a common back
end.  Examples are GNAT and DEC Ada.  In each case the back end
has to include at least some Ada-specific features, which some
might views as "proof by example" that a general purpose Ada-to-C
translator is not possible.

Larry Kilgallen

Re: Ada to C translator

[Ted Dennison]

Larry Kilgallen wrote:
> 
> In article <32E4C115.55BD@iies.es>, Gabriel Rouzaut <gabmrou@iies.es> writes:
> > Does anybody knows any tool to translate Ada source files to
> > C/C++ source files?. I was looking for it on the net, but I
> > couldn't find any.
> 
> The consensus in comp.lang.ada from the _many_ times this has been
> addressed in the past is that no general purpose translator could
> be built since the semantics of Ada are a superset of the semantics
> of C or C++ (no tasking for example).  Please read archives of the
> comp.lang.ada rather than starting the discussion up from scratch.
> 
> > I was told that some Ada compilers use C as intermediate language
> > before compilation. Does anybody know one?.
> 
> I don't know of any, but sometimes such reports are confused due
> to the fact that Ada compilers and C compilers use a common back
> end.  Examples are GNAT and DEC Ada.  In each case the back end
> has to include at least some Ada-specific features, which some
> might views as "proof by example" that a general purpose Ada-to-C
> translator is not possible.

This is one of the better explanations I have seen on this subject. It
would be a good candidate for inclusion in the c.l.a FAQ (hint hint).



-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada to C translator

[Keith Thompson]

In <1997Jan22.062734.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
[...]
> The consensus in comp.lang.ada from the _many_ times this has been
> addressed in the past is that no general purpose translator could
> be built since the semantics of Ada are a superset of the semantics
> of C or C++ (no tasking for example).  Please read archives of the
> comp.lang.ada rather than starting the discussion up from scratch.

I don't agree that a general purpose translator is impossible.  After all,
we know that a general purpose Ada to machine code translator is possible,
and machine code does not inherently support tasking.  The trick is
that you'd have to find a way to support or emulate tasking (and other
Ada-specific features) in the generated C.  The logical way to do this
is to generate calls to runtime support routines, possibly written in Ada.

Of course, this doesn't imply that an Ada to C translator is necessarily a
good idea.  Generating legible and maintainable C from Ada is a daunting
task.  Even if you could do it, it would be sort of like transmuting
gold into lead.  8-)}

There have been proposals to use C as an intermediate language to simplify
porting an Ada compiler to new architectures.  I don't know how practical
this turned out to be.  Note that C code generated as an intermediate
language is almost certain to be illegible and unmaintainable.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: Ada to C translator

[Robert Dewar]

<<As Ada is so different from C it is quite natural that Ada translated
into C looks horrible to a C programmer :-)  gi-go>>


Well I know there is a smiley there, but still, this statement is highly
misleading. The issue here has to do with much more fundamental issues
than Ada being different from C, it has to do with a mismatch in semantic
level for certain operations that leads to C that looks horrible to
anyone.

For example, because of the need to do overflow checking, we may well
have to translate:

   x := (a * b) + (c * d);

to

   x = PLUSOV (MULTOV (a, b), MULTOV (c,d));

where PLUSOV and MULTOV are macros that use operators like :? to check
for overflow. There are many other such cases to be dealt with.

Ada to C translator

[David Buscaglia]

I am looking for an Ada to C translator - anyone know of one?

Re: Ada to C translator

[Robert Dewar]

David asked

"I am looking for an Ada to C translator - anyone know of one?"

This is an FAQ, and we really have seen much in the way of valid answers,
but be warned that when you ask this question, if past experience is any
guide, you will get several "FABR"s (frequently answered bogus replies)
saying that GNAT can translate from Ada to C -- it cannot!

ADA to C++ translator

[Alain PUJOL]

Hi,


 I am looking for a tool able to translate ADA code into C++ (or C).


I any of you heard about such a tool, please give me a pointer either by
replying here, or by a mail to

  pujol@taec.enet.dec.com

Re: ADA to C++ translator

[Darren C Davenport]

Alain PUJOL wrote:
> 
> Hi,
> 
>  I am looking for a tool able to translate ADA code into C++ (or C).
> 

I'm not sure the code specified in the American Disabilities Act
is translatable to C++.

Darren

Re: ADA to C++ translator

[Vladimir Vukicevic]

Darren C Davenport <ddavenpo@redwood.dn.hac.com> writes:

> 
> Alain PUJOL wrote:
> > 
> > Hi,
> > 
> >  I am looking for a tool able to translate ADA code into C++ (or C).
> > 
> 
> I'm not sure the code specified in the American Disabilities Act
> is translatable to C++.
> 
> Darren

Well, I'm not sure if the American Dental Association's legacy code is
readily translatable into C++.. probably written in COBOL or something.
Perhaps they should consider Ada95?

	- Vladimir
	

Re: ADA to C++ translator

[Simon A Watts]

Alain PUJOL wrote:
> 
> Hi,
> 
>  I am looking for a tool able to translate ADA code into C++ (or C).
> 
> I any of you heard about such a tool, please give me a pointer either by
> replying here, or by a mail to
> 
>   pujol@taec.enet.dec.com

I think that the GNU Ada95 works by a translation to C (AFAIR).

-- 
+--------------------+
|   Simon A Watts    |
| DRA Farnborough UK |
| sawatts@dra.hmg.gb |
+--------------------+

Re: ADA to C++ translator

[David Wheeler]

Simon A Watts (sawatts@dra.hmg.gb) wrote:
: Alain PUJOL wrote:
: >  I am looking for a tool able to translate ADA code into C++ (or C).
: > 

: I think that the GNU Ada95 works by a translation to C (AFAIR).


No, not true.  The GNU compilers (C, C++, Ada, etc.) translate to
an internal tree structure, not to C.


--- David A. Wheeler
Net address: wheeler@ida.org

Re: ADA to C++ translator

[Robert Dewar]

Simon said

"I think that the GNU Ada95 works by a translation to C (AFAIR)."


Hmmm! I think Simon has not been reading this newsgroup for very long :-)

The answer to this FQM (frequently quoted misconception) is that GNAT in
no way works by translation to C. There is no C code, nor any internal
intermediate code in any sense equivalent to C at any point in the
compilation process. Therefore GNAT is completely useless for the purposes
of translating Ada 95 to C.

Re: ADA to C++ translator

[Simon A Watts]

Robert Dewar wrote:
> 
> Simon said
> 
> "I think that the GNU Ada95 works by a translation to C (AFAIR)."
> 
> Hmmm! I think Simon has not been reading this newsgroup for very long :-)

comp.lang.c++ : yes
comp.lang.ada : no

> 
> The answer to this FQM (frequently quoted misconception) is that GNAT in
> no way works by translation to C. There is no C code, nor any internal
> intermediate code in any sense equivalent to C at any point in the
> compilation process. Therefore GNAT is completely useless for the purposes
> of translating Ada 95 to C.

-- 
+--------------------+
|   Simon A Watts    |
| DRA Farnborough UK |
| sawatts@dra.hmg.gb |
+--------------------+

Re: ADA to C++ translator

[Darren C Davenport]

Simon A Watts wrote:
> 
> I think that the GNU Ada95 works by a translation to C (AFAIR).
> 
>

GNU Ada (aka GNAT) does not work by translation to C.

Darren

Re: ADA to C++ translator

[Kevin J. Weise]

Simon A Watts <sawatts@dra.hmg.gb> wrote (with minor deletions):
>
>I think that the GNU Ada95 works by a translation to C (AFAIR).
>
>-- 
>+--------------------+
>|   Simon A Watts    |
>| DRA Farnborough UK |
>| sawatts@dra.hmg.gb |
>+--------------------+

Well, this demon has appeared and been dispatched many times in this newsgroup.  So, 
before Dr. Dewar goes ballistic, let me respond:

You remember incorrectly.  GNAT is *NOT* and *never has been* an Ada95 to C 
translator.  The GNAT front end (written in Ada95, I might add) compiles Ada95 
source code to an intermediate representation.  The GNU back end takes the 
intermediate representation and produces *object code*.  There is also a gcc front 
end and a g++ front end (which compiles C and C++ to the same intermediate 
representation before giving it to the same backend) available from 
prep.ai.mit.edu/pub/gnu.

There is an excellent paper at cs.nyu.edu/pub/gnat that describes this process.  The 
only C code generation that takes place is during binding, which ensures that all 
the program units are properly elaborated before invoking the users' main program.

-----------------------------------------------------------------------------------
Kevin J. Weise                  email:  kweise@sed.redstone.army.mil
COLSA Corporation               voice:  (205) 842-9680
6726 Odyssey Dr.
Bldg 6260
Huntsville, AL  35806

standard disclaimers apply...

Re: ADA to C++ translator

[Simon A Watts]

Kevin J. Weise wrote:
> 
> Simon A Watts <sawatts@dra.hmg.gb> wrote (with minor deletions):
> >
> >I think that the GNU Ada95 works by a translation to C (AFAIR).
> >
> >--
> >+--------------------+
> >|   Simon A Watts    |
> >| DRA Farnborough UK |
> >| sawatts@dra.hmg.gb |
> >+--------------------+
> 
> Well, this demon has appeared and been dispatched many times in this newsgroup.  So,
> before Dr. Dewar goes ballistic, let me respond:
> 
> You remember incorrectly.  GNAT is *NOT* and *never has been* an Ada95 to C
> translator.  The GNAT front end (written in Ada95, I might add) compiles Ada95
> source code to an intermediate representation.  The GNU back end takes the
> intermediate representation and produces *object code*.  There is also a gcc front
> end and a g++ front end (which compiles C and C++ to the same intermediate
> representation before giving it to the same backend) available from
> prep.ai.mit.edu/pub/gnu.
> 
> There is an excellent paper at cs.nyu.edu/pub/gnat that describes this process.  The
> only C code generation that takes place is during binding, which ensures that all
> the program units are properly elaborated before invoking the users' main program.
> 

Would that explain the *.c files left after using GNAT under NT? I do
not use Ada, and was only trying it out with the test files with the
issue. I also (having reinstalled GNU tools) do not have it available at
this time.

> -----------------------------------------------------------------------------------
> Kevin J. Weise                  email:  kweise@sed.redstone.army.mil
> COLSA Corporation               voice:  (205) 842-9680
> 6726 Odyssey Dr.
> Bldg 6260
> Huntsville, AL  35806
> 
> standard disclaimers apply...

-- 
+--------------------+
|   Simon A Watts    |
| DRA Farnborough UK |
| sawatts@dra.hmg.gb |
+--------------------+

Re: ADA to C++ translator

[Richard Krehbiel]

In article <4sdi8k$fab@michp1.redstone.army.mil> "Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil> writes:

> Simon A Watts <sawatts@dra.hmg.gb> wrote (with minor deletions):
> >
> >I think that the GNU Ada95 works by a translation to C (AFAIR).
> >
> 
> You remember incorrectly.  GNAT is *NOT* and *never has been* an
> Ada95 to C translator.  The GNAT front end (written in Ada95, I
> might add) compiles Ada95 source code to an intermediate
> representation.  The GNU back end takes the intermediate
> representation and produces *object code*.

Well... assembly code.  :-)

But not C.
-- 
Richard Krehbiel, Kastle Systems, Arlington, VA, USA
rich@kastle.com (work) or richk@mnsinc.com (personal)

Re: ADA to C++ translator

[Jon S Anthony]

In article <31EB53A9.663E@dra.hmg.gb> Simon A Watts <sawatts@dra.hmg.gb> writes:

> > You remember incorrectly.  GNAT is *NOT* and *never has been* an Ada95 to C
> > translator.  The GNAT front end (written in Ada95, I might add) compiles Ada95
> > source code to an intermediate representation.  The GNU back end takes the
> > intermediate representation and produces *object code*.  There is also a gcc front
> > end and a g++ front end (which compiles C and C++ to the same intermediate
> > representation before giving it to the same backend) available from
> > prep.ai.mit.edu/pub/gnu.
> > 
> > There is an excellent paper at cs.nyu.edu/pub/gnat that describes this process.  The
> > only C code generation that takes place is during binding, which ensures that all
> > the program units are properly elaborated before invoking the users' main program.
> > 
> 
> Would that explain the *.c files left after using GNAT under NT? I do
> not use Ada, and was only trying it out with the test files with the
> issue. I also (having reinstalled GNU tools) do not have it available at
> this time.

You only get a C file for the generated sequence of elaboration code.
This is there so that it is easy for you to have a C main program with
Ada stuff.  From the C main you call the elaboration routine before
you call any Ada stuff.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ada to C translator

[Robert Dewar]

Polar asks:

"Can anyone give me a pointer to an Ada to C language translator that
 *supports Ada tasking*.

I am getting the impression that GNAT does not. However, I would prefer
C to C++ as that C++ would just require yet another compiler."

The comment on GNAT seems to suggest that GNAT might be an Ada to C
translator. It is most certainly nothing of the kind, it is an Ada
compiler, and no more relevant to the issue of translating Ada to C
(with or without Ada), than any other Ada compiler.

Doing an accurate translation of tasking Ada to C would be a big job,
since you would have to have a complete, and usable, version of the Ada
tasking support library written in C.

Ada to C translator

[Kevin H. Hunt x7343]

Does anyone know of a Ada to C translator?

--
Not necessarily the opinion of the company...
--
----------------------------------------------------------------------------    
Kevin H. Hunt     MESC           1313 Production RD    (219) 429-7343 Phone
MS 10-60          Fort Wayne     IN, 46808             (219) 429-5004 Fax 
We're all into carrot juice now....[JB]

Ada to C translator

[Joe Fasano]

Does anyone know where I may find an
Ada to C translator ?

Thanks,

joe
joe@veritas.com



-- 
	-------------------------------------------------------------
	joe			ARPAnet:  veritas!joe@apple.com
	joe@veritas.com		UUCPnet:  {apple,pyramid}!veritas!joe

Ada to C translator

[/2000]

Dear Ada Colleagues,

I am looking for an Ada to C translator, preferably in source form, running
on either a Sun 3, Sun 4, or PC. If would be nice if it were able to translate
full Ada, but post-editing is acceptable (to some degree). Is there anybody
out there who can point me into the right direction? Please mail me directly.

Thank you!

Job Honig,
Delft University of Technology