Home > Archive > Cobol > April 2004 > (IBM) SHARE - LNGC requirements
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
(IBM) SHARE - LNGC requirements
|
|
| William M. Klein 2004-03-26, 10:59 pm |
| I hope to have a number (many) SHARE LNGC requirements "Open for Discussion" in
the next few days (certainly by the end of next w ). If your "site" is a
SHARE member and you are not currently participating in the requirement process
for:
COBOL
PL/I
and/or
LE (Language Environment)
Please read and follow the information at:
http://home.netcom.com/~wmklein/IBM...%20-%20LNGC.htm
If you have already "registered" to participate in this (electronic only) method
of influencing the future of these IBM products, please make certain that you
"watch" the SHARE requirements website for new items for which your input is
being solicited.
SPECIAL NOTE:
Although I will be entering a number of requirements (based on what I have
heard as current needs/desires), creating and submitting requirements is open to
ALL share member organizations and I would really, REALLY appreciate as many
others creating new requirements as possible.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| John W. Kennedy 2004-03-26, 10:59 pm |
| These bloody-obvious PL/I requirements have been around for years:
Distinct binary and short-circuit logical operators (cf. C, Ada....).
Polymorphic objects and private information (cf. C++, Java).
INTEGER as a tertium-quid to FIXED and FLOAT (cf. Ada).
Overloading (as opposed to the lame GENERIC feature).
Although the macro language can be used to achieve templating, a true
templating feature would be better.
Assuming these, a set of collection classes would be good, too.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| Mark Yudkin 2004-03-26, 10:59 pm |
| To which you could add classes / objects, which is even partially supported
although totally undocumented in IBM's VA compilers. AFAIK, it has some of
the expected functionality, but is missing other features. Moreover it
apparently does not use a C++ / COM-compatible dispatch table, thus
preventing C++ / COM interoperability.
Currently, fixed bin and integer is even messier than you seem to realize:
Under rules(ibm), fixed binary can be scaled, but under rules(ans), fixed
binary is exactly integer, as non-zero scale factors are not permitted (see
the Programming Guide).
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:yxN4c.20487$Sp2.6467465@news4.srv.hcvlny.cv.net...
> These bloody-obvious PL/I requirements have been around for years:
>
> Distinct binary and short-circuit logical operators (cf. C, Ada....).
> Polymorphic objects and private information (cf. C++, Java).
> INTEGER as a tertium-quid to FIXED and FLOAT (cf. Ada).
> Overloading (as opposed to the lame GENERIC feature).
> Although the macro language can be used to achieve templating, a true
> templating feature would be better.
> Assuming these, a set of collection classes would be good, too.
>
> --
> John W. Kennedy
> "But now is a new thing which is very old--
> that the rich make themselves richer and not poorer,
> which is the true Gospel, for the poor's sake."
> -- Charles Williams. "Judgement at Chelmsford"
| |
| Tom Linden 2004-03-26, 10:59 pm |
| "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org> wrote in message news:<c31cg2$e4v$1@ngspool-d02.news.aol.com>...
> To which you could add classes / objects, which is even partially supported
> although totally undocumented in IBM's VA compilers. AFAIK, it has some of
> the expected functionality, but is missing other features. Moreover it
> apparently does not use a C++ / COM-compatible dispatch table, thus
> preventing C++ / COM interoperability.
>
> Currently, fixed bin and integer is even messier than you seem to realize:
> Under rules(ibm), fixed binary can be scaled, but under rules(ans), fixed
> binary is exactly integer, as non-zero scale factors are not permitted (see
> the Programming Guide).
In that event IBM shouldn't call it ANS(I) since ANSI does support
scaled fixed binary.
see
http://www.kednos.com/pli/docs/REFE...tml#index_x_336
[color=darkred]
>
> "John W. Kennedy" <jwkenne@attglobal.net> wrote in message
> news:yxN4c.20487$Sp2.6467465@news4.srv.hcvlny.cv.net...
| |
| John W. Kennedy 2004-03-26, 10:59 pm |
| Mark Yudkin wrote:
> To which you could add classes / objects, which is even partially supported
> although totally undocumented in IBM's VA compilers. AFAIK, it has some of
> the expected functionality, but is missing other features. Moreover it
> apparently does not use a C++ / COM-compatible dispatch table, thus
> preventing C++ / COM interoperability.
I supposed I had covered that when I asked for polymorphic objects. The
rest is -- interesting.
> Currently, fixed bin and integer is even messier than you seem to realize:
> Under rules(ibm), fixed binary can be scaled, but under rules(ans), fixed
> binary is exactly integer, as non-zero scale factors are not permitted (see
> the Programming Guide).
As far as I'm concerned RULES(ANS) PL/I isn't PL/I (as the Indian sage
famously remarked on the subject of Chinese Buddhism).
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| Peter Flass 2004-03-26, 10:59 pm |
| Tom Linden wrote:
> "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org> wrote in message news:<c31cg2$e4v$1@ngspool-d02.news.aol.com>...
>
>
>
> In that event IBM shouldn't call it ANS(I) since ANSI does support
> scaled fixed binary.
>
> see
> http://www.kednos.com/pli/docs/REFE...tml#index_x_336
>
ANSI Subset G doesn't support it. AFAIK, full ANSI still does.
IBM PL/I has a lot of non-standard extensions, however.
| |
| Shmuel (Seymour J.) Metz 2004-03-26, 10:59 pm |
| In <yxN4c.20487$Sp2.6467465@news4.srv.hcvlny.cv.net>, on 03/14/2004
at 12:18 AM, "John W. Kennedy" <jwkenne@attglobal.net> said:
>Polymorphic objects and private information (cf. C++, Java).
What ever happened to IBM's pilot project for OO PL/I?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.
Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@library.lspace.org
| |
| robin 2004-03-26, 10:59 pm |
| Subject: Re: (IBM) SHARE - LNGC requirements
From: "John W. Kennedy" <jwkenne@attglobal.net>, Optimum Online
Date: Sun, 14 Mar 2004 00:18:38 GMT
..
| These bloody-obvious PL/I requirements have been around for years:
|
| Distinct binary and short-circuit logical operators (cf. C, Ada....).
| Polymorphic objects and private information (cf. C++, Java).
| INTEGER as a tertium-quid to FIXED and FLOAT (cf. Ada).
..
Already available as a subset of FIXED BINARY under RULES (ANSI)
Already available virtually anyway with the fllg (RULES (IBM)):
%DCL INTEGER CHARACTER;
%INTEGER = 'FIXED BINARY (31)';
[ or 63 if you're using 64-bit integers.]
or even
DEFINE ALIAS INTEGER FIXED BINARY (31);
DCL K TYPE INTEGER;
..
| Overloading (as opposed to the lame GENERIC feature).
..
GENERIC is fine.
..
| Although the macro language can be used to achieve templating, a true
| templating feature would be better.
| Assuming these, a set of collection classes would be good, too.
|
| --
| John W. Kennedy
| |
| robin 2004-03-26, 10:59 pm |
| From: "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org>, CompuServe Interactive Services
Date: Sun, 14 Mar 2004 11:35:38 +0100
..
| Currently, fixed bin and integer is even messier than you seem to realize:
| Under rules(ibm), fixed binary can be scaled,
..
Not really. Try using the ADD, SUBTRACT, MULTIPLY, DIVIDE
builtins. They force conversion to FIXED DECIMAL,
which is a real pain.
..
| but under rules(ans), fixed
| binary is exactly integer, as non-zero scale factors are not permitted (see
| the Programming Guide).
..
and the Language Reference.
| |
| John W. Kennedy 2004-03-26, 10:59 pm |
| robin wrote:
> From: "John W. Kennedy" <jwkenne@attglobal.net>, Optimum Online
> | INTEGER as a tertium-quid to FIXED and FLOAT (cf. Ada).
> ..
> Already available as a subset of FIXED BINARY under RULES (ANSI)
Which means changing ALL semantics by changing a compiler option, and,
to get one desideratum, ruling out another. No thank you.
> Already available virtually anyway with the fllg (RULES (IBM)):
> %DCL INTEGER CHARACTER;
> %INTEGER = 'FIXED BINARY (31)';
> [ or 63 if you're using 64-bit integers.]
> or even
> DEFINE ALIAS INTEGER FIXED BINARY (31);
> DCL K TYPE INTEGER;
Machine dependent, and likely to go astray in complex expressions using
literals. No thank you.
> ..
> | Overloading (as opposed to the lame GENERIC feature).
> ..
> GENERIC is fine.
No it isn't. It is a first cut at the problem that every language
designer since has looked at and said, "But why not just make it
automatic?" It is essentially an artifact of the limits of the design
of the OS/360 linkage editor. And it doesn't work in association with
templating, whether makeshift templating by macros or true templating in
the language.
PL/I was the most advanced language of 1965. It continues to be in some
ways the most advanced language with mainstream support in z/OS. But
there are a great many things that have happened in language design
since 1965, some of them happening in explicit recognition of places
where hindsight has shown PL/I to have made a mistake, such as GENERIC,
anonymous pointers, dynamic condition handlers, automatic fixed-point
scaling by rule, and integers treated as merely scaled fixed-point with
q=0. It needs to be dragged into the 21st century if it is to continue
to exist as anything but a legacy.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| John W. Kennedy 2004-03-26, 10:59 pm |
| robin wrote:
> From: "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org>, CompuServe Interactive Services
> Date: Sun, 14 Mar 2004 11:35:38 +0100
> ..
> | Currently, fixed bin and integer is even messier than you seem to realize:
> | Under rules(ibm), fixed binary can be scaled,
> ..
> Not really. Try using the ADD, SUBTRACT, MULTIPLY, DIVIDE
> builtins. They force conversion to FIXED DECIMAL,
> which is a real pain.
No they don't.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| glen herrmannsfeldt 2004-03-26, 11:00 pm |
| robin wrote:
(snip)
> Not really. Try using the ADD, SUBTRACT, MULTIPLY, DIVIDE
> builtins. They force conversion to FIXED DECIMAL,
> which is a real pain.
"The base, scale, and mode of the result are determined by the rules
for expression evaluation."
Though the fourth argument can only be supplied for FIXED types.
-- glen
| |
| robin 2004-03-26, 11:00 pm |
| "John W. Kennedy" <jwkenne@attglobal.net> writes: > robin wrote:
>
>
> No they don't.
They do on earlier versions of the product.
When I raised it with Peter Elderon quite a while back,
his reply was to the effect that they weren't
ever going to change it.
Looks like he has done it after all.
> --
> John W. Kennedy
| |
| James J. Weinkam 2004-03-26, 11:00 pm |
| robin wrote:
> From: "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org>, CompuServe Interactive Services
> Date: Sun, 14 Mar 2004 11:35:38 +0100
> .
> | Currently, fixed bin and integer is even messier than you seem to realize:
> | Under rules(ibm), fixed binary can be scaled,
> .
> Not really. Try using the ADD, SUBTRACT, MULTIPLY, DIVIDE
> builtins. They force conversion to FIXED DECIMAL,
> which is a real pain.
You are right!
Here is a quote from the description of the ADD(x,y,p,q) builtin function from
the Personal PL/I for OS/2 Reference Manual:
"ADD returns the sum of x and y with a precision specified by p and q. The
base, scale, and mode of the result are determined by the rules for expression
evaluation."
Admittedly this does not actually say how the result will be arrived at, but
if both operands are binary, then according to the rules for expression
evaluation, the result will be binary, which certainly suggests that the
operation will be carried out in binary. Shows how wrong you can be. Who in
the world ever came up with such a preposterous idea?
I had always assumed that the purpose of the ADD, SUBTRACT, MULTIPLY, and
DIVIDE builtin functions is to enable the programmer to deal more or less
gracefully with situations in which the rules for determining the precision
and scale factor of intermediate results in fixed point arithmetic are not
appropriate for the application at hand. After all, there is no single set of
rules that is satisfactory for all applications.
This largely defeats the purpose of having the functions in the first place,
at least for binary operands. All I can say is STUPID, STUPID, STUPID.
I guess the reason that I have not previously discovered this is that
virtually all of my uses of these functions have been in DECIMAL.
Did the F and Optimizing Compilers also behave this way? Before seeing this
thread, I would have sworn that they computed the result in binary if the
operands were binary, but I can't remember for sure if I ever actually
checked, so I could well be mistaken. Does anyone remember?
| |
| James J. Weinkam 2004-03-26, 11:00 pm |
| glen herrmannsfeldt wrote:
> robin wrote:
>
> (snip)
>
>
>
> "The base, scale, and mode of the result are determined by the rules
> for expression evaluation."
>
> Though the fourth argument can only be supplied for FIXED types.
>
> -- glen
>
Yeah, I thought so too until I tried it. Just because the final result is
binary does not guarantee that the computation is carried out in binary. It
seems to depend on the compiler being used. At least the workstation products
appear to convert to decimal for the actual computation. Sad. See my reply
to Robin's message.
| |
| James J. Weinkam 2004-03-26, 11:00 pm |
| John W. Kennedy wrote:
> robin wrote:
>
>
>
> No they don't.
>
>
Well, that appears to depend on the implementation you are using. See my
reply to Robin's message.
| |
| Binyamin Dissen 2004-03-26, 11:00 pm |
| On Tue, 16 Mar 2004 15:38:41 GMT "John W. Kennedy" <jwkenne@attglobal.net>
wrote:
:>robin wrote:
[ snipped ]
:>> DEFINE ALIAS INTEGER FIXED BINARY (31);
:>> DCL K TYPE INTEGER;
:>Machine dependent, and likely to go astray in complex expressions using
:>literals. No thank you.
How is 31 bit (or any fixed bit) arithmetic "Machine dependent"?
It can be done on any machine with any word size.
[ snipped ]
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
| glen herrmannsfeldt 2004-03-26, 11:00 pm |
| Binyamin Dissen wrote:
> On Tue, 16 Mar 2004 15:38:41 GMT "John W. Kennedy" <jwkenne@attglobal.net>
> wrote:
> :>robin wrote:
> [ snipped ]
> :>> DEFINE ALIAS INTEGER FIXED BINARY (31);
> :>> DCL K TYPE INTEGER;
> :>Machine dependent, and likely to go astray in complex expressions using
> :>literals. No thank you.
> How is 31 bit (or any fixed bit) arithmetic "Machine dependent"?
> It can be done on any machine with any word size.
As far as I know, PL/I has a maximum that it supports.
For many implementations that is 31, but I don't know if 31
is required. Because of the way division is done, there
needs to be a maximum.
-- glen
| |
| Mark Yudkin 2004-03-26, 11:00 pm |
| If Peter had really broken ADD, SUBTRACT, MULTIPLY, DIVIDE to force decimal
arithmetic, etc. we would have had major problems when we migrated our
calendar arithmetic code from MVS to the PC that we'd have noticed it
extremely quickly, and I'd have opened a high priority PMR. I know for a
fact that we had no such problems.
You're going to have to prove your claim.
"robin" <robin_v@bigpond.mapson.com> wrote in message
news:5uM5c.106620$Wa.11848@news-server.bigpond.net.au...[color=darkred]
> "John W. Kennedy" <jwkenne@attglobal.net> writes: > robin wrote:
Interactive Services[color=darkred]
realize:[color=darkred]
>
> They do on earlier versions of the product.
> When I raised it with Peter Elderon quite a while back,
> his reply was to the effect that they weren't
> ever going to change it.
> Looks like he has done it after all.
>
| |
| Mark Yudkin 2004-03-26, 11:00 pm |
| I think I see what you're getting at.
From the description of arithmetic operations in the PL/I LRM:
The two operands of an arithmetic operation can differ in type, base, mode,
precision, and scale. When they differ, conversion takes place as described
below. (For coded arithmetic operands, you can also determine conversions
using Results of arithmetic operations for one or more FLOAT operands. Each
operand is converted to the type, base, and mode of the result. It is not
necessarily converted to the result's precision and scale.)
Note: Scaled FIXED BINARY operands are converted to scaled FIXED DECIMAL
before any operations on them are performed.
So although the _result_ of ADD, SUBTRACT, MULTIPLY and DIVIDE do have the
correct base, calculation is carried out using decimal arithmetic.
"robin" <robin_v@bigpond.mapson.com> wrote in message
news:5uM5c.106620$Wa.11848@news-server.bigpond.net.au...[color=darkred]
> "John W. Kennedy" <jwkenne@attglobal.net> writes: > robin wrote:
Interactive Services[color=darkred]
realize:[color=darkred]
>
> They do on earlier versions of the product.
> When I raised it with Peter Elderon quite a while back,
> his reply was to the effect that they weren't
> ever going to change it.
> Looks like he has done it after all.
>
| |
| Mark Yudkin 2004-03-26, 11:00 pm |
| By dynamic condition handlers, I assume you mean the oddity known as
"Dynamically descendant ON-Units" - that a condition is handled by whatever
condition is on the top of the execution stack at the time the condition is
signalled, regardless of the fact that condition handling is active, so that
if a condition occurs during handling of the same condition, you get into a
recursion. This is, of course, a design blunder (or a mistake that couldn't
be fixed?). Interestingly, when VA PL/I added RESIGNAL, they made the
semantic of RESIGNAL correct (start at the current ON).
Anonymous pointer were half-fixed with HANDLEs. Unfortunately, the need for
TYPEs to have constant string, array and area bounds made them less useful
as a replacement than might have been planned. I have a requirement open to
address this ("parameterized types"), it has been accepted, but I have no
idea when, or if, it will be realized.
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:5cF5c.15159$F17.2195550@news4.srv.hcvlny.cv.net...
> PL/I was the most advanced language of 1965. It continues to be in some
> ways the most advanced language with mainstream support in z/OS. But
> there are a great many things that have happened in language design
> since 1965, some of them happening in explicit recognition of places
> where hindsight has shown PL/I to have made a mistake, such as GENERIC,
> anonymous pointers, dynamic condition handlers, automatic fixed-point
> scaling by rule, and integers treated as merely scaled fixed-point with
> q=0. It needs to be dragged into the 21st century if it is to continue
> to exist as anything but a legacy.
| |
| robin 2004-03-26, 11:00 pm |
| "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org> writes:
> If Peter had really broken ADD, SUBTRACT, MULTIPLY, DIVIDE to force decimal
> arithmetic, etc. we would have had major problems when we migrated our
> calendar arithmetic code from MVS to the PC that we'd have noticed it
> extremely quickly, and I'd have opened a high priority PMR. I know for a
> fact that we had no such problems.
You're obviously using a later version.
It's in black and white in the manual.
At the time, Peter said that he had never seen a program that
used scaled fixed binary.
| |
| robin 2004-03-26, 11:00 pm |
| "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org> writes:
> I think I see what you're getting at.
>
> From the description of arithmetic operations in the PL/I LRM:
I see that you found it (re scaled fixed binary).
> The two operands of an arithmetic operation can differ in type, base, mode,
> precision, and scale. When they differ, conversion takes place as described
> below. (For coded arithmetic operands, you can also determine conversions
> using Results of arithmetic operations for one or more FLOAT operands. Each
> operand is converted to the type, base, and mode of the result. It is not
> necessarily converted to the result's precision and scale.)
>
> Note: Scaled FIXED BINARY operands are converted to scaled FIXED DECIMAL
> before any operations on them are performed.
>
> So although the _result_ of ADD, SUBTRACT, MULTIPLY and DIVIDE do have the
> correct base, calculation is carried out using decimal arithmetic.
>
> "robin" <robin_v@bigpond.mapson.com> wrote in message
> news:5uM5c.106620$Wa.11848@news-server.bigpond.net.au...
> Interactive Services
> realize:
>
>
| |
| Peter Flass 2004-03-26, 11:00 pm |
| Since we're not SHARE members I can't propose this directly. I'd like
to see PL/I EXTERNAL preprocessor procedures, I.E %DECLARE
external_proc ENTRY EXTERNAL;
A reference to external_proc would pass varying strings as arguments
and return a varying string result. The procedure could be written in
PL/I, Rexx, or the language of your choice.
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<g5v4c.18249$%06.217@newsread2.news.pas.earthlink.net>...
> I hope to have a number (many) SHARE LNGC requirements "Open for Discussion" in
> the next few days (certainly by the end of next w). If your "site" is a
> SHARE member and you are not currently participating in the requirement process
> for:
>
> COBOL
> PL/I
> and/or
> LE (Language Environment)
>
> Please read and follow the information at:
> http://home.netcom.com/~wmklein/IBM...%20-%20LNGC.htm
>
> If you have already "registered" to participate in this (electronic only) method
> of influencing the future of these IBM products, please make certain that you
> "watch" the SHARE requirements website for new items for which your input is
> being solicited.
>
> SPECIAL NOTE:
> Although I will be entering a number of requirements (based on what I have
> heard as current needs/desires), creating and submitting requirements is open to
> ALL share member organizations and I would really, REALLY appreciate as many
> others creating new requirements as possible.
| |
| John W. Kennedy 2004-03-26, 11:00 pm |
| Mark Yudkin wrote:
> By dynamic condition handlers, I assume you mean the oddity known as
> "Dynamically descendant ON-Units" - that a condition is handled by whatever
> condition is on the top of the execution stack at the time the condition is
> signalled, regardless of the fact that condition handling is active, so that
> if a condition occurs during handling of the same condition, you get into a
> recursion. This is, of course, a design blunder (or a mistake that couldn't
> be fixed?). Interestingly, when VA PL/I added RESIGNAL, they made the
> semantic of RESIGNAL correct (start at the current ON).
That's a blunder, too, but what I meant is the executable ON statement
itself, an unwise carry-over into HLL of the semantic model of SPIE,
STAE, etc.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| John W. Kennedy 2004-03-26, 11:00 pm |
| Mark Yudkin wrote:
> I think I see what you're getting at.
>
> From the description of arithmetic operations in the PL/I LRM:
>
> The two operands of an arithmetic operation can differ in type, base, mode,
> precision, and scale. When they differ, conversion takes place as described
> below. (For coded arithmetic operands, you can also determine conversions
> using Results of arithmetic operations for one or more FLOAT operands. Each
> operand is converted to the type, base, and mode of the result. It is not
> necessarily converted to the result's precision and scale.)
>
> Note: Scaled FIXED BINARY operands are converted to scaled FIXED DECIMAL
> before any operations on them are performed.
>
> So although the _result_ of ADD, SUBTRACT, MULTIPLY and DIVIDE do have the
> correct base, calculation is carried out using decimal arithmetic.
There is no such note for the z/OS LRM.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| robin 2004-03-26, 11:00 pm |
| From: "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org>, CompuServe Interactive Services
Date: Fri, 19 Mar 2004 13:12:33 +0100
| I think I see what you're getting at.
|
| From the description of arithmetic operations in the PL/I LRM:
|
| The two operands of an arithmetic operation can differ in type, base, mode,
| precision, and scale. When they differ, conversion takes place as described
| below. (For coded arithmetic operands, you can also determine conversions
| using Results of arithmetic operations for one or more FLOAT operands. Each
| operand is converted to the type, base, and mode of the result. It is not
| necessarily converted to the result's precision and scale.)
|
| Note: Scaled FIXED BINARY operands are converted to scaled FIXED DECIMAL
| before any operations on them are performed.
|
| So although the _result_ of ADD, SUBTRACT, MULTIPLY and DIVIDE do have the
| correct base, calculation is carried out using decimal arithmetic.
..
No, when the arguments are fixed binary, and the result is
scaled, the result of ADD, SUBTRACT, MULTIPLY, and DIVIDE
is always FIXED DECIMAL, as I said before.
..
Furthermore, the precision & scale expressed to these functions
e.g., 31 and 5 in DIVIDE (J, K, 31, 5)
are taken as the number of DECIMAL digits, not BINARY digits.
..
Might be a good idea to check this out on your system.
..
Try (with 31 digit decimal):
MULT:
PROC OPTIONS (MAIN);
DECLARE (J, K) FIXED BINARY (31);
J = 1234; K = 1233;
PUT LIST (DIVIDE(J, K, 31, 25));
END MULT;
..
1.0008110300081103000811030
..
| "robin" <robin_v@bigpond.mapson.com> wrote in message news:5uM5c.106620$Wa.11848@news-server.bigpond.net.au...
| > "John W. Kennedy" <jwkenne@attglobal.net> writes: > robin wrote:
| > >
| > > > From: "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org>, CompuServe Interactive Services
| > > > Date: Sun, 14 Mar 2004 11:35:38 +0100
| > > > ..
| > > > | Currently, fixed bin and integer is even messier than you seem to realize:
| > > > | Under rules(ibm), fixed binary can be scaled,
| > > > ..
| > > > Not really. Try using the ADD, SUBTRACT, MULTIPLY, DIVIDE
| > > > builtins. They force conversion to FIXED DECIMAL,
| > > > which is a real pain.
| > >
| > > No they don't.
| >
| > They do on earlier versions of the product.
| > When I raised it with Peter Elderon quite a while back,
| > his reply was to the effect that they weren't
| > ever going to change it.
| > Looks like he has done it after all.
| >
| > > --
| > > John W. Kennedy
| |
| Mark Yudkin 2004-03-26, 11:00 pm |
| Executable ON statements also exist in other languages - e.g. Visual Basic.
A block-based model (try catch), may be better, but I'm not sure one can
call "executable ON statements" a blunder per se.
"John W. Kennedy" <jwkenne@attglobal.net> wrote in message
news:TDF6c.30719$E8.6985232@news4.srv.hcvlny.cv.net...
> Mark Yudkin wrote:
whatever[color=darkred]
is[color=darkred]
that[color=darkred]
into a[color=darkred]
couldn't[color=darkred]
>
> That's a blunder, too, but what I meant is the executable ON statement
> itself, an unwise carry-over into HLL of the semantic model of SPIE,
> STAE, etc.
>
> --
> John W. Kennedy
| |
| Mark Yudkin 2004-03-26, 11:00 pm |
| Scaled fixed binary is part of both the OS/2 GPI and Windows GDI APIs (fixed
bin (31, 16)). In OS/2, it is the core data type of the matrix
transformation, since OS/2 was designed to run on hardware without floating
point hardware. Peter Elderon is definitely aware of this, if only because I
complained about rule(ans) leading to compilation errors with the OS/2 and
Windows headers, and requesting that scaled fixed binary be permitted if
used explicitly.
"robin" <robin_v@bigpond.mapson.com> wrote in message
news:78C6c.111034$Wa.64265@news-server.bigpond.net.au...
> "Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org> writes:
>
decimal[color=darkred]
>
> You're obviously using a later version.
> It's in black and white in the manual.
>
> At the time, Peter said that he had never seen a program that
> used scaled fixed binary.
| |
| John W. Kennedy 2004-03-26, 11:00 pm |
| Mark Yudkin wrote:
> Executable ON statements also exist in other languages - e.g. Visual Basic.
Like _that's_ a recommendation!
In 30 years of professional programming in PL/I, writing everything from
2260 inventory inquiries to MVS delinkeditors to SYS1.VTAMLST-to-TCTTE
generators, I never needed the executable ON statement, and cannot
offhand think of any occasion when it would even have simplified things.
I regard it as as nasty as COBOL ALTERed GO TO, for the same reason:
it alters the state of the program with no visible datum.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| John W. Kennedy 2004-03-26, 11:00 pm |
| William M. Klein wrote:
> Do PL/I programmers REALLY have such great difficulty in removing other
> newsgroups from the "to" line when they post replies?
>
> If you think COBOL programmers are interested in your "snide" comments about
> COBOL - then GREAT, keep them in your posts.
>
> Otherwise, PLEASE remove "irrelevant" newsgroups in your posts!
If you think COBOL's ALTERed GO TO is in any way a good thing, then you
have no business working with computers. Please find some mode of
employment less dangerous to yourself and to others.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
| |
| Howard Brazee 2004-03-26, 11:00 pm |
|
On 22-Mar-2004, "John W. Kennedy" <jwkenne@attglobal.net> wrote:
> If you think COBOL's ALTERed GO TO is in any way a good thing, then you
> have no business working with computers. Please find some mode of
> employment less dangerous to yourself and to others.
I suppose the WWW is full of ALTERed GO TOs.
| |
| Peter Flass 2004-03-26, 11:00 pm |
| I tend to agree with you. It's too late to change now, but I'd be happy
to have an ON-statement associated with a block, so its scope would be
the entire block regardless of where it appears (though hopefully
first). If you needed to narrow the scope, use BEGIN..END to bracket
what needs the ON.
John W. Kennedy wrote:
> Mark Yudkin wrote:
>
>
>
> Like _that's_ a recommendation!
>
> In 30 years of professional programming in PL/I, writing everything from
> 2260 inventory inquiries to MVS delinkeditors to SYS1.VTAMLST-to-TCTTE
> generators, I never needed the executable ON statement, and cannot
> offhand think of any occasion when it would even have simplified things.
> I regard it as as nasty as COBOL ALTERed GO TO, for the same reason: it
> alters the state of the program with no visible datum.
>
| |
| Michael Mattias 2004-03-26, 11:00 pm |
| "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:LaM7c.50647$Fh4.2606@twister.nyroc.rr.com...[color=darkred]
> I tend to agree with you. It's too late to change now, but I'd be happy
> to have an ON-statement associated with a block, so its scope would be
> the entire block regardless of where it appears (though hopefully
> first). If you needed to narrow the scope, use BEGIN..END to bracket
> what needs the ON.
As a long-time BASIC language programmer, I've had access to "ON <some
event> " code... and have assiduously avoided it. Implementing this requires
the compiler to insert "checks" between every single statement, which can
really bog down performance and swell code size.
Sure, the size thing is no longer a big deal, and today's faster processors
pretty much negate the performance penalty, but surely an applications
programmer can do better than checking willy-nilly after EVERY statement...
I mean, why should you poll for an "event" after each one of five or six
separate MOVE or COMPUTE (or equivalent in other languages) statements?
Surely one check for the "event" after all these operations is sufficient;
and often, a check after each (well-designed) paragraph, or pehaps at the
next I-O should be sufficient.
ON EVENT may make it easy to write programs, but IMNSHO it makes it too easy
to write poor-performing programs.
--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com
| |
| robin 2004-03-26, 11:00 pm |
| From: "John W. Kennedy" <jwkenne@attglobal.net>, Optimum Online
Date: Mon, 22 Mar 2004 04:20:32 GMT
| Mark Yudkin wrote:
| > Executable ON statements also exist in other languages - e.g. Visual Basic.
|
| Like _that's_ a recommendation!
|
| In 30 years of professional programming in PL/I, writing everything from
| 2260 inventory inquiries to MVS delinkeditors to SYS1.VTAMLST-to-TCTTE
| generators, I never needed the executable ON statement, and cannot
| offhand think of any occasion when it would even have simplified things.
..
The ON statement is one of the most important and useful
statements in PL/I.
..
Can you guarantee that all your programs had absolutely no
hidden bugs?
..
The error handler in PL/I is used for all sorts of applications,
including extended range floating-point, complex acos,
and typical run-time data conditions such as fixed-point overflow,
floating-point overflow, division by zero (yes, you can include
a specific test for zero divisor in every division),
and so on.
..
Makes life a lot easier.
..
At the very least, you can obtain a snapshot of the
variables at the time of an error, without having to re-run
the program. And it gives you a traceback listing the
statement numbers of who called what.
..
| I regard it as as nasty as COBOL ALTERed GO TO, for the same reason:
| it alters the state of the program with no visible datum.
| --
| John W. Kennedy
| |
| robin 2004-03-26, 11:00 pm |
| From: "Michael Mattias" <michael.mattias@gte.net>, SBC http://yahoo.sbc.com
Date: Tue, 23 Mar 2004 12:48:17 GMT
| "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message news:LaM7c.50647$Fh4.2606@twister.nyroc.rr.com...
| > I tend to agree with you. It's too late to change now, but I'd be happy
| > to have an ON-statement associated with a block, so its scope would be
| > the entire block regardless of where it appears (though hopefully
| > first). If you needed to narrow the scope, use BEGIN..END to bracket
| > what needs the ON.
| > >> Executable ON statements also exist in other languages - e.g. Visual
| > >> Basic.
..
| As a long-time BASIC language programmer, I've had access to "ON <some
| event> " code... and have assiduously avoided it. Implementing this requires
| the compiler to insert "checks" between every single statement,
..
Not necessarily. It depends on the hardware.
For FIXEDOVERFLOW, OVERFLOW, UNDERFLOW, etc, where the
hardware has provision to detect such errors,
there is nothing inserted between each statement.
The only "cost" is the setup cost.
The hardware detects and traps such occurrences automatically.
..
Where it is not automatically detected: (e.g., Intel,
there is an instruction INTO (interrupt on overflow)
whose execution time is trivial (4 clocks)).
..
| which can
| really bog down performance and swell code size.
..
Writing programs in such a way that they can produce
wrong results without warning is irresponsible.
..
| Sure, the size thing is no longer a big deal, and today's faster processors
| pretty much negate the performance penalty, but surely an applications
| programmer can do better than checking willy-nilly after EVERY statement...
..
That's how the Ariane 5 space mission resulted in total loss --
caused by a simple integer overflow.
..
| I mean, why should you poll for an "event" after each one of five or six
| separate MOVE or COMPUTE (or equivalent in other languages) statements?
| Surely one check for the "event" after all these operations is sufficient;
..
The test, or an accumulation of the test, may still be needed
after each arithmetic operation where the (e.g.) overflow can occur.
..
| and often, a check after each (well-designed) paragraph, or pehaps at the
| next I-O should be sufficient.
..
By that time, the contents of many variables could have been changed,
and there is little or no evidence remaining of where the error
occurred and where the programmer should look for the cause of the error.
..
| ON EVENT may make it easy to write programs, but IMNSHO it makes it too easy
| to write poor-performing programs.
..
See above.
..
| --
| Michael Mattias
| |
| Michael Mattias 2004-03-26, 11:00 pm |
| "robin" <robin_v@bigpond.mapson.com> wrote in message
news:Ts38c.121645$Wa.29262@news-server.bigpond.net.au...
http://yahoo.sbc.com[color=darkred]
..[color=darkred]
>By that time, the contents of many variables could have been changed,
Not in my code.
MCM
| |
| Mark Yudkin 2004-03-31, 1:30 am |
| "robin" <robin_v@bigpond.mapson.com> wrote in message
news:Ts38c.121645$Wa.29262@news-server.bigpond.net.au...
> From: "Michael Mattias" <michael.mattias@gte.net>, SBC
http://yahoo.sbc.com
> Date: Tue, 23 Mar 2004 12:48:17 GMT
>
> | "Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:LaM7c.50647$Fh4.2606@twister.nyroc.rr.com...
> | > I tend to agree with you. It's too late to change now, but I'd be
happy
> | > to have an ON-statement associated with a block, so its scope would be
> | > the entire block regardless of where it appears (though hopefully
> | > first). If you needed to narrow the scope, use BEGIN..END to bracket
> | > what needs the ON.
> | > >> Executable ON statements also exist in other languages - e.g.
Visual
> | > >> Basic.
> .
> | As a long-time BASIC language programmer, I've had access to "ON <some
> | event> " code... and have assiduously avoided it. Implementing this
requires
> | the compiler to insert "checks" between every single statement,
> .
> Not necessarily. It depends on the hardware.
> For FIXEDOVERFLOW, OVERFLOW, UNDERFLOW, etc, where the
> hardware has provision to detect such errors,
> there is nothing inserted between each statement.
> The only "cost" is the setup cost.
> The hardware detects and traps such occurrences automatically.
> .
> Where it is not automatically detected: (e.g., Intel,
> there is an instruction INTO (interrupt on overflow)
> whose execution time is trivial (4 clocks)).
You forgot the cost of the FWAIT (or you end up with the dreaded imprecise
interrupt). Since this flushes the floating point queue, the cost of which
is by no means negligable. Needless to say, I do pay that cost, and
everything is compiled with noimprecise by default.
< rest snipped>
> | Michael Mattias
| |
| glen herrmannsfeldt 2004-03-31, 4:30 am |
| Mark Yudkin wrote:
(snip regarding overflow detection)
> You forgot the cost of the FWAIT (or you end up with the dreaded imprecise
> interrupt). Since this flushes the floating point queue, the cost of which
> is by no means negligable. Needless to say, I do pay that cost, and
> everything is compiled with noimprecise by default.
I haven't done this for a while now, but I thought the need
for FWAIT went away a few generations ago. The 8086 had the
external 8087, and it actually had to wait for it to finish
an operation. The coupling was slightly closer on the 80286,
with the 80287, and by the 80486 the FPU was internal.
I thought that with the 486 no FWAIT was required.
Then again, this is a strange newsgroup to ask.
-- glen
| |
| Mark Yudkin 2004-04-11, 4:30 am |
| Unfortunately, FWAIT is still around. You ask the compiler to generate FWAIT
instructions with the NOIMPRECISE option. Unfortunately, parts of the
runtime library don't issue FWAIT, thus leading to imprecise interrupts and
subsequent 8094 errors. I have a PMR open against ERFC for such an issue.
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:abvac.145400$Cb.1522768@attbi_s51...
> Mark Yudkin wrote:
>
> (snip regarding overflow detection)
>
imprecise[color=darkred]
which[color=darkred]
>
> I haven't done this for a while now, but I thought the need
> for FWAIT went away a few generations ago. The 8086 had the
> external 8087, and it actually had to wait for it to finish
> an operation. The coupling was slightly closer on the 80286,
> with the 80287, and by the 80486 the FPU was internal.
>
> I thought that with the 486 no FWAIT was required.
>
> Then again, this is a strange newsgroup to ask.
>
> -- glen
>
|
|
|
|
|