I don't really understand why it has to be this way.
We had many problems with this topic, too, because we were a PL/1 -
ASSEMBLER
shop in the beginning, and then we added C in 1993 ca.
We always use the SIZE condition prefix in production. In the OS-PL/1
days, SIZE was
implemented like this:
0CA was activated by program mask (SPM)
if the DEC FIXED field has odd length, no special action required
if the DEC FIXED field has even length, then a value is constructed by
moving the
unused first digit left, so that when moving it into the target field,
it will throw a 0CA
exception (for example: 19999C fits in a DEC FIXED(4) field, although it
has 5 digits,
so it is moved to a work field as 1019999C - first digit copied - and
then back to the
target field - so you get the 0CA)
and the 0CA was monitored by the PL/1 runtime and gives the SIZE condition.
This was very natural - even if running NOSPIE, NOSTAE you had a very clean
behaviour - your PL/1 program acted almost like an ASSEMBLER routine.
Using SPM you could switch on and off the condition prefixes of PL/1.
Today, 0CA is always off and the SIZE condition is examined by
additional code
(and a call to a LE routine which activates the SIZE condition). Same
goes for 0C8.
I guess, that's because the code generation is inherited from other
platforms
where there are no such things as 0CA and 0C8 program checks. It's slow,
BTW.
I don't understand:
if it's necessary to make a difference between C and PL/1 - due to language
specification; why can't the program mask bits be set on entry and reset
on return?
So PL/1 could keep its clever condition handling and C could have its
own ...
no need to change anything for PL/1 ... I believe that LE - or more
precisely:
the new compilers - do not make good use of the unique features of the
z/Architecture like the PSW mask bits.
and: if wishes came true ... a C compiler generating code which allows
for the
0C8 mask bit being set ... so that we could control overflow, regardless
of the
C language specification. We had this already, with the very early
versions of
C/370. But LE also has to tolerate the 0C8 mask bit being set.
Kind regards
Bernd
Am 31.07.2013 14:45, schrieb John Gilmore:
This is a vexed topic.
PL/I always had full support for the FIXEDOVERFLOW condition for
binary fixed values, but when much of the backend support for C and
PL/I was merged, support for it, never provided in C, was dropped for
PL/I too, not quite but almost silently. The FIXEDOVERFLOW condition
is now supported only for decimal fixed, i.e., packed-decimal, values.
The LE has (or perhaps had) a callable service that enabled/disabled
FIXEDOVERFLOW, and you can of course do this for yourself with a
single, suitably framed SPM instruction. (It was mentioned but never
fully described in trhe LE Vendor Interfaces manual; and there was not
even an index entry for it in that manual.)
Before these kinds of things---There have been gratuitousx additions
too, like package in a language that supports multiple entries in a
procedure block, but these can be ignored---started to happen to IBM
implementations of PL/I I had had no animus against C. I thought of
it as a FORTRAN dialect that people should be free to use if they
wished to do so, as they are free to use, say, RPG II. That has
changed as its juvenile disorders have infected PL/I support too. I
am now actively hostile to it.
John Gilmore, Ashland, MA 01721 - USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
