|
Don wrote:
TOOOOOOO bad the AIX, linux and Windows boys haven't picked up on Single Level Storeage yet....
Fascinating debate! I first learned about the concept of single level store in school, circa 1979. While it is certainly interesting, you do have to wonder why, after all this time, there's really only one computer commonly available that implements it. As others have pointed out, there are always trade-offs in system design. All modern CPU's and operating systems implement virtual memory. Most implement it by giving each process its own address space, which minimizes the risk of one process adversely affecting others. But since all processes in an SLS architecture share the same (humongous) virtual address space, you need some means of ensuring that a process really is allowed to access a particular region of store. That puts more overhead on securing memory accesses, which requires substantial capabilities in the CPU itself. It also meant 16 byte pointers, which can increase memory requirements. If you remember back to the early days of the S/38, it had significant performance problems, which adversely affected the way system programming was done. (There *were* some very good reasons for rewriting the RPG compiler for RPG IV!) In terms of what it means to the average application developer, I don't think it really makes much difference. You still read files one record at a time, much like you would do in a non-SLS system. Even the idea of memory-mapped files (which would seem to be an obvious feature of a SLS system) is available in several non-SLS OS's. And even components like the RPG IV compiler front-end don't have any dependencies on the SLS architecture, which has allowed the code to be ported to other systems (such as the CODE program verifier and VA/RPG). Cheers! Hans
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.