Bart Smaalders wrote: > Garrett D'Amore wrote: > > My personal preference, for now, would be to deliver *both* 32- and > > 64-bit versions of the applications for both SPARC and x86, but deliver > > the 64-bit versions in a separate path (/usr/bin/sparcv9 and > > /usr/bin/amd64 or somesuch), so that end users can just adjust their > > $PATH appropriately if they know they need or want 64-bit capable > > programs (I think for the vast majority of users, this will not be > > necessary.) > > > > This has the added advantage of minimizing the ARC "impact" of this, by > > not changing the "default" version of the tools right now. (And doesn't > > preclude making such a change later, particularly if at some point we > > decide we can stop supporting 32-bit-only processors, which I imagine we > > might do some number of years in the future.) > > Why should we continue to deliver a 32 bit version of a command, if today > we always exec the 64 bit varient? Anything that goes through isaexec > today should be 64 bit only on SPARC. The fact that we still use isaexec on > SPARC at all is a bug.
Slightly offtopic: One case was ksh93 where we _explicitly_ ship 32bit and 64bit vesions on both SPARC and x86 via "isaexec" (even against gdamore's counsel) because ksh93 supports a plugin API (and these plugin may need other libraries which may only be available as 32bit versions), ksh93's ability to handle _vast_ amounts of data in variable trees and arrays (therefore the 64bit version being the default on 64bit platforms) and because we want to make APIs like libshell and libast open in the future (first for ARC contracts and then gradually increasing the stability level) and that requires both 32bit+64bit versions, too. However this was a _special_ case and we did lots of research and benchmarking for this topic to make sure we don't run into any problems. This 32bit+64bit support on 64bit-only platforms should IMO really be the exception and not the default. > x86 will for now need to deliver both 32 and 64 bit binaries. If you're > worried > about the performance issues involved w/ isaexec, then let's design > something > better.... but have the user adjust their path is a complete non-starter and > we still need isaexec for the correctness cases (proc tools, etc). Right now "isaexec" isn't that bad. However the extra |exec()| becomes an issue in two scenarios: 1. Tiny application with very small runtime (e.g. GNU "echo") 2. Machine with many CPUs - |exec()| must tear down the address space and makes crosscalls to all other CPUs... which will be a problem for the 256CPU Niagara2+ machine... and even more a problem when I read TheRegister.co.uk's article (http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/) about a possible 2048-core machine. 2048-1 crosscalls per |exec()| won't be fun... ;-( > As an example, to replace most instances of isaexec, we could create > /usr/bin/isaexec > as a mount point, and then during boot mount /usr/bin/i86 or > /usr/bin/amd64 on > /usr/bin/isaexec as a loopback mount. We also change the isaexec > hardlinks in /usr/bin to > be symbolic links pointing to /usr/bin/isaexec/{cmdname}.... no more > runtime isaexec > overhead and no fiddling w/ user paths. That won't work because you have usually more than two entries in the output of /usr/bin/isalist (which is needed to support specially optimized versions for some CPU types like Niagara1 (which doesn't implement all VIS instructions in hardware (which makes the use of -xarch=sparcv8a AFAIK "tricky")) or SPARC64 (which has extra floating-point instructions not available on other SPARC platforms)). And see CR #6474270 ("isaexec and magical builds" - http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) for another reason why "isaexec" should remain "dynamically" and not turned into a "static" switch. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
