Re: [patch 4.1.3] Correctly handle zero operands with gcc on PA

[John David Anglin]

> > that there are some inconsistencies in how gmp-4.1.3
> > treats hppa*-*-hpux* configure options relative to other packages.
> > See configfsf.guess to see how these options are currently being set.
> 
> We don't pay too much attention to the ABI or other extra information
> worked into the cpu type by config.guess, we prefer to read the cpu
> type as indicating the cpu type, and have a separate ABI=xx to drive
> the ABI.  This becomes significant when recognising various exact cpu
> types, something not presently done for hppa.

For better or worse, GCC 3.5 now requires gmp support for gfortran.
So, if the configure options are treated differently, it's going to
lead to confusion for many users.

> > Gmp treats hppa2.0w as indicating
> > that the compiler supports 64-bit longs and PA 2.0 features.  This
> > is wrong.
> 
> You have to say what you do, what gmp does, and what you think it
> should do.
> 
> But what I can say is we treat hppa2.0w and hppa2.0 as the same thing,
> a pa 2.0 cpu, and then we worry what ABIs the system actually
> supports.  Having hppa2.0n default to ABI=2.0n is a nod to what we
> understand as the intention of that versus hppa2.0w, ie. to ask for
> the 2.0n ABI.  Or that's the theory.

It's my understanding that hppa2.0 only is relevant to hpux 10.20.
The early PA 2.0 machines had a 32-bit PDC that was only capable of
booting a narrow 32-bit kernel.  Later PA 2.0 machines can boot either
32 or 64-bit kernels.  This led to the 'n' versus 'w' distinction
in hpux 11.  The narrow kernels don't support the 64-bit runtime.
So, I question the equivalence of 2.0 and 2.0w.

The big issue is that there isn't a direct relation between the
cpu portion of the string generated by config.guess and the code
level used in the assembler .level directive.  The config.guess
string pertains to properties of the kernel.  Given that wide
kernels support two distinct runtimes, configuring packages that
directly use or generate assembler code based solely on properties
of the kernel.  For this reason, config.guess does an additional
check on CC to determine the properties of CC.

I think the default mapping in configure should be something like this:

configure       CC code                         gmp ABI
target          level

hppa64-*-*      _PA_RISC2_0                     2.0w
hppa2*-*-*      _PA_RISC2_0                     2.0n
hppa*-*-*       _PA_RISC1_1                     1.1
hppa*-*-*       _PA_RISC1_0                     1.0

I believe that the gmp 2.0w ABI works with GCC as is except that hppa64
incorrectly defaults to the 32-bit pa7100 (1.1 ABI).  The 2.0n ABI needs
work with gcc.

GNU linux does not support 2.0w yet as there is no 64-bit userspace.
64-bit kernels probably support 2.0n although it's not well tested.
I suspect linux kernels don't restore the SAR register correctly
for 2.0n.  I believe that 32-bit kernels only save 32-bit register
values.

> > There are only two defined runtimes, irrespective of the PA architecture
> > (aside from the minor differences in the 32-bit runtime between hpux
> > 10 and 11).  It is possible to use some of the PA 2.0 64-bit features
> > under the 32-bit runtime when running a wide kernel as it saves the
> > full 64-bit context state.  GCC doesn't do this as 64-bit register
> > values are not preserved across function calls.  You can currently fudge
> > this by configuring gmp with hppa2.0n.
> 
> We interpret 2.0n as permission to use 64-bit regs etc in the asm
> code, but with the 32-bit calling conventions.

Yes, it's ok to use PA 2.0 features that don't depend on the W bit.
However, watch out when it comes to issues such as exception/unwind
support as these features are not part of the runtime architecture
specification.

> > However, this isn't portable, and
> > you need '-mpa-risc-2-0' set in CFLAGS as otherwise gas will object to
> > the use of PA 2.0 features.
> 
> I'm not sure we've ever had a gas to try 2.0n.  We give .level
> directives in the asm code though.

Yes, rechecking I see that there isn't a problem except in the
following situation:

./configure
checking build system type... hppa2.0w-hp-hpux11.11
checking host system type... hppa2.0w-hp-hpux11.11
...
using ABI="2.0w"
      CC="gcc"
      CFLAGS="-O2"
      CPPFLAGS=""
      MPN_PATH=" pa64 generic"
...
make
...
gcc -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_
divrem_1 -O2 -c divrem_1.c  -fPIC -DPIC -o .libs/divrem_1.o
divrem_1.c: In function `__gmpn_divrem_1':
divrem_1.c:183: warning: left shift count >= width of type
divrem_1.c:183: warning: left shift count >= width of type
/var/tmp//ccdky7ls.s: Assembler messages:
/var/tmp//ccdky7ls.s:122: Error: Invalid Compare/Subtract Condition: db
/var/tmp//ccdky7ls.s:125: Error: Invalid Compare/Subtract Condition: db
...

The assembler errors come from the macro definitions for add_ssaaaa
and sub_ddmmss in longlong.h.  The warnings come from the
count_leading_zeros macro.

The main issue is that the straight-forward configure command doesn't
work.  Configure has selected the "2.0w" ABI when gcc is generating
code for the 32-bit runtime.  It's not exactly clear that a user needs
to specify ABI=1.0 to obtain a successful build.  The gmp "1.0" or
"2.0n" ABI should be selected automatically.  Similarly, gmp "2.0w"
should be selected automatically for hppa64-*-hpux*.

The comment for these macros says:

/* These macros are for ABI=2.0w.  In ABI=2.0n they can't be used, since GCC
   (3.2) puts longlong into two adjacent 32-bit registers.  Presumably this
   is just a case of no direct support for 2.0n but treating it like 1.0. */

The reason GCC doesn't put longlongs in a single register when generating
PA 2.0 code for the 32-bit runtime is that there is no way to specify that
part of a register is clobbered across a call.  Although GCC doesn't directly
support operations on long longs in a 64-bit register in the 32-bit runtime,
it is possible to access the second register of a DImode pair using the 'R'
operand modifier.  The upper part of a register can be loaded with depd.
Thus, it should be possible to define add_ssaaaa and sub_ddmmss macros that
work reasonably effectively in your "2.0n" ABI using gcc.  Obviously, the
issues with the count_leading_zeros macro need to be addressed as well.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)