we can probably do better than inb() / outb().
You can't do any better than that [It] is the only one that makes sense (when you run things on ia32).
... and when you're not on an ia32 platform with a superIO chip?
That's a moot point. Then you have to emulate ia32 to run windows programs anyway.
Advantages of using ppdev over simple inb() / outb() are:
should support [*] cross-architecture (arm, alpha, powerpc, ...)
That'd be good for winelib only or wine-with-emulator (bochs? qemu?).
Yup, both. A ported applications (via winelib or qemu) should work under any Linux architecture. Unfortunately, it would be a Linux-specific solution; *-BSDs have their own interface.
If you have access to the source it's simpler to write a native device driver. The only reason d'etre of running legacy windows apps that bit-bang things via direct port i/o is that there's no documentation for the hardware.
should support [*] some esoteric devices (USB-parallel converters, ...)
At a huge performance penalty ;)
But it would work, 's my point. The performance of parallel-over-USB is a separate issue.
Legacy devices (such as parallel ports) are being gradually faded out. So writing code that requires a SuperIO chip is not best.
Sure. But then you're talking about the driver code, not user code.
I think this discussion needs some clarification, as there are distinct use cases:
Case 1. Running legacy ia32 windows code that does port I/O on ia32. Case 2 : Running such legacy code on non-ia32. Case 3. Porting such apps over to winelib when the source code is available.
For (1) ioperm is the only reasonable solution. The hardware is there for you to do the job, so why bother emulating existing functionality.
For (2) you are doing instruction-by-instruction emulation, or at least block translation anyway, i.e. wine running with an ia32 emulator. So it doesn't really matter what you do, as there's no ia32 and likely no direct access to the 'ports' on target hardware. If the target hardware is a serial/parallel port, the motherboard chipset is likely to implement it in a wholly different way (or not at all!). The only chance for 1:1 plug-in compatibility is when target hardware is a PCI card. I don't know how many direct-IO win32 apps are there for PCI cards that are relevant enough to be moved to a more up-to-date non-ia32 hardware.
For (3), the simplest thing to do is to tear off the driver code and port it to the platform's driver infrastructure. Using winelib for any sort of emulation there is a waste of resources.
AFAIK, the overhead stems from the fact that instead of a machine instruction you have to:
- process an exception in the kernel, which then signals SIGSEGV to the
process
- invoke the signal handler
- determine what's up and disassemble the instruction at CS:EIP
- invoke a function/syscall based on the disassembled instruction
If this isn't dog slow, I don't know what is. I wasn't entirely clear, the syscall is the least of our worries in fact :)
I think you may be confusing some other activity (maybe an invalid memory access?).
How's an invalid memory access different from a legacy win32 application trying to do direct port IO without sufficient privileges?
1. You have an IN or OUT opcode in the code. When ioperms are not set, the CPU raises an exception. 2. That exception results in SIGSEGV being signalled to the process. 3. The signal handler has to determine what type of an exception is it. I don't recall whether the exception data has information about the type of exception, but in any event the opcode has to be disassembled just to get the port address and data operands. 4. Then in all likelihood the operands are not immediate constants, so the relevant registers have to be interrogated from the saved below-signal process context. 5. A port-to-filehandle look up has to be performed, in order to determine which open device has to handle that port I/O. 6. An ioctl has to be invoked on that handle. 7. Kernel's ioctl machinery is invoked, and the ioctl percolates to the driver code. Remember that ioctl requests can be handled by different layers of the driver stack, so it has literally to go the slowest path, through all the intermediate layers down to the driver. That's a bunch of switch statements to go through. 8. An actual port I/O is done by the driver, in case of 1:1 mapping, or a request is put to the bus subsystem if a legacy device (like a parallel port) is being handled via a usb/firewire "converter".
This code path is on the order of thousands of instructions long. If you have a legacy ia32 app running under wine on ia32 hardware, there's no point in doing all that in place of a simple port I/O.
A syscall is pretty simple.
Of course. But it's not "just about a syscall". And besides, even a syscall that has just a "ret" on the kernel side is still equivalent to say 40-50 "average" instructions.
At the cost of slowing things down. For devices that bit bang data (like programmers), this makes things unacceptably slow.
I can't say I share that experience (about being unacceptably slow, that is). A 40-60% increase in overhead for a single instruction would be definitely noticeable,
You're talking about a 3 orders of magnitude slow down, not a 40-60% increase.
but only if this is the bottleneck in the program.
When you do bit-banging, that's all that counts. The least a bit-banging application needs to do is to have two port accesses per bit (to flip the clock back and forth). Suppose you need to move 10 kilobytes in that fashion. That's 160 thousand travels through the points 1-8 described above. That'd be some 160 million equivalent instructions, assuming that the 1-8 path takes as much as a 1000 "average" instructions. How does 160 million instructions compare to say 50 thousand?
Putting that in real-life terms, if you're bit-banging to a programmable logic device that's on a PCI card, when you interleave bit-banging code with parse logic that works on a jedec file, you can easily get 5 bits/us on modern hardware.
Now, I'm not saying that there are any useful legacy windows apps that do just that and that would benefit from wine being fast in that respect.
What I'm saying is that for case (1) from the first list above, the ioperm() solution is the only one that makes sense. For other cases, you very likely have to do some hardware emulation anyway, and then it's not general enough to go into wine anyway. Maybe emulating the old-and-good parallel port would be sensible, but that's about as far as one can sensibly go.
The worse-case would be something driving the parallel port as a square-wave generator: you'd get the full 40-60% drop in performance (assuming all the above numbers).
Last time I checked, I could do about 5 million 16-bit writes per second onto an I/O port on a 5V, 32MHz PCI card sitting in my otherwise idle and not very new PIII system. Maybe I was just very lucky, then, but I don't buy the argument that executing steps 1-8 above can be done 5 million times a second.
The real question is: what applications are out there that need "hardware" support in wine. One likely class is applications with usb minidrivers. Those should be easy to handle via libusb, after implementing the necessary WDM functionality in userspace (in wine). Presumably some code for that can be leeched from ndiswrapper and any similar projects.
Cheers, Kuba