In article <3154560307111841.wa.mutazilahgmail....@listserv.ua.edu> you wrote: > On Mon, 7 May 2018 08:58:15 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> > 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 sas...@sas.com (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
