The current 32GiB physical address space limit might seem generous, but it seems reasonable that some embedded systems might exceed that limit in the near future. There seem to be several ways to increase the physical address range. Perhaps the simplest method would be to provide 64-bit PTEs, at least for 64-bit versions of OpenRISC. Doubling the size of PTEs would allow one to vastly increase the physical address range _and_ allow for more bits to communicate page-information (e.g., a bit indicating 'page is compressed in memory', several bits indicating page_group for support of a Single Address Space environment [cf. HP PA-RISC]) or for operating system use. The increase in the size of page tables should be modest (small processes might have no increase while the fractional increase of doubling the number of page table pages might be acceptably small for large processes) and the increase in bandwidth should not be problematic (multi-GiB systems are unlikely to have 32-bit wide memory interfaces). A more complex method that would preserve 32-bit PTEs would be to require mandatory page coloring. This seems unattractive because it can lead to memory-wasting pseudo-internal fragmentation, it requires a specific method of page assignment from the OS (The OS could do additional binning on top of the few bits of page coloring, of course.), it requires somewhat more complex TLB handling code, and it only buys a modest delay before reaching memory limits again (four bits might buy 6 years). Because page directory entries would presumably not have any page coloring, their physical addresses might be restricted to the lower area of memory, though one could interprete all the bits other than L (last) bit as part of the physical address (indicating an invalid directory by presenting it as an invalid Area/huge-page). Another complex method could use the otherwise unused bits of a directory entry to indicate a segment, using those as the MSbits of the physical addresses of all the pages provided by the directory. These nine bits could extend the address limit to 16TiB (enough to reach the end of Moore's Law, at least for embedded systems???). While this avoids complexity for 'small' systems (those bits could be set to zero), for larger systems it could significantly increase the complexity of page allocation by requiring each 16MiB _virtual_ Area to be allocated entirely within a single 32GiB Region. The main advantage of this scheme seems to be its providing a subset that matches the existing scheme well. A possibly simpler method would restrict the high address spaces to Area and Region translations, shifting the Physical Page Number by 11 bits. This has the advantage of adding minimal complexity to the OS (the upper ranges are simply reserved to Area/huge page translations). It might also be reasonable in that many memory demanding applications would prefer the use of huge pages to avoid TLB thrashing. However, a huge number of small processes would be hindered from using the higher addresses by their only using small pages. Of course, this is mainly a theoretical point as OpenRISC is unlikely to be taking on MIPS and PowerPC at the high end of the embedded world within the next few years much less entering the higher-end server/workstation market. Paul A. Clayton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20041106/4a517af5/attachment-0001.htm