On Sun, 18 Aug 2019 20:43:52 +, Seymour J Metz wrote:
>
> 5. No memory pricing for any of the 7 dwarves (BUNCH, RCA and General
> Electric),
>Bendix, Data General, DEC, PB, Philco, SDS, Sylvania, TRW or the major
> European manufacturers.
>
The DEC PDP-6 was relentlessly asynchronous
Sent: Friday, August 16, 2019 7:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was Re: Instruction speeds
I'd note this fun page:
https://secure-web.cisco.com
On 2019-08-16 3:17 AM, Tony Harminc wrote:
This is really interesting. For those put off by the "C++" note that the
issue has nothing whatsoever to do with C++. It is a pure branch prediction
issue. Picture a program that computes an array of pseudo-random 8-bit
integers from 0 to 255. Then it
On Thu, 15 Aug 2019 00:46:00 -0500, Support, DUNNIT SYSTEMS LTD. wrote:
>2 digit years I recall a shop who throughout the 70's implemented 1 digit
>year dates across their files because of the precious cost and availability of
>DASD space. In 1979, someone there took are hard look at what
@LISTSERV.UA.EDU
Subject: (External):Re: Reason for 2 digit years was Re: Instruction speeds
> foremoms and foredads
Some of us were there at the time. I've lost track of the number of times that
I've criticized something only to be accused, decades later, of only having
"20-20 hindsight&quo
On Wed, 14 Aug 2019 at 18:56, Charles Mills wrote:
> This is really interesting. For those put off by the "C++" note that the
> issue has nothing whatsoever to do with C++. It is a pure branch prediction
> issue. Picture a program that computes an array of pseudo-random 8-bit
> integers from 0
List on behalf of
Clark Morris
Sent: Wednesday, August 14, 2019 6:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Reason for 2 digit years was Re: Instruction speeds
[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:
>There were other opti
u.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Jesse 1 Robinson
Sent: Wednesday, August 14, 2019 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was Re: Instruction speeds
It's a modern day cottage industry--or hobby maybe-
bytes.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Nightwatch RenBand
Sent: Thursday, August 15, 2019 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Reason for 2 digit years was Re: Instruction
I worked at such company that had 1 digit years. The routine(s) to keep them
straight across the decades I never did fully understand.
OTOH, I also worked at a small Insurance company. The best (non) joke was when
a client called regarding a new build discount she was getting on her house.
My first programming experience was in the mid to late 1960's and even then
there were "old timers" who explained things like this in lurid detail;
perhaps, as King Henry V said " with advantages what feats he did that
day". As I remember they said that the problem was memory. They programmed
on
I interned in a catalog sales company in the marketing department in
1984. Used 1 digit year and purged sales data over 6 years old.
On Thu, Aug 15, 2019 at 12:46 AM Support, DUNNIT SYSTEMS LTD.
wrote:
>
> 2 digit years I recall a shop who throughout the 70's implemented 1 digit
> year
2 digit years I recall a shop who throughout the 70's implemented 1 digit
year dates across their files because of the precious cost and availability of
DASD space. In 1979, someone there took are hard look at what the future held
in store. So they did a full conversion project and changed
List On Behalf Of
>Clark Morris
>Sent: Wednesday, August 14, 2019 3:29 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Reason for 2 digit years was Re: Instruction speeds
>
>[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main
>sme...@gmu.edu (Seymour J Metz)
s to do with
modern CPU technology, not C++.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Tuesday, August 13, 2019 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
Some int
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Clark Morris
Sent: Wednesday, August 14, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Reason for 2 digit years was Re: Instruction speeds
[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main
t;To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000,
>insurance companies apparently coasted along because they had ALWAYS needed to
&g
IBM has published the LSPR numbers for thirty years. They're a ballpark of what
to expect.Each company should have a benchmark workload for capacity planning
and growth. In 2017 WDC came out with MF counters to help measure the effects
of different
Le 14/08/2019 à 18:10, Jesse 1 Robinson a écrit :
A couple of observations on Y2K accommodation.
-- As my shop was slogging through remediation required for year 2000,
insurance companies apparently coasted along because they had ALWAYS needed to
handle four-digit years from the inception of
On Wed, 14 Aug 2019 11:34:14 -0700, Charles Mills wrote:
>... Not to mention that time in microseconds since 1900 would have fit in a
>64-bit integer.
>
With a several thousand year range. And when another choice was made
there were many extant birth dates and contract dates prior to 1900. I
o decimal as punched into Hollerith cards and printed on reports.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Seymour J Metz
Sent: Wednesday, August 14, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction spee
On Wed, 14 Aug 2019 17:21:06 +, Seymour J Metz wrote:
>There were other options to reduce the storage requirement of a date, e.g.,
>store them in binary.
>
In some cases, dates have been stored in two-byte signed decimal, biased
by -1900, supporting dates through 2899 with minimal code
, 2019 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
A couple of observations on Y2K accommodation.
-- As my shop was slogging through remediation required for year 2000,
insurance companies apparently coasted along because they had ALWAYS needed to
handle four-digit years
Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: Wednesday, August 14, 2019 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Instruction speeds
> That assumes that you know w
mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, August 14, 2019 2:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
And: don't write unnecessary code.
A nice example is how to determine leap yea
gt; Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Vernooij, Kees (ITOP NM) - KLM
> Sent: Wednesday, August 14, 2019 1:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [External] Re: Instruction speeds
>
> And: don't write unnecessary
than three times as far away as 2000 was in 1970.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pommier, Rex
Sent: Wednesday, August 14, 2019 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
H
On 8/14/19 5:29 AM, Raphaël Jacquot wrote:
> Le 14/08/2019 à 08:18, Vernooij, Kees (ITOP NM) - KLM a écrit :
>> And: don't write unnecessary code.
>> A nice example is how to determine leap years: from as long as I
>> program the flow is:
>> - dividable by 4?
>> - dividable by 100?
>> - dividable
@LISTSERV.UA.EDU
Subject: [External] Re: Instruction speeds
And: don't write unnecessary code.
A nice example is how to determine leap years: from as long as I program the
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?
The last 2 are completely unnecessary until the year 2100
>JNE generates the same machine instruction as BNE, etc.
Not true.
BNE generates the same machine instruction as BC x (47xy).
JNE generates the same machine instruction as BRC x (A7x4).
Peter Relson
z/OS Core Technology Design
On 2019-08-14 8:40 PM, Raphaël Jacquot wrote:
that's what they said in 1965 when they were storing years in dates on 2
digits...
hilarity ensued in 1999 when they were all panicked that their 1964
vintage cobol code world would crumble...
Yeah...
Didn't Fred Brooks in "The Mythical Man
Le 14/08/2019 à 08:18, Vernooij, Kees (ITOP NM) - KLM a écrit :
And: don't write unnecessary code.
A nice example is how to determine leap years: from as long as I program the
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?
The last 2 are completely unnecessary until the
It may be fast, but it runs a long time. Talking about 'speed'!
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rick J. Valles
> Sent: 13 August, 2019 18:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re:
August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
>
> Avoid processor-specific optimizations; what is millicode on one box may
> not be on another. Worry first about getting your code correct and
> maintainable.
>
>
> --
> Shmue
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds
Hi everyone,
I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times
This link has been posted here before, but in case anyone missed it,
https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf
Jim Mulder
BTW Change "LHI 4,4096*512" and "LHI 5,4096*1024" to something like
"LHI 4,4096*16-1"etc. or it will not fit in a halfword - just wrote it
"off the top of my head" without checking. :-(
On 14/08/2019 03:24, CM Poncelet wrote:
> FWIW
>
> On the Hitachi Skyline bipolar mainframe (from
FWIW
On the Hitachi Skyline bipolar mainframe (from 1995), the instruction
processor speeds were:
- RR: 3ns.
- SS: 6-10ns if L2 cached, else 60-80ns if data-fetched from central
storage.
On IBM's CMOS G4 mainframes:
- RR: 20ns approx.
- SS: no idea, did not check.
IBM said it had 'improved'
Discussion List on behalf of
Christopher Y. Blaicher
Sent: Tuesday, August 13, 2019 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
Sorry, but 360 timings have no relevance to today's systems. Out-of-order
processing, executing up to 6 instructions concurrently and a myriad
If you are interested in how these things work under the covers (regardless
of whether it is possible or useful to minutely optimize your code these
days), you might check out any of the several presentations done at SHARE
and other places by Bob Rogers, now retired from IBM, under titles like
@LISTSERV.UA.EDU] On Behalf
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman wrote:
>Hi everyone,
>
>I did some searching, but I didn't find anything that really
on behalf of
Christopher Y. Blaicher
Sent: Monday, August 12, 2019 9:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
There is no instruction cycle time table. There are some general guidelines
you can follow.
Don't overload cache. Locality of reference for instructions and data
List on behalf of
Mike Shaw
Sent: Tuesday, August 13, 2019 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SUSPECTED SPAM] Re: Instruction speeds
On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> ..>
> JUMPs are faster than BRANCHes.
> .
I don't know what you mean b
8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds
Hi everyone,
I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?
For example; moving
On Aug 13, 2019, at 11:26 AM, Jesse 1 Robinson wrote:
>
> My advice is always to make it easy for next guy. Chances are, over time, the
> 'next guy' will be the future you.
Amen. The advice I give (I got it from Eric S. Raymond) is “Always write code
as if the next person who will maintain
Discussion List on behalf of
Brian Chapman
Sent: Tuesday, August 13, 2019 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
Thanks Charles and Steve.
Now that I am becoming a more experience assembler programmer, I have
wondered if I should be greatly concerned about instruction
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
John McKown
Sent: Tuesday, August 13, 2019 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Instruction speeds
On Tue, Aug 13, 2019 at 11:10 AM Brian Chapman wrote:
> Thanks Charles and Steve.
>
On Tue, Aug 13, 2019 at 11:10 AM Brian Chapman wrote:
> Thanks Charles and Steve.
>
> Now that I am becoming a more experience assembler programmer, I have
> wondered if I should be greatly concerned about instruction timings or
> pipeline order, or just simply focus on readability and
On Tue, 13 Aug 2019 at 11:39, Steve Smith wrote:
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions. Surely by now, this should go
> without saying. Regardless of whether they're "faster" or not, they are
> much better,
Here’s my IEFBR15 “Utility” - it’s pretty fast:
Active Usings: None
Loc Object CodeAddr1 Addr2 Stmt Source Statement
000 2 1 IEFBR15 CSECT
00 07FF 2 BR15
3 END
On 2019-08-13 10:33, Mike Shaw wrote:
JNE generates the same machine instruction as BNE, etc.
Nope.
Are you possibly fooling yourself by looking at code that uses IEABRC or
IEABRCX?
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905)
UA.EDU] On Behalf
Of Mike Shaw
Sent: Tuesday, August 13, 2019 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SUSPECTED SPAM] Re: Instruction speeds
On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> ..>
> JUMPs are faster than BRANCHes.
> .
I don't know what you
Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds
Hi everyone,
I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most
Write good code and forget about instruction timings. With any luck your
code will have to perform on several generations of architecture and
machines.
There's a big difference between B- (base-index-displacement) branches and
J- (or BR-) (relative address) instructions. Surely by now, this
+1
Hardware is cheap. Programmers (and bugs!) are expensive.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
hapman
Sent: Tuesday, August 13, 2019 7:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds
Thanks everyone for your input. I learned a lot from these responses. I
actually meant to write ADD HALFWORD IMMEDIATE in my original email. I was
surprised to hear about LA. I had assumed that
Hi Brian,
I did not see this sort of publications for three or four decades.
Maybe IBM zServer engineers still use some instruction timing charts during
chip design/development.
As far as I'm concerned, my emphasis while coding is on clarity and
readability.
Regards,
On Tue, 13 Aug 2019
ittle while and an L takes a really long time. (How's
that for technical precision?)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Brian Chapman
Sent: Tuesday, August 13, 2019 7:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re
Mike,
I believe the difference is related to the fact that branch instructions
require a base register and jump does not.
Thank you,
Brian Chapman
On Tue, Aug 13, 2019 at 10:40 AM Mike Shaw wrote:
> On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> > ..>
> > JUMPs are faster than
Thanks Giliad. This is what I was searching for. I understand that the
timings in this document are very old and probably wildly inaccurate for
today's Z systems, but would it be on a relative scale? Would a LR be twice
the speed of a L?
Thank you,
Brian Chapman
On Tue, Aug 13, 2019 at 10:28
On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
..>
JUMPs are faster than BRANCHes.
.
I don't know what you mean by that Chris.
The various types of Jump instructions are just extended mnemonics for
various types of Branch instructions. JNE generates the same machine
On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman wrote:
>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed this
>on the topic that I'm interested. Is there anything published that compares
>the cycle times of the most used instructions?
>
>For example;
;instructions take no time at all; memory accesses take forever."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 5:48 PM
> To:
."
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds
Hi everyone,
I did some searching, but I di
Blaicher
Technical Architect
Syncsort, Inc.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Brian Chapman
Sent: Monday, August 12, 2019 8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds
Hi everyone,
I did some searching
1. Speed within the highest level cache are publish, along with the
slowdown for lower levels of cache. Paging in speeds are not covered.
2. Varies between processors.
3. If you can avoid base and index registers, you can gain quite a bit of
speed by avoiding address arithmetic. And I think the
Discussion List On Behalf Of
Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Instruction speeds
Hi everyone,
I did some searching, but I didn't find anything that really discussed this on
the topic that I'm interested. Is there anything
I have always used 'immediate' instructions (AHI etc.) when possible, as
they are embedded in the instruction code and need no data fetches from
L2 cache.
On 13/08/2019 01:48, Brian Chapman wrote:
> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed this
> on
Hi everyone,
I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?
For example; moving an address between areas of storage. I would assume
that
69 matches
Mail list logo
