PLI to C processor? 
Author Message
 PLI to C processor?

Hello,

is there any processor or cross compiler available which could help us
to automatically (to a certain degree) translate PLI-sources into
C-code?

Best regards

Tanyew Meichner
Munich
Germany



Tue, 12 Apr 2005 00:36:41 GMT  
 PLI to C processor?
See the DMS Software Reengineering Toolkit.
http://www.semdesigns.com/Products/Services/LegacyMigration.html.

--
Ira D. Baxter, Ph.D., CTO   512-250-1018
Semantic Designs, Inc.      www.semdesigns.com


Quote:
> Hello,

> is there any processor or cross compiler available which could help us
> to automatically (to a certain degree) translate PLI-sources into
> C-code?

> Best regards

> Tanyew Meichner
> Munich
> Germany



Tue, 12 Apr 2005 01:34:21 GMT  
 PLI to C processor?
A friend of mine who used to program in PL/I a while back told me that a
company called
Datatek, converted alot of their PL/I to C.  There are a couple of Datateks
out there, but he thought the link was www.datatek-net.com.  If that's not
it, might want to try variations on the same name or check a search engine.


Quote:
> Hello,

> is there any processor or cross compiler available which could help us
> to automatically (to a certain degree) translate PLI-sources into
> C-code?

> Best regards

> Tanyew Meichner
> Munich
> Germany



Mon, 25 Apr 2005 12:55:18 GMT  
 PLI to C processor?

Quote:


> > Hello,

> > is there any processor or cross compiler available which could help us
> > to automatically (to a certain degree) translate PLI-sources into
> > C-code?

> > Best regards

> > Tanyew Meichner
> > Munich
> > Germany

The DMS Software Reengineering Toolkit is generalized compiler technology
used to parse/analyze/transform/prettyprint large scale software sources.
It could be used to do this.   We have a production C front/backend,
and a draft PL/1 front end, so much of the work is done.
What is left is to write a map of transforms.
Using DMS, we have successfully automatically translated other languages on
scale (350K SLOC)
to C with about 3% breakage.

See http://www.semdesigns.com/Products/Services/LegacyMigration.html

--
Ira D. Baxter, Ph.D., CTO   512-250-1018
Semantic Designs, Inc.      www.semdesigns.com



Tue, 26 Apr 2005 12:11:06 GMT  
 PLI to C processor?
The challenge is that the storage models are so different in PL/I and C. As
someone who has a great deal of experience programming in both languages, I
don't see how you would translate up-level references by PL/I internal
procedures to the automatic variables of the containing blocks.  ANSI C has
neither up-level references nor nested scoping of procedures.  (Now, some C
compilers, GCC among them, have some interesting extensions, but this is by
no means common, and AFAIK is certainly not available in ANSI C).  When you
add varying strings, bit strings, and other features unique to PL/I,
automatically converting it to another language is a difficult problem.  We
wrote up some test cases and sent them off to a company that claims to offer
PL/I to C conversions but couldn't get them to run them thru their package
for us.  My gut feeling is that the best you can do is convert the common
subset of PL/I and C code (e.g., the fortran subset), but that's hardly
worth it.

In general, I think an organization is better off staying with their
existing programming languages as long as possible. I think the litmus test
for re-engineering an application package should be whether it meets the
current needs of the enterprise. At the point where an application package
no longer needs the current (or future) needs, it should be redesigned and
reimplemented using current tools and techniques.  The trick is that many
organizations have so many applications that such work has to be done piece
by piece.  We have plenty of techniques for hooking up components written in
one language with components written in another language that there need be
no barrier to the choice of language when a new piece is created.

Here at Stratus we can (and do) mix and match PL/I and C code.  We added a
char_varying datatype to C to make this job easier, but most of the credit
goes to the compiler designers who allow PL/I and C programs to call each
other in a natural and simple manner.

PG
--
Paul Green, Senior Technical Consultant, Stratus Computer.
Voice: +1 978-461-7557; FAX: +1 978-461-3610
Speaking from Stratus not for Stratus


Quote:
> A friend of mine who used to program in PL/I a while back told me that a
> company called
> Datatek, converted alot of their PL/I to C.  There are a couple of
Datateks
> out there, but he thought the link was www.datatek-net.com.  If that's not
> it, might want to try variations on the same name or check a search
engine.



> > Hello,

> > is there any processor or cross compiler available which could help us
> > to automatically (to a certain degree) translate PLI-sources into
> > C-code?

> > Best regards

