Evaluated purely on technical merit, I really like this idea. IMO it comes close to making some sort of elegant simplicity category. But if evaluated based on cost benefit, things seem extremely murky indeed. It also appears to be primarily championed by folks from the Hercules and OS380 developer community, folks that represent the wants and needs of IBM's bread and butter zSeries customer base. Right?
With unlimited development resources, fantastic idea, otherwise I think digging a hole for the carcass is overdue. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Tuesday, May 15, 2018 11:33 AM To: [email protected] Subject: Re: GETMAIN LOC=32 I should know better than to poke this thing again but I just do not see how it makes sense. - If the code runs AM=31 then 32-bit addresses will not work. - If the code runs AM=64 then the high words of the registers are significant. One cannot count on them being zero -- trust me on this, been there and got the S0C4 tee shirt* -- so you now have to at least be cognizant of high halves of registers, which defeats the OP's idea of pretending that bits 0-31 don't exist. You have to save those high halves (if you want to be well-behaved) and you have to zero or LLGF into them. And by running AM=64 aren't you getting away from this (silly IMHO) concept of portability back to s/370? Does that not make the case for this fall apart? The sole benefit is that programs could address > 2GB (and < 4GB) while still storing pointers in "traditional" single-word fields -- saving storage and saving having to re-work DSECTs. That's a lot of work on IBM's part to solve a very narrow need in the application world -- programs that need more than 2GB but will never need more than 4GB (or where the expansion to > 4GB cannot be justified). You want to do your RFE? Go for it. Follow @Jim's suggestion of requesting that STORAGE support asking for storage in the 2GB to 4GB range. That is your entire solution, right? *In fact at the last SHARE I learned a cool testing technique from @Ray Mullins. When testing an AM=64 subroutine, on entry do a LHM 0,15,=16F'-1'. That way you will pick up in testing any failures to properly initialize high register halves. Otherwise it will bite you now and then down the road. You can do the same thing with AR's when testing AR-mode code. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: Tuesday, May 15, 2018 8:13 AM To: [email protected] Subject: Re: GETMAIN LOC=32 On Tue, May 15, 2018 at 10:03 AM, Paul Edwards <[email protected]> wrote: > On Tue, 15 May 2018 04:16:44 -0700, Ed Jaffe > <[email protected]> > wrote: > > >On 5/12/2018 2:02 PM, Ed Jaffe wrote: > > >Of course, you might have to change numerous existing LLGT > >instructions into LLGF instructions, but that's only a fraction of > >the effort needed to widen all of your pointers. > > I'm not familiar with LLGT. All my code uses 32-bit instructions found > in S/370, so there is no LLGT to change. If you simply write your > 32-bit code sensibly (don't use the high bit or byte in addresses for > flags), it will run AM-infinity, including AM64. > I think what Ed is getting at is to load a "32 bit" pointer, you need to insure that the high word of the register being loaded (bits 0..31) are zero. You can do this simply by somehow being sure that it is and using an L, or the LLGF will load the 32 bits into the low word (32..63) of the register and zero out the high word automatically (bits 0..31). This is the safest way, rather than using an old fashioned L instruction. Of course, if you are absolutely certain that the high word will always be zero, then this is overkill. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
