Re: Win CE target

[dewarr@my-dejanews.com]

In article <6u65h0$f1b$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <EzLBxq.40n.0.-s@inmet.camb.inmet.com>,
>   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
> > We have an Ada 95 compiler that generates efficient, human-readable
> > ANSI C as an intermediate language.  Given sufficient interest, this
> > could be integrated with any ANSI C development system for "Wince"
> > to produce an Ada 95 capability.
>
> Is this the legendary "Ada to C" converter that everyone is always asking
> about? :-)


Well of course the issue is the word "readable" in Tuck's
message (some people can read things more easily than others,
after all some people think the whole of the Ada RM is quite
readable :-)

Compiling Ada by translating into C is nothing new, at least
two vendors have followed this route before. Whether IM has
somehow managed to succeed where the others failed in
producing readable code remains to be seen.

Some of the trouble areas in compiling into C are

  1. Arithmetic overflow checks, especially in complex
     expressions, which have to be broken down into steps
     or written in prefix notation.

  2. Nested procedures, and particularly nested procedures
     with complex local declarations.

  3. Subunits (hard to do anything other than create a huge
     source in which the subunits are substituted).

  4. Exceptions

Note here I am talking about readability, rather than
efficiency, although all the above are also efficiency
issues.

Of course if you write simple minded Ada that uses only
features that translate into C, then the two vendors
compilers that I have talked about in the past have
worked fine.

Note that the list above is a small one, there are many
other problems.

It is interesting in the case of GNAT and GCC, that of course
it was possible for us to translate GNAT into a form that can
be processed by the backend, but we preferred not to because
the transformations were awkward and would have intefered
with optimizations in some cases. So we enhanced the backend
for example by adding self describing types to map Ada's
variant records directly. And remember we were working not
with C, but with GNU C, which solves some of these problems

Actually if I was trying to write a translator like this, I
would certainly consider Ada to GNU C, which would be much
easier. However, that would not meet all needs (e.g. the
requirement as for the SHARC of interfacing to the vendors
proprietary C compiler).

I will say for the record, that, according to MY definition
of readability, it is not possible to translate Ada 95 into
readable C in all cases.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum