luating systems, you have three choices, fast,
> cheap
> > and good; choose two.
> >
> > -Original Message-
> > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> > l...@listserv.uga.edu] On Behalf Of Richard Kuebbing
> > Sent: Monday, Octo
ERV.UGA.EDU
> Subject: Re: The Pointlessness of handwriting "efficient" code (was One Byte
> MVC Versus IC/STC)
>
> The First Rule of Program Optimization: Don't do it. The Second Rule of
> Program Optimization (for experts only): Don't do it yet.
> When developing or ev
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Richard Kuebbing
Sent: Monday, October 16, 2017 13:24
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: The Pointlessness of handwriting "efficient" code (was One Byte
MVC Versus IC/STC)
Efficiency is doing things right. Effectivenes
@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Monday, October 16, 2017 3:02 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: The Pointlessness of handwriting "efficient" code (was One Byte
MVC Versus IC/STC)
And if Dave Cole isn't a high enough authority (but he is :-)),
"Programmers
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of David Cole
Sent: Monday, October 16, 2017 12:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: The Pointlessness of handwriting "efficient" code (was One Byte MVC
Ver
On 2017-10-16, at 10:23:50, David Cole wrote:
>
> But all these techniques for efficiency that IBM has created are not human
> compatible. They are too complex, they are too messy[!] and they are not even
> the same techniques from one machine to the next. In fact, sometimes code
> written to
llium Software is now a part of Syncsort.
-Original Message-
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robin Vowels
Sent: Monday, October 16, 2017 10:03 AM
To: MVS List Server 2 <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Subject: Re: One Byte MVC Versus I
, 2017 8:41 AM
To: 'IBM Mainframe Assembler List'
Subject: RE: One Byte MVC Versus IC/STC
And I suspect "it depends."
Are the operands already in cache? Must the processor do a read-to-write switch
on a cache line? What instructions came before? What come after? What is the
preceding and
IST@LISTSERV.UGA.EDU] On
Behalf Of Robin Vowels
Sent: Monday, October 16, 2017 7:03 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: One Byte MVC Versus IC/STC
From: "David S." <dlstaudac...@gmail.com>
Sent: Thursday, December 17, 2015 6:10 AM
>> > "... a good
Server 2 <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Subject: Re: One Byte MVC Versus IC/STC
From: "David S." <dlstaudac...@gmail.com>
Sent: Thursday, December 17, 2015 6:10 AM
>> > "... a good reason why small MVCs run slower than LG/STG pairs ...
>> >
From: "David S."
Sent: Thursday, December 17, 2015 6:10 AM
> "... a good reason why small MVCs run slower than LG/STG pairs ...
> overhead at the beginning of an MVC ... check if the operands are on
'good'
> boundaries ... check for operand overlap ... length check
David,
> > > "... a good reason why small MVCs run slower than LG/STG pairs ...
> > > overhead at the beginning of an MVC ... check if the operands are on
'good'
> > > boundaries ... check for operand overlap ... length check ...
[meanwhile] the
> > > LG/STG is far on its way. Anyone writing a
On 2015-12-16 12:10, David S. wrote:
>
> Nevertheless, IC/STC is what the newer mainframe compilers generate for a
> one-byte move. For the reasons given, it's less work for the system than
> an MVC.
>
For fortuitous alignment, is L; STC better? I'm confident that for adverse
alignment L is no
From: "David S."
Sent: Thursday, December 17, 2015 6:10 AM
> "... a good reason why small MVCs run slower than LG/STG pairs ...
> overhead at the beginning of an MVC ... check if the operands are on 'good'
> boundaries ... check for operand overlap ... length check ...
14 matches
Mail list logo