On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith <[email protected]> wrote:
> It's important to note that the reservation of x'80000000' through > x'FFFFFFFF' is merely to help avoid addressing issues, as well-explained > previously. It's not a fundamental issue at all, and the architecture > itself doesn't have any such restriction. > > Also, you CAN allocate memory in this area (which was extended to > x'7_FFFFFFFF'). There's an undocumented keyword on IARV64 called something > like USE2GTO32G. You can expect no one to help you debug storage overlays > if you decide to do that! > > I read somewhere that Java wanted this area because it could "compress" > pointers to 4 bytes. I presume that they only need to address to > doubleword granularity, and so can shift the address 3 bits to the right to > store it in a 4-byte word (and conversely shift left 3 bits to use it). > Addresses up to 32G are the maximum that will fit in that scheme, and > that's where the "restricted" area now ends. > > I don't know why Java (or anyone else) would really need to do that - I'd > think just going to 8-byte addresses would be more sensible. But there it > is. > Well, my _guess_ about this is that Java runs (or is supposed to run) the same "everywhere". Part of that "everywhere" is in the embedded space where bits remain more precious that they are on the desktop and enterprise class machines. So this address compression doesn't do much for most, but does in the embedded arena. -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! <>< John McKown
