Hans Boldt wrote:
But you also avoided the point I was making, which was that, at a
programming level, there's really nothing about the underlying
architecture of a single level store system that the programmer has to be
aware of. From the programmer's perspective, programming is all about
writing open, read, write, update, and close operations.
I didn't avoid it - it's just irrelevant to *my* point. Hiding the complexity of the hardware from the application programmer is something any operating system worth the name should do. I'm talking about that part of the OS that lives between the application programmer and the hardware - that part is easier to reimplement for SLS than it is for any other architecture.
To recap, here's your original statement:
The essential goodness of SLS is that no part of the application is
ever involved with moving things between memory and disk. Everything
has an address, and when you access that address, the operating
system decides whether data is available or whether it needs to be
paged in.

My point is simply that, strictly speaking, the same could be said about
conventional O/S architectures. It's the job of the (modern) O/S to shield
these details from the application programmer. (Then again, maybe we're
just arguing semantic nuances here.)

Maybe we are. It's my contention that i5/OS would be easier to implement on a cloud (or on DNA-based circuitry, or whatever) than any other OS simply because you only have to rewrite the one piece of code that resolves an address and makes it available to the CPU. In traditional architectures, this can require multiple resolutions, while with SLS it's a single operation.

Anywho, it's not an issue worth much more space. Gotta go write an article about SQL ...

Joe

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 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.