Both BFP and DFP are IEEE-standard. Both are more portable if that
means usable outside IBM environments, than HFP; but this portability
is compromised by big- and little-endian differences.
In general, HFP values are readily converted into BFP or DFP ones
using hardware instructions on a
I can only speak for the insurance company that I am working with
since a very long time now.
For them, the portability across platforms of the non-trivial
arithmetic package
is the most important challenge, and so they decided to do it all in C,
(using HFP
on the mainframe, because at the
On Fri, 28 Feb 2014 00:43:02 +0100, Bernd Oppolzer wrote:
I can only speak for the insurance company that I am working with
since a very long time now.
For them, the portability across platforms of the non-trivial arithmetic
package
is the most important challenge, and so they decided to do it
On 25 Feb 2014 15:16:54 -0800, in bit.listserv.ibm-main you wrote:
There is evidence that IBM's COBOL people are thinking hard about
making Mike Cowlishaw's ANSI-standard DFP available in COBOL. They
may even have progressed further. Tom can, however, speak for himself
and will, I suspect, do
There is evidence that IBM's COBOL people are thinking hard about
making Mike Cowlishaw's ANSI-standard DFP available in COBOL. They
may even have progressed further. Tom can, however, speak for himself
and will, I suspect, do so.
Actually, we have it on our list of things that we will for sure
In 1068899486.316495.1393186164299.javamail.r...@comcast.net, on
02/23/2014
at 08:09 PM, DASDBILL2 dasdbi...@comcast.net said:
Just for future reference, since the name of this list-server is IBM
Mainframe Discussion List, what particular IBM systems, other than
System/360 and its descendants,
On Mon, 24 Feb 2014 09:00:43 -0500, Shmuel Metz (Seymour J.) wrote:
on 02/23/2014 at 08:09 PM, DASDBILL2 said:
Just for future reference, since the name of this list-server is IBM
Mainframe Discussion List, what particular IBM�systems, other than
System/360 and its descendants, are also called
paulgboul...@aim.com (Paul Gilmartin) writes:
Surely, when comparing technologies hardware and software from other
vendors should not be considered off-charter.
re:
http://www.garlic.com/~lynn/2014c.html#62 Optimization, CPU time, and related
issues
http://www.garlic.com/~lynn/2014c.html#64
In
caarmm9rptczsrhfjzecu8vmto_hvpfjnm0wn_amihxpjgxa...@mail.gmail.com,
on 02/21/2014
at 06:47 PM, Tony Harminc t...@harminc.net said:
It was surely clear from the context that I was speaking of the S/360
and its descendants.
That may have been your intent; it was clear to me that in channel
.) shmuel+ibm-m...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, February 22, 2014 7:35:54 PM
Subject: Re: Optimization, CPU time, and related issues
In
caarmm9rptczsrhfjzecu8vmto_hvpfjnm0wn_amihxpjgxa...@mail.gmail.com,
on 02/21/2014
at 06:47 PM, Tony Harminc t...@harminc.net
In 2459250746283941.wa.paulgboulderaim@listserv.ua.edu, on
02/19/2014
at 09:10 AM, Paul Gilmartin paulgboul...@aim.com said:
ObQoheleth?
Indeed, for there is nothing new under the Sun.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
In
caarmm9rzepkzt2z1eb2rqcjxeildu75-9bxjbkeech++ay1...@mail.gmail.com,
on 02/19/2014
at 02:43 PM, Tony Harminc t...@harminc.net said:
No what?
No, that is not how conditional branching in channel programs has
always worked.
I think we need a counter for your yearly use of this cliché,
I
On 20 February 2014 21:40, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
on 02/19/2014 at 02:43 PM, Tony Harminc t...@harminc.net said:
I didn't suggest, let alone say, anything counter to this.
Then who wrote Indeed this is the way conditional execution and
branching works (and
On 2/18/2014 1:59 PM, John Gilmore wrote:
... The cache
and other such programmer-inaccessible machinery are devices for
optimizing and in particular speeding up the code that programmers
write or translators generate.
Their characteristics, mostly but not entirely undocumented, must be
Ed Jaffe opines:
Of course, Fugget about it is expected from IBM, but there are
software vendors making a comfortable living helping their customers
save serious cash by minimizing their monthly peak R4HAs. Some of them
spread out batch workload; some of them raise, lower, and move LPAR caps
From: Timothy Sipples sipp...@sg.ibm.com
To: IBM-MAIN@listserv.ua.edu
Date: 19/02/2014 09:11
Subject:Re: Optimization, CPU time, and related issues
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
Ed Jaffe opines:
Of course, Fugget about it is expected from
Most of what Timothy Sipples says is fair controversial comment on
Edward Jaffe's post. His use of the verb 'opines' is not. As far
back as the Alexandrian rhetoricians money collected for my worthy
cause has gone into a 'war chest' and that collected to advance your
despicable ends has instead
On Wed, 19 Feb 2014 05:40:10 -0500, John Gilmore wrote:
Marketing people, those of both IBM and
its competitors, do of course try to put the best possible face on the
characteristics of their products; and it would be naif to expect them
to behave differently.
tis a pity some of them choose to
John Gilmore wrote:
snip
Locality of reference was always a good notion, and now it is
a crucially important one.
snip
I would like to ask some additional questions in this context:
How precise are the measures provided by TIMEUSED?
Do these measures take into account the delays caused by cache
Arthur,
In my experience the TIMEUSED macro is useful chiefly for timing the
CP usage of entire routines, which may of course be short ones, not
individual instructions.
Care is required in using it. The two successive TIMEUSED macros
employed to obtain a difference/measurement should be so
On Tue, 18 Feb 2014 18:39:42 -0500, Shmuel Metz (Seymour J.) wrote:
at 01:47 PM, Tony Harminc t...@harminc.net said:
Indeed this is the way conditional execution and branching works (and
has always worked) in channel programs.
No. Every generation believes that it invented sex, ...
This chart has helped me:
http://xkcd.com/1205/
Regards,
Greg Shirey
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
On 18 February 2014 18:39, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
on 02/18/2014 at 01:47 PM, Tony Harminc t...@harminc.net said:
Indeed this is the way conditional execution and branching works (and
has always worked) in channel programs.
No.
No what?
Every generation
I have one work task. Use to do it about twice a week, because that
was all the typing I could stand. So I wrote an Access DB to hold the
info, and a script to read the files from the various servers that
needed to be checked. Now I can double click on all the servers in 5
hours every day, and
re:
http://www.garlic.com/~lynn/2014c.html#62 Optimization, CPU time, and related
issues
aka the internal operation of the machine ... and the execution elements
actually being managed ... are becoming less less directly related to
the external instruction architecture.
for instance, risk
re:
http://www.garlic.com/~lynn/2014c.html#62 Optimization, CPU time, and related
issues
aka the internal operation of the machine ... and the execution elements
actually being managed ... are becoming less less directly related to
the external instruction architecture.
for instance, risk
On 19/02/2014 4:00 PM, Ed Jaffe wrote:
On 2/18/2014 1:59 PM, John Gilmore wrote:
... The cache
and other such programmer-inaccessible machinery are devices for
optimizing and in particular speeding up the code that programmers
write or translators generate.
Their characteristics, mostly but
It's also getting extremely hard to keep electrons properly corralled
within microprocessors as the fabrication processes increasingly hit the
limits of physics. Those physical and physics limits will naturally
increase the emphasis on coding for efficiency. It's hard to predict
precisely how hard
On 2/18/2014 12:06 AM, Timothy Sipples wrote:
I also agree with the opinions expressed about optimizing where it makes
the most sense (or dollars, euro, yen) and only there, in some priority
order. Though I'd mostly disagree about that additional peak MSU.
Of course, Fugget about it is
Ed Jaffe wrote:
To put into perspective, it took 13 cycles to access a doubleword operand on a
S/360 Model 91. That same memory access on a zEC12 can now be up to 75 TIMES
slower (relatively speaking).
Interesting. Did you measured that with a handheld tamperproof stopwatch? ;-D
;-D
Does
On Tue, 18 Feb 2014 01:09:30 -0800, Ed Jaffe wrote:
Of course, Fugget about it is expected from IBM, but there are
software vendors making a comfortable living helping their customers
save serious cash by minimizing their monthly peak R4HAs.
ROTFLMAO ...
What a concept, *helping* customers save
On 2/18/2014 9:40 AM, Tom Marchant wrote:
On zOS machines you'd need to
specify the skip amount to make them usable in general, or use macros?
Why? The next instruction would already have been fetched, as well as the
following instruction.
How could a macro help the hardware process a new
On Tue, 18 Feb 2014 09:50:55 -0500, Gerhard Postpischil gerha...@charter.net
wrote:
On 2/18/2014 9:40 AM, Tom Marchant wrote:
The next instruction would already have been fetched, as well as the
following instruction.
How could a macro help the hardware process a new instruction?
I was
On 17 Feb 2014 13:42:30 -0800, in bit.listserv.ibm-main you wrote:
Starting a new thread .
This discussion leads to a new thought. There may be a greater need
for USAGE BIT, DECIMAL FLOATING POINT and IEEE floating point in COBOL
programs. There also are added instructions related to these.
On 2/18/2014 3:26 AM, Elardus Engelbrecht wrote:
Ed Jaffe wrote:
To put into perspective, it took 13 cycles to access a doubleword operand on a
S/360 Model 91. That same memory access on a zEC12 can now be up to 75 TIMES
slower (relatively speaking).
Interesting. Did you measured that with
On 2/18/2014 10:09 AM, Tom Marchant wrote:
Ok, I see what you mean about using a macro to generate Skip the
next 4 byte instruction. I still contend that coding the length of
the next instruction wouldn't be necessary because the processor
would already know the length of the next instruction.
re:
http://www.garlic.com/~lynn/2014c.html#62 Optimization, CPU time, and related
issues
aka the internal operation of the machine ... and the execution elements
actually being managed ... are becoming less less directly related to
the external instruction architecture.
for instance, risk
My suggestion is, that the new instruction
SKPNZ (for example)
skips the following instruction, if the CC is NZ.
That is, the following instruction should not be executed,
but of course the opcode of the following instruction has to be fetched,
which gives the length of the instruction and
On Tue, 18 Feb 2014 21:44:16 +0100, Bernd Oppolzer bernd.oppol...@t-online.de
wrote:
The key is: the hardware today doesn't have the possibility to fetch an
instruction,
but not execute it.
Sure it does. It happens all the time when branch prediction guesses wrong.
--
Tom Marchant
Ed Jaffe wrote
begin extract
Most of that is non-sequitur. We've already established in prior
conversations that uncached memory access is approaching 1000 cycles
on modern System z machines. That's roughly 75 times slower
(relatively speaking) than memory access speed on the Model 91.
/end
There is evidence that IBM's COBOL people are thinking hard about
making Mike Cowlishaw's ANSI-standard DFP available in COBOL. They
may even have progressed further. Tom can, however, speak for himself
and will, I suspect, do so.
The problems with HFP and BFP in business applications center on
In
CAArMM9TjtWJBYsHTB5eDHC38tBoFeEO8eZT90iwn9XmcC2=m...@mail.gmail.com,
on 02/18/2014
at 01:47 PM, Tony Harminc t...@harminc.net said:
Indeed this is the way conditional execution and branching works (and
has always worked) in channel programs.
No. Every generation believes that it invented
Starting a new thread .
It seems to me that as the hardware has gotten faster and faster, it is
tempting to think that optimization and CPU time no longer matter. I think
three things have conspired to make that thought not true:
1. Of course as hardware has gotten faster and faster, transaction
My objection to sentiments like
. . . as the hardware has gotten faster and faster, it is tempting to
think that optimization and CPU time no longer matter.
is of a different sort.
They erode the notion that craftsmanship is important. It is easy to
make fun of attempts to shave a µsec from
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Monday, February 17, 2014 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Optimization, CPU time, and related issues
My objection to sentiments like
. . . as the hardware has gotten faster and faster
On Feb 17, 2014, at 3:42 PM, Charles Mills wrote:
Starting a new thread .
--
SNIP--
2. Much of the increase in speed has been due to increased numbers of
processors per box. That gives the customer
On 2/17/2014 1:42 PM, Charles Mills wrote:
It would be an interesting exercise to try to figure out an estimated dollar
cost for a million instructions executed per day, using an assumed typical
installation and an assumed typical mix of IBM and non-IBM software
Sub-capacity pricing for IBM
Hello,
when we discussed the one bit copy topic recently, I had a solution
in mind that was kind of inspired by the new store on condition
instruction,
but there was no such solution, because a instruction like OI on condition
or NI on condition would have been necessary, and there are no such
On 2/17/2014 7:34 PM, Bernd Oppolzer wrote:
My question is: if we had such an instruction, how would this fit into the
overall machine concept? And: are there some performance benefits,
or are there some problems with this approach, which I do not see?
I'm sure, that some historical machines
: Optimization, CPU time, and related issues
Hello,
when we discussed the one bit copy topic recently, I had a solution in mind
that was kind of inspired by the new store on condition
instruction,
but there was no such solution, because a instruction like OI on condition
or NI on condition would have been
On Mon, 17 Feb 2014 20:05:12 -0500, Gerhard Postpischil wrote:
On 2/17/2014 7:34 PM, Bernd Oppolzer wrote:
My question is: if we had such an instruction, how would this fit into the
overall machine concept? And: are there some performance benefits,
or are there some problems with this
On Mon, Feb 17, 2014 at 6:34 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:
Hello,
when we discussed the one bit copy topic recently, I had a solution
in mind that was kind of inspired by the new store on condition
instruction,
but there was no such solution, because a instruction like
: Monday, February 17, 2014 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Optimization, CPU time, and related issues
Hello,
when we discussed the one bit copy topic recently, I had a solution in
mind
that was kind of inspired by the new store on condition
instruction,
but there was no such solution
Skip Robinson wrote:
Finally caving in to overwhelming temptation.
All of us have this ONE temptation because of branch prediction, cache,
optimization, etc:
My proposed code would really be this, but I can at most just dream... ;-D
PPB 1000 (Predict and Prevent Bugs in next 1000
On 2/18/2014 12:11 AM, Skip Robinson wrote:
L Rn,COUNTERFetch the counter
LA Rn,1(,Rn)Increment the count
ST Rn,COUNTER Update the counter
I realize hindsight is wonderful, but I can't keep wondering why you
didn't use something like:
LA Rn,1
AL Rn,COUNTER
55 matches
Mail list logo
