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

[Jan-Benedict Glaw]

On Mon, 2009-03-02 18:23:41 +0000, Maciej W. Rozycki <macro at linux-mips.org> wrote:
> 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.

Oh yes, we have! We can dump all legacy signals, and maybe even
all filesystem syscalls that are not LFS, maybe even a 64bit time_t :)

> >   * 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.

GCC does, but not libc, does it? All that sin/exp/cos/... stuff... And
keep in mind that there are two alternative float types that could
makeup the `double' type in C.

>  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.

The PA-RISC folks just added it these weeks to the toolchain. (Though
they were working on it, testing it, for quite some time.)

> > 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.

Sure. But we're not yet there :)

>  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?

There's no special sense in using simulator, except for speed or
memory reasons. Real hardware is what we develop for, don't we? But
for testing a compiled kernel (esp. in the early stages of testing), a
simulator is really a nice thingie. I for one only have some spare
minutes here and there to hack on it, most of the time not being at
home. I'd use a remote power switch, but a MVII with lots of memory on
my ia32 laptop is a good start.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
  Signature of:                          Zensur im Internet? Nein danke!
  the second  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/vax-linux/attachments/20090302/074f0b36/attachment.pgp>
-------------- next part --------------
_______________________________________________
Linux-Vax mailing list
Linux-Vax at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax