Mark L. Gaubatz wrote:
You have to be careful in analysis. The MVC sequences are intentionally
moving and modifying parts of Page Zero. This is probably related to
swapping of the current running user on MUSIC, or status being maintained
for the current user. In addition, the sequences shown would require
MULTIPLE MVCLs, thus MVC was the proper choice in the example.
It somehow failed to dawn on me that the MVCs in URMON were going to/from zero page and therefore there was no possibility of some of the code being repeated in a loop to move a full page. However, I did check that the sources and destinations of the sequences of four 256 byte MVCs are all consecutive, therefore each sequence of four 256 byte MVCs could have been replaced by a single MVCL to move 1024 bytes of data at a one time, assuming availability of four suitable registers.
In addition, the two sequences are mirrors of each other. Basically, one
section is SAVE something and the other is RESTORE something. This is also
indicated by the moves/restores from FLC and the upper part of Page Zero.
Agreed. These are not the only 256 byte MVCs in the MUSIC nucleus - they are just the largest congregation of them in one place. I did some more hunting and I found these in the TRACE module which move a total of 804 sequential bytes: MVC 88(256,R5),0(R4) MVC 344(256,R5),256(R4) MVC 600(256,R5),512(R4) MVC 856(36,R5),768(R4) There are a few possible examples of one or two 256 byte MVCs, some of which might be inside loops in all of these other modules: FIOCS, SIOCS, MFIO USRSVC, LODSVC, TCS, COMAND, NEWTCB, FSIO, MCHINT, CDSRCH and TRANTB. However it is a bit of a chore to drag them all out and disassemble them to find out when it is only of academic interest. Regards, Peter Coghlan
Mark
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Peter Coghlan
Sent: Thursday, April 16, 2020 5:05 AM
To: [email protected]
Subject: Re: [h390-vm] memset help
Drew Derbyshire wrote:
On 4/14/20 11:32 PM, Peter Coghlan wrote:
I wonder could this have been the COBOL compiler abusing MVCL
instructions in situations where they were not the appropriate instructions to use?
Perhaps instructions such as MVCL would be expected to be "hot
spots" because they can deliver a relatively large amount of work for a
single instruction?
Or is it that implementations of this instruction were sometimes
poorer than they ought to be and they were really not delivering bang
for buck?
I was told back in the 1980s that for performance reasons MUSIC moved
4096 bytes of data via a series of MVC commands in place of one MVCL.
My feeling is that something like this would be likely to have remained in
place forever more. I had a look through the "current" MUSIC nucleus object
deck for 256 byte MVC instructions (X'D2FF'). I found this section of code
in
the URMON module:
BR R14
LTR R4,R4
BZ 2224(R0,R12)
MVC 3112(4,R0),16(R0)
MVC 4056(4,R0),540(R0)
MVC 4060(4,R0),548(R0)
MVC 1456(256,R4),3072(R0)
MVC 1712(256,R4),3328(R0)
MVC 1968(256,R4),3584(R0)
MVC 2224(256,R4),3840(R0)
MVC 472(1,R4),3524(R12)
BR R14
MVC 3072(256,R0),1456(R13)
MVC 3328(256,R0),1712(R13)
MVC 3584(256,R0),1968(R13)
MVC 3840(256,R0),2224(R13)
MVC 16(4,R0),3112(R0)
MVC 540(4,R0),4056(R0)
MVC 548(4,R0),4060(R0)
Without doing a bit of work to figure out exactly what is going on, it is
not clear to me whether these code sections get called four times in a loop
or not but it could be the case.
Of course, it's harder to locate MVCL instructions (X'0E') in an object deck
but there seem to be a few in there, including this one in URMON:
ST R11,144(R0,R13)
XC 440(32,R13),440(R13)
LA R0,1456(R0,R13)
LA R1,1024(R0,R0)
SLR R3,R3
MVCL R0,R2
MVI 472(R13),32
L R5,3444(R0,R12)
ST R13,620(R0,R0)
LR R8,R12
L R12,3644(R0,R12)
BALR R14,R12
However, this could have been added later the lifetime of MUSIC.
Regards,
Peter Coghlan.
--
Drew Derbyshire
"All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
|
