Remember PL/M? 
Author Message
 Remember PL/M?

I've been given the "opportunity" to maintain a large (78,000 lines)
project written in PL/M. I don't have a PL/M compiler/development
system, nor do I even have any documentation on the syntax of the PL/M
language. Hence my post here...

The long term plan is to buy a PL/M to C translator, and redo the whole
thing in C, but for immediate bug fixes, I need to find a way to build
he PL/M code. The company we bought this product from did all their
development on VAX's, and we're running PC's with WIN95/98, so we can't
use their development tools...

Is there anybody out there that would like to get rid of some PL/M
documentation, and/or some PL/M development tools. The tools would need
to run on a Win95 (or DOS) box. I'd also appreciate any ideas on where
to look for resources.

Thanks for any help, or ideas!

Hank Schnieder
Wulfsberg Electronics




Fri, 19 Apr 2002 03:00:00 GMT  
 Remember PL/M?

Quote:

> I've been given the "opportunity" to maintain a large (78,000 lines)
> project written in PL/M. I don't have a PL/M compiler/development
> system, nor do I even have any documentation on the syntax of the PL/M
> language. Hence my post here...

What about a PL/I compiler?  There's IBM's for OS/2 and Windows
compilers, and there's DR PL/I for DOS.
Quote:
> The long term plan is to buy a PL/M to C translator, and redo the whole
> thing in C, but for immediate bug fixes, I need to find a way to build
> he PL/M code. The company we bought this product from did all their
> development on VAX's, and we're running PC's with WIN95/98, so we can't
> use their development tools...

> Is there anybody out there that would like to get rid of some PL/M
> documentation, and/or some PL/M development tools. The tools would need
> to run on a Win95 (or DOS) box. I'd also appreciate any ideas on where
> to look for resources.

> Thanks for any help, or ideas!

> Hank Schnieder
> Wulfsberg Electronics





Fri, 19 Apr 2002 03:00:00 GMT  
 Remember PL/M?
I may be wrong, but I'm pretty sure that PL/1 is a completely different
language than PL/M. But I'll check on it...

Thanks

Hank

Quote:


> > I've been given the "opportunity" to maintain a large (78,000 lines)
> > project written in PL/M. I don't have a PL/M compiler/development
> > system, nor do I even have any documentation on the syntax of the PL/M
> > language. Hence my post here...

> What about a PL/I compiler?  There's IBM's for OS/2 and Windows
> compilers, and there's DR PL/I for DOS.

> > The long term plan is to buy a PL/M to C translator, and redo the whole
> > thing in C, but for immediate bug fixes, I need to find a way to build
> > he PL/M code. The company we bought this product from did all their
> > development on VAX's, and we're running PC's with WIN95/98, so we can't
> > use their development tools...

> > Is there anybody out there that would like to get rid of some PL/M
> > documentation, and/or some PL/M development tools. The tools would need
> > to run on a Win95 (or DOS) box. I'd also appreciate any ideas on where
> > to look for resources.

> > Thanks for any help, or ideas!

> > Hank Schnieder
> > Wulfsberg Electronics





Mon, 22 Apr 2002 03:00:00 GMT  
 Remember PL/M?

Quote:

>> I've been given the "opportunity" to maintain a large (78,000 lines)
>> project written in PL/M. I don't have a PL/M compiler/development
>> system, nor do I even have any documentation on the syntax of the PL/M
>> language. Hence my post here...
> What about a PL/I compiler?  There's IBM's for OS/2 and Windows
> compilers, and there's DR PL/I for DOS.

I've done some coding in PL/M (on CP/M machines) and also some PL/I
(MVS, OS/2 and also CP/M). Believe me, they *are* different!

A good PL/M book would be

        McCracken
        PL/M - A guide to PL/M programming for microcomputer
                applications
        Addison-Wesley, 1978

It was very long in print, I bought mine "only" 10 years ago. And no,
I don't sell it. :-)

Andreas

f'up2 comp.lang.misc

--
Andreas Sons             | sons [at] hanse.de
Hamburg-Altona           | http://www.signal.hanse.de
Germany                  | AS6076-RIPE / AS18567



Thu, 25 Apr 2002 03:00:00 GMT  
 Remember PL/M?

Quote:

