IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> wrote on 01/10/2012 03:11:25 PM:
> The intent of my post was that it would be a lead-in to a more > generalized discussion as to why it might be that System/360 was > designed with a set of registers that contain heterogeneous control > information, sometimes within a single register and yet provides > instructions for loading and storing their values in a whole register at > a time fashion. Having 16 of every type of register promotes a more > orthogonal design aesthetic but I wonder if the designers got a little > carried away with the concept. It allows for a smaller instruction set > I suppose since you only need LCTL and STCTL for reading and updating > values in one or more Control Registers but wholesale loading of control > registers can involve interdependencies that add significant overhead. > The existence of instructions such as ESEA that load specific bits of > Control Registers without incurring overhead due to interdependencies > suggests to me that the 16 of every type of register design aesthetic > may have been over-extended a tad. > > As for using the ESEA instruction? I see no issue with doing so > provided steps are taken to ensure that changes to the EAX are > encapsulated (such as when a PC routine whose ETE specifies a non-zero > EAX value is executed). Like all privileged instructions its use > requires care and attention to detail. > > BTW, I have not been able to find any documentation that corroborates > Jim's assertion that ESEA is only for operating system use. Is there a > list of OS-only instructions that I should be aware of? I guess I'd > like to make sure it's okay for me to be using SCKC and SPX (just > kidding). When the EAX was introduced with 370/ESA architecture. the intended method for altering the EAX was PC/PR. With the introduction of the R bit in the ASCE in z/Architecture, z/OS implemented a means for itself to access real storage by making it look like a Scope=Common data space. A private (i.e. EAX protected) Access List Entry is used for this purpose, and it was not practical to encapsulate all of the code which uses it (like most of the Real Storage Manager) into PC routines. So ESEA was created as alternate means to manipulate the EAX. While use of ESEA outside of this environment is not prohibited, I would not expect it to be prevalent. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
