I dont understand the Interaction Between CPU and Devices. Can someone explain i
Hello- I'm entirely new to assembly and such, and I have several questions regarding the Interaction Between CPU and Devices.
How does the CPU communicate with various devices? Hows does it see if a device exists? What organization or standard, de facto or otherwise, determines how the CPU interacts with these devices?
I just look at all the computers these days with variable numbers of slots and capabilities- new computers with new features using the same old processors- where do I find out how to utilize these features?
I can't find it in the Intel Documentation. I'm so lost =/
[628 byte] By [
tgwdnghn] at [2007-11-20 11:12:05]
# 1 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
The CPU can adresss data in:
- the registers
- the memory space
- the I/O space (that how I call it, I don't remember its official name)
Devices are exchanging data with the CPU by the means of the "in" and "out" statements. But usually, there are several layers, and only in the core layer you will find the "in" and "out" statements.
In real life it is not useful to know the means of communication between CPU and devices. What is interesting is the communication between the operating system of the computer and the software of the devices. That's were "device drivers" are involved.
# 2 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
That is precisely where I'm getting at. Not even at the operating system level, but slightly below it- right where the drivers are. Somehow, between whatever hardware interaction mechanisms are in place, via drivers or otherwise, there must be a way to identify and manipulate these drivers.
Question regarding to this process:
how do I identify the presence of a hardware device at the assembly level?
how do I know where to look for that device with regards to addresses and ports? What standards or organizations, de facto or otherwise (ie. de jure, standards, recommendations), define these means?
In addition, regarding "PC Architecture" (ie. a typical machine with an x86 processor as outlined in any A+ book), what defines this architecture (again, standards or organizations, de factor or de jure)? Like I know the basic steps a computer takes to start up, but I'm wondering what the specific steps are with respect to when and where the processor first takes control in executing commands
I really am looking for a firm understanding of what happens below the OS, if anyone can point me to some materials and resources or just talk to me about these issues. Preferably nothing too general- I'm looking for specifics
# 3 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
Here's my shot as answering your question, it's bound to be incomplete, and I'm sure there are others that frequent dev-archive who can correct my shortcomings, but here goes:
(this is based on univeristy course experience and work with the 8086 chipset in an embedded environoment)
Several other chips are generally connected to the CPU chip, and they generally share a data bus. When you wish to send data to one of these chips, you use the out assembly command and supply a virtual address and data (I don't remember the order or use of registers in this...see your documentation).
Particular low (usually) addresses will generally map (see your docs) to certain chip write signals. The data will be placed on the data bus, and the chip receiving the write signal will use the data while the other chips essentially ignore it.
Likewise you can get data from one of the chips by using the in assembly command and supplying the same virtual address.
Certain chips also have a signal line connected to the CPU, notifying the CPU that there is data pending. These will be connected to an Interrupt line. These interrupts signal the processor to jump to a different piece of code, called an "interrupt service routine" (ISR), so tasks can be completed relating to that chip.
Here's where the hardware and software meshes. Each interrupt line matches with particular virtual addresses that are placed in a special register when one occurs. The operating system writer uses certain routines (my memory of the jargon here is failing me) at startup to match the virtual address in this register to the ISR.
In order for an ISR to fully save and restore the processor state before it was activated, it needs to be written fully in assembly (there are particulars about stack behavior that C/Pascal/etc compilers can't handle with respect to ISRs...once again, my memory is limited here), and should be kept as short as possible to minimize disruption to the CPU.
Hopefully this gets you started. Driver routine gurus feel free to correct me on any of this stuff.
# 4 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
Yes Yes Yes!!! So, I assume you're trying to say that the chips themselves are what handle all these mechanisms regarding hardware. That definitely helps to know. So now, I dissect even further (I am a very decisive, comprehensive, bottom-up kind of guy. Mind me if I go on and on forever, but this stuff really interests me, and I like to trace these things to the source)
What kinds of chips? (eg. are these the same chips such as fdd controllers and, say, controllers of other things such as the hard drive, USB, graphics cards, USB drives, etc. etc.?)
What defines how these chips operate? (ie. standards, organizations, or de facto or de jure usage?)
What defines what kinds of chips are included in a computer? (I assume this is up to motherboard designers, considering how each mobo has different combinations of features, some have mo re than others, some have none at all)
The chip concept proved to be really insightful to me. I think I can see where this is going, but I can't wait to see what the outcome of this is =)
# 5 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
Exactly how the other chips interface with the CPU microprocessor is partially dependant on the design of the CPU. But, from the point of view of the CPU, the other chips are little more than memory cells. Under the x86 architecture, these are addressed with the in and out assembly commands, the address you give these commands mapping to individual chips, rather than a location within an array of RAM.
Generally a motherboard will have several chips: and I/O controller, a PCI controller, a harddrive controller, etc.
USB, Bluetooth, Firewire, older PS/2 (or Apple ADB) ports, and sometimes Network controllers will generally be connected to the I/O controller.
If you work in an embedded enviroment, you generally won't have any of these external chips to start with, so what controllers you have is up to you as a designer.
There's just so much to get into here. Give me some time and I can come up with some genuinely good textbooks (Title, Author, ISBNs), that treat this stuff.
In the meantime, you might want to find a processor user guide to one of the simpler chips, try this one: AMD 186ES, we used it at my university, and it's not overly complex http://www.amd.com/epd/processors/2.16bitcont/2.am186exfa/6.am186es/index.html
.......
If you don't mind be asking, where are you at education-wise?
This end of computer design tends to be in the Electrical Engineering/Computer Engineering realm. So if you are really interested in this stuff, getting into a good University program would be a very good idea.
# 6 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
This is quite exciting. The more the separation between the CPU and the controllers is defined, the clearer the possibilities make of themselves. I'm starting to visualize a CPU and merely processing how the controllers are supposed to work (ie. what they're supposed to be doing at the moment).
I haven't had time to look at your link yet (bombarded with things to do today), but until I look at it, my questions get narrowed down a tad more, just a tad
Is the functionality of these controllers standardized? Or is it just a "de facto" standard ripped off from some company or other?
Is there a way for the processor (perhaps more abstractly) to identify the presence and capabilities of each controller? (I assume so, since probably now all controllers are the same and you could theoretically have a driver for each)
Blah, I find it absolutely despicable how all the companies either haven't come to terms with clearly defined standards, or how they haven't made their standards, de facto or otherwise, too clear. I prefer Sun's approach- not only have a well documented standard available, but document the language to the extreme AND provide several in-depth, free tutorials that doesn't merely teach you how to use it, but outlines the relationship between the components of Java and everything else (especially the huge multi-layer and highly partitioned "cube" diagram they have)
It's almost like a lifelong mission for me to create 100% definitive, complete works on various computing topics from what-is-a-computer? to the infinite possibilities that await. I notice that the best sources for learning about things always either explain the exterior relationships between said topic (eg. a C book might discuss Unix and the ISO standard), or heavily sites and explains it's sources (if any of you ever saw the Bibliography for "How Linux Works?", which [the bib] is available online for free, you'll see exactly what I mean)
So again, mind me for cutting down deeper and deeper, I'm just trying to put it all together comprehensively
# 7 Re: I dont understand the Interaction Between CPU and Devices. Can someone explain i
Identifying the presence and the capabilities of a given controller would be more of a software/firmware (code) issue. USB is a popular example of this, and has both a hardware and software standard (but no so much as to be OS-limited).
The CPU chips are generally designed with a "best configuration" in mind for what control chips are connected to where, and the do quite a good job in documenting these sort of things. Sometimes you have to do some digging for the info, since much of the documentation was designed with CPU Manufacturing Company A sending the info to Mother Board/ROM Programming Company B and OS Programming Company C, but not to the basement tinkerer.
On the other hand, the same CPU Manufacturer's also give also sell chips to those that make Embedded Circuit Boards. These are much more bare bones than mother boards. They usually have the CPU, RAM (and ram controller), a Flash RAM ROM substitute, 2 serial "COM" ports (and the appropriate controllers), and a breakout board where you can hook up anything else you desire. When dealing with embedded systems, you can find some pre-build embedded operating systems (a popular hobby one is MicroC/OS www.micrium.com, often printed as C/OS and pronounced "mucous"), or you can program your own operating system from the ground-up.
Even more rudimentary than this, you can even buy your own Microprocessor and build outward from there. A very popular line for that is the PIC Microprocessor www.microchip.com.
As to standards for operation for various controllers, most start as proprietary company standards, but end up getting submitted to IEEE (Institute of Electrical and Electronics Engineers) for review, revision, and wide standardization.
One caveat, the CPU manufacturers still largely control the standards of the CPU chips, but they are still well documented. The big four CPU standards are x86 (Intel, AMD), PowerPC (IBM, Motorola/Freescale; used in Apple products starting ~1993), 68k (Motorola; used in Apple products until ~1996), and MIPS (independent standard; used by Playstation 1/2, not sure if PS 3).
In summary, I guess the reason -why- there isn't a comprehensive guide on this stuff is because the possibilities are nearly infinite.