> Is there anybody out there that would like to get rid of some PL/M
> documentation, and/or some PL/M development tools. The tools would need
> to run on a Win95 (or DOS) box. I'd also appreciate any ideas on where
> to look for resources.

> Thanks for any help, or ideas!

At http://www.tuxedo.org/~esr/retro/ there is a free PL/M to C
translator.  See also http://www.ristancase.ch/da-plm/index.htm which
appears to be a complete Win32 PL/M development envioronment.
http://ourworld.compuserve.com/homepages/AlternativeSolutions/ is a
comercial PL/M to C translator.

--

http://www.auntfloyd.com/



Sun, 28 Apr 2002 03:00:00 GMT  
 Remember PL/M?

Quote:


> >> I've been given the "opportunity" to maintain a large (78,000 lines)
> >> project written in PL/M. I don't have a PL/M compiler/development
> >> system, nor do I even have any documentation on the syntax of the PL/M
> >> language. Hence my post here...

> > What about a PL/I compiler?  There's IBM's for OS/2 and Windows
> > compilers, and there's DR PL/I for DOS.

> I've done some coding in PL/M (on CP/M machines) and also some PL/I
> (MVS, OS/2 and also CP/M). Believe me, they *are* different!

The syntax of PL/M is strikingly similar to PL/I, and if contemplating
converting to another language, PL/I is the obvious choice.
.
Some of PL/M is based on XPL -- in particular, the LITERALLY attribute,
the use of INPUT and OUTPUT built-in functions for performing I/O,
the DO CASE statement, SHL and SHR for left and right shifts, and arrays
starting at element zero.
.
The DO group as implemented in PL/M requires no change to operate in PL/I.
.
The program needs to be wrapped in a procedure (or, the first DO statement
needs to be changed to PROCEDURE).
.
The IF-THEN-ELSE statement needs no change to be compiled in PL/I.
.
The PL/M DECLARE STRUCTURE has a direct equivalent in the DEFINE STRUCTURE
statement in PL/I.  Alternatively, the statement can be translated to a
traditional PL/I strecture.
.
The PL/M DO CASE statement has an equivalent structure in PL/I's SELECT
statement.
.
The PL/M built-in functions SHL and SHR have direct PL/I equivalents as
ISRL nad ISLL.
.
The BYTE attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(7).
.
The ADDRESS attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(15);
.
The LITERALLY attribute has an equivalent PL/I construct via the macro
processor.
.
The PL/M DATA attribute has a direct PL/I equivalent VALUE attribute.
Alternatively, PL/I's INITIAL attribute nay be used.
.
The PL/M INITIAL attribute is identical with PL/I.
.
The PL/M NOT, AND, OR, and XOR operators have equivalent PL/I operators.
Alternatively the PL/I builtin functions INOT, IAND, IOR, IEOR could be used.
.
The PL/M MOD operator would be replaced by PL/I's MOD built-in function.
.
PL/M's Input and Output operations can be replaced by an equivalent PL/I
READ, WRITE, GET, or PUT statement
.
As for constants, PL/M's binary constant is identical with PL/I's.
PL/I's decimal constant is identical, provided that the suffix 'D' is not used.
PL/I does not have an octal constant, but this could easily be converted by
program, likewise the hexadecimal constant.  Embedded '$' characters would need
to be filtered out.
.
Embedded $ could be edited out; SHL, SHR, LITERALLY, BYTE, ADDRESS could be
handled by simple macro text replacement (see below), or edited via a text
editor:
.
%DECLARE (SHL, SHR, BYTE, ADDRESS, NOT, AND, OR, XOR) CHARACTER;
%SHL = ISLL; %SHR = ISRL; %BYTE = 'UNSIGNED FIXED BINARY (7)';
%ADDRESS = 'UNSIGNED FIXED BINARY (15)';
%NOT = '^'; %AND = '&'; %OR = '|'; %IEOR = '^'; etc
Quote:

> Andreas

> --
> Andreas Sons             | sons [at] hanse.de
> Hamburg-Altona           | http://www.signal.hanse.de
> Germany                  | AS6076-RIPE / AS18567




Mon, 29 Apr 2002 03:00:00 GMT  
 Remember PL/M?
I think you'll have an awful lot of cleanup to do!  PL/M is a much lower level language and all of the I/O
primitives and most of the data declarations are quite dissimilar.

Also, PL/M has a lot of things that although syntactically similar are semantically unlike, especially in the
pre-processor primitives!!

How much code do you have to port?  78k lines??  That's a lot, and the application will not be as robust as
the original PL/M program, even if the new machines are 100X times faster...

If you send me say 250 lines or so, I will use a translator I built to go from PL/M to C several years ago.
One of the more successful word processors was originally written in PL/M and I converted it to C for the
owner.

After looking at 250 lines of PL/M to C, you can advise me whether or not you like the resulting C source.

Quote:



> > >> I've been given the "opportunity" to maintain a large (78,000 lines)
> > >> project written in PL/M. I don't have a PL/M compiler/development
> > >> system, nor do I even have any documentation on the syntax of the PL/M
> > >> language. Hence my post here...

> > > What about a PL/I compiler?  There's IBM's for OS/2 and Windows
> > > compilers, and there's DR PL/I for DOS.

> > I've done some coding in PL/M (on CP/M machines) and also some PL/I
> > (MVS, OS/2 and also CP/M). Believe me, they *are* different!

> The syntax of PL/M is strikingly similar to PL/I, and if contemplating
> converting to another language, PL/I is the obvious choice.
> .
> Some of PL/M is based on XPL -- in particular, the LITERALLY attribute,
> the use of INPUT and OUTPUT built-in functions for performing I/O,
> the DO CASE statement, SHL and SHR for left and right shifts, and arrays
> starting at element zero.
> .
> The DO group as implemented in PL/M requires no change to operate in PL/I.
> .
> The program needs to be wrapped in a procedure (or, the first DO statement
> needs to be changed to PROCEDURE).
> .
> The IF-THEN-ELSE statement needs no change to be compiled in PL/I.
> .
> The PL/M DECLARE STRUCTURE has a direct equivalent in the DEFINE STRUCTURE
> statement in PL/I.  Alternatively, the statement can be translated to a
> traditional PL/I strecture.
> .
> The PL/M DO CASE statement has an equivalent structure in PL/I's SELECT
> statement.
> .
> The PL/M built-in functions SHL and SHR have direct PL/I equivalents as
> ISRL nad ISLL.
> .
> The BYTE attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(7).
> .
> The ADDRESS attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(15);
> .
> The LITERALLY attribute has an equivalent PL/I construct via the macro
> processor.
> .
> The PL/M DATA attribute has a direct PL/I equivalent VALUE attribute.
> Alternatively, PL/I's INITIAL attribute nay be used.
> .
> The PL/M INITIAL attribute is identical with PL/I.
> .
> The PL/M NOT, AND, OR, and XOR operators have equivalent PL/I operators.
> Alternatively the PL/I builtin functions INOT, IAND, IOR, IEOR could be used.
> .
> The PL/M MOD operator would be replaced by PL/I's MOD built-in function.
> .
> PL/M's Input and Output operations can be replaced by an equivalent PL/I
> READ, WRITE, GET, or PUT statement
> .
> As for constants, PL/M's binary constant is identical with PL/I's.
> PL/I's decimal constant is identical, provided that the suffix 'D' is not used.
> PL/I does not have an octal constant, but this could easily be converted by
> program, likewise the hexadecimal constant.  Embedded '$' characters would need
> to be filtered out.
> .
> Embedded $ could be edited out; SHL, SHR, LITERALLY, BYTE, ADDRESS could be
> handled by simple macro text replacement (see below), or edited via a text
> editor:
> .
> %DECLARE (SHL, SHR, BYTE, ADDRESS, NOT, AND, OR, XOR) CHARACTER;
> %SHL = ISLL; %SHR = ISRL; %BYTE = 'UNSIGNED FIXED BINARY (7)';
> %ADDRESS = 'UNSIGNED FIXED BINARY (15)';
> %NOT = '^'; %AND = '&'; %OR = '|'; %IEOR = '^'; etc

> > Andreas

> > --
> > Andreas Sons             | sons [at] hanse.de
> > Hamburg-Altona           | http://www.signal.hanse.de
> > Germany                  | AS6076-RIPE / AS18567




Mon, 29 Apr 2002 03:00:00 GMT  
 Remember PL/M?

Quote:

> I think you'll have an awful lot of cleanup to do!  PL/M is a much lower level language
> and all of the I/O
> primitives and most of the data declarations are quite dissimilar.

