home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / intel / 1626 < prev    next >
Encoding:
Text File  |  1992-09-01  |  2.5 KB  |  60 lines
  1. Newsgroups: comp.sys.intel
  2. Path: sparky!uunet!van-bc!rsoft!agate!iat.holonet.net!uupsi!psinntp!hns!symborski
  3. From: symborski@hns.com (Carl Symborski)
  4. Subject: Re: PLM programming query
  5. Message-ID: <1992Aug31.180059.13941@hns.com>
  6. Sender: news@hns.com (USENET news system)
  7. Organization: Hughes Network Systems Inc.
  8. References: <1992Aug26.093356.6125@canon.co.uk> <MAYER.92Aug26102743@porky.sono.uucp> <id.OCRS.SBE@ferranti.com>
  9. Distribution: hns
  10. Date: Mon, 31 Aug 1992 18:00:59 GMT
  11. Lines: 47
  12.  
  13. In article <id.OCRS.SBE@ferranti.com>, kunkee@ferranti.com (randy kunkee) writes:
  14. |> In article <MAYER.92Aug26102743@porky.sono.uucp> mayer@sono.uucp (Ron Mayer) writes:
  15. |> >Yeah, me too.  Unless you have a huge codebase of existing PL/M code
  16. |> >which needs to be maintained, I'd _strongly_ recommend switching to C
  17. |> >(or c++, fortran, lisp, forth, teco, assembly language, or anything
  18. |> >but PL/M (1/2 :-)).
  19. |> >
  20. |> 
  21. |> Ditto for us.
  22. |> 
  23.  
  24. AMEN TO THIS!  There is no reason to begin a new development effort in PL/M
  25.  
  26. |> >
  27. |> >Also, on a similar subject, has anyone had any experience with any of
  28. |> >these things, could you let me know your opinions of them:
  29. |> >
  30. |> >    The plm front end for GCC supposedly being developed by someone at
  31. |> >    the "Technical Research Centre of Finland, Laboratory for
  32. |> >    Information Processing (VTT/TIK)"
  33. |> >
  34. |> >    The PL/M-86 to C converter by
  35. |> >    "Micro-Processor Services, Inc.; (516) 499 4461"
  36. |> >
  37. |> >
  38. |> >    Ron Mayer
  39. |> >    mayer@acuson.com
  40. |> 
  41. |> 
  42. |> I've spoken to the MPS folks, and decided that our PLM code was too
  43. |> idiosyncratic to work well with them.  We have Robert Ankeney's
  44. |> translater and will be enhancing it ourselves to translate PLM to C.
  45. |> Still, if your PLM is not very convoluted, MPS might work well.  We
  46. |> just had some different ideas about how things should be done.
  47. |> 
  48.  
  49. We tried the MPS product on our "well maintained" PL/M code.  As Randy
  50. suggests the translator didn't work that well due to the clever hacks
  51. which we have been done to our code over the years.  We also tried Robert
  52. Ankeney's PD translator.... it dumped core on the same test cases!!
  53.  
  54. In the end we choose to stick with the MPS product.  They have been
  55. helpful to us by making some changes to the translator to help in our
  56. 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.
  57.  
  58. Carl Symborski
  59.  
  60.