On Mon, 2 Mar 2009, Jan-Benedict Glaw wrote:
* Re-Port the VAX stuff to some current kernel version. (Working straight on it, I think it's a week it'll take making it commpile again.)
Good -- I'll be happy to update the kernel at one point. It looks like we may have an opportunity to get the API/ABI right at this point, before anyone uses the wrong stuff. For example we can start by dumping the legacy pre-RT signal syscalls. Nobody should be using them anymore so why bother implementing them? IA64 does not have them either and has never had for example.
* Get a libc up'n'running. (For a start, to do some testing, maybe uClibc is a good start, because a somewhat working port exists. In the long term, we'll want to have GNU libc. One problem here is that there's currently no __thread implementation in GCC/binutils, which current GNU libc requires. There once was a generic approach, but I'm not sure if that's still available or if we even *want* to use it. Another nitpick is that I actually don't know (yet :-P) how to get libm up'n'running. The VAX architecture has a different floating point unit that most of today's machines, and so it'll either need soft-float (slow) or something own (needs to be written).)
The FP seems a piece of cake to me. It's not that different from IEEE 754 as it was used as a reference during the IEEE 754 committee talks. Actually apparently if not for the lack of denormals, it would have become the IEEE standard instead. The ISO C standard is not bound to IEEE 754 and GCC seems to support the VAX FP just fine. And TLS does not have to be supported from the very beginning. Most if not all Linux architectures only added it at one stage; I'm not sure if all of them actually support TLS already.
A cross compiler is the way to go. Anything else will be painfully slow. For testing/running compiled kernel/software, SIMH is quite nice. (You don't need a switched-on VAX all the time and SIMH on a fast PeeCee is actually *faster* than a real VAX. And you can easily put a hugh amount of RAM into SIMH, which isn't all that easy with a real VAX...)
Sooner or later you'll need a native development environment as there are pieces of software out there which won't build or have full functionality if cross-compiled. Sad but true. I have a personal preference to use actual hardware over a simulator -- after all, it's the definite reference. What would be the sense if a piece of software worked correctly on a simulator but failed on a real chip? Maciej _______________________________________________ Linux-Vax mailing list Linux-Vax@pergamentum.com http://www.pergamentum.com/mailman/listinfo/linux-vax