The data tyles have simple text replacements that can be carried out
via a text editor or by the macro-preprocessor, except for
structure declarations.  These would have to be rewritten,
or could be translated by a straight-forward text processor.

Quote:
> Also, PL/M has a lot of things that although syntactically similar are semantically
> unlike, especially in the
> pre-processor primitives!!

I already mentioned that LITERALLY has an equivalent facility via the macro processor.
The CASE structure has an equivalent in PL/I's SELECT statement.
The INPUT and OUTPUT primitives can be replaced by
simple GET, READ, PUT, WRITE statements.
Quote:

> > The syntax of PL/M is strikingly similar to PL/I, and if contemplating
> > converting to another language, PL/I is the obvious choice.
> > .
> > Some of PL/M is based on XPL -- in particular, the LITERALLY attribute,
> > the use of INPUT and OUTPUT built-in functions for performing I/O,
> > the DO CASE statement, SHL and SHR for left and right shifts, and arrays
> > starting at element zero.
> > .
> > The DO group as implemented in PL/M requires no change to operate in PL/I.
> > .
> > The program needs to be wrapped in a procedure (or, the first DO statement
> > needs to be changed to PROCEDURE).
> > .
> > The IF-THEN-ELSE statement needs no change to be compiled in PL/I.
> > .
> > The PL/M DECLARE STRUCTURE has a direct equivalent in the DEFINE STRUCTURE
> > statement in PL/I.  Alternatively, the statement can be translated to a
> > traditional PL/I strecture.
> > .
> > The PL/M DO CASE statement has an equivalent structure in PL/I's SELECT
> > statement.
> > .
> > The PL/M built-in functions SHL and SHR have direct PL/I equivalents as
> > ISRL nad ISLL.
> > .
> > The BYTE attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(7).
> > .
> > The ADDRESS attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(15);
> > .
> > The LITERALLY attribute has an equivalent PL/I construct via the macro
> > processor.
> > .
> > The PL/M DATA attribute has a direct PL/I equivalent VALUE attribute.
> > Alternatively, PL/I's INITIAL attribute nay be used.
> > .
> > The PL/M INITIAL attribute is identical with PL/I.
> > .
> > The PL/M NOT, AND, OR, and XOR operators have equivalent PL/I operators.
> > Alternatively the PL/I builtin functions INOT, IAND, IOR, IEOR could be used.
> > .
> > The PL/M MOD operator would be replaced by PL/I's MOD built-in function.
> > .
> > PL/M's Input and Output operations can be replaced by an equivalent PL/I
> > READ, WRITE, GET, or PUT statement
> > .
> > As for constants, PL/M's binary constant is identical with PL/I's.
> > PL/I's decimal constant is identical, provided that the suffix 'D' is not used.
> > PL/I does not have an octal constant, but this could easily be converted by
> > program, likewise the hexadecimal constant.  Embedded '$' characters would need
> > to be filtered out.
> > .
> > Embedded $ could be edited out; SHL, SHR, LITERALLY, BYTE, ADDRESS could be



Wed, 01 May 2002 03:00:00 GMT  
 Remember PL/M?
Dear Robin:

You are headed for trouble!

But this is a case where you should follow your instincts, in taking this course of action
you will learn a great deal.  But don't imagine that what you are doing will result in a
successful conversion!  NO!!  Instead, you will have 78k lines of code that looks quite good,
but has horrid semantic problems which, after much effort, you and the others involved in
this project, will give up on.

I'm in a different business now, but for 10 years I wrote compilers, and subsequently spend
15 years building source-code translation, migration and conversion tools.  I am the author
of two programming languages designed explicitly for doing these types of projects, I refer
to aiSOFT and aiTRAN.

aiSOFT is a language designed to write front-end tools.  I once wrote a COBOL front-end in
under two hours (a prospect had made this the test for closing on a business project).
Primitives in the language relate to lexical and syntactic issues.

aiTRAN is a symbolic language, you may know what computer algebra is.  aiTRAN is a computer
algebra langauge, but not designed to do mathematics, but instead to manipulate and alter
deep semantics of expressions (all source code translations occur to first translate an
entire program into a single expression, and then to alter the expression using algebra, and
finally to translate the altered expression back into source code).  These 'expressions' are
typically huge, and contain ALL of the information originally in the code, including such
things as white-space and comments.

I was trying to help you with my earlier remarks, but as I said, take your chosen course.  It
will be highly educational, both for you and your team.

I am in a different business now, where these kinds of tools are useful -- but not the basic
underpinnings.   I did find that making highly technical sales to folks with applications was
not my strength.  I meant my remarks to help you, because I see you embarking -- not on a
fool's errand, but a path that cannot succeed.

Enjoy your day.
Jules

Quote:


> > I think you'll have an awful lot of cleanup to do!  PL/M is a much lower level language
> > and all of the I/O
> > primitives and most of the data declarations are quite dissimilar.

> The data tyles have simple text replacements that can be carried out
> via a text editor or by the macro-preprocessor, except for
> structure declarations.  These would have to be rewritten,
> or could be translated by a straight-forward text processor.

> > Also, PL/M has a lot of things that although syntactically similar are semantically
> > unlike, especially in the
> > pre-processor primitives!!

> I already mentioned that LITERALLY has an equivalent facility via the macro processor.
> The CASE structure has an equivalent in PL/I's SELECT statement.
> The INPUT and OUTPUT primitives can be replaced by
> simple GET, READ, PUT, WRITE statements.


> > > The syntax of PL/M is strikingly similar to PL/I, and if contemplating
> > > converting to another language, PL/I is the obvious choice.
> > > .
> > > Some of PL/M is based on XPL -- in particular, the LITERALLY attribute,
> > > the use of INPUT and OUTPUT built-in functions for performing I/O,
> > > the DO CASE statement, SHL and SHR for left and right shifts, and arrays
> > > starting at element zero.
> > > .
> > > The DO group as implemented in PL/M requires no change to operate in PL/I.
> > > .
> > > The program needs to be wrapped in a procedure (or, the first DO statement
> > > needs to be changed to PROCEDURE).
> > > .
> > > The IF-THEN-ELSE statement needs no change to be compiled in PL/I.
> > > .
> > > The PL/M DECLARE STRUCTURE has a direct equivalent in the DEFINE STRUCTURE
> > > statement in PL/I.  Alternatively, the statement can be translated to a
> > > traditional PL/I strecture.
> > > .
> > > The PL/M DO CASE statement has an equivalent structure in PL/I's SELECT
> > > statement.
> > > .
> > > The PL/M built-in functions SHL and SHR have direct PL/I equivalents as
> > > ISRL nad ISLL.
> > > .
> > > The BYTE attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(7).
> > > .
> > > The ADDRESS attribute has a direct PL/I equivalent as UNSIGNED FIXED BINARY(15);
> > > .
> > > The LITERALLY attribute has an equivalent PL/I construct via the macro
> > > processor.
> > > .
> > > The PL/M DATA attribute has a direct PL/I equivalent VALUE attribute.
> > > Alternatively, PL/I's INITIAL attribute nay be used.
> > > .
> > > The PL/M INITIAL attribute is identical with PL/I.
> > > .
> > > The PL/M NOT, AND, OR, and XOR operators have equivalent PL/I operators.
> > > Alternatively the PL/I builtin functions INOT, IAND, IOR, IEOR could be used.
> > > .
> > > The PL/M MOD operator would be replaced by PL/I's MOD built-in function.
> > > .
> > > PL/M's Input and Output operations can be replaced by an equivalent PL/I
> > > READ, WRITE, GET, or PUT statement
> > > .
> > > As for constants, PL/M's binary constant is identical with PL/I's.
> > > PL/I's decimal constant is identical, provided that the suffix 'D' is not used.
> > > PL/I does not have an octal constant, but this could easily be converted by
> > > program, likewise the hexadecimal constant.  Embedded '$' characters would need
> > > to be filtered out.
> > > .
> > > Embedded $ could be edited out; SHL, SHR, LITERALLY, BYTE, ADDRESS could be



Thu, 02 May 2002 03:00:00 GMT  
 Remember PL/M?
some PL/M resources can be found:

http://deltasoft.fife.wa.us/cpm/

http://deltasoft.fife.wa.us/cpm/archive/unofficial/

PL/M-80 source (in fortran66):
http://deltasoft.fife.wa.us/cpm/archive/unofficial/download/plm80s.zip

PL/M to C translator
http://deltasoft.fife.wa.us/cpm/archive/unofficial/download/plm2c.zip

another version of PL/M to C translator, for Unix
http://deltasoft.fife.wa.us/cpm/archive/unofficial/download/newplm.zip

There is a lot more in the download area, if one wants to dig . .
Also lots of CP/M stuff (surprise, surprise)
--
Kevin G. Rhoads, Ph.D. (The Cheshire Cat for official Internet mascot.)



Thu, 02 May 2002 03:00:00 GMT  
 Remember PL/M?

Quote:

> You are headed for trouble!

> But this is a case where you should follow your instincts, in taking this course of action
> you will learn a great deal.  But don't imagine that what you are doing will result in a
> successful conversion!  NO!!  Instead, you will have 78k lines of code that looks quite good,
> but has horrid semantic problems which, after much effort, you and the others involved in
> this project, will give up on.

PL/M has clearly-defined semantics
that have direct equivalents in PL/I.

Furthermore, PL/I has additional types not supported
by PL/M, in which certain PL/M computations can be handled
far more efficiently (in terms of source code) and
more clearly, when it comes to computation involving
binary fixed-point with scale factor.

Quote:
> Enjoy your day.
> Jules


> > > I think you'll have an awful lot of cleanup to do!  PL/M is a much lower level language
> > > and all of the I/O
> > > primitives and most of the data declarations are quite dissimilar.

> > The PL/M data types have simple text replacements that can be carried out
> > via a text editor or by the macro-preprocessor, except for
> > structure declarations.  These would have to be rewritten,
> > or could be translated by a straight-forward text processor.

> > > Also, PL/M has a lot of things that although syntactically similar are semantically
> > > unlike, especially in the
> > > pre-processor primitives!!

> > I already mentioned that LITERALLY has an equivalent facility via the macro processor.
> > The CASE structure has an equivalent in PL/I's SELECT statement.
> > The INPUT and OUTPUT primitives can be replaced by
> > simple GET, READ, PUT, WRITE statements.


> > > > The syntax of PL/M is strikingly similar to PL/I, and if contemplating
> > > > converting to another language, PL/I is the obvious choice.
> > > > .
> > > > Some of PL/M is based on XPL -- in particular, the LITERALLY attribute,
> > > > the use of INPUT and OUTPUT built-in functions for performing I/O,
> > > > the DO CASE statement, SHL and SHR for left and right shifts, and arrays
> > > > starting at element zero.
> > > > .
> > > > The DO group as implemented in PL/M requires no change to operate in PL/I.
> > > > .
> > > > The program needs to be wrapped in a procedure (or, the first DO statement
> > > > needs to be changed to PROCEDURE).
> > > > .
> > > > The IF-THEN-ELSE statement needs no change to be compiled in PL/I.
> > > > .
> > > > The PL/M DECLARE STRUCTURE has a direct equivalent in the DEFINE STRUCTURE
> > > > .



Thu, 02 May 2002 03:00:00 GMT  
 Remember PL/M?
I've spent a lot of time working on a substantial PL/M to C porting effort.

The whole pointer model is radically different. Converting PL/M to C requires
almost a complete PL/M parser and syntactic analyser, to track what pointers
are used for what variables. If you're lucky you'll have code like this:

        DCL FOO_PTR POINTER;
        DCL FOO BASED FOO_PTR INTEGER;

If you're not lucky you'll end up with pointers moved from one variable to
another in the middle of a subroutine, and you'll never keep them straight:

        DCL TRAIN_PTR POINTER;
        DCL TRAIN1 BASED TRAIN_PTR STRUCTURE (...);
        DCL TRAIN2 BASED TRAIN_PTR STRUCTURE (...);

I've worked on PL/M code (at another job... the code in Ranger was very
well disciplined) where the some pointer was toggled between the two
structures multiple times in a routine, because some luser ran out of space
in the structure declaration and was too lazy to clean things up.

This is the big problem. It's particularly a pain when you have some pointer
declared globally in an include file but the structure declarations are in
the source code... you have to analyze the two structures to make sure that
you have a unique pointer. Interfile dependency checking is a pain.

--

 `-_-'   Ar rug t barrg ar do mhactre inniu?
  'U`    "And now, little kittens, we're going to run across red-hot
          motherboards, with our bare feet." -- Buzh.



