bubien@beowulf.ucsd.edu (Mark Bubien) (06/27/91)
I am working for a company which has an application program written in UCSD Pascal under the P-system. We want to convert the code to C (using the p2c utility) under Unix. Has anyone taken UCSD Pascal under the P-system and converted to some other OS (Unix, MS-DOS, etc.)? I'd really like to get in touch with someone who's done this because it's going to be a real hassle, and the more help I can get the better. Thanks Mark Bubien bubien@cs.ucsd.edu
milne@ics.uci.edu (Alastair Milne) (06/30/91)
In <21003@sdcc6.ucsd.edu> bubien@beowulf.ucsd.edu (Mark Bubien) writes: >I am working for a company which has an application program written >in UCSD Pascal under the P-system. We want to convert the code >to C (using the p2c utility) under Unix. >Has anyone taken UCSD Pascal under the P-system and converted >to some other OS (Unix, MS-DOS, etc.)? >I'd really like to get in touch with someone who's done this >because it's going to be a real hassle, and the more help >I can get the better. We recently completed a project doing this for IBM with one of our older p-System projects. Specifically, we ported it to Turbo Pascal 5.0 . There's a lot to be said about it, I think. Fortunately Turbo Pascal descends from UCSD Pascal, so there were a lot of lucky similarities. Less fortunately, they didn't include things like SEGMENT routines or UCSD's rather strange SCAN function. And whereas UCSD Pascal allows sets of up to 4070 elements (4069?) other Pascal's think they're being generous with 256. If a UCSD Pascal program was using a set to check graphics coordinates on the screen, as an example, you will either get a compiler error -- if you're lucky -- or that check will quietly start permanently returning FALSE. I think the thing that ultimately caused us the most problems is that UCSD Pascal has an EXIT(<proc-name>); construct that lets you exit only a specified distance up the call chain, rather than just locally or the whole program. We made very creative use of this in putting together a turnkey system. Turbo Pascal doesn't have it. However, you might be able to simulate it, though probably less safely, with markjmp/longjmp in C. Apart from language matters, sheer disc space becomes a potential problem. As you may know, UCSD Pascal compiles to code files typically 1/2 or 1/3 the size of the sources, both because of the great compactness of p-code (much more compact than 80*86) and the automatic dynamic linking supported for every piece of code in the system, which means library code is almost never copied into the code files of programs. From my point of view, the size of the executables when moved to DOS exploded, though I suppose a DOS programmer would think they were actually pretty good. Nevertheless, they hadn't the faintest chance of fitting in our old packaging scheme, and they also took much longer to load than the relatively tiny p-System code files had done. So I had to reorganise the internal arrangement entirely -- basically turning several programs which chained among each other to one single monolithic program. When starting to explore this, once we realised IBM was going to insist on it, I came up with a list of a number of points for the conversion of UCSD Pascal to Turbo Pascal. Now, that's not quite what you want, but perhaps in conjunction with a list of differences between Turbo Pascal and C, it would produce something workable. I can e-mail you that list if you want. Be warned, though, it assumes familiarity with UCSD Pascal. On the encouraging side, I can tell you the ported version of the program is out and being marketed by IBM. Alastair Milne Educational Technology Center, U. Calif. Irvine Internet: milne@ics.uci.edu BITNet: AMILNE@UCI