John Plocher wrote:
> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> Switch SPARC GNU coreutils+bash from 32 to 64bit
> 1.2. Name of Document Author/Supplier:
> Author: Roland Mainz
> 1.3 Date of This Document:
> 30 May, 2008
> 4. Technical Description
>
> gisburn: Does it require an ARC case if we switch the GNU coreutils
> from 32bit to 64bit on SPARC only (no changes in interfaces and
> delivered files)?
> plocher: It doesn't sound like this has any architectural
> implications...
> gisburn: Not that I am aware of.
> plocher: so, I'd say that this was the entire arc review :-)
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> SFW
> 6.5. ARC review type: Automatic
> 6.6. ARC Exposure: open
>
Sorry, I want a fast-track.
1) I believe this is an incomplete project. What's good for GNU coreutils
is also good for the rest of the utilities. The source of the
utilities doesn't
matter.
Project completeness is always an arc concern.
2) We have a 32-bit user land (only) because 32-bit utilities on SPARC
weren't any faster than 64-bits (so why support both?). Since we have
unsupported any 32-bit SPARC hardware, the change could be made
now. However, validation needs to be done that this doesn't result in
performance regression. (Should be faster on an x86 - its all about
the number of registers, not the data path.) This is a C-team (PAC?)
issue, but it should be considered.
- jek3