Fri, 03 May 2002 03:00:00 GMT  
 Remember PL/M?
Yeh Peter:

I don't know enough about the ladies code to make specific comments, and she
declined my offer to convert 250 lines for free to help acquaint her with some of
the problems.

Look, everyone makes mistakes -- and it looks like Robin wants to make some on
her employers dime.

I wish it were otherwise, but I think we have to allow her that privilege -- I've
certainly excercised that same privilege often enough, both with other people's
money and on my own.

--jg

Quote:

> I've spent a lot of time working on a substantial PL/M to C porting effort.

> The whole pointer model is radically different. Converting PL/M to C requires
> almost a complete PL/M parser and syntactic analyser, to track what pointers
> are used for what variables. If you're lucky you'll have code like this:

>         DCL FOO_PTR POINTER;
>         DCL FOO BASED FOO_PTR INTEGER;

> If you're not lucky you'll end up with pointers moved from one variable to
> another in the middle of a subroutine, and you'll never keep them straight:

>         DCL TRAIN_PTR POINTER;
>         DCL TRAIN1 BASED TRAIN_PTR STRUCTURE (...);
>         DCL TRAIN2 BASED TRAIN_PTR STRUCTURE (...);

> I've worked on PL/M code (at another job... the code in Ranger was very
> well disciplined) where the some pointer was toggled between the two
> structures multiple times in a routine, because some luser ran out of space
> in the structure declaration and was too lazy to clean things up.

> This is the big problem. It's particularly a pain when you have some pointer
> declared globally in an include file but the structure declarations are in
> the source code... you have to analyze the two structures to make sure that
> you have a unique pointer. Interfile dependency checking is a pain.

> --

>  `-_-'   Ar rug t barrg ar do mhactre inniu?
>   'U`    "And now, little kittens, we're going to run across red-hot
>           motherboards, with our bare feet." -- Buzh.



Fri, 03 May 2002 03:00:00 GMT  
 Remember PL/M?

Quote:
> I've spent a lot of time working on a substantial PL/M to C porting effort.

> The whole pointer model is radically different. Converting PL/M to C requires
> almost a complete PL/M parser and syntactic analyser, to track what pointers
> are used for what variables. If you're lucky you'll have code like this:

>    DCL FOO_PTR POINTER;
>    DCL FOO BASED FOO_PTR INTEGER;

> If you're not lucky you'll end up with pointers moved from one variable to
> another in the middle of a subroutine, and you'll never keep them straight:

>    DCL TRAIN_PTR POINTER;
>    DCL TRAIN1 BASED TRAIN_PTR STRUCTURE (...);
>    DCL TRAIN2 BASED TRAIN_PTR STRUCTURE (...);

> I've worked on PL/M code (at another job... the code in Ranger was very
> well disciplined) where the some pointer was toggled between the two
> structures multiple times in a routine, because some luser ran out of space
> in the structure declaration and was too lazy to clean things up.

BASED variables are a standard feature of PL/I.

- Show quoted text -



Fri, 03 May 2002 03:00:00 GMT  
 Remember PL/M?

Quote:


> > I've spent a lot of time working on a substantial PL/M to C porting effort.

[...]

Quote:
> BASED variables are a standard feature of PL/I.

Yes, and what does that have to do with translating PL/M to C?

--

 `-_-'   Ar rug t barrg ar do mhactre inniu?
  'U`    "And now, little kittens, we're going to run across red-hot
          motherboards, with our bare feet." -- Buzh.



Sat, 04 May 2002 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Remember PL/M?

2. Anyone remembers PL/M ?

3. MS-DOS PL/I: PROBLEMS

4. PL/I for MS-DOS

5. PL/I Compilers for MS-DOS

6. Logo Komeniusz PL (Logo Comenius PL)

7. Derivation of PL/I (was Usenet group for PL/M language)

8. Mapping local files to FILE declarations in PL/I with IBM VisualAge PL./I for Windows

9. Difference PL/1 PL/I

10. What is the difference between DEC PL/1 and OS/390 PL/1

11. Initialization Expressions in PL/I (was ANSI PL/I)

12. Migrating from OS/VS PL/I to VA PL/I

 

 
Powered by phpBB® Forum Software