From: <jmk...@at...> - 2003-05-27 13:08:14
|
Jon wrote: > Paul wrote: > >I'd caution against using x86 assembler in the code - There has been talk > >elsewhere of running EMC on a non Intel platform. Stick with standard C and > >leave the assembler code where it belongs (in the arch headers). > > > Yes, I agree in principle with this. But, unfortunately, there is > ALREADY x86 assembly code in some parts of the R/T side of EMC! > The module asm/io.h is called for in a number of places related to > flipping bits in the parallel port. I have used it VERY extensively, > as it is the way to get fast I/O transfers using the IEEE-1284 > functions of the PC's parallel port. It would be nice if there > was no need to do this, but how do you access a raw I/O port on > x86 hardware without it? C has absolutely no function for handling > I/O ports directly. Anything that is memory mapped can be done pretty > easily in very generic C code, but I/O ports are another matter > entirely. Also, note that even the user-mode side of EMC probably > uses these, and also uses a system call to authorize access to a > range of I/O space addresses. All of this is awfully platform specific! > As long as all the x86 specific stuff is done by calls to things defined in asm/io.h, all is well. Someone porting to another platform does expect to do some machine specific work, after all! They will have to write their own version of asm/io.c, that implements all the functions and macros defined in asm/io.h in a way that works on their machine. What we need to avoid is scattering bits and pieces of x86 assembly throughout dozens of EMC source code files. And of course, any drivers or other code that interacts directly with the hardware will need revised anyway, since the hardware will be different. John Kasunich |