NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C 
Author Message
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

A new method for converting PL/1 source materials into professional quality C
code has been developed by Symbolic Mechanics of Massachusetts. (508)643-9407

The purpose of this announcement is to request small amounts of PL/1 source

Please send nothing proprietary or otherwise confidential.

PL/1 programs of less than 100 lines will be converted to C and returned to
the original recipient.  As the expression goes, please allow 3-4 weeks for
delivery.

These programs, presumably prepared from different sources and employing
differing coding methodoligies should be very useful.

Thanks,
Jules Gilbert



Sat, 15 Mar 1997 06:22:11 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

: > ---PL/I can't be translated to C, because C is a very small subset of the
: > facilities offered by PL/I.  In other words, C lacks the facilities and the
: > support facilities that PL/I offers and needs.

: Which facilities are you thinking of? I don't know whether standard PL/1
: contains concurrency - that would need some library support - but other-
: wise I think it's feasible even in a quite portable manner. Whether it's
: worth the time and efficient enough is hardly decidable in general; that
: depends on the exact circumstances.

Dec's Modula-3 compiler translates to C as an intermediate language.
So this kind of thing can be done, but I am not sure you want to read the
resulting C code or call it 'maintainable'.

BTW, is I recall PL/M as being PL/1 for Microcomputers (or was it
Minicomputers).  Does anyone know if this is true?  Also, does anyone
have a good book/descitption of PL/M?

thanks

: ------------------------------------------------------------------------------
:    *   wonder everyday   *   nothing in particular   *   all is special   *



Sat, 05 Apr 1997 23:14:35 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

Quote:


>    A new method for converting PL/1 source materials into professional quality C
>    code has been developed by Symbolic Mechanics of Massachusetts. (508)643-9407

>---PL/I can't be translated to C, because C is a very small subset of the
>facilities offered by PL/I.  In other words, C lacks the facilities and the
>support facilities that PL/I offers and needs.

>   As has been pointed out by others, such a project [PL/I to C] was abandoned
>as a waste of time, and instead, a PL/I compiler was written instead.  It's
>now available on Unix systems . . .

>   PL/I is also available on the PC.

You read a liitle too far in my story.  Yes, we abandoned the translation
approach, but it was not because it was not possible.  Rather it was because
the particular translation was incorrect and inefficient.  It is perfectly
possible to develop a translator that will do 100% translations with minimal
overhead.  It would not be easy, plus the resulting code would not be
maintainable.  We opted for a compiler because it existed, and would
give us the breathing room in order to do a rewrite  of the project in C.

Regards.
-----------------------------------------------------------------------
        Gary Gendel                     Vice President

        9 Piney Woods Drive             phone:  (908) 281-0164
        Belle Mead, NJ 08502-1109       fax:    (908) 281-9607
-----------------------------------------------------------------------



Sat, 05 Apr 1997 22:34:30 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

Quote:

> Dec's Modula-3 compiler translates to C as an intermediate language.

This isn't true any more; now it uses a modified GCC backend, and it would
be unfair to classify this as C (though some properties of C probably have
an influence on its general design).

Quote:
> So this kind of thing can be done, but I am not sure you want to read the
> resulting C code or call it 'maintainable'.

I'd even guess you could make it quite readable and maintainable for large
amounts of code - though "esoteric" features (from a C viewpoint) would be
implemented via function calls and/or macros.

(At work I'm programming in PL/I now and then, and privately I'm currently
working on an Oberon-2 to GNU-C translator; thus I've pondered these tings
for some time ;-)

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *



Sun, 06 Apr 1997 02:47:41 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

[GCC backend]

Quote:
> It's probably best to classify it as annotated-lisp.

I wouldn't say so, just because it uses something like s-expressions as
external representation - that's like comparing Chinese texts with APL,
just because both looks cryptic to me ;-)

Quote:
> It would be interesting to see how you'd implement multiple entry points or
> PL/I traps.

I don't remember exactly what traps are; we're only using PL/1 to write
subprograms for a 4GL. Does that refer to interrupt handling? Maybe you
could write a short example showing the essential functionality.

