LDW@USCMVSA.BITNET (Leonard D Woren) (04/26/91)
The thread that wouldn't die... > > ... does that MVC/MVCL > >instruction resolve to 1 machine code instruction? > Yes AND no: MVCL is one machine code instruction for the assembler. ... I've been known to remark that MVCL is an 18 byte RR instruction. Let's see now: LA Rx,source 4 LA R(x+1),source_length 4 LA Ry,target 4 LA R(y+1),target_length 4 MVCL Ry,Rx 2 --- 18 Of course, in the most common usage it's only 16 bytes because you do LR R(y+1),R(x+1) to set the target length. :-) And yes, I realize that you often don't need all those instructions because you may have things handy in registers. /Leonard
rickert@CS.NIU.EDU (Neil Rickert) (04/26/91)
In article <9104260659.AA07567@ucbvax.Berkeley.EDU> LDW@USCMVSA.BITNET writes: > >I've been known to remark that MVCL is an 18 byte RR instruction. >Let's see now: > LA Rx,source 4 > LA R(x+1),source_length 4 > LA Ry,target 4 > LA R(y+1),target_length 4 > MVCL Ry,Rx 2 > --- > 18 This is why I sometimes prefer an MVC or an MVC/EX loop. But of course your 18 bytes is a serious underestimate. After all you must first save the current contents of the registers, and later restore them. If something is really worth doing in assembler, you are probably going to have all registers tied up, so there just aren't two even/odd pairs readily available. MVCL is mostly useful when you need its feature of padding the destination. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
PERSHNG@YKTVMH3.BITNET ("John A. Pershing Jr. 784-7167", 914) (04/26/91)
Invariably, registers 0, 1, 14, and 15 are available for use in an MVCL
instruction -- with no saving/restoring of previous contents. In fact,
I rarely see Real Programmers using any other registers with an MVCL!
Practical rule-of-thumb:
If the string being moved is known to *always* be 256 bytes or
less, then go with an EXECUTE of a MOVE CHARACTERS instruction (but
watch for a length of zero bytes!). If the string being moved is
of a constant length (i.e., known at assembly time) which is 4K or
less, then a series of MOVE CHARACTERS instructions is usually
"best" (*not* a loop: a series of MVC instructions). In all other
cases (more than 4K, or an unknown length that may exceed 256), go
with the MOVE LONG instruction.
Note that MOVE LONG cannot handle strings that are longer than 16 Megs
(the length fields are only the bottom 24 bits of the odd registers).
However, if you are dealing with objects whose sizes are measured in
megabytes, you probably shouldn't be moving them around, anyway...
John Pershing
IBM Research, Yorktown Heightsrickert@CS.NIU.EDU ("Neil Rickert, N Illinois U, CS") (04/27/91)
>Invariably, registers 0, 1, 14, and 15 are available for use in an MVCL I usually avoid writing that type of program if I can. What if you have a reentrant subroutine, R15 is your base reg, R1 has parameters, R2-12 are tied up for your computationally intense algorithm, and the routine will be used heavily enough that you cannot afford the cost of a GETMAIN? >instruction -- with no saving/restoring of previous contents. In fact, >I rarely see Real Programmers using any other registers with an MVCL! > >Practical rule-of-thumb: > Another practical rule of thumb: If there is any chance whatsoever that the move will violate the MVCL restrictions on destructive overlap, use an MVC loop or a Load and Store loop (for aligned numeric data). Don't assume that just because the instruction is MVC or MVCL you are dealing with characters. It might just be an array of numbers. -Neil Rickert
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/29/91)
rickert@CS.NIU.EDU (Neil Rickert) writes: > But of course your 18 bytes is a serious underestimate. After all you must >first save the current contents of the registers, and later restore them. >If something is really worth doing in assembler, you are probably going to >have all registers tied up, so there just aren't two even/odd pairs readily >available. MVCL is mostly useful when you need its feature of padding the >destination. In most cases, when I need an MVCL, the addresses I need are already in the registers. Careful register reallocation gets them into the correct registers. For instance I try to keep address/length data in even/odd pairs even before I anticipate needing an MVCL. Only rarely do I need to dump something out of registers to do an MVCL. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
news@ucf1vm.BITNET (04/29/91)
rickert@CS.NIU.EDU (Neil Rickert) writes: > But of course your 18 bytes is a serious underestimate. After all you must >first save the current contents of the registers, and later restore them. >If something is really worth doing in assembler, you are probably going to >have all registers tied up, so there just aren't two even/odd pairs readily >available. MVCL is mostly useful when you need its feature of padding the >destination. In most cases, when I need an MVCL, the addresses I need are already in the registers. Careful register reallocation gets them into the correct registers. For instance I try to keep address/length data in even/odd pairs even before I anticipate needing an MVCL. Only rarely do I need to dump something out of registers to do an MVCL. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/29/91)
PERSHNG@YKTVMH3.BITNET ("John A. Pershing Jr. 784-7167", 914) writes: >Invariably, registers 0, 1, 14, and 15 are available for use in an MVCL >instruction -- with no saving/restoring of previous contents. In fact, >I rarely see Real Programmers using any other registers with an MVCL! Mostly I use R2/3 and R4/5 and sometimes R6/7. Occaisionally I use R14/15 but very rarely R0/1 because R0 is pretty useless for addresses. The reason I may be different than what you see usually done is because of the ways I go about assigning register usage. I usually do it, and the coding, backwards. >Note that MOVE LONG cannot handle strings that are longer than 16 Megs >(the length fields are only the bottom 24 bits of the odd registers). >However, if you are dealing with objects whose sizes are measured in >megabytes, you probably shouldn't be moving them around, anyway... Where this might end up being a problem is where resultant usage of a program ends up exceeding 16 megabytes by a user of the program who needed to really stuff the program in ways the original programmer never thought of. I agree on the advice of not moving so much data. Doing things like exchanging addresses would be far better. Still there are times it cannot be avoided, and it would be good advice to always test lengths when they come from circumstances where you cannot be sure they are under the 16 megabyte limit. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
news@ucf1vm.BITNET (04/29/91)
PERSHNG@YKTVMH3.BITNET ("John A. Pershing Jr. 784-7167", 914) writes: >Invariably, registers 0, 1, 14, and 15 are available for use in an MVCL >instruction -- with no saving/restoring of previous contents. In fact, >I rarely see Real Programmers using any other registers with an MVCL! Mostly I use R2/3 and R4/5 and sometimes R6/7. Occaisionally I use R14/15 but very rarely R0/1 because R0 is pretty useless for addresses. The reason I may be different than what you see usually done is because of the ways I go about assigning register usage. I usually do it, and the coding, backwards. >Note that MOVE LONG cannot handle strings that are longer than 16 Megs >(the length fields are only the bottom 24 bits of the odd registers). >However, if you are dealing with objects whose sizes are measured in >megabytes, you probably shouldn't be moving them around, anyway... Where this might end up being a problem is where resultant usage of a program ends up exceeding 16 megabytes by a user of the program who needed to really stuff the program in ways the original programmer never thought of. I agree on the advice of not moving so much data. Doing things like exchanging addresses would be far better. Still there are times it cannot be avoided, and it would be good advice to always test lengths when they come from circumstances where you cannot be sure they are under the 16 megabyte limit. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/29/91)
rickert@CS.NIU.EDU ("Neil Rickert, N Illinois U, CS") writes: > What if you have a reentrant subroutine, R15 is your base reg, R1 has >parameters, R2-12 are tied up for your computationally intense algorithm, and >the routine will be used heavily enough that you cannot afford the cost of >a GETMAIN? If you were designing the calling interface, I'd go back and rethink it. One possible savings might be in passing in a temporary data area to play with, that would hopefully not need to be allocated over and over in the calling program. But then, I find it a but hard to imagine a program that is computationally intense AND having shove some bytes, too. But anything is possible. > Don't assume that just because the instruction is MVC or MVCL you are dealing >with characters. It might just be an array of numbers. Hopefully you at least know in advance. I did write a FORTRAN callable function called MVCL (and one called CLCL; guess what it did). There were 5 arguments: array1, length1, array2, length2, pad. Of course this program had no idea what the data type was, but the calling program was the one to decide if there were any overlaps. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) (04/29/91)
rickert@CS.NIU.EDU ("Neil Rickert, N Illinois U, CS") writes: > What if you have a reentrant subroutine, R15 is your base reg, R1 has >parameters, R2-12 are tied up for your computationally intense algorithm, and >the routine will be used heavily enough that you cannot afford the cost of >a GETMAIN? If you were designing the calling interface, I'd go back and rethink it. One possible savings might be in passing in a temporary data area to play with, that would hopefully not need to be allocated over and over in the calling program. But then, I find it a but hard to imagine a program that is computationally intense AND having shove some bytes, too. But anything is possible. > Don't assume that just because the instruction is MVC or MVCL you are dealing >with characters. It might just be an array of numbers. Hopefully you at least know in advance. I did write a FORTRAN callable function called MVCL (and one called CLCL; guess what it did). There were 5 arguments: array1, length1, array2, length2, pad. Of course this program had no idea what the data type was, but the calling program was the one to decide if there were any overlaps. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
klassen@SOL.UVIC.CA (Melvin Klassen) (05/01/91)
In article <9104260659.AA07567@ucbvax.Berkeley.EDU> you write: > >I've been known to remark that MVCL is an 18 byte RR instruction. >Let's see now: > LA Rx,source 4 > LA R(x+1),source_length 4 > LA Ry,target 4 > LA R(y+1),target_length 4 ICM R(y+1),B'1000',=CL1'fill' 4 > MVCL Ry,Rx 2 > --- > 18 22 Sometimes, non-null fill is required!