Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-18 Thread Paul Gilmartin
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-18 Thread Seymour J Metz
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-16 Thread Phil Smith III
I'd note this fun page: https://web.archive.org/web/20170108175446/http://www.jcmit.com/memoryprice.htm -- For IBM-MAIN subscribe / signoff /

Re: Instruction speeds

2019-08-16 Thread David Crayford
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Paul Gilmartin
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Jesse 1 Robinson
@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

Re: Instruction speeds

2019-08-15 Thread Tony Harminc
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Seymour J Metz
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Seymour J Metz
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-

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Seymour J Metz
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Matthew Stitt
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.

Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Nightwatch RenBand
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-15 Thread Mike Schwab
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Support, DUNNIT SYSTEMS LTD.
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Clark Morris
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)

Re: Instruction speeds

2019-08-14 Thread Charles Mills
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

Re: Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Jesse 1 Robinson
-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

Reason for 2 digit years was Re: Instruction speeds

2019-08-14 Thread Clark Morris
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

Re: Instruction speeds

2019-08-14 Thread Edward Finnell
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

Re: Instruction speeds

2019-08-14 Thread Raphaël Jacquot
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

Re: Instruction speeds

2019-08-14 Thread Paul Gilmartin
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

Re: Instruction speeds

2019-08-14 Thread Charles Mills
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

Re: Instruction speeds

2019-08-14 Thread Paul Gilmartin
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

Re: Instruction speeds

2019-08-14 Thread Seymour J Metz
, 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

Re: Instruction speeds

2019-08-14 Thread Jesse 1 Robinson
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

Re: Instruction speeds

2019-08-14 Thread Seymour J Metz
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

Re: Instruction speeds

2019-08-14 Thread Mike Schwab
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

Re: Instruction speeds

2019-08-14 Thread Charles Mills
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

Re: Instruction speeds

2019-08-14 Thread Joel C. Ewing
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

Re: Instruction speeds

2019-08-14 Thread Pommier, Rex
@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

Re: Instruction speeds

2019-08-14 Thread Peter Relson
>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

Re: Instruction speeds

2019-08-14 Thread Greg Price
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

Re: Instruction speeds

2019-08-14 Thread Raphaël Jacquot
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

Re: Instruction speeds

2019-08-14 Thread Vernooij, Kees (ITOP NM) - KLM
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:

Re: Instruction speeds

2019-08-14 Thread Vernooij, Kees (ITOP NM) - KLM
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

Re: Instruction speeds

2019-08-14 Thread David Crayford
Some interesting information on branch prediction in that paper. If you've got a z/OS C++ compiler try this snippet out, it's fascinating: https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array On 2019-08-13 11:47 PM, Charles

Re: Instruction speeds

2019-08-13 Thread Jim Mulder
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

Re: Instruction speeds

2019-08-13 Thread CM Poncelet
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

Re: Instruction speeds

2019-08-13 Thread CM Poncelet
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'

Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
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

Re: Instruction speeds

2019-08-13 Thread Tony Harminc
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

Re: Instruction speeds

2019-08-13 Thread Christopher Y. Blaicher
@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

Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
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

Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
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

Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
It's almost impossible to compare timings between processors except in the context of a well defined benchmark; run a different benchmark and you get a different answer. A classic example is comparing a 370/158 to a 4341; use packed decimal heavily and you get one answer; use floating point

Re: Instruction speeds

2019-08-13 Thread Pew, Curtis G
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

Re: Instruction speeds

2019-08-13 Thread Seymour J Metz
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

Re: Instruction speeds

2019-08-13 Thread Jesse 1 Robinson
-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. >

Re: Instruction speeds

2019-08-13 Thread John McKown
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

Re: Instruction speeds

2019-08-13 Thread Tony Harminc
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,

Re: Instruction speeds

2019-08-13 Thread Rick J. Valles
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

Re: Instruction speeds

2019-08-13 Thread Brian Chapman
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 maintenance. Especially since assembler programming is becoming a dying

[SUSPECTED SPAM] Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Gord Tomlin
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)

Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Charles Mills
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

Re: Instruction speeds

2019-08-13 Thread Charles Mills
A GREAT introduction to this topic, by someone who unlike me actually knows what he is talking about: https://linuxmain.blogspot.com/2017/02/zoptimizationprimer.html Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian

Re: Instruction speeds

2019-08-13 Thread Steve Smith
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

Re: Instruction speeds

2019-08-13 Thread Charles Mills
+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

Re: Instruction speeds

2019-08-13 Thread Charles Mills
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

Re: Instruction speeds

2019-08-13 Thread Giliad Wilf
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

Re: Instruction speeds

2019-08-13 Thread Charles Mills
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

Re: [SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Brian Chapman
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

Re: Instruction speeds

2019-08-13 Thread Brian Chapman
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

[SUSPECTED SPAM] Re: Instruction speeds

2019-08-13 Thread Mike Shaw
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

Re: Instruction speeds

2019-08-13 Thread Giliad Wilf
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;

Re: Instruction speeds

2019-08-13 Thread Brian Chapman
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 direct register manipulation was the fastest. On the topic of cache, how do I know that my literal pool

Re: Instruction speeds

2019-08-13 Thread Charles Mills
I second everything Chris Blaicher says. You just cannot say how long an instruction takes. Let me give you an example. (The example is based on theoretical concepts and has not been tested or benchmarked.) Let's say you had some tight loop that was executed many thousands or millions of

Re: Instruction speeds

2019-08-12 Thread Christopher Y. Blaicher
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 is important. The machine will do out-of-order instruction processing, but there are limits. If you load a register don't use it

Re: Instruction speeds

2019-08-12 Thread Mike Schwab
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

Re: Instruction speeds

2019-08-12 Thread Jesse 1 Robinson
This question touches a nerve. In my very first job in IT, I was tasked to (re)write a program that tabulated the contents of a large master file. The idea was to examine each record and record its 'type' in a table. This was 1978. I was fresh out of programming school. Sort of starry eyed, I

Re: Instruction speeds

2019-08-12 Thread CM Poncelet
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