OSDev.org

Hi all. Ive been looking into deepening my understanding of IO, i was looking for a CPU with no IO and found this (a general blurb on IO) http://www.cs.nmsu.edu/~pfeiffer/classe ... es/io.html which some might find useful.

Is there anything anyone would disagree with on that article?

Mikey

A CPU without any IO is functionally equivalent to a brick. The only difference that's being discussed is how IO is actually implemented - does it have dedicated channels for devices and memory or does it look all the same from the CPU's point of view?

In the end, on some CPUs, software-visible IO channels might end up on the same physical bus as regular memory accesses, and on some other CPUs, different sections of address space might get stuffed onto different buses. Pretty much all CPUs of some complexity are built with awareness of the distinction between IO and memory, at various levels of details being divided between silicon and code.

Modularity seems to be the driving force behind IO, so i wanted to see how different CPUs are pushing this to its extremes. Some very early (monolithic?) computers do exist without IO. I guess they could be considered bricks.

combuster wrote:The only difference that's being discussed is how IO is actually implemented - does it have dedicated channels for devices and memory or does it look all the same from the CPU's point of view?

Could you add some comments about what is the benefits between channels and memory-mapped IO? The link discusses issues with the C language, but id be interested in other issues? Will future cpus go one way or the other? Or will both co-exist for the forseeable future?

What would a micro-kernel be required to provide to device drivers for these two methods (just access?), Is it standard or beneficial for a micro-kernel to abstract these into some generic model (Related to above question)?

cxzuk wrote:In the end, on some CPUs, software-visible IO channels might end up on the same physical bus as regular memory accesses, and on some other CPUs, different sections of address space might get stuffed onto different buses. Pretty much all CPUs of some complexity are built with awareness of the distinction between IO and memory, at various levels of details being divided between silicon and code.

This implies a functional equivalence between the two?

I liked the paragraph stating the IO superset categories. Would you agree with these categories?

Sampling < Polling < Interrupts < DMA < IO Controllers < IO coprocessor

Thank you for your reply,
Mikey

cxzuk wrote:This implies a functional equivalence between the two?

Wouldn't IO on x86 be nothing but uncached ordered accesses? You can after all achieve the same functional effect with page tables.
Also, if you have a system with a single bus, without out-of-order execution or caching, can you reliably tell if a bus cycle is an IO or memory access just by looking at the signals?

I liked the paragraph stating the IO superset categories. Would you agree with these categories?
Sampling < Polling < Interrupts < DMA < IO Controllers < IO coprocessor

Sounds like a homework question. Tell me, in what category would a sound card fall when it's recording audio?

cxzuk wrote:Modularity seems to be the driving force behind IO, so i wanted to see how different CPUs are pushing this to its extremes. Some very early (monolithic?) computers do exist without IO.

That depends on what you mean by "not having IO". Even the earliest computers had some means for the user to put data into memory and to read the contents of memory.

That said, the computer itself may not have had any way of performing IO on its own initiative (I/O instructions, DMA, etc), and if that's what you mean, then yes, those old computers didn't have any IO.

Yes, so long as you have a way of stopping the "machine" and accessing its internal state at the end of your calculation (to see the results), a machine with no IO still has a use. And yes, that does describe ENIAC, and it also describes modern-day DNA computers.

I would say that the real point of memory mapping all your IO is to offload all the details of IO processing from the CPU chip itself, because then some slave IO processor chip can separate the accesses and handle them appropriately. Your IO hierarchy also seems to assume the same thing for its ordering. This has been tried in the past many times, and during those attempts it turned out that having the CPU control all the IO directly was more economical (not more efficient, please note) -- and that economics trumped efficiency.

Certainly, at some point, one would hope that everything can be standardized sufficiently that a disk drive will KNOW what kind of filesystem it contains, and exactly how to transmit a file on that filesystem directly to the NIC card -- and everything will be smart enough to do all this with only the bare minimum of direction from the CPU. However, that day will also be the death of the x86 architecture, so it's still quite a way off.

