Re: 386 (commercial) back-end needed

Hi all,
Sorry for following up on my own thread. The reason to react is that I got
several reactions sugesting to translate CHILL to C, the moderator has even
added a footnote in that sense. In order to save you typing I would like to
clarify what I already did in that direction and why I abandoned it, a few
years ago (I've spent 3 months on it as a background job). I never cared to
put any results on paper so I'm working from my recollection.


In my first posting I was not clear on UNIX question.
    - We want the compiler to run on UNIX
    - the target board runs our own OS, Data Base and Communication handler


So if you have sugestions how to solve any of our problems, we can
make a second attempt. Perhaps some of you can benefit from our experience, as
well.


problem 1 : (unresolved up to now)
    Our implementation of CHILL allows us to have multiple processes (threads)
    within one module. There is a 'supervisor' and he can instantiate dynamicaly
    'application' threads. The supervisor can't access data of the applications,
    applications can access data of the supervisor.
    To acheive this we place all supervisor's global data into the data segment,
    and allocate a private stack segment for non-global data of the supervisor.
    The application process places all its data global and non-global onto its
    stack, and gets access to the supervisors data segment.
    Our context extractors and checkers mandate that the two application and
    supervisor are in the same source.
    The problem is that we don't see a way to impose a C compiler to make a
    distinction between global data of the supervisor and the application part,
    and we found no way to force the use of two different stacks for the
    supervisor and the application (to allow dynamic instantiation).
    Sounds confusing, but I don't know how to explain it better.


problem 2: (unresolved up to now)
    The aim is that the programmers when debugging are not confronted with
    generated (difficult to read (goto's criptic labels, ...)) C code when
    debugging. We don't want whiz-kids to start manipulating the intermendiate
    C code, because this will remove the link between the original source code
    and the delivered executable.


problem 3 : (unresolved up to now)
    How do we debug such a CHILL to C convertor? CHILL is a very complex (some
    say rich) language. It wil take forever before we have debugged our convertor.
    Programmers will always blame the convertor first, putting the burden of
    proof on our shouldes, taking into account the fact that the genreated code
    will be hard to read, ...


problem 4 : (unresolved up to now)
    Over time some particularities (some say semantic deviations) have creeped in.
    We must preserve these sometimes (badly documented) 'features'. Converting
    them to C will be very hard.


problem 5 : (hard to solve)
    CHILL has a 'DO WITH' statement, equivalent to WITH .. DO in PASCAL. They can
    be nested. A translator would have to parse and treat the declarations in
    order to be able to generate C.


problem 6 : (partialy solved hard part unsolved)
    CHILL can impose local packing of non-homegenious bit fields and ranges.
    Making the declarations work was hard but can be done, for assignments and
    compile time checking of type compatibility and range checking requires
    full parsing.


problem 7 : (unsolved but less important?)
    CHILL has NEWMODE and SYNMODE (derived mode). C has no equivalent for that.
    I was planning to use #define <synmode> <newmode>. This is not exact but
    gives a good aproximation.


problem 8 : (soved but I'm not pleased with outcome)
    CHILL allows for nested procedures and declarations. C is flat. I tried two
    approaches to solve it.
    1. Prepend a program generated prefix to each nested declaration and provide
          a XREF (both way) to obtain full nesting names. The C code was unreadble,
          even to me, so I saw no way to debug my name convertor and XREF table, in
          a reasonable time.
    2. Check for duplicate names when flattening. Where found apply approach 1.
          Make everything flat for code generation. Chop into separate compilation
          blocks (with emty procedures) to verify scoping. (At that time no ANSI
          C compiler with prototypes was available to me). I even considdered
          using the CHILL compiler to chek the source and throw away its code, just
          retain the error and warning messages.


problem 9 : (could (?) get solved when C compilers become better)
    The generated C code was very far from optimal. I doubt that any compiler
    can pull it straight again. Too many intermediate variables with long lives
    needed to be introduced, assignments and usage were very dispersed.


When using a intermediate compiler output, all of the problems above will be
solved. However I'm aware that the back-end approach has problems as well :


problem 1 :
    As our back-end supplier would have to adapt to new requirements comming
    from his front-end he could select to enhance his intermediate format. We will
    have to follow.


problem 2 :
    As our back-end supplier would have to adapt to new processor families he
    might be forced to modify the intermediate format and its semantics.


problem 3 :
    Undoubtfully our front-end makes some assumptions on the behaviour of our
    back-end. Some times we have solved typical front-end problems in our
    back-end because it seemd easier at that time. I'm convinced that there are
    (many) such dependencies that we are not aware of.


I'm very pleased to get a lot of email reactions, thanks to all that have
reacted. We will reply to all that have sent us sugestions or offers.


bero.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.