Re: Explaining single level store to non i people

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