Thank you for your replies all;

cxzuk wrote:Sampling < Polling < Interrupts < DMA < IO Controllers < IO coprocessor
Sounds like a homework question. Tell me, in what category would a sound card fall when it's recording audio?

I had considered these categories more relating to the interface to a device, rather than the devices purpose. The higher the better.

bewing wrote:ENIAC, and it also describes modern-day DNA computers.

I had a good read of the ENIAC, thank you. I will look into DNA computing too.

bewing wrote:Certainly, at some point, one would hope that everything can be standardized sufficiently that a disk drive will KNOW what kind of filesystem it contains, and exactly how to transmit a file on that filesystem directly to the NIC card -- and everything will be smart enough to do all this with only the bare minimum of direction from the CPU.

Ive read this as "IO coprocessors" (in the IO interface hiearchy listed above) where the NIC and disk drive would have a coprocessor each, and each coprocessor would be programmed by the CPU and left to it to do as instructed?

If so, would the IO Channel architecture be an implementation of this? http://en.wikipedia.org/wiki/Channel_I/O

and is the Cell processor similar in concept?

Thank you
Mikey

cxzuk wrote:

Combuster wrote:

cxzuk wrote:Sampling < Polling < Interrupts < DMA < IO Controllers < IO coprocessor

Sounds like a homework question. Tell me, in what category would a sound card fall when it's recording audio?

I had considered these categories more relating to the interface to a device, rather than the devices purpose. The higher the better.

Not really. Take a network card for example: several modern ones have TCP logic built-in. Pretty much all of them have an optional simple filter on MAC addresses. Yet, you can't use the TCP logic for UDP or ICMP and you need to use the device on a lower level. Also, if you want to debug the network you might simply want all traffic and you disable the mac address filter and enter promiscuous mode, after which you are forced by consequence to do the filtering all on your own.

In other words, the hierarchy is questionable as you can't typically pinpoint a device to one particular category.

cxzuk wrote:

bewing wrote:Certainly, at some point, one would hope that everything can be standardized sufficiently that a disk drive will KNOW what kind of filesystem it contains, and exactly how to transmit a file on that filesystem directly to the NIC card -- and everything will be smart enough to do all this with only the bare minimum of direction from the CPU.

Ive read this as "IO coprocessors" (in the IO interface hiearchy listed above) where the NIC and disk drive would have a coprocessor each, and each coprocessor would be programmed by the CPU and left to it to do as instructed?

Something to meditate on: Where will you draw the line between having another coprocessor and having another processor core? Who will be writing the firmware?

Combuster wrote:Something to meditate on: Where will you draw the line between having another coprocessor and having another processor core? Who will be writing the firmware?

Before i properly try to reply. What is the difference between a processor core, and a co-processor?

Didn't I just ask you that?

And no, I did not post that to get an answer. I was simply hoping you would realize there's no spoon.

Combuster wrote:Something to meditate on: Where will you draw the line between having another coprocessor and having another processor core? Who will be writing the firmware?

Im sorry, just to clarify. Ive read above to mean that you have in your mind some kind of division between the two?

For me, a coprocessor and a (central) processor core (and for that matter graphics processor unit) are just Processing Units[1], but have been given a role. Which is irrelavent for interfacing.

cxzuk wrote:Who will be writing the firmware?

Im assuming that firmware here means the instructions to be run by a processing unit for application needs? And not the non-volatile code/data held in ROM/EPROM/Flash memory[2]?

The processing unit playing the Controller role would be responsible for firmware loading.

A question relating to the NIC comment in early posts;

Combuster wrote:Yet, you can't use the TCP logic for UDP or ICMP and you need to use the device on a lower level.

Does this include using the NIC at a lower-level for TCP too?

[1] http://en.wikipedia.org/wiki/Flynn's_ta ... ifications
[2] http://en.wikipedia.org/wiki/Firmware