The list is great, I got exhaustive answers from Fletcher, Joe Daniel Polombo
Hendrik Visage and Casper Dik. I quote almost entirely Casper Dik's answer (>)
to my question (>>), with some integrations from the other (no prefix)
> >I wonder what implications it has if we migrate our old
> >and new machines to 2.7. Shall we be able to run 32-bit on all of them ?
> >Shall we be able to run 64-bit on all of them ? Should we choose either way ?
> >If we are forced run a mixture of 64-bit and 32-bit do we need two sets of
> >binaries ? Shall we designated a specific platform for compilations ?
>
> All systems capable of running SOlaris 2.5.1 and Solaris 7 can run
> a 32 bit kernel.
> The option to run a 64 bit kernel was introduced in Solaris 7.
----------------------------------------------------------------------------
> >(0) is there a command to tell which SPARC Vn (7,8,9) chip is onboard
> > and/or whether the kernel is 32- or 64-bit ? arch, mach and uname
> > do not supply this information.
>
/usr/sbin/psrinfo -v prints some detail about the processor.
> Only when "uname -m" prints "sun4u" you have a V9 chip.
> The exact revision of chip can then be gotten using "prtdiag"
/usr/platform/`uname -i`/sbin/prtdiag -v
> "isainfo -kv" tells you what type of kernel you can boot.
Check out: isaconf (since Solaris 7)
----------------------------------------------------------------------------
> >(1) am I correct that 32-bit and 64-bit kernel are imcompatible at
> > binary code level (i.e. we need dual installation of all s/w) ?
>
> No, you are incorrect.
>
> All 32 bit applications continue to run on a 64 bit kernel.
>
> Only applications specifically compiled for UltraSPARC (whether 32 bit
> or 64 bit compilation is used) will not run on non-Ultra hardware; only
> applications specifically compiled for 64 bit will not run on 32 bit kernels.
>
> (When "file foo" says something that includes "ELF 64-bit", it will only
> run on a 64 bit kernel; when "file foo" says something that
> includes "V8+ Required" or "UltraSPARC1 Extensions Required", then it
> will only run on UltraSPARC (on 32 or 64bit kernels))
>
> All UltraSPARC-I and -II systems can have both kernels installed
> and boot either fromteh same installation.
>
> UltraSPARC-III systems can only boot 64 bit kernels but will run
> 32 bit apps.
>
> Lowest common denomination compilations for "32 bit, SPARC v8"
> work on all SPARC hardware. (V7 hardware emulates V8 instructions in
> the kernel)
----------------------------------------------------------------------------
> >(2) Then I asked my second question
> >>> WHAT IS THE SITUATION at source code level, particularly for all those
> >>> items which may be affected going from 32 to 64 bit ?
> >
> The answer is both yes and no. You can still compile your apps
> as 32 bit apps and have full source compatibility.
>
> Or you can compile it as a 64 bit app; in that case you will need
> to do some porting (as misuse of "long" and asuming that "char *" fits
> in an int isn't too uncommon)
Solaris can run in 64-bit mode from 2.6 on (though it is NOT
advised to run a 2.6 in 64-bit mode, better use 7 or 8). This
is true only on UltraSparc platforms (sun4u), not for earlier
platforms (sun4m, sun4c, etc).
Also note that on some Ultra-1 workstations, you might have
to upgrade the OBP (eeprom) before you can boot in 64-bit mode.
64bit code (Ie. sparcv9 (and later) ) ill not easily run on a 32bit
kernel, althought it might be a 64bit CPU (ie. UltraSPARC).
32bit bit code will run on the 64bit OS, GIVEN: there are no kernel specifics
involved.
If posible: Load it with the 64bit kernel (Solaris 7 and later)
on the UltraSPARCs, and only go back to the 32bit once
certain 32bit modules (eg. FW-1 or other hardware) is needed to run
on the machine, or the application is fetching something in kernel
space in a 32bit specific fashion.
Be aware that GCC still can't compile 64bit specific applications, but
that doesn't preclude then from running on the 64bit OS. That's the
way I'm currently running all my Solaris 7 (and later) servers. It's
only the 2.6 versions which in any case doesn't have a 64bit kernel
which is 32bit only.
----------------------------------------------------------------------------
> >(3) and finally my last question
> >>> IS THERE an option similar to the -taso [option]
>
> There are basically two compilation modes; default for 32 bit compilation
> and -xarch=v9 for 64 bit compilation).
>
> The default mode is more or less -taso except that the executables run
> with the "mask upper 32 bits of address" bit in the processor set so
> that ven 64 bit addresses will be treated as 32 bit addresses.
> In the sense that there is still a lowest common denominator and that
> binary compatibility is guaranteed, yes; but you also
> get the ability to run 64 bit processes (i.e., address space >= 4GB)
> for which you do need to do some effort and for which binary compatibility
> is less (runs only on 64 bit kernels)
>
> >>you will
> >>have to use a special compiler option to get *64*-bit code, and that if
> >>you don't use a special option, you'll get 32-bit code.
>
> This is what is now the case.
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@sunmanagers.ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:18 CDT