🚀 go-pugleaf

In article <id.OCRS.SBE@ferranti.com>, kunkee@ferranti.com (randy kunkee) writes:
|> In article <MAYER.92Aug26102743@porky.sono.uucp> mayer@sono.uucp (Ron Mayer) writes:
|> >Yeah, me too.  Unless you have a huge codebase of existing PL/M code
|> >which needs to be maintained, I'd _strongly_ recommend switching to C
|> >(or c++, fortran, lisp, forth, teco, assembly language, or anything
|> >but PL/M (1/2 :-)).
|> >
|> 
|> Ditto for us.
|> 

AMEN TO THIS!  There is no reason to begin a new development effort in PL/M

|> >
|> >Also, on a similar subject, has anyone had any experience with any of
|> >these things, could you let me know your opinions of them:
|> >
|> >    The plm front end for GCC supposedly being developed by someone at
|> >    the "Technical Research Centre of Finland, Laboratory for
|> >    Information Processing (VTT/TIK)"
|> >
|> >    The PL/M-86 to C converter by
|> >    "Micro-Processor Services, Inc.; (516) 499 4461"
|> >
|> >
|> >    Ron Mayer
|> >    mayer@acuson.com
|> 
|> 
|> I've spoken to the MPS folks, and decided that our PLM code was too
|> idiosyncratic to work well with them.  We have Robert Ankeney's
|> translater and will be enhancing it ourselves to translate PLM to C.
|> Still, if your PLM is not very convoluted, MPS might work well.  We
|> just had some different ideas about how things should be done.
|> 

We tried the MPS product on our "well maintained" PL/M code.  As Randy
suggests the translator didn't work that well due to the clever hacks
which we have been done to our code over the years.  We also tried Robert
Ankeney's PD translator.... it dumped core on the same test cases!!

In the end we choose to stick with the MPS product.  They have been
helpful to us by making some changes to the translator to help in our
conversion.  For a lot of things it does a good job. Still, there are some changes which need to be made either pre or post conversion.  After looking at the PD converter sources it will be easier for us to whip up a simple pre/post processor....at least for our code.

Carl Symborski