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: 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 produced a special EXC

Re: Moves and others

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 overlapping move condition. It was changed in a

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

DSPSERV Question

I want to be able to pass an Assembler Subroutine a space allocation for DSPSERV. The macro below ( from IBM Manual ): DSPSERV CREATE,NAME=CCACHE,STOKEN=VOYTOKEN, C BLOCKS=DSPCSIZE,ORIGIN=DSPCORG .. DSPCSIZE EQU 100 * 1 Million Bytes * DSPBLCKS

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