EMC on AMD64
Now that realtime patches are available for x86_64 to run in native 64 bit mode, it was decided to see what was involved in getting EMC to run... Using the BDI-4 tree as a starting point, a subset of the sources were selected so that a minimal system could be compiled - Junking the build system in favour of automake was the first stage as the configure script is able to detect and set assorted options for Xenomai. A few compile time errors needed fixing in libnml which was anticipated from work elsewhere, these are mainly limited to network support..Because Xenomai does not have any floating point math libraries and gcc flags used by the kernel prevent the use of FPU math in kernel space, any binaries needed to be built for user space. This meant the procfs and module init/cleanup sections had to be removed along with a few kerne; only calls inside the trajectory loop. With the removal of module init/cleanup, out went the RTAI calls to set up periodic threads and shared memory - Not a problem as a brand new main() had to be crafted anyway... Xenomai provides several "skins" with various flavours of realtime APIs, probably the cleanest to use being native.
A few minutes with a text editor, and main() was coded and linked in to the new user space freqmod binary with just a handful of non-fatal compiler warnings.. Initial testing revealed a minor hiccup in generic.nml that was quickly resolved by increasing the size of the Tool Status buffer.. To save time, no run scripts were generated, opting instead to launch each of the four sections manually from xterms.
With minimillio, freqmod, minimilltask, and xemc fired up in that order, 3D_Chips.ngc was loaded and run. Considering the time involved (less that a couple of hours including tea breaks), the results were encouraging.
Having demonstrated EMC running in full native 64 bit mode on x86_64, the sources were committed to an archive on Zathras - These are not intended for public release, instead acting as a reference point for further work on user land realtime control on both 32 and 64 bit platforms with RTAI, PREEMPT-RT, and Xenomai. e.g. Moving trajectory planning out of kernel space and into user space (where it really belongs) opens up the possibility of linking in some very powerful math libraries to perform complex multi-axis planning. Profiling and debugging code is also greatly simplified in the process.
Are there any downsides to running pure user space realtime ?
Yes - Some architectures do not have inb() & outb() calls available in user space, so for these platforms, low level hardware drivers would need to reside in kernel space.
As with kernel space, great care is needed to prevent deadlocks and there are still a handful of calls that if not ordered correctly, will bring a system down..