[parisc-linux] __hp9000s700 predefined

[parisc-linux] __hp9000s700 predefined

[Grant Grundler]

Hi all,
I was looking at how to properly ifdef code for parisc-linunx
and it seems that "#ifdef __hppa__" is "the right way" to do this.

Currently two files use ifdef CONFIG_PARISC: genrtc.c and hilkdb.c
Randolf (tausq) is fixing genrtc.c.
Any volunteers (ie 715/50 or 715/33 owners) for hilkdb.c?

But Randolf also noted that gcc predefines a few other things:
	-D__hp9000s700 -D_PA_RISC1_1

John Marvin suggested we remove the __hp9000s700 from the pa-linux
config files since it's HPUX crud. I think he's right since parisc-linux
kernels are intended to run on both 700's and 800's.
parisc-linux configs functionality in/out based on CONFIG_XXX flags
or run-time checks (ie register_driver()).
Can we remove the "-D__hp9000s700" from gcc/gcc/config/pa/pa-linux.h?

Similarly, gcc/gcc/config/pa/pa-linux64.h has "-D__hp9000s800"
which could/should be removed at the same time.

Any other thoughts on this?

thanks,
grant

Re: [parisc-linux] __hp9000s700 predefined

[David Huggins-Daines]

Grant Grundler <grundler@cup.hp.com> writes:

> John Marvin suggested we remove the __hp9000s700 from the pa-linux
> config files since it's HPUX crud. I think he's right since parisc-linux
> kernels are intended to run on both 700's and 800's.
> parisc-linux configs functionality in/out based on CONFIG_XXX flags
> or run-time checks (ie register_driver()).
> Can we remove the "-D__hp9000s700" from gcc/gcc/config/pa/pa-linux.h?

Yes

> Similarly, gcc/gcc/config/pa/pa-linux64.h has "-D__hp9000s800"
> which could/should be removed at the same time.

Yes

It's true, those defines are only there for compatibility with broken
HP/UX source.  I left them in because I figured it wouldn't break
anything.  If they really offend people I can certainly remove them :)

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] __hp9000s700 predefined

[John David Anglin]

> But Randolf also noted that gcc predefines a few other things:
> 	-D__hp9000s700 -D_PA_RISC1_1
> 
> John Marvin suggested we remove the __hp9000s700 from the pa-linux
> config files since it's HPUX crud. I think he's right since parisc-linux
> kernels are intended to run on both 700's and 800's.
> parisc-linux configs functionality in/out based on CONFIG_XXX flags
> or run-time checks (ie register_driver()).
> Can we remove the "-D__hp9000s700" from gcc/gcc/config/pa/pa-linux.h?
> 
> Similarly, gcc/gcc/config/pa/pa-linux64.h has "-D__hp9000s800"
> which could/should be removed at the same time.

These are needed for user apps as well as the kernel.  They allow cpp
to process files based on the machine features of the version of gcc used
for the compilation (e.g.: PA 1.0, 1.1, or 2.0; 32 or 64 bit; s700 or s800).
Thus, these or a similar set of defines are needed under parisc-linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] __hp9000s700 predefined

[Grant Grundler]

"John David Anglin" wrote:
...
> These are needed for user apps as well as the kernel.  They allow cpp
> to process files based on the machine features of the version of gcc used
> for the compilation (e.g.: PA 1.0, 1.1, or 2.0; 32 or 64 bit; s700 or s800).

o PA 1.1 vs PA 2.0 can be handled with -D_PA_RISC1_1.
  Since neither HPUX 10.X, HPUX 11.X, nor parisc-linux supports PA1.0,
  I don't know or care that is going to work (apologies to the
  folks who made spectrum happen).

o 32 vs 64-bit can be handled with __LP64__.

o s700 vs s800 is an artifact of HP's workstation vs server divisions.
  ie an artifact of how HP was organized. With HPUX 11, HP no longer ships
  different binaries for workstations vs servers (to many customers
  relief since we now only have one patch stream per release).

o As I noted before, linux enable/disables specific functionality and
  HW support with either CONFIG_XXX or runtime checks.

John, is there something specific you are concerned about which
can't be handled by the above predefined symbols?

BTW, HPUX vs parisc-linux vs osf vs hiux differences can be handled
with hpux, linux, mach, hiux predefines...ugh....looking at
gcc/gcc/config/pa/pa*h makes me want to puke...


> Thus, these or a similar set of defines are needed under parisc-linux.

I don't believe this yet...having worked on HPUX 10.20 and HPUX 11
extensively, I'm going to be hard to convince too...

thanks,
grant

> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] __hp9000s700 predefined

[John David Anglin]

> "John David Anglin" wrote:
> ...
> > These are needed for user apps as well as the kernel.  They allow cpp
> > to process files based on the machine features of the version of gcc used
> > for the compilation (e.g.: PA 1.0, 1.1, or 2.0; 32 or 64 bit; s700 or s800).
> 
> o PA 1.1 vs PA 2.0 can be handled with -D_PA_RISC1_1.
>   Since neither HPUX 10.X, HPUX 11.X, nor parisc-linux supports PA1.0,
>   I don't know or care that is going to work (apologies to the
>   folks who made spectrum happen).

You probably know better than I but I think PA1.0 is the "portable" default
for most libraries under 10.X.  I believe that gcc also defines _PA_RISC2_0
for PA2.0.  This is not used under hpux 10.X.  However, it is used under 11
in setjmp.h and varargs.h.  I also see _PA_RISC1_0 there, so gcc probably
should be defining it as well (at least for hpux).

Although parisc-linux may not run on PA1.0 hardware, you never know what some
software maniac will do in the future.  The gcc infrastructure to generate
PA1.0 code is there and works.  Thus, I don't buy the argument that this
capability shouldn't be supported under linux simply because you don't
want the symbol defines to support it in the namespace.  Kernel support
and building the appropriate libs are more of an issue.  Take a look
at the IDs in unistd.h and magic.h.  There are IDs for 1.0, 1.1, 1.2 and
2.0.

> o s700 vs s800 is an artifact of HP's workstation vs server divisions.
>   ie an artifact of how HP was organized. With HPUX 11, HP no longer ships
>   different binaries for workstations vs servers (to many customers
>   relief since we now only have one patch stream per release).
> 
> o As I noted before, linux enable/disables specific functionality and
>   HW support with either CONFIG_XXX or runtime checks.
> 
> John, is there something specific you are concerned about which
> can't be handled by the above predefined symbols?

I was just being cautious about __hp9000s[7-8]00.  I looked at some of
the uses in the hpux 10.X headers, and for usage in gcc and binutils.  I
don't see any obvious reason why these two symbols need to be defined
for linux.

I believe that the compiler only should predefine symbols that are necessary
for the control of code generation.  Neither CONFIG_XXX or runtime checks
will help you for this since gcc only has a limited capability to change
its code generation at runtime.  There appears to be some model dependence
in the floating point implementations from one pa machine to another.  If
this can't all be hidden in the kernel, some further specification of the
hardware might be needed for floating point.  For example, __i686__ is
defined on the Pentium Pro and is used in bits/mathinline.h.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] __hp9000s700 predefined

[Grant Grundler]

Summary ----------
Ok. It looks like we are in agreement.
I'm going to remove __hp9000s[78]00 from pa-linux*.h files.

grant

Full Reply -------------

"John David Anglin" wrote:
> You probably know better than I but I think PA1.0 is the "portable" default
> for most libraries under 10.X.

It's definitely not under 10.20. PA1.1 is the minimum.
I think PA1.0/CIO support was completely dropped after
10.01 or 10.10 releases.

> I believe that gcc also defines _PA_RISC2_0
> for PA2.0.  This is not used under hpux 10.X.  However, it is used under 11
> in setjmp.h and varargs.h.  I also see _PA_RISC1_0 there, so gcc probably
> should be defining it as well (at least for hpux).

Agreed. 10.X doesn't use _PA_RISC2_0 since it has to run on PA1.1 HW
and only supports narrow mode on PA2.0 platforms. Any differences
in the processor architectures are handled with runtime checks.
(like boot time patching of inline spinlocks).

_PA_RISC1_0 is cruft in HPUX 11. It's definitely not supported
and no maniac is going that change that.

> 
> Although parisc-linux may not run on PA1.0 hardware, you never know what some
> software maniac will do in the future.

I don't think the proposed change will prevent anyone from *attempting*
to port parisc-linux to PA1.0 architecture. <shudder>.

But this digresses from the original question about __hp9000s[78]00.

...
> > John, is there something specific you are concerned about which
> > can't be handled by the above predefined symbols?
> 
> I was just being cautious about __hp9000s[7-8]00.  I looked at some of
> the uses in the hpux 10.X headers, and for usage in gcc and binutils.  I
> don't see any obvious reason why these two symbols need to be defined
> for linux.

Ok. I was just going on my (limited) knowledge of the platforms
and how linux configuration works.

> I believe that the compiler only should predefine symbols that are necessary
> for the control of code generation.

Agreed. That's why we wanted it removed.

...
> There appears to be some model dependence
> in the floating point implementations from one pa machine to another.  If
> this can't all be hidden in the kernel, some further specification of the
> hardware might be needed for floating point.  For example, __i686__ is
> defined on the Pentium Pro and is used in bits/mathinline.h.

