|386 (commercial) back-end needed email@example.com (1995-11-28)|
|Re: 386 (commercial) back-end needed firstname.lastname@example.org (1995-11-30)|
|From:||email@example.com (B Brekalo)|
|Organization:||Alcatel Bell Telephone, Antwerp, Belgium|
|Date:||Thu, 30 Nov 1995 09:59:08 GMT|
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
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
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.
Return to the
Search the comp.compilers archives again.