> > Tanyew Meichner
> > Munich
> > Germany



Sat, 07 May 2005 00:21:48 GMT  
 PLI to C processor?

Quote:
> The challenge is that the storage models are so different in PL/I and C.
As
> someone who has a great deal of experience programming in both languages,
I
> don't see how you would translate up-level references by PL/I internal
> procedures to the automatic variables of the containing blocks.  ANSI C
has
> neither up-level references nor nested scoping of procedures.

To translate "up-level" references you "simply" need to recognize
that a language with lexically-nested scoping rules can be simulated
by one without (after all, assembler is used to simulate PL/1,
and C is just high level assembler).    So the same techniques
used to implement block structure in assembler can be used
to implement scope structures in C.

The essential idea is to declare a C struct ("local struct") for each set of
local variables
that can be referenced by more deeply nested lexical procedures,
with an additional pointer slot I call "parent" that will always
points to the struct for the lexically enclosing procedure.
The local-struct must be instantiated
as a local variable in the C subroutine simulating the PL/1 subroutine.

When one PL/1 subroutine calls another, the lexical context
(a pointer to the instantiated locals struct) has to be passed
as an extra argument to the callee,
and stored by the called subroutine in its locals-struct,
thus creating a dynamic uplevel reference chain.
References to "up-level" variables are turned into
C access paths of the form
      locals.parent->parent->parent->...->variable.
[There are various optimizations of all this,
but this is enough to get the basic idea across].
This is essentially the trick used by the PL/1 generated assembly
code, and is well understood by compiler builders.

I'll agree it isn't the prettiest thing in the world,
but it isn't the ugliest, either.

So the hard part is really parsing the PL/1, and determining
which references are up-level references.   This amounts
to name and type resolution, which you essentially have to do
to translate PL/1 (or any other language) sensibly anyway.

Quote:
>  (Now, some C
> compilers, GCC among them, have some interesting [scoping] extensions,

This makes it easier, but doesn't change the fundamentals.
The only question is who organizes the passing around the dynamic
lexical scope pointers, the GCC compiler or a translator.

Quote:
>When you
> add varying strings, bit strings, and other features unique to PL/I,
> automatically converting it to another language is a difficult problem

While we don't claim to offer a PL/1 to C conversion tool at this point,
we don't see any fundamental problems to doing it
(other than sweat, lots of it.to implement such things as above,
and perhaps less sweat than you might expect if you have
the right translation infrastructure).
We've translated other complex languages (such as JOVIAL, see slides at
http://www.semdesigns.com/Products/Services/LegacyMigration.html).

Quote:
> In general, I think an organization is better off staying with their
> existing programming languages as long as possible. I think the litmus
test
> for re-engineering an application package should be whether it meets the
> current needs of the enterprise. At the point where an application package
> no longer needs the current (or future) needs, it should be redesigned and
> reimplemented using current tools and techniques.

I agree that organizations should stay with the existing language
as long as possible.

I don't agree that the organization should then necessarily rewrite
from scratch or replace (if this is The Right thing, then sure).
But what often happens is the "rewrite" effort is so big,
that the organization cannot afford to do it [time/dollars/management
reward].
More importantly, when you "rewrite", your programmers always fail to
look at what the current application is doing carefully,
and so they fail to implement all the details that made
it so successful.  So you not only get a rewrite,
but you also get a downstream rediscover-and-reimplement
all that lost knowledge, and in the meantime, the application
isn't doing its job well.    If this scenario is not good for you,
then translation is worth considering.  YMMV.

[Yes, we're interested in translation services.
No, I don't want to do it or push it on an organization
that has a better way out.]

--
Ira D. Baxter, Ph.D., CTO   512-250-1018
Semantic Designs, Inc.      www.semdesigns.com



Sun, 08 May 2005 01:39:48 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. PLI to Fortran processor

2. to CS: or not to CS: in F-PC assembler

3. VisualAge PLI Enterprise vs. VisualAge PLI Personal

4. PLI-32 Alpha 3.10 (Single message ZIP file (30K)) - pli-32.zip (0/1)

5. PLI-32 Alpha 3.10 (Single message ZIP file (30K)) - pli-32.zip (1/1)

6. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (10/10)

7. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (06/10)

8. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (05/10)

9. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (09/10)

10. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (01/10)

11. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (04/10)

12. PLI-32 For NT, alpha 3.10 (ZIP File: 378K] - pli-32.zip (00/10)

 

 
Powered by phpBB® Forum Software