Whose illustration? (Serious question -- don't know what you are replying to.)
If I understand you correctly there is no "protection" needed for readers. No
matter how many readers read a word in storage, they will all retrieve the same
value, until it changes.
Charles
-Original
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
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
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
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 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
> The storage bus has been at least 16 bits wide as long as anyone can
> remenber.
Well, I can't remenber at all, but I can remember shorter busses. Some of us
can remember farther back that others, and there was one subscriber to IBM-MAIN
who was prominent in the 1950s.
--
Shmuel (Seymour
>> 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
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
11 matches
Mail list logo
