TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: David Harrison <[log in to unmask]>
Date: Tue, 16 Sep 1997 09:59:31 -0500
Reply-To: David Harrison <[log in to unmask]>
Parts/Attachments: text/plain (36 lines)
IMHO, translations from any one language to any other are fraught with pitfalls, not the
least of which is the translator's inability to detect bad code in the input - and we all know
"GIGO's Law".  Another pitfall is that of platform-dependency, as illustrated in the example
below.  But the biggest single objection I have to translators per se is the underlying
assumption that all languages are the same, and therefore, what is done in one must be
the same as what is done in another.
I once was called in to work on a project that involved a two-processor system.  The
system was to be coded in PLM-86. The code for the first processor was already done ,
and that for the second was not yet completed.  At this point the customer delcared that
the system must be delivered in Ada (83), and even suggested a company that
specialized in language translation technology.  The compnay was contacted, and shortly
began the delivery of working Ada code produced by the translation of the P\LM-86 input.
 This was encouraging, and they began to apply the translator to the pieces of existing
code for the second processor.  Oh, Woe! It didn't work!  What could be the matter? It
quickly came to light that the problem(s) lay in the assumption that if it worked on the
code for one, it should therefore work on the code for the second (or third, etc.)

Here's what happened:
PLM-86 used  "pointers", as does another widely-used language.  The translators
converted these to Ada address types, and went merrily on their way.  This was OK for
the first processor, as the Ada compiler vendor was implementing system'address as a
type of integer - a reasonable assumption, given that this supported arithmetic operations
on the "pointers".  And now for the tough part..... The compiler vendor for the second
processor (not the same) had - for some curious reason - chosen to implement
system'address as a string! Thus, any arithmetic operations on a "pointer", required two
conversions - EVERY TIME!  Of course, this played havoc with timing.
An even bigger problem was that variables were not defined with default values.  And the
biggest of all:  translators cannot do much about the implicit program architecture.
Inefficient structuring generated more code than could be made to fit into the limited
space available.  In short, translation COULDN'T work in this case without complete
re-thinking of the engineering approach.