On Apr 15, 2022, at 21:30:35, Robin Vowels wrote:
>>>
>> R0 doesn't count because no one else uses it.
>
> nonsense!
>
(That was sarcasm.)
> On Apr 15, 2022, at 21:28:55, Robin Vowels wrote:
>
> MVCL will do what you want.
>
Yes.
> and MVCL will even deal with zero lengths.
>
It must,
- Original Message -
From: "Tom Harper"
Sent: Saturday, April 16, 2022 4:19 AM
I think that is unnecessary because the proposal is only for one to 256 bytes
so no need to make it interruptible. If you want to use for longer areas, use a
move long.
For shorter areas, use MVCL.
From: "Tom Harper"
Sent: Saturday, April 16, 2022 3:10 AM
For a fixed length move, none.
You can use MVC for that. And XC.
For a variable length move, one.
For which MVCL is eminently suitable.
---
This email has been checked for viruses by Avast antivirus software.
- Original Message -
From: "Steve Smith"
To:
Sent: Saturday, April 16, 2022 2:49 AM
Subject: Re: Next instruction needed
Tom Harper made a perfectly clear proposal, that evidently only you cannot
comprehend.
The proposal is clearly irrational, and for a need that almost doesn't
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Saturday, April 16, 2022 2:48 AM
On Apr 15, 2022, at 10:27:47, Robin Vowels wrote:
On 2022-04-16 02:23, Tom Harper wrote:
As mentioned, R0.
Make up your mind! You just said that no registers were involved.
From: "Tom Harper"
Sent: Saturday, April 16, 2022 12:34 AM
Subject: Re: Next instruction needed
Robin,
See embedded remarks.
See mine.
MVCL will do what you want.
It was designed to do the operation without overruns.
The lengths of the source and the destination areas are both
specified
> Conceptually,the MVCL instruction could treat cases that specified the
> same register pair for source and target operands as a request to clean or
> fill the designated storage area.
You'd have to change the current behavior of MVCL -- when the same register is
specified for both operands, it
If R0 is acceptable, then maybe R1 and R15 are also acceptable because
"nobody ever uses them".
For my clears I usually default to:
MVCL R0,R14
Tony Thigpen
Tom Harper wrote on 4/15/22 12:23:
Sent from my iPhone
On Apr 15, 2022, at 12:20 PM, Robin Vowels wrote:
On 2022-04-16 00:25,
Conceptually,the MVCL instruction could treat cases that specified the same
register pair
for source and target operands as a request to clean or fill the designated
storage area.
Keven
Sent from my iPhone
> On Apr 15, 2022, at 13:54, Mike Hochee wrote:
>
> I apparently stopped reading
It used to matter IIRC -- longer shifts took longer -- but I doubt that it
does anymore.
How long does an instruction take anymore? It depends ...
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent:
On Fri, 15 Apr 2022 at 14:59, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
> On Apr 15, 2022, at 12:47:40, Tony Harminc wrote:
> >
> > ... it's obvious that if you want
> > to rotate right, say 5 bits, you can instead rotate left 59 bits ...
> >
> Performance?
On Apr 15, 2022, at 12:47:40, Tony Harminc wrote:
>
> ... it's obvious that if you want
> to rotate right, say 5 bits, you can instead rotate left 59 bits ...
>
Performance? Does the timing depend on the distance shifted?
Maybe model-dependedent. How much does it matter?
--
gil
I apparently stopped reading before the 'limited to 256' statement in the
original post and incorrectly assumed it covered long moves as well, since you
mentioned MVCL* type instructions (of course they cover all lengths). I see it
being a lot more useful if it had long capabilities.
On Fri, 15 Apr 2022 at 03:06, Ian Worthington
<0c9b78d54aea-dmarc-requ...@listserv.uga.edu> wrote:
>
> Thanks Seymour, it had never occurred to me they were totally identical apart
> from CC and sign extension. I'd always had a suspicion that there might be
> something that happened at the
Any "long" clear storage instruction is presumably going to require two
registers (target and length) to support interuptibility so the benefit over
MVCL becomes minimal. IOW I agree with "if you want longer, use MVCL."
Charles
-Original Message-
From: IBM Mainframe Assembler List
I think that is unnecessary because the proposal is only for one to 256 bytes
so no need to make it interruptible. If you want to use for longer areas, use a
move long.
Many instructions have been added over the years for small items. This would
find significant use as soon as the instruction
On Apr 15, 2022, at 11:34:40, Tom Harper wrote:
>
> If it was interrupted, where would the hardware restart? The instruction
> itself cannot be changed.
>
Make it an RFE. Support it with a business case, that it would provide added
value to end users inducing them to spend more on IBM
Actually, and I haven't looked, I suspect that there is room in the actual (new
proposed FILLI) machine instruction for both an immediate value and a zero to
256 length
> -Original Message-
> From: IBM Mainframe Assembler List l...@listserv.uga.edu> On Behalf Of Tom Harper
> Sent:
If it was interrupted, where would the hardware restart? The instruction itself
cannot be changed.
Sent from my iPhone
> On Apr 15, 2022, at 1:19 PM, Dave Clark wrote:
>
> "IBM Mainframe Assembler List" wrote on
> 04/15/2022 01:10:36 PM:
>> For a fixed length move, none. For a variable
Zero is nothing after all.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Friday, April 15, 2022 9:49 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Next instruction needed
On Apr 15, 2022,
"IBM Mainframe Assembler List" wrote on
04/15/2022 01:10:36 PM:
> For a fixed length move, none. For a variable length move, one.
Why not zero registers required for a variable length initialize?
For an extended displacement instruction such as what follows, the second
full-word
For a fixed length move, none. For a variable length move, one.
Sent from my iPhone
> On Apr 15, 2022, at 12:27 PM, Robin Vowels wrote:
>
> On 2022-04-16 02:23, Tom Harper wrote:
On Apr 15, 2022, at 12:20 PM, Robin Vowels wrote:
>>> On 2022-04-16 00:25, Tom Harper wrote:
Well
Tom Harper made a perfectly clear proposal, that evidently only you cannot
comprehend.
I have my own opinion on its value, but I for one, don't think the world
needs to know every opinion I happen to have.
sas
>
>
On Apr 15, 2022, at 10:27:47, Robin Vowels wrote:
>
> On 2022-04-16 02:23, Tom Harper wrote:
>>>
>> As mentioned, R0.
>
> Make up your mind! You just said that no registers were involved.
>
R0 doesn't count because no one else uses it.
--
gil
On 2022-04-16 02:23, Tom Harper wrote:
On Apr 15, 2022, at 12:20 PM, Robin Vowels
wrote:
On 2022-04-16 00:25, Tom Harper wrote:
Well known. But the instruction I’m proposing has no registers
involved
Oh? How do you propose that such an instruction move
N bytes (where N is variable)
Sent from my iPhone
> On Apr 15, 2022, at 12:20 PM, Robin Vowels wrote:
>
> On 2022-04-16 00:25, Tom Harper wrote:
>> Well known. But the instruction I’m proposing has no registers
>> involved
>
> Oh? How do you propose that such an instruction move
> N bytes (where N is variable) without
On 2022-04-16 00:25, Tom Harper wrote:
Well known. But the instruction I’m proposing has no registers
involved
Oh? How do you propose that such an instruction move
N bytes (where N is variable) without the value of N
being in a register?
(other than base displacement) and thus there is no
On 4/15/2022 1:49 AM, David Cole wrote:
Thanks for the correction, Ed. I didn't know that. -Dave
"If your product still supports z/OS 2.3 or less, you must dual-path CTX
as well."
And this is precisely the reason CTX hasn't had the widespread adoption
unrealistically expected by the
Robin,
See embedded remarks.
Tom
Sent from my iPhone
> On Apr 15, 2022, at 5:08 AM, Robin Vowels wrote:
>
> - Original Message - From: "Tom Harper"
>
> To:
> Sent: Friday, April 15, 2022 3:06 AM
>
>
>> IMHO, the next instruction to add to z/Architecture would be an instruction
Well known. But the instruction I’m proposing has no registers involved (other
than base displacement) and thus there is no way to restart the instruction to
complete the process.
So to avoid that, limiting it to 256 bytes removed that as an issue.
Sent from my iPhone
> On Apr 15, 2022, at
Static variables need special handling for shared code. Those instructions
would intuitively seem useful only for unshareable code.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List
It's especially ugly on ones complement machines.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Ian Worthington
You can have interruptability without an arbitrary length restriction; CLCL and
MVCL work just fine. All that you need is that the instruction be resumeable
and for the hardware/microcode/millicode to periodically check for pending
interrupts and update the registers as needed
--
Shmuel
- Original Message -
From: "Tom Harper"
To:
Sent: Friday, April 15, 2022 3:06 AM
IMHO, the next instruction to add to z/Architecture would be an instruction to clear storage to
zeros.
Right now a number of methods are in widespread use, none of which are clean and simple. I mean,
Thanks for the correction, Ed. I didn't know that. -Dave
At 4/14/2022 07:59 PM, Ed Jaffe wrote:
On 4/14/2022 10:35 AM, David Cole wrote:
Note, "dual path'ing" your code applies to TX, not to CTX.
That's true if your minimum supported z/OS
release is z/OS 2.4. Not even IBM is that
Thanks Seymour, it had never occurred to me they were totally identical apart
from CC and sign extension. I'd always had a suspicion that there might be
something that happened at the boundaries that I hadn't considered!
Good to know.
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
Both signed and unsigned integer operations are required to either wrap or give
undefined results in C. To my mind this is a horrible problem which gets
kicked down the road by the expansion of the size of variable size every few
years, presumably accompanies by the sacrificing of farmyard
Is this maybe because the variables are declared as static?
In the case of:
void addStuff(__uint64_t a64, __uint64_t b64, __uint32_t a32, __uint32_t b32 ) {
__uint32_t sumu32;
__uint64_t sumu64;
sumu32 = a32 + b32;
sumu64 = a64 + b64;
}
it generates:
120: sumu32 = a32 +
38 matches
Mail list logo
