On 08/05/2018 08:13 AM, Robin Vowels wrote:
From: "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, August 03, 2018 3:09 AM
A principal use of EX is to be able to use a register mask to
modify the
target. CDC 3800 had a clever alternative to
- Original Message -
From: "Steve Thompson"
To:
Sent: Monday, August 06, 2018 4:21 AM
Subject: Re: EX
On 08/05/2018 08:13 AM, Robin Vowels wrote:
From: "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, August 03, 2018 3:09
On 2018-08-05, at 19:30:25, Robin Vowels wrote:
>
> Of course. In the context, EX can modify everything.
>
> And anyway, why would you want to EX an EX?
>
Wrong question to ask a programmer. My maxim:
• Unix was not designed to stop you from doing stupid things,
On 06/08/2018 02:30, Robin Vowels wrote:
And anyway, why would you want to EX an EX?
To cause an ABEND after an error, of course!
I have seen "EX 0,*" in production code to do this
(along with "J *+1")
--
Martin
Dr Martin Ward | Email: mar.
From: "Martin Ward"
Sent: Monday, August 06, 2018 6:40 PM
On 06/08/2018 02:30, Robin Vowels wrote:
And anyway, why would you want to EX an EX?
To cause an ABEND after an error, of course!
I have seen "EX 0,*" in production code to do this
(along with "J *+1")
nd anyway, why would you want to EX an EX?
>
> To cause an ABEND after an error, of course!
> I have seen "EX 0,*" in production code to do this
> (along with "J *+1")
Jonathan Scott, HLASM
IBM Hursley, UK
Robin Vowels wrote:
> L 0,1
> will do it.
That instruction will normally produce an alignment warning at
assembly time but won't stop anything at run time unless you're
running on a System/360 without the BOOF (byte oriented operand
feature) or on Linux on Z, where page 0 is not addressable by
nor
On 08/05/2018 09:30 PM, Robin Vowels wrote:
- Original Message - From: "Steve Thompson"
To:
Sent: Monday, August 06, 2018 4:21 AM
Subject: Re: EX
On 08/05/2018 08:13 AM, Robin Vowels wrote:
From: "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv
rts it as "TRAP occurred at offset &1 in &2".
Martin Ward writes:
On 06/08/2018 02:30, Robin Vowels wrote:
And anyway, why would you want to EX an EX?
To cause an ABEND after an error, of course!
I have seen "EX 0,*" in production code to do this
(along with &quo
On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with
> an 0C1.
>
I am *not* going to read the PoOps to learn why that "is guaranteed
to fail". I'm merely dismissing it as elitist opaque code. Comments
help only slightly.
>
We do the same.
The relative halfword count is at +2 - so the instruction is 00
It's handy to see where exactly you died. And why.
On 8/6/18, 10:51 AM, "IBM Mainframe Assembler List on behalf of Paul
Gilmartin" wrote:
On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
> We use 'Jxx *+2'
On Mon, Aug 6, 2018 at 9:51 AM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
>
> > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1.
> >
> I am *not* going to read the PoOps to learn why th
ssage-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, August 6, 2018 7:51 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EX
On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no regi
Ed Jaffe writes:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1.
I like that; OK by assembler and no branch in the normal case
but guaranteed to program check on 00. If my old code that uses
TRAP ever needs to be updated to a relative addressing version,
I
John McKown writes:
> Just in case anyone else is interested, given that Gil has disclaimed any
> interest at all. J *+2 generates the instruction: 7A44 0001 .
On IBM Z the instruction is actually A7F4 0001.
7A44 0001 would be AE 4,1(4,0)
Jonathan Scott, HLASM
IBM Hursley, UK
Ditto for
EX R0,*
except that you get a 0C3 program interrupt instead, which is usually a sign of
code scuttling itself and can be treated as such in recovery routines
On Mon, 6 Aug 2018 at 16:35, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1.
>
> I'm very fond of having an extra code for the type of assert, so I can
already blush before I see the listing ;-)
I suppose I could have the macro generate *+(c
Ouch, obviously not as Jonathan points out... :facepalm:
On Mon, 6 Aug 2018 at 17:23, Rob van der Heij wrote:
> On Mon, 6 Aug 2018 at 16:35, Ed Jaffe wrote:
>
>> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
>> with an 0C1.
>>
>> I'm very fond of having an extra code fo
On 8/6/2018 8:23 AM, Keven wrote:
Ditto for
EX R0,*
except that you get a 0C3 program interrupt instead, which is usually a sign of
code scuttling itself and can be treated as such in recovery routines.
Yes, I used the 'EX R0,*' technique back in the 80s and
On 2018-08-06 10:35, Ed Jaffe wrote:
We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
with an 0C1.
'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a
code base register and so is more generally usable in modern code.
-
On Mon, Aug 6, 2018 at 10:22 AM Jonathan Scott
wrote:
> John McKown writes:
> > Just in case anyone else is interested, given that Gil has disclaimed any
> > interest at all. J *+2 generates the instruction: 7A44 0001 .
>
> On IBM Z the instruction is actually A7F4 0001.
>
Thanks. I thought that
nal Message-
From: IBM Mainframe Assembler List On Behalf
Of Gord Tomlin
Sent: Monday, August 6, 2018 10:57
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EX
On 2018-08-06 10:35, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
> with an 0C1
Robert Ngan writes:
> Not sure why no one has mentioned the COMPARE AND TRAP type instructions, in
> most(?) cases they'll do the test and force the abend when required.
If you have to write product code that still works for CMS users
in ESA mode, then COMPARE AND TRAP is not an option. It needs
Sent: Monday, August 6, 2018 12:20
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: EX
Robert Ngan writes:
> Not sure why no one has mentioned the COMPARE AND TRAP type
> instructions, in
> most(?) cases they'll do the test and force the abend when required.
If you have to write prod
No, you get a program interrupt 003; you only get an ABEND S0C3 if the program
interrupt is not handled by a SPIE/ESPIE exit. There's actually software that
uses EX 0,* as a control structure. I don't recall whether it was a debugger, a
profiler or "E none of the above".
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Monday, August 6, 2018 10:51 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EX
On 2018-08-06, at 08:35:57, Ed Jaffe wrote:
> We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with
> an 0C1.
du/~smetz3
From: IBM Mainframe Assembler List on behalf
of Ed Jaffe
Sent: Monday, August 6, 2018 10:35 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EX
We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail
with an 0C1.
On 8/6/2018 3:10 AM, Jonathan Scott wrote
s no registers and is guaranteed to
fail with an 0C1.
'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a
code base register and so is more generally usable in modern code.
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Compute
nly get an ABEND S0C3 if the program
interrupt is not handled by a SPIE/ESPIE exit. There's actually software that
uses EX 0,* as a control structure. I don't recall whether it was a debugger, a
profiler or "E none of the above".
--
Shmuel (Seymour J.) Met
I was once asked why the execute exception existed. That is, why not just let
the hardware — or, in this odd case, the firmware — cascade down a chain of
multiple EX instructions, ORing the bits of the R1 field with the subsequent
target instruction, whatever instruction that might be. Aside
On 2018-08-06, at 16:12:37, Dan Greiner wrote:
> I was once asked why the execute exception existed. That is, why not just let
> the hardware — or, in this odd case, the firmware — cascade down a chain of
> multiple EX instructions, ORing the bits of the R1 field with the subsequent
I get the impression that the hardware handles EX like a subroutine call. If
a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM.
Subroutine returns are a heckuva lot easier to implement if you only allow
subroutine calls to be one deep. You have only one return address pointer to
On 2018-08-06, at 17:07:35, Charles Mills wrote:
> I get the impression that the hardware handles EX like a subroutine call. If
> a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM.
>
> Subroutine returns are a heckuva lot easier to implement if you only allow
> subr
From: IBM Mainframe Assembler List on behalf
of Charles Mills
Sent: Monday, August 6, 2018 7:07 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: EX
I get the impression that the hardware handles EX like a subroutine call. If
a B or J is like a COBOL GOTO, then EX is like a COBOL PERFORM.
On 8/6/2018 18:12, Dan Greiner wrote:
I was once asked why the execute exception existed. That is, why not just let
the hardware — or, in this odd case, the firmware — cascade down a chain of
multiple EX instructions, ORing the bits of the R1 field with the subsequent
target instruction
There's a fundamental difference between B * and EX reg,*; the EX gives you a
single instruction that never terminates, while the branch gives you multiple
instructions each of which completes quickly. So to allow the execute you'd
have to make it re startable.
BTW, IBM had earlier m
There is a difference;
when coding B *, the CPU has to fetch the instruction
again and again, so it is easy to interrupt the endless loop by another
process or task. But a (theoretical) EX R0,* loop cannot be interrupted,
because
the loop is inside the execution logic of ONE instruction.
Kind
BTW: the German mainframe Telefunken TR440 had some similar instructions
which were not protected the same way like EX. There were at least three
ways to stop the CPU from a non-privileged program ... I recall them being
called "Schecher-Stop type n" (n = 1,2,3), because Schecher was t
structions
which were not protected the same way like EX. There were at least three
ways to stop the CPU from a non-privileged program ... I recall them
being
called "Schecher-Stop type n" (n = 1,2,3), because Schecher was the name
of the famous programmer who exploited them :-)
Kind
On 2018-08-06, at 23:35:58, Bernd Oppolzer wrote:
> BTW: the German mainframe Telefunken TR440 had some similar instructions
> which were not protected the same way like EX. There were at least three
> ways to stop the CPU from a non-privileged program ... I recall them being
> call
Dan,
>> where Linux developers will quickly remind you that zOS is not the
>> only OS
heh heh- I know an other opsys that runs on 360 type boxes (way longer
than Linux) and far more common genes with OS.
Martin
From: "Dan Greiner"
Sent: Tuesday, August 07, 2018 8:12 AM
I was once asked why the execute exception existed. That is, why not just let
the hardware —
or, in this odd case, the firmware — cascade down a chain of multiple EX
instructions,
ORing the bits of the R1 field with the
Steve Thompson wrote:
> BTW, there are a few instructions on IBM systems that are not
> documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an
> SIE either (this is part of the Interpretive Execution Facility).
Actually, the original SIE was documented in "IBM System/370 Extended
Arc
On 08/07/2018 04:37 PM, Dan Greiner wrote:
Steve Thompson wrote:
BTW, there are a few instructions on IBM systems that are not
documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an
SIE either (this is part of the Interpretive Execution Facility).
Actually, the original SIE was docu
z/VM has VSIE, which is a CP thing where a second-level guest can run its
guests using SIE, transported up to first level. I'm sure I'm munging the
description; never had to understand it beyond the fact that it's White Majick.
OK, I hope I'm not becoming wearisome with my yammering. But I am not too busy
right now. And I still really like and respect the z architecture (despite its
horrendous price).
I ask about the CPU cost of an EX because that same program that I'm working on
uses the EX a fair amou
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, August 03, 2018 3:09 AM
A principal use of EX is to be able to use a register mask to modify the
target. CDC 3800 had a clever alternative to this, a modify-next-instruction
instruction (I fo
John,
>> move "variable length" strings into a blank-initialized area for
>> reporting purposes.
How about using MVCL and using the padding function to fill in the
blanks
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
You're welcome. :-)
Fred!
Sent from my iPad
On Jan 12, 2012, at 16:33, "McKown, John" wrote:
> As an aside, to whomever it was who recommended the TROO as a way to move
> bytes from an input area to an output area, while testing for "unprintable"
> bytes - thanks! It made my code much easier
On 1/12/2012 9:15 AM, Martin Truebner wrote:
John,
move "variable length" strings into a blank-initialized area for
reporting purposes.
How about using MVCL and using the padding function to fill in the
blanks
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more a
Instead, why not use MVCLE with the padding byte?
--jg
On 1/12/12, Steve Comstock wrote:
> On 1/12/2012 9:15 AM, Martin Truebner wrote:
>> John,
>>
move "variable length" strings into a blank-initialized area for
reporting purposes.
>>
>> How about using MVCL and using the padding func
EX is indeed expensive, but my guess (untested) is that an EXecuted MVC for
small lengths (not only under 256 but even less) is probably still more
efficient than MVCL for those lengths, and *definitely* more efficient than
MVCLE. My prior experiences in replacing MVCL/CLCL's with multipl
My own experience has been much more mixed, but I'd like to accept, in
order to address what I take to be a more important issue, that Peter
Farley is right when he says
My prior experiences in replacing MVCL/CLCL's with multiple MVC/CLC's
and even MVC/CLC loops for "small" areas (FSVO "small") i
On Thu, Jan 12, 2012 at 6:59 PM, Farley, Peter x23353
wrote:
> EX is indeed expensive, but my guess (untested) is that an EXecuted MVC for
> small lengths (not only under 256 but even less) is probably still more
> efficient than MVCL for those lengths, and *definitely* more effic
Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Rob van der Heij
Sent: Thursday, January 12, 2012 5:28 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How bad is the EX instruction?
On Thu, Jan 12, 2012 at 6:59 PM, Farley, Peter x23353
wrote:
> EX is indeed expensive, but
On Fri, Jan 13, 2012 at 1:05 AM, Hall, Keven wrote:
> If you're looking to reduce CPU usage you might want to optimize the TRT
> the heck out of the equation. Talk about expensive! [augment with
> imagined or actual sound of cash register "cah-ching" sound for added
> emphasis/effect]
Ok... b
lication software?
> I ask about the CPU cost of an EX because that same program that I'm working
> on uses the EX a fair amount to move "variable length" strings into a
> blank-initialized area for reporting purposes. Instead of EX of an MVC, I
> could use MVCL
On Jan 12, 2012, at 17:05, Hall, Keven wrote:
> If you're looking to reduce CPU usage you might want to optimize the TRT
> the heck out of the equation. Talk about expensive! [augment with
> imagined or actual sound of cash register "cah-ching" sound for added
> emphasis/effect]
>
Boyer-Moore?
is on very current machines, on older
ones EX added 40 to 50% to the instruction time (EX overhead on
some Amdahl machines was greater); 4 MVCs of 256 bytes were
about the same as a 1K MVCL; and 5 CLI/BE were about the same as
one TRT/B *+4(R2). In each case if paid to identify the most
frequently exe
tion of a tight loop on a
doubleword boundary, for example).
Keven
-Original Message-
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Rob van der Heij
Sent: Thursday, January 12, 2012 7:16 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How bad i
Rob,
have you tried SRST?
I had a hard time getting used to SRSTs way of using/wanting the
resgisters- but then... It does an excellent job on searching for one
(and only one) character in a string.
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapc
Rob,
here is a simple sample for SRST:
L R15,SAVE point in string for cont
LAR14,256(R15)
LAR0,C'/'
SRST R14,R15
* R14 is now on the first /
LAR15,1(R14)
SRST R14,R15
* R14 is now on the second /
Two hints:
1.) SR
lems completing
> overnight jobs in their assigned batch window, or just
> processing large amounts of data.
>
> While I haven't tried this on very current machines, on older
> ones EX added 40 to 50% to the instruction time (EX overhead on
> some Amdahl machines was greater);
On Fri, Jan 13, 2012 at 8:13 AM, Martin Truebner wrote:
> Rob,
>
> have you tried SRST?
>
> I had a hard time getting used to SRSTs way of using/wanting the
> resgisters- but then... It does an excellent job on searching for one
> (and only one) character in a string.
Martin,
Haven't, and probab
Gerhard Postpischil wrote:
In general I tend to agree with this, but I've worked or consulted at
installations that either had problems completing overnight jobs in
their assigned batch window, or just processing large amounts of data.
I value GP's concurrence. Let me add, however, that 1) in
On Fri, 13 Jan 2012 11:18:40 +0100, Rob van der Heij wrote:
>On Fri, Jan 13, 2012 at 8:13 AM, Martin Truebner wrote:
>> have you tried SRST?
>
>Haven't, and probably should for my own education. We restrict our
>products to older architecture levels for a number of good reasons.
How old?
SRST was
...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From:
John Gilmore
To:
ASSEMBLER-LIST@listserv.uga.edu,
Date:
13/01/2012 13:20
Subject:
Re: How bad is the EX instruction?
Sent by:
IBM Mainframe Assembler List
IDs: MartinPacker
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
>
>
> From:
> John Gilmore
> To:
> ASSEMBLER-LIST@listserv.uga.edu,
> Date:
> 13/01/2012 13:20
> Subject:
> Re: How bad is the EX instruction?
> Sent by:
> IBM Mainfra
e next 3-byte place holder and load the
2-byte index into the table, a few RX (L LA IC), an SLL
to convert the index to an ofsset, an SR/JNP to detect and
move text between tokens and lastly an EX-MVC combo.
For this elite group here, this post is really OFF-TOPIC.
You worry about picoseconds bec
Original Message From: "John Gilmore"
Martin Packer's point is, of course, well taken.
Yours likewise!
I got these kinds of optmization mandates because
of CPU Hours and EXCPs it cost to run some batch
jobs and CICS transactionsat my clients' service bureau.
Egregiously bad SQL can be the vi
On 1/12/2012 7:32 AM, McKown, John wrote:
I ask about the CPU cost of an EX because that same program that I'm working on uses the
EX a fair amount to move "variable length" strings into a blank-initialized
area for reporting purposes. Instead of EX of an MVC, I could use MVC
> For short EX MVC's the burden of getting stuff in the right registers
> makes MVCL less interesting.
As I understand it, and doesn't seem to have been mentioned, the big
effect on EX has to do with caching. I believe that it should be
near code and not data. (That is,
On Fri, 13 Jan 2012 18:29:55 -0800, glen herrmannsfeldt wrote:
>> The EX CLC is in fact in loop scanning a linked list for the right
>> entry among 100-200 elements.
>
>You could also do binary search, which will find the right entry
>with about log(n) comparisons.
How do y
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Tom Marchant
Sent: Monday, January 16, 2012 6:35 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How bad is the EX instruction?
On Fri, 13 Jan 2012 18:29:55 -0800, glen herrmannsfeldt wrote:
>> The EX CLC is in fact in loop scanning a linke
On Sat, Jan 14, 2012 at 3:29 AM, glen herrmannsfeldt
wrote:
> I usually use a hash table. Especially if speed is important.
>
> You could also do binary search, which will find the right entry
> with about log(n) comparisons.
Yeah, and I prefer to stop the earth rotation when I take a sun bath..
ary
search.
Marginal savings, I think, compared to EX/CLC or CLCL,
for the reason that both CLC and CLCL give up after examining the
first character, should they be unequal.
Might be more fruitful to compare length of the key with that of an element
first,
and then carrrying out the compare sh
t;search.
I don't know if the cost of EX is high enough that you would benefit
from doing a one byte CLC before an EX of a CLC. I don't see how a CLI
will help you though.
--
Tom Marchant
;>CLC/CLCL if the CLI matches. This trick even works if doing a binary
>>search.
>
> I don't know if the cost of EX is high enough that you would benefit
> from doing a one byte CLC before an EX of a CLC. I don't see how a CLI
> will help you though.
Having the CLC nea
On 2012-01-13 02:18, Rob van der Heij wrote:
On Fri, Jan 13, 2012 at 8:13 AM, Martin Truebner wrote:
Rob,
have you tried SRST?
I had a hard time getting used to SRSTs way of using/wanting the
resgisters- but then... It does an excellent job on searching for one
(and only one) character in a s
On Jan 16, 2012, at 05:35, Tom Marchant wrote:
> On Fri, 13 Jan 2012 18:29:55 -0800, glen herrmannsfeldt wrote:
>
>>> The EX CLC is in fact in loop scanning a linked list for the right
>>> entry among 100-200 elements.
>>
>> You could also do binary search, whi
;
than for strings beginning with " ".
> Marginal savings, I think, compared to EX/CLC or CLCL,
> for the reason that both CLC and CLCL give up after examining the
> first character, should they be unequal.
>
> Might be more fruitful to compare length of the key with tha
Saying that "... sub-optimizing of this sort is, I think, evidence of a
pervasive malaise..." is a short sighted generalization.
Performance is one of the strongest reasons for coding in assembler and
this discussion characterizes some of the low hanging fruit available for
the attainment thereof.
From: "Rob van der Heij"
Sent: Tuesday, 17 January 2012 2:37 AM
Having the CLC near the EX helps for cache. I also like to assemble it
in-line because the right USINGs apply. We noticed that it is
attractive to run over the CLC (with the length byte 0 as assembled)
and then EX behind
From: "Paul Gilmartin"
Sent: Tuesday, 17 January 2012 7:33 AM
CDC 3600/3800 had a "Modify following instruction" instruction
The S/360 and subsequent machines have one like that also.
In the case of MVC/CLC instructions :-
stc 1,*+5
mvc a(0),b
can be useful.
EX does mo
From: "McKown, John"
Sent: Friday, 13 January 2012 2:32 AM
OK, I hope I'm not becoming wearisome with my yammering. But I am not too busy
right now. And I still really like and
respect the z architecture (despite its horrendous price).
I ask about the CPU cost of an EX be
On Tue, Jan 17, 2012 at 6:49 AM, robin wrote:
> From: "Rob van der Heij"
> Sent: Tuesday, 17 January 2012 2:37 AM
>
>> Having the CLC near the EX helps for cache. I also like to assemble it
>> in-line because the right USINGs apply. We noticed that it is
>>
Rob,
>> My experience was that executing the MVC or CLC twice (first with
length 0) is better than to branch over it.
I doubt that doing something little and then full is faster than doing
it full the first time
If you observed major difference I do suspect that it is because
the first execu
gt; anyway.
I thought that putting instructions between the data was considered
evil practice. But I merely assumed it applied to the target of EX as
well.
When reading the code, I find it breaks the line of thought when I
have to go look for the exact instruction that's targeted by EX. And I
h
> Having the CLC near the EX helps for cache. I also like to assemble it
> in-line because the right USINGs apply. We noticed that it is
> attractive to run over the CLC (with the length byte 0 as assembled)
> and then EX behind your back to do the real thing. More attractive
> t
On Tue, Jan 17, 2012 at 1:31 PM, Fred van der Windt
wrote:
>> Having the CLC near the EX helps for cache. I also like to assemble it
>> in-line because the right USINGs apply. We noticed that it is
>> attractive to run over the CLC (with the length byte 0 as assembled)
>>
Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of robin
> Sent: Monday, January 16, 2012 11:40 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Sub
> I doubt that doing something little and then full is faster than doing it
> full the first time
>
> If you observed major difference I do suspect that it is because the first
> execution triggered a pagein (or a swap or a steal...whatever).
I did a very Q&D test and...
J *+10
CLC
ase of MVC/CLC instructions :-
>
> stc 1,*+5
> mvc a(0),b
>
> can be useful.
>
No, no, no, no, no!:
o RENT!? (How does this affect instruction pipelining?)
o The CDC instruction didn't modify the storage; it
modified the execution of the instruction after it had
been fetche
On Jan 17, 2012, at 05:31, Fred van der Windt wrote:
>> Having the CLC near the EX helps for cache. I also like to assemble it
>> in-line because the right USINGs apply. We noticed that it is
>> attractive to run over the CLC (with the length byte 0 as assembled)
>> and
On Jan 16, 2012, at 08:21, Kerry wrote:
>
> Performance is one of the strongest reasons for coding in assembler and
> this discussion characterizes some of the low hanging fruit available for
> the attainment thereof.
>
Others have said here that performance is a strong reason
for _not_ coding in a
On 1/17/2012 6:40 AM, Paul Gilmartin wrote:
I forget; is the target of EX treated as a data access or as an instruction
access for cacne management?
The 256-byte cache line containing the target instruction is loaded into
I-cache.
--
Edward E Jaffe
Phoenix Software International, Inc
831
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Paul Gilmartin
> Sent: Tuesday, January 17, 2012 10:32 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: How bad is the EX instruction?
>
> O
> From: "Farley, Peter x23353"
> IMHO, COBOL generated code is so bad that if I was on the COBOL
> code-generation development team I would be embarrassed to admit it.
The cobol code generator appears to be the beneficiary of benign neglect.
The net result of using only the halfword immediate in
/2012 11:06 AM
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
l...@listserv.uga.edu] On Behalf Of Paul Gilmartin
Sent: Tuesday, January 17, 2012 10:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How bad is the EX instruction?
On Jan 16, 2012, at 08:21, Kerry
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
> Sent: Tuesday, January 17, 2012 9:32 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: How bad is the EX instruction?
>
> O
1 - 100 of 113 matches
Mail list logo
