Fwd: About the names of CPUs and architectures

[David Holmes]

Magnus,

You need to clarify exactly in what context you plan to make these 
changes. For example, i386 is the "libarch" name for 32-bit x86 and it 
probably has to remain the same for backward compatibility.

x86 is generically the Intel x86 architecture. We used that for the 
shared src/cpu directory when the 32-bit and 64-bit x86 code was 
combined some time ago (far too much duplication to have them separate).

x86_32 and x86_64 are specifically the 32-bit and 64-bit variants. We 
use these in specific file names when 32-bit and 64-bit need different code.

For a long time i386 was generically used as the 32-bit x86 architecture 
name in our bundles etc, but this was eventually updated to be i586 
(which is now more out dated than i386 was at the time it became i586).

amd64 has been phased out except for the legacy libarch value.

Note i686 is also used on the JDK side as the 32-bit x86 "arch" value.

Also note that the use of i386/i586/i686 does not actually reflect what 
instruction set the C compiler is told to generate. And we actually have 
the file i486.make in hotspot (but that doesn't instruct the compiler 
either!)

These values are used in a range of different contexts, so if you 
propose to change them you need to be clear exactly what is being 
changed. And your proposal below seems too simplistic. Taking a 32-bit 
x86 build then you need:

a) x86 to refer to the shared src/cpu directory
b) x86_32 to name 32-bit specific files
c) a name for the libarch directory (x86_32?)
d) a name for the bundle (x86_32)
e) possibly an "architecture" directive to pass to the C compiler (i586, 
i686 ?)
f) name for the .make file

I understand the desire to simplify and "modernise" but we don't 
necessarily have the luxury of being able to clean the slate here.

Cheers,
David

On 18/06/2012 8:37 PM, Magnus Ihse Bursie wrote:
> I tried to send this a few days ago, but it seems like it never reached
> the list..? Weird; I'm trying to resend it. Sorry if it's a dupe.
>
> *The background
> *
> Currently, there is a lot of different names floating around in the
> build system for the same piece of hardware, especially regarding Intel
> architecture. This is not just our fault, there is no complete
> world-wide industry consensus.
>
> For the 32-bit Intel CPU, we have:
> x86, i386, i586 and ia32.
>
> For the 64-bit Intel CPU, we have:
> x86_64, amd64 and x64.
>
> Fredrik wanted to unite this as much as possible. Unfortunately, he did
> so by introducing new names that was not used before (ia32 and x64).
> Currently, these show up mainly in how the configurations are named (the
> directories under build/). While the new names might have their merits,
> I believe they are not as commonly used as the old names. I also believe
> not much is gained by introducing a new name.
>
> As a reference, configure is consistently using the name x86_64 for the
> 64-bit Intel architecture, but switches between i386 and i586 depending
> on OS (and, of course, how antique the CPU is).
>
> In the OpenJDK source code, the 64-bit architecture was previously
> relatively consistently named amd64, but recently this platform has been
> renamed x86_64 -- but only on macosx. This is an even more unfortunate
> situation, that we have different names internally for the same CPU
> depending on OS. We should really be able to avoid this.
>
> The 32-bit architecture has been most commonly refered to as i586, but
> there is really no clear winner between i586 and i386.
>
> On top of this is the difference between "cpu" and "cpu architecture",
> where the former specifices a specific cpu with a given address length
> (e.g. x86_64) and the latter a family of cpu:s with different address
> lengths (e.g. x86 and x86_64). Currently we support two such familys,
> the sparc family and the Intel family. In the current build-infra
> solution they are named "sparc" and "x86", respectively.
>
> *My proposal*
>
> I propose that we change our new default names to:
> 32-bit Intel: x86
> 64-bit Intel: x86_64
> Intel arctitecture: x86
>
> (As reference:
> 32-bit Sparc: sparc
> 64-bit Sparc: sparcv9
> Sparc architecture: sparc)
>
> Rationale:
> x86_64 seems like the easy choice. It matches the configure name, and
> the new macosx name. Appearantly it was important for macosx to change
> this, so we should try to move the rest of the product this was. It also
> matches other large open source projects like Linux.
> "amd64" seems a bit old-fashioned, and "x64" is more common in marketing
> than in development projects.
>
> x86 is trickier. It is possible to argue for i586 instead, since it
> matches configure (sometimes) and the old name (sometimes). However, it
> feels like it is a superset of i386 and that it opens up for the
> possibility to be able to choose i386 instead, when that really is not
> an option. Also, I believe it would create a more coherent system of cpu
> and cpu architecture naming, corresponding to the sparc world (and
> possibly other future cpu architectures like arm (arch)/arm
> (32-bit)/arm64). I won't fight to defent this name, though, so if I'm
> voted down I'll accept that. :-)
>
> Furthermore, I'd like to change the source so we use the new names as
> far as just possible. In the places where it is not possible (basically,
> where it will affect visible parts of the resulting product, like
> directory names or os.arch property), we should have a simple mapping
> table replacing the names that needs replacing.
>
> Unfortunately, I'm leaving for vacation/parental leave today, and won't
> be able to implement any changes. Jonas and Erik might do that, but
> stated that there is "no promises".
>
> But at least it would be good to hear your opinions. I hope we don't get
> as an infected debate as with the build/target issue; let's keep this
> one civilized ;-)
>
> /Magnus
>