[LV] Now for another bit of noise , ok any noise ...

[Maciej W. Rozycki]

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 at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax