In other words - you make sure all your programs are ... in-continent ?? Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services Humana Inc. 123 East Main Street Louisville, KY 40202 Humana.com (502) 476-2538 or 407-7266
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Don Poitras Sent: Monday, May 7, 2018 11:02 AM To: [email protected] Subject: Re: [IBM-MAIN] GETMAIN LOC=32 In article <[email protected]> you wrote: > On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant <[email protected]> > wrote: > >>Updating 32-bit programs to conform to > >>AM64 requirements is far less onerous than the massive changes > >>required to create a 64-bit application. > > > >No, it isn't. Why do you think it is? > All references to "L" to load an address need to be changed to "LG". Not necessarily. When we implemented large heap support for SAS/C, we used a scheme where we could avoid re-writing large parts of the assembler source by limitting ourselves to 2G "Continents" (a term I coined). By calling IARV64 and requesting 4G, we are guaranteed that at least 2G can be addressed via L and ST and so on in AMODE64 as long as the high half of the 64-bit register has been set. Testing the high half of the register in AMODE31 should be as easy as testing bit 32 to determine if you need to switch to AMODE64 or not. As long as you don't cross the 2G boundary, you can safely use L, ST, LA and whatever other non-grand instructions you desire and still be using memory above the bar. This falls down when you just want to look at some pointer in a control block to determine if you need to go AMODE64, but you could handle that by bumping your starting point from 0 in the low half of the continent to x'80000000'. You'd have almost what you're proposing with the additional overhead of ensuring the high half of your register contains your continent when you recognize the bit and switch to AMODE64. > All A() constants need > to be changed to AD(). Not unless you're also trying to support RMODE64 > Well, there is a way > around that. You can instead do a SGR and then continue to use L. All > save areas need to be changed to cope with the larger requirements. > But even if it was easy, most applications don't need more than 4 GiB > of memory, so it's best to keep them 32-bit as that is more compact. > Would it help if I ask the author of REVIEW how much effort it would > take him to produce a 64-bit version of his product so that datasets > more than 4 GiB in size can be edited? That would certainly be nice. > BFN. Paul. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [email protected] (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- 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
