Re: Moves and others

LER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Robert Ngan > Sent: Tuesday, October 27, 2015 5:27 PM > To: MVS List Server 2 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > Subject: Re: Moves and others > > There's also MVCOS (with zero in R00 for problem state code). It also uses > 2 extra reg

Re: Moves and others

[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert Ngan Sent: Wednesday, October 28, 2015 12:35 PM To: MVS List Server 2 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Subject: Re: Moves and others Were these experiments with MVCOS, MVCL or both? Robert Ngan CSC Financial Services Group IBM Mai

Re: Moves and others

IST@LISTSERV.UGA.EDU> Subject: Re: Moves and others There's also MVCOS (with zero in R00 for problem state code). It also uses 2 extra registers (R00, plus a length register). I heard it was also quite slow compared to MVC, but not sure how it's performance compares to an executed MVC (or a MVC loop, plus a

Re: Moves and others

On 2015-10-15, at 16:01, David de Jongh wrote: > The problem I found was that overlapping moves (to perform array > initialization, for example) no longer worked. I (and no doubt many others) > flew into a rage after looking at the object code and realizing that there > was no test for the

Re: Moves and others

From: "Jon Perryman" Sent: Thursday, November 21, 2013 1:24 PM Rather than moving the data to the 8 byte work field, you could calculate the length you want to move and then move it. LA R3,5 Counter for EX MOVE MVC WORKAREA(0),0(R9)Move

Re: Moves and others

> I'm sure that there was originally some hardware reason to move one more byte > than the number in the MVC. Surely the ability to move [0..255] is not really > significantly less useful than the ability to move [1..256] I was told the reason that the length in instructions like MVC and CLC was

Re: Moves and others

On Thu, Oct 15, 2015 at 9:48 AM, Robin Vowels wrote: ​ > > The reason is that they wanted the ability to move up to 256 bytes. > Had zero been a "no-op" as you suggest, then MVC could move up to > only 255 bytes (1:255). > ​I can accept that, but the difference between

Re: Moves and others

On Thu, Oct 15, 2015 at 7:30 AM, Robin Vowels wrote: > From: "Jon Perryman" > Sent: Thursday, November 21, 2013 1:24 PM > > > Rather than moving the data to the 8 byte work field, you could calculate >> the length you want to move and then move it. >>

Re: Moves and others

On 2015-10-15, at 07:14, John McKown wrote: > > ​I've sometimes thought that it would have been better if the length field > in the MVC was actually the number of bytes to move. Which would make a > length of zero essentially be a "no-op". But would be more intuitive. And > make it easier to put

Re: Moves and others

From: "John McKown" Sent: Friday, October 16, 2015 3:45 AM ​I had some "weird" assembler code which "optimized" something like that long ago. I did a complicated series of test and ended with a CC for ==0 or <0 or >0. I then used the IPM instruction to save the CC

Re: Moves and others

- Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Friday, October 16, 2015 3:16 AM Subject: Re: Moves and others On 2015-10-15, at 08:48, Robin Vowels wrote: IBM should have

Re: Moves and others

-LIST@LISTSERV.UGA.EDU Subject: Re: Moves and others I seem to recall when COBOL first started to compile to MVCL, Amdahl SEs zapped it to an MVC loop and greatly improved COBOL performance. Or something like that... Gary On 2015-10-15 12:21, John McKown wrote: > On Thu, Oct 15, 2015 at 11:16

Re: Moves and others

On 15 October 2015 at 13:16, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > I recall struggling to backport some code > which used IPM...SPM to older hardware that lacked those instructions. Must've been *very* old hardware... SPM is original with S/360. IPM is much

Re: Moves and others

On Thu, Oct 15, 2015 at 11:16 AM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2015-10-15, at 08:48, Robin Vowels wrote: > > > > IBM should have produced a special EXC instruction for characters, > > that did what EX does, but accepts k, the number of bytes to

Re: Moves and others

On Thu, Oct 15, 2015 at 11:24 AM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2015-10-15, at 09:26, John McKown wrote: > > > > Going beyond that, I have often wanted a "execute next instruction on > > condition". I.e. check the CC value, like a branch does, if

Re: Moves and others

On Thu, Oct 15, 2015 at 11:39 AM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > > I suspect FORTRAN's 3-way IF was a reflection of a hardware instruction > of the IBM 70* series (as was SIGNF()). John Gilmore has lamented the > lack of 3-way IF in more recent

Re: Moves and others

On 2015-10-15, at 10:58, Gary Weinhold wrote: > I seem to recall when COBOL first started to compile to MVCL, Amdahl SEs > zapped it to an MVC loop and greatly improved COBOL performance. Or > something like that... > ... and the entire loop might have fit in no more bytes of code than were

Re: Moves and others

On 2015-10-15, at 08:48, Robin Vowels wrote: > > IBM should have produced a special EXC instruction for characters, > that did what EX does, but accepts k, the number of bytes to move (or > compare, etc), > tests for zero (and performs a no-op if it is), subtracts 1, and then > executes MVC. >

Re: Moves and others

On 2015-10-15, at 10:45, John McKown wrote: > > ​I had some "weird" assembler code which "optimized" something like that > long ago. I did a complicated series of test and ended with a CC for ==0 or > <0 or >0. I then used the IPM instruction to save the CC in a general > register. Later, I did

Re: Moves and others

I can't remember the specifics, but back when I could read VM source code, I recall CP modules passed condition codes back when returning to the caller using some scheme like you describe. I thought it was cool and esoteric, but now I realize that even testing a condition code a couple of

Re: Moves and others

On 22 November 2013 00:50, Rich Long xmann...@yahoo.com wrote: R8 is holding the variable number of bytes (length of 1-8). The move below is working. Ran test data from 1-8 characters long, and it worked fine. The other move works now also, after adding the registers. There's not enough

Re: Moves and others

Here economy of means would lead me to prefer an SRST to Jon Perryman's traditional approach, which searches for a delimiter or delimiters using a TRT[E]. Just where the break point is depends upon how many delimiters are being searched for concurrently. When, as here, it is a single character

Re: Moves and others

There's no problem with having an inline targe for the EX instruction. It's used regularly by at least 1 ISV. The instruction get's executed twice but the second time has the instructions and data already in the pipe. I wonder if the second instruction fetch offsets the second execution of the

Re: Moves and others

On 11/21/2013 10:34 AM, Tony Harminc wrote: SRST has been around for much longer than that; it certainly long predates z architecture. So it is quite safe in any real world scenario to assume that the instruction is available. SRST and the other string instructions were available on early

Re: Moves and others

At 06:31 -0800 on 11/21/2013, Jon Perryman wrote about Re: Moves and others: There's no problem with having an inline targe for the EX instruction. It's used regularly by at least 1 ISV. The instruction get's executed twice but the second time has the instructions and data already in the pipe

Re: Moves and others

    BH    EDITEXIT  B EDITLOOP From: Tony Harminc t...@harminc.com To: Rich Long xmann...@yahoo.com Sent: Thursday, November 21, 2013 6:33 PM Subject: Re: Moves and others On 21 November 2013 19:20, Rich Long xmann

Re: Moves and others

To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, November 21, 2013 12:05:27 AM Subject: Re: Moves and others Correction: MVC uses a length CODE. Thus, if you load 5 into your EX register, the actual move is SIX bytes. Second, the sequence used will execute the TRT once for 1 byte, then repeat

Moves and others

Issue I am facing - reading fixed length records, then searching for a fixed length character string.  Once I find that string, there is a need to check the next 8 bytes to see how much data follows.  It could be 1-8 characters in length.  Finding the fixed piece is easy enough.  When

Re: Moves and others

What doesn't like the MVC 0(1,R5),0(R9)? What do you mean by this? Maybe you could include the code snippet that you can't get working and possibly an example of one of the records with what you want it to do. It's not clear what results you are looking for. Rather than moving the data to the

Re: Moves and others

the 'not found yet' condition comes in. Pieter Wiid From: jperr...@pacbell.net Sent: 2013/11/21 04:24:24 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Cc: Subject: RE: Re: Moves and others What doesn't like the MVC 0(1,R5),0(R9)? What do you mean by this? Maybe you could include the code snippet that you can't get