Memory and Addressing (Was: Google Android

[mbbrutman]

This really isn't an issue of fairness .. physical memory is well defined. I've not changed any rules or definition - no architecture text or OS would consider bank switched memory to be physical memory.

The 808x has 16 bit pointers. Segments are 64 bits. Using segment pointers and offsets the CPU can put any combination of 20 bits on the address bus. Looking at the 808x and claiming that it is bank switched because it uses a segment pointer and offset to generate the 20 bits for address bus seems a bit tortured to me, when the generally accepted definition of bank switching is using external hardware to bring the different banks of memory into view at a window in the memory map.

The same goes for the Z80 variants. The Z180 that you refer to has 20 address lines, hence the addressability of up to 1MB. (The DIP variant only has 19 lines, and only gets to 512K. This must be the version you referred to.) Zilog calls the extra hardware they put on the chip a memory management unit.

I think the key difference between an external bank switching mechanism and an 'on chip' one like on the 8088 and 8086 is that the external schemes are usually manipulated using memory mapped I/O or through I/O space, while a memory management unit is programmed using directly accessible hardware registers in the CPU. The 808x and Z80180 clearly have MMUs that generate their 20 bit addresses, not a hacked on bank switch mechanism like on a LIMS board.

If you choose to call an onboard MMU that is implemented with hardware registers a bank switching scheme, well, it is not. If it happens internal to the CPU and doesn't require extra hardware or setup to external latches on the bus, then it's physical memory. If you've got to program some I/O port to make it work, then it's a bank switching scheme.

And it's really irrelevant if said hardware exists on-chip or off.

It is very relevant. It's programmed different, it behaves differently. It's the difference between doing some I/O writes to bring a piece of RAM into view before putting a 16 bit address on a bus, vs. having the chip do it internally and generating a straight 20 bit address. The code to do it is different, and much faster when it is done by an integrated MMU.

 

[MikeS]

Well, perhaps in arcane textbooks the term "physical" memory is restricted to your definition, but I still suspect that *most* people would not interpret it that way, as you say they would. All the dozen or so definitions I looked up on the Web define it the obvious way, as any RAM "physically" installed in a system as opposed to "virtual" memory usually swapped in and out to external storage, without any consideration of the CPU or interface hardware; whether that agrees with your textbooks or not I would think that it's at least representative of what *most* people think it means.

Since to me and apparently many other sources there are only two types of memory from this perspective, physical and virtual, I would really appreciate it if you answered at least one of my questions, i.e. what do you call memory that is neither virtual or physical, or is any memory not directly addressable virtual in your opinion, regardless of how physically present it might in fact be?

And is the UMB in a DOS system "physical" or not, since accessing it requires essentially the same overhead as bank switching?

And finally, does a Z80 system that switches among several 64KB banks have any physical memory at all? If so, which bank is the physical one, and what makes it so?

Honestly, I'm not just being argumentative, I really am trying to understand how you actually define it since it seems so counterintuitive and inconsistent with the meaning of "physical". One or two of those authoritative references that "clearly define" physical memory as specifically excluding shadowed or bank switched memory would also be helpful.

 

[Chuck(G)]

Mike, I think your distinction is artificial.

Instructions to load a segment or a bank register are pretty much the same thing. Like an external bank register, other than loading or storing a segment registers, no operations can be performed on it. For example, it's not possible to add 1 to a segment/offset combination at its high addressing limit to get the next segment/offset in memory. If you want the next location, you have to calculate it and reload the segment register, exactly as you would do with a bank select register.

I remember how stunned I was when I asked the Intel applications engineer about how one would handle a data structure larger than 64K. It's pretty ugly.

The Z180 (I've worked with the HD64180, the Z180 as well as a couple of Rabbit variants) is very much a bankswitching design also, and very limited at that. That the MMU is on-board is mostly a matter of integration and not architecture. And it's programmed with I/O instructions, just like any external bankswitching hardware would be.

So if your criterion is "only what's under the epoxy", we can expand the epoxy easily to include whatever extra hardware we need.

On the other hand, the MC68000 is a true 24 bit design. Linear address space; no gimmicks to expand the physical address space such as segment or bank registers.

So it looks like we'll have to agree to disagree.

 

[MikeS]

I have to agree with you, Chuck; perhaps this is really just a semantic question, that in some circles the term "physical" means what Mike says instead of what most of us would understand, in which case no argument is possible.

But I don't see any real distinction between segment switching and bank switching either; like I said, even accessing the UMB of a PC architecture seems like the same thing even though the RAM is within the CPU's address space, and where this switching actually takes place seems totally irrelevant in this context.

I don't see why the fact that a Z80/MMU addresses its memory differently than a 68000 should mean that the 68000's RAM is "physical RAM" while the Z80 system's identical set of chips is not; that programming would be different just as programming a 6502 is different from programming a segmented 8088 also doesn't seem relevant.

The real distinction I see is between memory that contains data ready to be accessed by the CPU by either putting an address on the address bus or outputting a byte to a bank selection register, and a storage medium (which can of course also be RAM) that is *not* accessible via the address bus or a register and which must first have its contents transferred to the CPU's RAM. I think that's also what most folks would think of as "physical" and "virtual" memory.

But let's see what references Mike comes up with to support his definition; perhaps we'll both learn something.

 

[Dwight Elvey]

---snip---
But if you want to quibble, then sure, you can get a 286 to address (directly) 32MB of RAM. The status lines indicate when an instruction read is being performed, so you simply convert to a Harvard architecture and bingo, you've got 32MB of directly-addressable memory; 16MB of code and 16MB of data. As far as I know, the "instruction read" status was only used with ICE--but it's there.

QUOTE]

Hi Chuck
I thought I might mention that the Olivetti M20 uses a scheme where it splits
instruction and data memory, giving it 128K of memory ad one time.
It is interesting that you mention the difference between logical memory
and physical memory. If one looks at the M20's memory, the physical memory
is chopped in a number of places to have chunks for video and such.
Even the instruction space that is mapped into the 128K chunk is
also mapped elsewhere as data memory ( so it can be loaded from disk
as data memory ).
It uses a Z8000 processor. It didn't use a memory management chip, it just
used a ROM to map everything.
I know it always take me some time to get others to understand that
when using the debugger and one wants to alter an instruction that
you have to use a segement that has that physical memory mapped
as data. You can't alter it when mapped as instruction.
Physical memory and logical memory need not have any relation and
can be mapped anyway one feels like.
Dwight

 

[Fallo]

On a 286 this is done using a nasty system of segment registers, which to my knowledge only OS/2 ever used. (Maybe a Unix clone tried it too?)

Windows 3.x used 286 protected mode, although it supported 386 features such as virtual memory and V8086 mode. OS/2 (the original 286 version) had no 386 support of any kind.

On a 386 or better the nasty 286 system of segment descriptors is available, but a much nicer 'flat' address space model is also available. All of the modern OSes use the flat address space.

In fact, 386 protected mode is paged, meaning that you have segments, but they can be any size you want. Flat memory would refer to a scheme where there are no segments at all. Macs used this until OS X, when they switched to paged memory.

 

[pontus]

Gosh, what a discussion.

I think running android on a 486+ would be awesome! I think it'd be best accomplished via an emulation layer, so that you can use Android programs natively, instead of special x86 android programs. My (probably wrong) .20 (inflation)

I'm doing it right now If you download the Android SDK you get a QEMU(I think) which emulates an Arm machine with an android phone system on it.

 

[Chuck(G)]

Hi Dwight,

Indeed. When a mapping RAM is used for translation, one can even have the same physical memory at several different logical addresses--and physical memory addresses completely inaccessible (not in the mapping RAM).

I'm sorry I never got to fool around with the M20; there were certainly a lot of noteworthy designs back then.

I love huge logical addressing spaces.

When I was on the CDC STAR project, we had 256 64-bit registers and a 48-bit logical address space (bit addressable). Although there was only a half-megaword of core, the huge (for the time) addressing space made for lots of interesting variations. File I/O was most often done by mapping a file into an address range (the pager did all of the I/O). Open a file mapped to an address and treat it like a big array (the vector instructions let you do some pretty neat things). We had shared libraries and the OS kernel was mapped into the high address space of all programs, so context switching was fairly clean. And this was circa 1970.

On the other hand, the CDC 6000 series was the opposite--cramped 17-bit address space (128Kw). The 6000 series had an option for an added bulk core store of up to 4Mw. There were instructions to read and write from it and it had the same per-task relocation and field length registers that "regular" memory had. You couldn't execute out of it, however--just transfer to and from main memory. (So how much physical memory could a CDC 6600 address? 128Kw or 4Mw?) Extending your program by doing explicit transfers from ECS was a real pain.

Even though the two machines were separated by only about 5 years (and sold during the same period), the philosophies were worlds apart. The STAR had virtual memory with read/write/execute control and was a CISC vector implementation and 8 bit characters with 64 bit words.

The CDC 6000, on the other hand, was real addressing with only primitive protections and what amounts to a RISC implementation (although nobody called it that). 60 bit words with 6 bit characters. A very different world.

 

[mbbrutman]

Mike, I think your distinction is artificial.

Instructions to load a segment or a bank register are pretty much the same thing. Like an external bank register, other than loading or storing a segment registers, no operations can be performed on it. For example, it's not possible to add 1 to a segment/offset combination at its high addressing limit to get the next segment/offset in memory. If you want the next location, you have to calculate it and reload the segment register, exactly as you would do with a bank select register.

I remember how stunned I was when I asked the Intel applications engineer about how one would handle a data structure larger than 64K. It's pretty ugly.

The Z180 (I've worked with the HD64180, the Z180 as well as a couple of Rabbit variants) is very much a bankswitching design also, and very limited at that. That the MMU is on-board is mostly a matter of integration and not architecture. And it's programmed with I/O instructions, just like any external bankswitching hardware would be.

So if your criterion is "only what's under the epoxy", we can expand the epoxy easily to include whatever extra hardware we need.

On the other hand, the MC68000 is a true 24 bit design. Linear address space; no gimmicks to expand the physical address space such as segment or bank registers.

So it looks like we'll have to agree to disagree.

Well, we've been disagreeing quite a bit here. I'm not torturing any definitions to make a point though. You brought up address space when somebody asked how much RAM can be attached, you managed to claim that cache memory is equivalent to main memory (it is not - it operates in a much different manner, hence the tag bits), and you have suggested moving to a Harvard architecture for a processor designed and used as Von Neumann, and you are claiming that an integrated MMU is the same as an external bank switching setup.

If the manufacturer considers it to be part of the architecture, calls it an MMU, and then sets up the address bus with more lines to address the extra memory naturally, I'd say that is addressable physical memory. In the case of the Z180 you get more address lines coming out of the blob of expoxy and the bus cycle to access that memory always looks the same. The integration makes it much faster, and the software that runs on the two is different.

 

[JT64]

Gosh, what a discussion.



I'm doing it right now If you download the Android SDK you get a QEMU(I think) which emulates an Arm machine with an android phone system on it.

I am not sure i follow you, do you have a minimal Linux distribution that runs Qemu and emultates an Arm machine?

Did the linux dist come with Android?

JT