need advice on module structure for ISA-specific sources and classes

[John Rose]

On Sep 4, 2014, at 3:08 PM, Alex Buckley <alex.buckley at oracle.com> wrote:

> - I see there are multiple versions of the VIS extension for SPARC, and of the AVX extension for x86. Do you envisage encoding ISA versions into the $CPU value? What taxonomy of ISAs is suggested by JNR?

The current set of "raw" processor names in libffi is:
  arm i386 mips mipsel ppc s390 s390x sparc sparcv9 x86_64

In HotSpot sources, we find it helpful to organize the x86 and sparc variants together, which may or may not be the right answer here.  There might be similar arguments for mips, s390, and arm variants.

The x86 and sparc sources can go together, even though the old 32-bit and new 64-bit ISAs are very different.  That is because there are enough similarities to justify some common code, and also because the chip vendors usually give enough hooks (cpu version queries) to tell the versions apart dynamically.  I.e., once you know the processor family, you can often work from a common source base.

Dunno whether that theory will work for arm64.

> - If precision is desirable, can I suggest preferring isa/$ISA to cpu/$CPU throughout? First, because we don't want to sling CPU-ish terms like "x86" when we mean ISA-ish terms like "x64-with-AVX2". Second, because I think Java's heritage is more ISA than CPU (see JVMS section 1.2).

I confess to being confused between CPU and ISA, and also between uname "-m" "-i" "-p" etc.  I think you are right that ISA is a more correct term than CPU; by saying CPU I'm mainly following the HotSpot convention which might be an outlier.

If we are going for precision, ISA (although more inclusive than CPU in the strict sense) may be too precise since it distinguishes several layers of x86_64 (to say nothing of the 32- vs. 64-bit operating modes).

> - With reference to mlib_v_ImageCopy_blk.s: it is OS-specific, SPARCv9-with-VIS-specific code, right? So its path would be something like:
> 
> src/java.desktop/unix.sparc9vis/native/libawt/sun/...

Probably just unix.sparc (under the above theory about keeping twins together) or unix.sparcv9.  There are several layers of vis, but they can be distinguished down in the weeds using cpu version sensing, ifdefs, etc.

Thanks for helping air this out.

— John