6

In I/O-mapped I/O (as opposed to memory-mapped I/O), a certain set of addresses are fixed for I/O devices. Are these addresses a part of the RAM, and thus that much physical address space is unusable ? Does it correspond to the 'Hardware Reserved' memory in the attached picture ?

If yes, how is it decided which bits of an address are to be used for addressing I/O devices (because the I/O address space would be much smaller than the actual memory. I have read this helps to reduce the number of pins/bits used by the decoding circuit) ?

What would happen if one tries to access, in assembly, any address that belongs to this address space ?

'Hardware Reserved' memory

Cygnus
  • 3,222
  • 9
  • 35
  • 65
  • 4
    No, they are not part of the memory, they are part of the _address space_. The hardware will handle these ranges of adresses differently and use IN/OUT when you read/write from/to these addresses. – wildplasser Jan 02 '14 at 11:20
  • I have edited my question. Please look at that, and could you add some details and post as an answer ? – Cygnus Jan 02 '14 at 11:27
  • I don't know what "Hardware reserved" means. It is just what your tool thinks it is. It could also include memory for bios/video buffers or even DMA (which are all somehow reserved, and can not be allocated to processes) – wildplasser Jan 02 '14 at 11:32
  • So it is not related to port addresses ? Also, since you mentioned BIOS (reading about which had led me to this question), I have posted a question here - http://superuser.com/questions/695769/how-is-the-nvram-eprom-which-contains-the-firmware-placed-and-used. Maybe clearing that would solve this one too. – Cygnus Jan 02 '14 at 11:38

1 Answers1

7

I/O mapped I/O doesn't use the same address space as memory mapped I/O. The later does use part of the address space normally used by RAM and therefore, "steals" addresses that no longer belong to RAM memory.

The set of address ranges that are used by different memory mapped I/O is what you see as "Hardware reserved".

About how is it decided how to address memory mapped devices, this is largely covered by the PnP subsystem, either in BIOS, or in the SO. Memory-mapped devices, with few exceptions, are PnP devices, so that means that for each of them, its base address can be changed (for PCI devices, the base address of the memory mapped registers, if any, is contained in a BAR -Base Address Register-, which is part of the PCI configuration space).

Saving pins for decoding devices (lazy decoding) is (was) done on early 8-bit systems, to save decoders and reduce costs. It haven't anything to do with memory mapped / IO mapped devices. Lazy decoding may be used in both situations. For example, a designer could decide that the 16-bit address range C000-FFFF is going to be reserved for memory mapped devices. To decide whether to enable some memory chip, or some device, it's enough to look at the value of A15 and A14. If both address lines are high, then the block addressed is C000-FFFF and that means that memory chip enables will be deasserted. On the other hand, a designer could decide that the 8 bit IO port 254 is going to be assigned to a device, and to decode this address, it only looks at the state of A0, needing no decoders to find out the port address (this is for example, what the ZX Spectrum does for addressing the ULA)

If a program (written in whatever language that allows you to access and write to arbitrary memory locations) tries to access a memory address reserved for a device, and assuming that the paging and protection mechanism allows such access, what happens will depend solely on what the device does when that address is accessed. A well known memory mapped device in PC's is the frame buffer. If the graphics card is configured to display color text mode with its default base address, any 8-bit write operation performed to even physical addresses between B8000 and B8F9F will cause the character whose ASCII code is the value written to show on screen, in a location that depends on the address chosen.

I/O mapped devices don't collide with memory, as they use a different address space, with different instructions to read and write values to addresses (ports). These devices cannot be addressed using machine code instructions that targets memory.

Memory mapped devices share the address space with RAM. Depending on the system configuration, memory mapped registers can be present all the time, using some addresses, and thus preventing the system to use them for RAM, or memory mapped devices may "shadow" memory at times, so allowing the program to change the I/O configuration to choose if a certain memory region will be decoded as in use by a device, or used by regular RAM (for example, what the Commodore 64 does to let the user have 64KB of RAM but allowing it to access device registers some times, by temporarily disabling access to the RAM that is "behind" the device that is currently being accessed at that very same address).

At the hardware level, what is happening is that there are two different signals: MREQ and IOREQ. The first one is asserted on every memory instruction, the second one, on every I/O insruction. So this code...

MOV DX,1234h
MOV AL,[DX]    ;reads memory address 1234h (memory address space)
IN AL,DX       ;reads I/O port 1234h (I/O address space)

Both put the value 1234h on the CPU address bus, and both assert the RD pin to indicate a read, but the first one will assert MREQ to indicate that the address belong to the memory address space, and the second one will assert IOREQ to indicate that it belongs to the I/O address space. The I/O device at port 1234h is connected to the system bus so that it is enabled only if the address is 1234h, RD is asserted and IOREQ is asserted. This way, it cannot collide with a RAM chip addressed at 1234h, because the later will be enabled only if MREQ is asserted (the CPU ensures that IOREQ and MREQ cannot be asserted at the same time).

These two address spaces don't exist in all CPU's. In fact, the majority of them don't have this, and therefore, they have to memory map all its devices.

mcleod_ideafix
  • 11,128
  • 2
  • 24
  • 32
  • Thanks for the answer. I had read that memory-mapped devices and the applications can both use the address space freely. So why reserve the memory ? Doesn't that make it same as i/o mapped i/o ? – Cygnus Jan 02 '14 at 11:50
  • Thank you again. I understood the part about how many pins to use and memory access. However, for the rest, here is my summary (please correct me if I am wrong): i/o mapped i/o uses a separate address space from the actual memory which is accessed by special instructions. this memory cannot be accessed by memory access instructions (not sure what would happen if one tried to). for memory mapped i/o, all the address space is shared and accessed by memory access instructions. – Cygnus Jan 02 '14 at 14:56
  • Also, the "hardware reserved" memory is the memory used by the BIOS/video buffers etc which cannot be overwritten and is unusable by normal programs. It is different from the space reserved for i/o mapped i/o. Same question : is this right ? – Cygnus Jan 02 '14 at 15:06
  • 1
    Yes to all, but don't call "memory" to addresses belonging to the I/O address space ("this memory cannot be accessed by memory access instructions"). You cannot even try to address I/O address space with memory instructions because by definition, memory instructions address only memory space (which may contain memory mapped ports). See updated answer about how the system differentiates between memory accesses and pure I/O accesses. – mcleod_ideafix Jan 02 '14 at 17:02
  • So its more like giving "numbers" which the processor knows stand for i/o devices, and which i/o device each stands for ? – Cygnus Jan 02 '14 at 17:27
  • The address is not the only input memory and I/O devices get. There are some other control signals that participate in a bus cycle. Read, for example, the data sheet of the Z80 processor. It may be old, but simple enough to understand what signals from the CPU are asserted (and when) when there are a memory read/write, or an I/O read/write. – mcleod_ideafix Jan 02 '14 at 17:32
  • Thank you! This discussion was very helpful. – Cygnus Jan 02 '14 at 17:34