Depending on the surrounding code, one could implement MEPs either as a
set of functions which call one big function doing the whole work, or a
set of functions which contain the appropriate subset of the code. When
the "one big worker" approach is choosen, have the caller store all the
arguments in a struct which contains slots for all possible parameters,
ignoring those which aren't used for the particular entry point. That's
probably quite easy for the cases where I'd consider using MEPs as "not
too ugly to be banned in the first place", anyway, and there's no point
trying to generate beautiful C code for something that's already a mess
in PL/1 ;-)

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *



Sun, 06 Apr 1997 05:16:31 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

Quote:


>> Dec's Modula-3 compiler translates to C as an intermediate language.
>This isn't true any more; now it uses a modified GCC backend, and it would
>be unfair to classify this as C (though some properties of C probably have
>an influence on its general design).

It's probably best to classify it as annotated-lisp.

Quote:
>> So this kind of thing can be done, but I am not sure you want to read the
>> resulting C code or call it 'maintainable'.
>I'd even guess you could make it quite readable and maintainable for large
>amounts of code - though "esoteric" features (from a C viewpoint) would be
>implemented via function calls and/or macros.

It would be interesting to see how you'd implement multiple entry points or
PL/I traps.
--

int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}


Sun, 06 Apr 1997 03:40:53 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

Quote:


>> It would be interesting to see how you'd implement multiple entry points or
>> PL/I traps.
>I don't remember exactly what traps are; we're only using PL/1 to write
>subprograms for a 4GL. Does that refer to interrupt handling? Maybe you
>could write a short example showing the essential functionality.

Yeah, interrupts (traps, interrupts, signals, exceptions, whatever :-).  In
PL/I you can give the statement:

        ON OVERFLOW BEGIN;
        ...
        END;

To have the statements between the BEGIN...END executed when an
overflow occurs.  Now besides the problem that C doesn't have a signal for
integer overflow, the statements between BEGIN and END have the same scoping
level as the proceedure the ON is in.  For example:

foo:    proc;
        dcl i init(0);
        on overflow
                begin;
                i=10;
                end;
        call bar;
        put list ('Return status',i);
        end;

If an overflow occurs in 'bar', 'i' gets set to 10 and bar continues.

You could perhaps handle this in C; but it would not be pretty.  You could
make 'i' a global variable: but only if you don't have a PROC RECURSIVE.
You could make a bunch of global variables which contain the addresses of
all the local variables which are accessed in the block for the signal
handler.  To complicate matters further, there can be GOTOs in the ON block.
This means that there has to be a switch(setjmp(&jmpbuf)) { case n: goto
...; ... } in place of the ON and the 'jmpbuf' also has to be stackable and
accessable by the signal handler.

It could be done, but it's a mess.  If C allowed you to declare functions
inside of functions, this would work a lot better.  I think GNU C has such
an extension to C...

Quote:
>Depending on the surrounding code, one could implement MEPs either as a
>set of functions which call one big function doing the whole work, or a
>set of functions which contain the appropriate subset of the code. When
>the "one big worker" approach is choosen, have the caller store all the
>arguments in a struct which contains slots for all possible parameters,
>ignoring those which aren't used for the particular entry point. That's
>probably quite easy for the cases where I'd consider using MEPs as "not
>too ugly to be banned in the first place", anyway, and there's no point
>trying to generate beautiful C code for something that's already a mess
>in PL/1 ;-)

Another fun thing to implement is asynchronous tasks (in PL/I:
call foo(...) task(...);) Your C needs to run on a machine with threads.
--

int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}


Sun, 06 Apr 1997 09:39:31 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

[implementing conditions]

Quote:
> To have the statements between the BEGIN...END executed when an
> overflow occurs.  Now besides the problem that C doesn't have a signal for
> integer overflow,

Yes, checking that will be a source of ineffiency (though I'd guess that in
many cases you could switch checking off without problems).

Quote:
> To complicate matters further, there can be GOTOs in the ON block.
[...]
> It could be done, but it's a mess.

I agree that the general case would look very ugly. However, I'd think that
there would be a few common cases which can be recognized, and handled in a
less general but more readable form. For example, use simple functions with
a static link for condition handlers which always continue, and longjmp for
escape-only cases. With (more or less) global analysis it would probably be
possible to recognize several usual patterns which don't need fully general
treatment, and I'd guess that the rest wouldn't be very common either. As I
said, I'd only expect readable code for a large amount of programs, not for
all. (If one gives up the goal of readability, it would be worth looking at
a Lisp/Scheme to C compiler; closures, non-local exits, unwind-protect, and
Scheme's call-with-current-continuation should yield sufficient information
about implementation methodologies for sequential control structures.)