HPUX hides it all in the kernel somehow...and __hp9000s[7-8]00 won't
help with this problem anyway.

thanks for your insight,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] __hp9000s700 predefined

[John David Anglin]

> > There appears to be some model dependence
> > in the floating point implementations from one pa machine to another.  If
> > this can't all be hidden in the kernel, some further specification of the
> > hardware might be needed for floating point.  For example, __i686__ is
> > defined on the Pentium Pro and is used in bits/mathinline.h.
> 
> HPUX hides it all in the kernel somehow...and __hp9000s[7-8]00 won't
> help with this problem anyway.

Agreed.

-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] __hp9000s700 predefined

[John David Anglin]

> "John David Anglin" wrote:
> > You probably know better than I but I think PA1.0 is the "portable" default
> > for most libraries under 10.X.
> 
> It's definitely not under 10.20. PA1.1 is the minimum.
> I think PA1.0/CIO support was completely dropped after
> 10.01 or 10.10 releases.

Don't think so under 10.20.  We're talking about code generation here,
not device support.  The HP cc compiler uses the +DAarchitecture option
to control generation of code for a particular version of the PA-RISC
architecture.  It also specifies which version of the math library to
use when -lm is specified.  The directory /usr/lib/pa1.1 under 10.20
still has different versions for libcl.[a,sl] and libm.a.  As I noted
before, there is a complete list of models and architectures in
/opt/langtools/lib/sched.models.

I tried different code generation options with the HP cc compiler
under 10.20 and 11.  The HP cc compiler sets LPATH (at least if it is not
defined) to /usr/lib/pa1.1:/usr/lib:/opt/langtools/lib: for PA1.1 and PA2.0
models.  The default for PA1.0 models is /usr/lib:/usr/ccs/lib, according
to the ld man page.  Here are the HP cc predefines for 808, 735 and 700
models under 10.20:

-D__hp9000s700 -D__hp9000s800 -D__hppa -D__hpux -D__unix -e -D_PA_RISC1_0 -D__CLASSIC_C__

-D__hp9000s700 -D__hp9000s800 -D__hppa -D__hpux -D__unix -e -D_PA_RISC1_1 -D__CLASSIC_C__

-D__hp9000s700 -D__hp9000s800 -D__hppa -D__hpux -D__unix -e -D_PA_RISC1_1 -D__CLASSIC_C__

The _PA_RISC1_1 define for the 700 changes to a _PA_RISC2_0 define under 11.
Under 11, only a remnant of the pa1.1 library remains for old link scripts.
The same libraries appear to be used for PA1.0 to PA2.0.  This leads me
to conclude that the libraries must all be PA1.0 compatible.  HP cc uses the
.LEVEL directive to tell the assembler which object format to generate.

> > There appears to be some model dependence
> > in the floating point implementations from one pa machine to another.  If
> > this can't all be hidden in the kernel, some further specification of the
> > hardware might be needed for floating point.  For example, __i686__ is
> > defined on the Pentium Pro and is used in bits/mathinline.h.
> 
> HPUX hides it all in the kernel somehow...and __hp9000s[7-8]00 won't
> help with this problem anyway.

The +FP cc option can be used to control floating operation.  10.20 also has
fpgetround and friends for runtime control.  11.0 has fenv.h, and fegetround
and friends.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] __hp9000s700 predefined

[Grant Grundler]

"John David Anglin" wrote:
> We're talking about code generation here,
> not device support.

John,
Got it. Architecture flags (eg _PARISC1_1) determine code generation.

I'm not preventing people from building PA1.0 code if that's what
they really want.

thanks,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] __hp9000s700 predefined

[John David Anglin]

> > John, is there something specific you are concerned about which
> > can't be handled by the above predefined symbols?
> 
> I was just being cautious about __hp9000s[7-8]00.  I looked at some of
> the uses in the hpux 10.X headers, and for usage in gcc and binutils.  I
> don't see any obvious reason why these two symbols need to be defined
> for linux.
> 
> I believe that the compiler only should predefine symbols that are necessary
> for the control of code generation.  Neither CONFIG_XXX or runtime checks
> will help you for this since gcc only has a limited capability to change
> its code generation at runtime.  There appears to be some model dependence
> in the floating point implementations from one pa machine to another.  If
> this can't all be hidden in the kernel, some further specification of the
> hardware might be needed for floating point.  For example, __i686__ is
> defined on the Pentium Pro and is used in bits/mathinline.h.

There is a nice table listing model numbers, architecture and processor
type in /opt/langtools/lib/sched.models under hpux 11.  It still appears
possible to compile and link a PA1.0 app under hpux 11.  I am guessing
but it looks like there are 5 different PA1.1 float implementations (a-e).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)