Re: sparc64 and sparc architecture -- any consensus?
On Tue, May 11, 1999 at 07:25:27AM -0600, Ward Deng wrote:
> > > The way sparc64 is going to work is pretty much already planned out by
> > > the egcs and glibc programmers. Sparc64 will cohabitate in a sparc32
> > > environment. There will be a /lib64:/usr/lib64 (not sure where the
> > > includes go, perhaps they remain the same for both?).
> >
> > Its not yet planned out, I have just an idea how to lay things out, but need
> > to make linker and glibc changes to make it work (well, the changes are
> > mostly done, but the hard part is to get them accepted).
>
> Solaris 7 uses /usr/lib/64 while SPARC64/OS(HAL) uses /usr/lib/sparc64. Can
> we use a similar layout?
The defines for these are in one file in egcs iirc, so it's trivial to
change. What do the FS standards say about this type of thing? (I'm
assuming nothing) since this is obviously going to affect more than just
Debian/RedHat/UltraPenguin. BTW, why wasn't /usr/sparc64-linux/lib used?
> > > The compiler for
> > > sparc64 will be able to generate 32bit and 64bit binaries (seems it
> > > always does 64bit by default, I'm checking into that), so it will only
> > > take mere compile CFLAG changes to make it compile/link as a 64bit
> > > object.
> >
> > It can default to 32bit as well, depends on how do you compile it.
> > I'd like the default to be determined by uname -m during runtime and you can
> > use sparc32 program to change uname -m output.
>
> Good idea!
Quick question, is it not a loss in overhead for just any old program to
be compiled 64bit? Is there not some loss in memory used and physical
binary size that most of the time is not worth the trade off of little
performance gain?
Also, what if a person is on a mostly sparc32 system, and they compile
perl (which currently is sparc32 on their system), now the resulting perl
is sparc64, and after installing most of the script don't work due to
failing to load the sparc32 dynamic modules (third party modules not
supplied by perl).
Basically I don't think we should make it easy for some one to screw there
system up. sparc64 is a long way off from being able to be the "main
environment". Until then, we should probably keep the default sparc32,
IMHO on both environments.
> "We" are looking for the following 64-bit libraries:
>
I have a libc.a, ld-linux64.so, and libelf.so if that helps any.
Reply to: