Subj : Extending Pl/I
To : Murray Lesser
From : David Noon
Date : Thu Feb 22 2001 12:30 am
Hi Murray,
Replying to a message of Murray Lesser to David Noon:
DN>> More interestingly, REXX is an extensible language. This means you
>> can write extension DLL's in whatever native code language you
>> fancy, provided it supports _System linkage convention. There are
>> plenty of samples in C, and I have posted samples in PL/I and
>> assembler. Thus, when the base language runs out of capability or too
>> slowly, branch off into some native object code to do the fiddly
>> bits.
ML> PL/I is also extensible :-). (Almost any compiled language and
ML> many interpreted languages are extensible with assembled procedures.
ML> I wrote three books in the 1980s dealing with extending various
ML> dialects of MS BASIC compilers).
Moreover, PL/I is extensible (at least lexically) in PL/I. See the language
reference manual for the description of %PROCEDURE ... STATEMENT, under the
macro preprocessor.
ML> There used to be less necessity for
ML> extending PL/I than for extending REXX, and it is much more
ML> difficult. Extending PL/I may have become more likely for those of
ML> us who write text-mode utilities, now that IBM has dropped the PL/I
ML> capability to make direct calls to the 16-bit OS/2 APIs.
Yes, if IBM removes in-line thunking one must use a thunk layer of some sort,
or re-visit the issue of keyboard/mouse/screen handling completely.
DN>> None of the major development tools vendors is supporting
>> 16-bit code any more, except in their assemblers. All
>> modern compilers produce 32-bit code exclusively. The
>> upshot is that DOS is dead. Indeed, there is no ISO/ANSI-
>> certified C++ compiler for 16-bit DOS, AFAIK. [Jonathan
>> might know of one.] All the 16-bit C compilers are C89 or
>> worse [K&R], with no C99 compilers available. As I said,
>> DOS is dead.
ML> Hmmm. Is that new fashion the reason IBM dropped the ability to
ML> compile PL/I procedures calling the 16-bit bsesub.cpy OS/2 API
ML> functions, in FP-6? Another loss to fashion?
Not really.
The reason nobody produces 16-bit compilers these days is that a back-end that
produces 16-bit code is more expensive to develop than one that produces 32-bit
code, and the vendor is obliged to produce a 32-bit back-end simply to support
the modern CPU hardware. It is a matter of cost/benefit: the 16-bit code
benefits very few people, but costs a packet.
ML> I keep a copy of the
ML> FP-4 version of my compiler in a different partition, just to avoid
ML> having to "extend" PL/I with assembled procedures. Once compiled,
ML> the calls run fine under the runtime DLLs that came with FP-6.
Of course. But "thunking down" to call a 16-bit API is not quite the same thing
as producing an entire 16-bit application, which is what Mike seems to want.
What would be nice would be to have IBM supply a 32-bit DPMI extender (a la
Watcom, R.I.P.) and allow the 32-bit code to be linked as a DOS application
(LE-format executable), as well as or instead of an OS/2 application (LX-format
executable) or Win32 application (PE-format executable).
DN>> Only you can answer the question. How you collect
>> background information to formulate the answer is up to
>> you. But you have been given information from the two
>> members of this echo who have the most experience with
>> PL/I, and we both know/knew C too. I also know C++ quite
>> thoroughly. And I dabble in REXX a bit, too. ... :-)
ML> Thanks for the kind words. However, Mike should note that I am
ML> one of the _only_ two members of this echo who admit to having an
ML> acquaintance with PL/I.
I recall Will Honea admitting some brief dalliance with PL/I a couple of years
ago.
ML> If he really needs technical advice, he
ML> should do what I do: ask you :-).
:-)
Regards
Dave
<Team PL/I>
--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)
