Hi Edwin,
The discussion is very helpful to me in clarifying my thinking, so I would like to address the points you raise. You wrote:
> In an ISO seven layer scheme for example I think of the Presentation Level (seven) as being able to display status of lower levels such as physical, data-link, and network layers, whereas the physical layer would have no knowledge of the higher layers. This seems the converse of what you're saying.
Yes, my thinking is opposite yours. Perhaps the difference is that I am describing the layers in a process-oriented way, in other words what happens as they perform their duties, and you are describing the static structure of the information packet. Of course both are valid as descriptions, but in what follows I will try to clarify my process viewpoint.
It is true that higher layers will structure information in their own ways that lower layers may not be able to easily interpret. But notice what happens when the upper layers want to communicate: they appeal to lower layers to get the job done. As part of that, the lower layers can see what they are sending (every bit of it). The lower layers are also party to everything the upper layers receive.
On the other hand, the specifics of the operation of the lower layers (e.g. whether implemented in hardware or software, etc) is invisible to the upper layers. They call the API and it "just happens". So the upper layers "know" less about the lower layers. All they know is the architectural contract the layer provides, not how the service is achieved. They have no way to "see" what the lower layers are doing. This is the asymmetry that is important.
> Similarly, debuggers and disassemblers (for example) can access breakpoint registers, decode global and local descriptor tables, and otherwise poke around in **and interpret** lower level status,...
The same architectural layering principle that applies to software stacks such as ISO also applies to emulation stacks, such as the example of the 80386 emulating an 8051 that you mentioned earlier.
In this case, the layer boundary is at the 8051 instruction set level. Software compiled for the 8051 runs in the higher layer. It has no way of knowing what happens when it issues an 8051 instruction. (It could be processed by a physical 8051, or it might be handled by the 80386 based emulator, or even on the chalkboard of a computer science class.). The results look the same from *within* the upper layer.
On the other hand, the lower layer sees every opcode the upper layer issues, and generates each change in the (virtual or physical) 8051 machine state. So it "knows" a lot more about what is happening up there; it just may have difficulty "understanding" it.
A debugger implemented using 8051 instructions would just be another upper layer process, so it can know the upper layer machine state, but it can't "see" below the architectural boundary. The boundary occurs between a process that issues instructions defined by an architecture and a process that implements those instructions.
> ...whereas the raw machine level instructions don't know beans about email, calendars, spreadsheets, Second Life, etc.
It is true that upper layer software is able to use the machine level instructions in idiosyncratic ways, and the lower level might have a hard time understanding what the upper level is doing. But notice that the lower level can modify the machine state whenever it wants to, not just when the upper level tells it to. Of course, it might technically be breaking its no-side effects clause in the interface contract when it does... but who is to know? This can be very useful to the lower level. For example, it might initialize memory at startup with a program it wants to run. Such agents run in the upper level and can interact with other software there (assuming the architecture defines a process interaction model) and they might tell the lower level a lot about what is going on up there.
> I'll check your blog and I'd be interested in "non-physical memory storage".
I am working on a post for the blog now to describe my conception. Thanks so much for your time in this discussion; it has really helped me get clear what I mean.
Hugh