Quote:
> If C allowed you to declare functions
> inside of functions, this would work a lot better.  I think GNU C has such
> an extension to C...

Yes, and a goto from (statically) nested functions to outer ones, too. That
would help enormously.

Quote:
> Another fun thing to implement is asynchronous tasks (in PL/I:
> call foo(...) task(...);) Your C needs to run on a machine with threads.

Of course, a runtime library would certainly be needed for this.

No, I wouldn't want to write such a translater (not liking PL/1 much in the
first place), and it would surely be a lot of work ;-)

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *



Mon, 07 Apr 1997 04:05:57 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

        A new method for converting PL/1 source materials into professional quality C
        code has been developed by Symbolic Mechanics of Massachusetts. (508)643-9407

---PL/I can't be translated to C, because C is a very small subset of the
facilities offered by PL/I.  In other words, C lacks the facilities and the
support facilities that PL/I offers and needs.

   As has been pointed out by others, such a project [PL/I to C] was abandoned
as a waste of time, and instead, a PL/I compiler was written instead.  It's
now available on Unix systems . . .

   PL/I is also available on the PC.



Sat, 05 Apr 1997 11:57:32 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

Quote:

> ---PL/I can't be translated to C, because C is a very small subset of the
> facilities offered by PL/I.  In other words, C lacks the facilities and the
> support facilities that PL/I offers and needs.

Which facilities are you thinking of? I don't know whether standard PL/1
contains concurrency - that would need some library support - but other-
wise I think it's feasible even in a quite portable manner. Whether it's
worth the time and efficient enough is hardly decidable in general; that
depends on the exact circumstances.

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *



Sat, 05 Apr 1997 16:33:28 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C


Quote:



>>> It would be interesting to see how you'd implement multiple entry points or
>>> PL/I traps.

Yes, it is interesting.  C doesn't have any *efficient* way to deal with
numeric overflows, while allowing the program to remain in control, so,
not surprisingly, neither does the gcc back end.  But typical hardware
does.

However, the GNAT project (the GNU Ada compiler being done at NYU) has
the same problem, since Ada has something similar to PL/I traps --
exceptions.  I believe they are extending the gcc back end to deal with
the issue, and the new code will be part of the standard gcc (as will
the Ada front end).  I don't know if their extensions will be sufficient
to handle PL/I -- PL/1 is a bit more general (and more trouble for
compilers), in that exception handlers can jump back to the offending
code.  And (I think) handlers can be attached more dynamically.

Note that the latest version of C++ is also adding exceptions, with
similar capabilities to the Ada feature.

- Bob

P.S. The Ada 9X Reference Manual is available via anonymous ftp from
ajpo.sei.cmu.edu in /public/ada9x/rm9x.  Check out the Rationale first
-- the Reference Manual itself is a bit dense.
--

Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)



Sun, 06 Apr 1997 10:29:10 GMT  
 NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

Quote:

>---PL/I can't be translated to C, because C is a very small subset of the
>facilities offered by PL/I.  In other words, C lacks the facilities and the
>support facilities that PL/I offers and needs.

If PL/1 can't be translated to C, because "C lacks the facilities ... PL/1 ...
needs", then how are you going to compile it to assembler or machine code?
You can't have it both ways!
--
 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 300 5011

 ...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 300 5235
                    HI-TECH C: Compiling the real world...


Sat, 05 Apr 1997 14:15:19 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. NEW PL/1 COMPILER and SOURCE TRANSLATOR TO C

2. PL/M-C source translator ?

3. Open Source PL/1 Compilers?

4. Source code for PL/C (or any Subset G) compiler

5. Looking for PL/I source for GAUSS compiler

6. New PL/I Compiler announced today

7. IBM announces a new PL/I compiler version

8. New PL/I compiler for OS/390

9. PL/I - new IBM compiler for MVS ...

10. source-to-source translators

11. PL/I (was: IBM Needs to seed the PL/I Compiler)

12. New PL/I or Old working PL/I releases

 

 
Powered by phpBB® Forum Software