I think of the operative term as "doubleword consistency" (it is implied
that the doubleword is on a doubleword boundary).
That is why LM of two regs from a doubleword gets you "consistency", but
"L from 1st word followed by L from 2nd word" does not).
And yes, for the most part, it doesn't have
On 2019-01-15, at 10:48:52, Ngan, Robert wrote:
> If you want to load two doublewords, block concurrency guarantees each
> (aligned) doubleword is consistent, but if task 2 is in process of updating
> both doublewords, using (for example) LMG may result in you loading one
> doubleword from
-
From: IBM Mainframe Assembler List On Behalf
Of Keven
Sent: Monday, January 14, 2019 16:54
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
Shouldn’t that be:Protection for readers is only necessary when the
storage in question doesn’t cross
ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
Yes, your illustration is exactly what I was concerned about. My instinct was
CS was just about updaters of storage, and not readers, so there must be some
other type of protection for readers.
Thanks, Joe
DXC Technolo
, January 10, 2019 04:28
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
Yes, your illustration is exactly what I was concerned about. My instinct was
CS was just about updaters of storage, and not readers, so there must be some
other type of protection for readers
tz3
From: IBM Mainframe Assembler List on behalf
of Tony Harminc
Sent: Thursday, January 10, 2019 5:08 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
On Thu, 10 Jan 2019 at 13:44, Paul Gilmartin
<0014e0e4a59b-dmar
On 2019-01-10, at 15:53:59, gah wrote:
>
>> So two processers both fetch the same 16-bit frame. One
>> updates the even half; the other into the odd half. Both store.
>> Last guy wins (sort of).
>
> With only one processor, you still have I/O to consider.
>
I understand that on some systems
On Thu, 10 Jan 2019 at 17:54, gah wrote:
> > I remember the 360/30 (used one in high school), and I'm pretty sure
> > it had an 8-bit bus. But I could be wrong.
>
> The 360/30 has an 8 bit bus and 8 bit ALU.
Thanks for confirming my, uh memory.
> > So two processers both fetch the same 16-bit
>> The storage bus has been at least 16 bits wide as long as anyone can
>> remenber.
> I remember the 360/30 (used one in high school), and I'm pretty sure
> it had an 8-bit bus. But I could be wrong.
The 360/30 has an 8 bit bus and 8 bit ALU.
The 360/40 has a 16 bit bus, but still 8 bit ALU.
On Thu, 10 Jan 2019 at 13:44, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> Ever since I learned of the NIL and OIL macros, I have wondered why MVI
> and STC did not have the same exposure as OI and NI:
>
> The storage bus has been at least 16 bits wide as long as
eymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Thursday, January 10, 2019 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: R
On 2019-01-10, at 09:46:38, Peter Relson wrote:
>
> Many of us grew up with machines where OI and some other instructions were
> done in multiple stages, and at just the wrong point could result in lost
> data if CS/CDS was being used. You could not mix and match.
>
Ever since I learned of
On Thu, 10 Jan 2019 11:46:38 -0500, Peter Relson wrote:
>If on a new enough z/OS, you can rely on the interlocked access facilities
>being available.
Interlocked access facility 2 was first described in the -9 edition of the
zArchitecture Principles of Operation, corresponding to the zEC12.
On Thu, 10 Jan 2019 at 01:07, Jim Mulder wrote:
>
> The coordination with other CPUs is in getting exclusive control of
> the storage operand cache line. CS and ST both have to do that, so they
> would be similar in performance in that regard.
But CS and friends carry the perhaps quite high
On Wed, 9 Jan 2019 at 09:25, Mark Boonie wrote:
>
> On all z/Architecture CPUs, MVC will appear fullword-concurrent provided
> both the source and target operands are fullword-aligned.
You're not wrong, but the commitments for MVC (and a few similar
instructions) are quite a bit stronger than
Surely the cost of CS/CDS is far less than the cost of PLO. In my opinion,
if you know that you can use transactional execution (which would be the
case if you're on z/OS 2.3 or later *and* you know that you are not
running z/OS under z/VM 6.3 or earlier), then you should never use PLO. A
al Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Joe Owens
Sent: Thursday, January 10, 2019 2:28 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
Yes, your illustration is exactly what I was concerned about. M
Yes, your illustration is exactly what I was concerned about. My instinct was
CS was just about updaters of storage, and not readers, so there must be some
other type of protection for readers.
Thanks, Joe
es Mills"
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 01/10/2019 01:04 AM
> Subject: Re: Multi CPU interlock question
> Sent by: "IBM Mainframe Assembler List"
> Avoid CS if you don't need it (and in this case you don't). CS is
> expensive because every CPU has to sit up and take notice.
.
Poughkeepsie NY
> From: "Charles Mills"
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 01/10/2019 12:59 AM
> Subject: Re: Multi CPU interlock question
> Sent by: "IBM Mainframe Assembler List"
>
> Take your pick of answers:
>
> 1. I don't know.
> 2.
Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Wednesday, January 9, 2019 11:52 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
How does the cost of CS/CDS compare to PLO?
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Joe Owens
Sent: Wednesday, January 9, 2019 8:11 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
Hi Everyone, thanks for the answers. I did read the POP, but obviously not hard
ailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Joe Owens
Sent: Wednesday, January 9, 2019 8:11 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Multi CPU interlock question
Hi Everyone, thanks for the answers. I did read the POP, but obviously not hard
enough. (It is never an ea
> Does CS tell the right story, or does CS itself require alignment?
The updated storage area is required to be fullword aligned, which is why
you could/should just skip the CS.
- mb
Hi Everyone, thanks for the answers. I did read the POP, but obviously not hard
enough. (It is never an easy read).
The block concurrency section explains it perfectly. The fullword is aligned so
all should be good. The question about MVC was just out of interest.
Thanks.
Joe
>> Does CS tell the right story, or does CS itself require alignment?
yea it does- from POP:
Otherwise, a specification exception is recognized
Martin
On 2019-01-09, at 07:34:27, Mark Boonie wrote:
> Speaking for myself, I would consider it "proper" to align the operands
> and skip the CS -- the architecture guarantees the behavior, so doing the
> update with CS seems like overkill. (I'd probably also add a comment in
> the code for each
Speaking for myself, I would consider it "proper" to align the operands
and skip the CS -- the architecture guarantees the behavior, so doing the
update with CS seems like overkill. (I'd probably also add a comment in
the code for each operand pointing out the reason for the alignment
On all z/Architecture CPUs, MVC will appear fullword-concurrent provided
both the source and target operands are fullword-aligned.
- mb
IBM Mainframe Assembler List wrote on
01/09/2019 06:17:29 AM:
> MVC might on some CPUs appear to do it 4 byte wise (or other multiples
> thereof) -
On Wed, 9 Jan 2019 at 12:17, Martin Truebner wrote:
> Joe,
>
> Robs is answer is already saying everything but let me give you
> some more details.
>
> the load (or store) will always do it on a fullwordBUT to do it
> proper would require doing it with a CS.
>
As long as the operand is
Joe,
Robs is answer is already saying everything but let me give you
some more details.
the load (or store) will always do it on a fullwordBUT to do it
proper would require doing it with a CS.
MVC might on some CPUs appear to do it 4 byte wise (or other multiples
thereof) -
And again
On Wed, 9 Jan 2019 at 11:29, Joe Owens wrote:
> A 4 byte address field in virtual storage has one updater and many readers
>
> If using load and store instuctions, will the readers always see a
> complete (valid) address, or could a CPU see a partially updated field
> while a store is in
32 matches
Mail list logo
