Re: Explaining single level store to non i people

Joe wrote:

Your objection really has nothing to do with my statement.

I'll try to make it a little clearer.

In a traditional system, you have multiple places where things get
read into and out of memory. One example is reading data from a
file, which is relatively trivial (at least when reading from
something like a disk drive). Another example is reading a program
in; that requires a different sort of read as well as some cool
address translation as you move it from disk to physical memory.
These two things are very different in non-SLS systems, but they're
virtually identical in SLS, because in both cases as far as the
application level and supporting routines are concerned, it's just
a memory access.

If you don't understand the different between that and the
fundamental differences in, say, a Unix or Windows environment
between loading a program and reading a disk file, then I guess
I'm unable to get my point across. Similarly with the JVM issue.
JVMs don't page. If you're not convinced, run Java on any memory
starved system (*nix, DOS, i5/OS) and watch the thrashing.

This is just common sense stuff. If you don't see it, that's cool.

Joe: Yeah, sure, I know what you're saying. To summarize, you're basically
saying that, on the iSeries, loading a program to memory is no different
than loading data to memory.

But on a conventional operating system, that's also largely true. The disk
devices, device drivers, and lower levels of the O/S, don't know what kind
of stuff they're moving from disk to memory. The only real difference, as
you point out, is that once executable code is loaded into memory, the O/S
might perform some address translation on the data, er, executable code.

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.

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.)

Cheers! Hans