Re: sparc64 and sparc architecture -- any consensus?
Adam Di Carlo <adam@onshore.com> writes:
> Nils has asked me to do a content merge of the sparc64 and sparc
> porting web pages. I wish we were clearer in our mind exaclty how
> sparc64 is going to work.
Well the big issue is that Debian runs fine on UltraSparcs, but the
sparc64 webpage, which people with UltraSparcs read, essentially says
that nothing has been done yet.
> The last consensus I remember is that the situation is that most
> packages work fine in 32-bit emulation mode, and recompiling the whole
> shbang for 64-bit wasn't really worthwhile. As such, it seems that we
> were leaning towards a "derivative architecture" approach, in which
> one a few packages need to be specific to sparc64: egcs64,
> kernel-image, and maybe number-crunch intensive applications that
> really derived benefit from being 64-bit.
It would be nice if egcs64 remained 32 bit - so that sparc32 machine
can also build sparc64 kernels.
> The head-scratching aspect of this idea is that dinstall, wanna-build,
> etc., don't support this concept. In fact, it would be almost easier
> to just let the autobuilders crunch away and do a full 64-bit port.
> Anyhow, I think getting fundamental consensus on what exactly we're
> doing for sparc64 is a very important early step.
I don't want a full 64-bit port. 64-bit should only be used for
programs that need it. Anything else slows down the program (cache)
and wastes memory. (Not to mention wasting space on the archives that
could be used for useful stuff, and unnecessarily requiring two sets
of CDs for sparc rather than one.)
It doesn't make much sense to add a few GB to the ftp site, slow down
Debian Linux, and use up a _lot_ of CPU just to avoid fixing dinstall
and wanna-build.
> The other issues which are unclear in my mind, and which I would need
> to know about, is how the fundamental toolchain (glibc, egcs, ldso) is
> doing w.r.t. sparc-64 support. Reading back in the archives, the only
> indicators I see is:
> * glibc should be basically there (??)
> * egcs not quite there (grab from ultrapenguin needed)
> * binutils not quite there (grab from ultrapenguin needed)
Middle of the summer for the preliminary userspace toolchain. It has
not been released yet. Ultrapenguin no longer exists. (It has been
replaced by Red Hat 6.0 - Jakub is now working directly on Red Hat to
reduce repetition of work.)
egcs and binutils should be fine. We currently do have a toolchain for
building kernels, but not for general user binaries, until work is
done upstream - at that point we can build a cross compiler using the
stock egcs package (as a "sparc" package) and build a glibc package.
You're probably reading messages from December/January, when I was
just starting to add UltraSparc support. Debian 2.1 works on
UltraSparcs, and will compile sparc64 kernels on any sparc.
> * xserver accellorated for Creator FB not yet merged
Accelerated Creator and LEO are in the XFree86-1_3.3.3.1-3 source
package (which I just built). A recent kernel will be needed for
Creator and Mach64 (e.g. any UltraSparc).
Steve
dunham@cse.msu.edu
Reply to: