Re: PLI to Fortran processor

[... a discussion started in comp.lang.pl1...]


"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:a0in8a$1f6@gap.cco.caltech.edu...
> "Ira D. Baxter" <idbaxter@semdesigns.com> writes:
>
> >Close syntax" isn't a good argument (for FORTRAN being a good PL/I
translation target).
> >As a builder of professional translation systems,
> >I find the problem of building a translator is driven much more
> >by the language semantics (PL/1 is really complex),
> >how macros are used (and how to translate them),
> >what (application) libraries are used by the code, ....
>
> How hard is it to write a PL/I parser, compared to other
> languages. PL/I is pretty complex, but using parser
> generators should help a lot.


Right. In fact, we have a draft PL/I parser, based on our own parser
generators. That's rather the easy part.


> The preprocessor can be done as a completely separate pass (slower,
> but probably better and easier to debug).


Building this is a pain. It is completely specific to PL/I and
therefore completely custom.. (We haven't done this for PL/I; but the
ones we have done for C/C++ and JOVIAL taught us a lot). And if you
are translating somebody's source code, you have a worse
problem... they really don't want you simply expand every preprocessor
directive in the translated result. (Imagine removing the platform
dependency conditionals from a piece of C code: the translated result
is now platform-specific). So now you have a much more complicated
preprocessor than the PL/I compiler guys face... it has to be able to
act as a preprocessor (so you can check its accuracy), and it has to
be able to "not expand" so there is something to try and translate.


Often these macros/preprocessor directives are not on "neat" language
boundaries; consider the C example:
              #define BEGIN { int counter;"
And some macros simply won't translate.


So now the macro processor has to conditionally expand a macro,
depending on whether it is translatable or not. (We do a good part of
this in our JOVIAL to C translator). This is a lot harder than one
thinks. (Macros makes FORTRAN a truly lousy target, because with no
preprocessor of its own, you can hardly translate even easy macros to
it).


> The library is much more complicated than most other languages, too.
> Much more math library than even Fortran, plus bit and character
> strings.


We agree on the *scale* of the runtime library, but there isn't much
hard about this, just lots of sweat. My comment is about the language
semantics itself: what are the variable-name scoping rules? How do
exceptions work? How does one implement "resume"? Tasking? These
generally require low-level machine code support that is hard to coax
another language into producing effectively, especially if you insist
that the generated code be sort of readable. Of course, you might
resort to bits of assembler on the target platform, but now your
translator is only good for that target.


Secondly, most application programs use some 3rd party library
(databases, GUIs, storage management packages, you name it), and when
translating the application, there has to be some effectively
equivalent replacement. Each customer chooses a different target
platform and set of 3rd party support libraries, which means the
translation depends on the customer choices (and can be easier or
harder for exactly that reason).


> Then there is the code generator for the large variety of data types
> that PL/I has, which may or may not match well with the hardware.
> (Decimal is hard on some machines, though still possible on many.)


This is just more sweat (although the cross product of pairs of
operands for PL/I seems pretty painful). (It is possible and even
straightforward to "do decimal" on any machine; especially if you have
bitwise boolean operators in the target language, that's the least of
the problems).


-- IDB
[I agree that the semantics are the issue. In the late 1960s I used a
Fortran to PL/I translator that IBM provided for its mainframe
systems. The code bloat was huge due to relatively minor semantic
differences between similar Fortran and PL/I constructs that required
lots of arcane PL/I code to implement Fortran details that the
programmer more often than not didn't even care about. -John]

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