I thought that the descriptions of the vector instructions were a much easier
read than the, e.g., sort, transaction, instructions.
Something that I'd like to see inPoOps is an example of using UNPK and TR to
convert binary to hexadecimal.
--
Shmuel (Seymour J.) Metz
Of course you can. There are no bit patterns in hexadecimal, only sixteen
symbols. Nor do the symbols need to be EBCDIC; they could as well be ASCII. I
will admit that the UNPK/TR technique won;t work so well with Unicode, but then
neither will TROT.
UNPK/TR is convenient when you only need
Do you mean conversion to printable hex, e.g. convert x'1234' to
x'f1f2f3f4'? These days, I use the TROT instruction.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: 07 June 2020 19:21
To:
On 6/7/2020 9:23 AM, Farley, Peter x23353 wrote:
Is there any chance you could provide (maybe eventually in a SHARE session
presentation?) a set of good examples of using the vector instructions as you
say you do?
Peter,
There was a thread called "Count Words" into which at one time I
Well, any set of 16 symbols encoded in 8 bits; it doesn't work so well with,
e.g., Unicode. My intent for PoOps was to illustrate that UNPK is not just a
decimal instruction.
As for TROT, it would depend on whether the degree of use justified the larger
translate table. If I went that way I
Ed,
Is there any chance you could provide (maybe eventually in a SHARE session
presentation?) a set of good examples of using the vector instructions as you
say you do?
Or am I late to the party and there have already been such SHARE sessions that
I missed?
If I have one particular beef with
Something that I'd like to see inPoOps is an example of using UNPK
and TR to convert binary to hexadecimal.
You can't "convert" binary to hexadecimal, their bit patterns are the
same. If you're referring to displaying bytes' hexadecimal representation
in EBCDIC, then I'd say it's a bit late for
Dan,
A belated reaction, sorry about the delay.
I just checked the source code. It seems START is treated as a synonym
of CSECT.
At the java level the z390 code does not seem to expect an argument.
If you need it, we could raise an RPI.
Kind regards,
Abe Kornelis.
z390 coordinator
==
Thanks Ed. Already received.
It sure would be helpful to have someone with the tutorial and writing skills
of John Ehrman to put together an extended explanation that covered all the
varieties of vector facilities we now have. The less we know the farther
behind we get from the HLL compiler
Ed, I too would be interested in your presentation from March 2017 SHARE ...
I can only imagine the barrage of knee-jerk responses you likely
encountered.
Sad but unfortunately predictable.
regards,
Kerry Liles
On Sun, 7 Jun 2020 at 18:23, Ed Jaffe wrote:
> On 6/7/2020 9:23 AM, Farley,
I thought that I was cynical, but I would not have predicted it.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Kerry Liles [kerry.li...@gmail.com]
Sent: Sunday,
>>IBM has "Vector" instructions, but the size of a vector is limited to
one
>>quadword.
>That limitation is not the case for z/Architecture vector operations.
I erred in writing that. Shmuel was of course correct. The "vector
register" is 128 bits (one quadword).
The extent of the
On 6/7/2020 7:11 AM, Peter Relson wrote:
That limitation is not the case for z/Architecture vector operations.
I erred in writing that. Shmuel was of course correct. The "vector
register" is 128 bits (one quadword).
The extent of the "vectorization" depends on the size of the operands.
We
13 matches
Mail list logo
