>> I tried posting a much longer response to this, but it was >> apparently rejected by the moderators. Here's a shorter one.
> As I already mentioned in the other reply to this thread, feel free > to send me more specific replies to that article. I'm not sure why it didn't get posted -- it got "lost in the Ether" somehow and that maybe had nothing to do with the moderation. It was in part a response to your specific article, but also a much longer response to the overall thread which has taken a lot of circuitous tangents. I know it will piss off some people and will spur an even longer thread, so am unsure that I should try to post it again. But I also think it says some things that need to be said. If you're willing, I'll send it to you privately and see if you think I should try posting it again. >>>>> I/O has also vastly speedup (we have SSD speeds of up to 6 >>>>> GB/sec). Just not by doing IN/OUT, but by using memory mapped >>>>> PCI devices. >>>> >>>> I think you're confusing two different things -- MMIO and >>>> DMA/Bus-Mastering. >>> >>> He is NOT. >> >> I wasn't talking about ecm being confused, I was talking about you. >> AFAIK, ecm never tested either MMIO or bus-mastering so never said >> anything about them. > > Yes, the only tests I did involved running Slowdown with and without > the one port I/O instruction patched out in the waste loop. However, > Tom is correct that this specific *port* I/O access to that > particular port is not representative of all possible ways of doing > I/O. That is correct, but when I pointed out there really is not any difference in speed between MMIO and PMIO (the two general categories of doing I/O), Tom accused me of spewing BS. I gave him the opportunity to defend himself with some data, and he so far hasn't done that. Let me explain why I said what I did. In the Intel architecture, there is only one address bus and one data bus (in some of the older CPUs the address and data bus were the same physical pins on the CPU, but that is a peripheral discussion). The exact same address and data bus(ses) are used for access to both ports (PMIO) and memory (RAM or MMIO). There is a pin (I've seen it referred to both as IO/M and M/IO) on the CPU that is also part of the bus that tells the external devices whether the address on the bus is a port address or a memory address. The device (or RAM) with both the correct address _and_ address type is the only one allowed to respond. For PMIO, of course, only the first 16 address lines are valid and the rest are ignored (there are only 64k possible PMIO addresses). Also, instead of single pin on the CPU, some of them have a set of pins where some combination of highs and lows on the pins designate ports vs. memory addresses, but the concept is the same. The point is that there is only one bus. When the CPU wants to send or receive data from a device (whether it is RAM or I/O) it sets the pins on the address bus appropriately (the address, address type, direction of transfer, and some others as well) and waits for the device to respond. The fact that the IO/M pin is set or not has nothing to do with the transfer speed -- it all uses the same bus. The CPU must simply wait however long it takes for the device to respond. The simple fact that a device responds to port address(es) versus memory address(es) has nothing to do with the speed of transfer. However, there is a little more "flexibility" in the CPU instructions that can be used with MMIO vs. PMIO. With PMIO the only way you can transfer data is with IN, INS, OUT, or OUTS. With MMIO you can use (at least theoretically) all the CPU instructions that have memory pointers (which a lot of them do). But some devices have limitations on that, too (e.g., with some devices you can only modify an entire Word or DWord at once and not individual Bits or Bytes, and on some devices reading data from a port can actually change some configuration parameter and you don't even need to write to it). In theory, MMIO can make the code a little faster (or at least more efficient) if it is done properly, but if done improperly can actually make things slower. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
