Re: [RFC PATCH] Add support for sparc compare-and-branch.
I've scanned the documentation and there is no indication of any
preprocessor predefines or anything like that.
And keep in mind that __VIS__ is our very own invention.
Sun's compilers never predefined this.
Their makefiles do for various targets in the MediaLib sources, but that's
a source tree and header file localized convention.
Sun also never provided intrinsics other than via assembler inlines in
their VIS header. They were never compiler builtins like our's. The
user had to define __VIS__ on the command line to get visibility of
the routines they wanted from Sun's VIS inline assembler header file.
Sun also does not provide, and is almost certainly not going to ever
provide crypto intrinsics.
Therefore there is no convention to follow and we can do whatever we want
here.
OK, thanks. I keep thinking that we should use -mcpu=sparc4/-D__sparc4__ for
new instructions in the SPARC-T4 architecture that aren't related to VIS.
And given Rainer's insight, I agree that switching to the -m{32,64} -xarch=
scheme with recent assemblers is the way to go. I'll try and get my hands on
one of them...
--
Eric Botcazou
Re: [RFC PATCH] Add support for sparc compare-and-branch.
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 16 Oct 2012 12:10:51 +0200
I've scanned the documentation and there is no indication of any
preprocessor predefines or anything like that.
And keep in mind that __VIS__ is our very own invention.
Sun's compilers never predefined this.
Their makefiles do for various targets in the MediaLib sources, but that's
a source tree and header file localized convention.
Sun also never provided intrinsics other than via assembler inlines in
their VIS header. They were never compiler builtins like our's. The
user had to define __VIS__ on the command line to get visibility of
the routines they wanted from Sun's VIS inline assembler header file.
Sun also does not provide, and is almost certainly not going to ever
provide crypto intrinsics.
Therefore there is no convention to follow and we can do whatever we want
here.
OK, thanks. I keep thinking that we should use -mcpu=sparc4/-D__sparc4__ for
new instructions in the SPARC-T4 architecture that aren't related to VIS.
And given Rainer's insight, I agree that switching to the -m{32,64} -xarch=
scheme with recent assemblers is the way to go. I'll try and get my hands on
one of them...
Ok.
Meanwhile I asked some folks and there doesn't appear to be any special
CPP symbols set by the Solaris compiler when -xarch=sparc4.
So what I'm going to do is get rid of the __VIS__==0x400 thing for now
and we can add that, or something similar, at a later date.
Re: [RFC PATCH] Add support for sparc compare-and-branch.
The only versions of the Solaris assembler I have access to only support v8plusX according to the man page. Has that changed recently? For the older stuff I mean doing something like -m32 -xarch=v9X OK, this is for fbe, not for as. I think that the latter is always available on the machines, but I'm not sure for the former. Rainer very likely knows. The current assembler in Solaris Studio (called 'fbe') calls this stuff sparc4 which I guess means SPARC-T4 and later. Ah, thanks. I agree that using the same monikers is the right thing to do... I'm just calling it VIS4 in GCC so that we can export intrinsics of, for example, the cryptographic instructions at some point using the __VIS__ version CPP tests. ...that's why I'm not sure we should invent VIS4 at this point. How is this done on the Solaris Studio side? Couldn't we add a new architecture to the compiler (-mcpu=sparc4, with -mcpu=niagara4 as first variant), and define __sparc4__ for the preprocessor? -- Eric Botcazou
Re: [RFC PATCH] Add support for sparc compare-and-branch.
Eric Botcazou ebotca...@adacore.com writes: The only versions of the Solaris assembler I have access to only support v8plusX according to the man page. Has that changed recently? For the older stuff I mean doing something like -m32 -xarch=v9X OK, this is for fbe, not for as. I think that the latter is always available on the machines, but I'm not sure for the former. Rainer very likely knows. The assembler lives with the Studio compilers as fbe, but once in a while that version is backported (or provided as a patch) as /usr/ccs/bin/as. For Solaris 10, the latest SPARC assembler patch, 118683-08, includes -xarch=sparc4 support, rev. -07 didn't. At least in Solaris 11.1, as does as well, not completely sure about Solaris 11 where it may have only been introduced in an SRU (support repository update). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC PATCH] Add support for sparc compare-and-branch.
David Miller da...@davemloft.net writes: Could one of you help me get the solaris side correct? I made sure that binutils accepts the same options for this stuff, that's why I can unconditionally use '-xarch=sparc4' in the configure test. I assume this works because gas 2.22 had neither SPARC-T4 support nor did it accept -xarch=sparc4? diff --git a/gcc/configure.ac b/gcc/configure.ac index b6c049b..9d2eb29 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3501,6 +3501,24 @@ foo: fnaddd %f10, %f12, %f14],, [AC_DEFINE(HAVE_AS_FMAF_HPC_VIS3, 1, [Define if your assembler supports FMAF, HPC, and VIS 3.0 instructions.])]) + +gcc_GAS_CHECK_FEATURE([SPARC4 instructions], + gcc_cv_as_sparc_fmaf,, Shouldn't reuse a cache variable here, but use e.g. gcc_cv_as_sparc_sparc4 instead. + [-xarch=sparc4], + [.text + .register %g2, #scratch + .register %g3, #scratch + .align 4 + cxbe %g2, %g3, 1f +1: cwbneg %g2, %g3, 1f +1: sha1 + md5 + aes_kexpand0 %f4, %f6, %f8 + des_round %f38, %f40, %f42, %f44 + camellia_f %f54, %f56, %f58, %f60 + kasumi_fi_xor %f46, %f48, %f50, %f52],, + [AC_DEFINE(HAVE_AS_SPARC4, 1, +[Define if your assembler supports SPARC4 instructions.])]) ;; changequote(,)dnl Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC PATCH] Add support for sparc compare-and-branch.
From: Eric Botcazou ebotca...@adacore.com Date: Mon, 15 Oct 2012 10:00:02 +0200 The only versions of the Solaris assembler I have access to only support v8plusX according to the man page. Has that changed recently? For the older stuff I mean doing something like -m32 -xarch=v9X OK, this is for fbe, not for as. I think that the latter is always available on the machines, but I'm not sure for the former. Rainer very likely knows. The current assembler in Solaris Studio (called 'fbe') calls this stuff sparc4 which I guess means SPARC-T4 and later. Ah, thanks. I agree that using the same monikers is the right thing to do... I'm just calling it VIS4 in GCC so that we can export intrinsics of, for example, the cryptographic instructions at some point using the __VIS__ version CPP tests. ...that's why I'm not sure we should invent VIS4 at this point. How is this done on the Solaris Studio side? Couldn't we add a new architecture to the compiler (-mcpu=sparc4, with -mcpu=niagara4 as first variant), and define __sparc4__ for the preprocessor? I've scanned the documentation and there is no indication of any preprocessor predefines or anything like that. And keep in mind that __VIS__ is our very own invention. Sun's compilers never predefined this. Their makefiles do for various targets in the MediaLib sources, but that's a source tree and header file localized convention. Sun also never provided intrinsics other than via assembler inlines in their VIS header. They were never compiler builtins like our's. The user had to define __VIS__ on the command line to get visibility of the routines they wanted from Sun's VIS inline assembler header file. Sun also does not provide, and is almost certainly not going to ever provide crypto intrinsics. Therefore there is no convention to follow and we can do whatever we want here.
Re: [RFC PATCH] Add support for sparc compare-and-branch.
David Miller da...@davemloft.net writes: I'm just calling it VIS4 in GCC so that we can export intrinsics of, for example, the cryptographic instructions at some point using the __VIS__ version CPP tests. ...that's why I'm not sure we should invent VIS4 at this point. How is this done on the Solaris Studio side? Couldn't we add a new architecture to the compiler (-mcpu=sparc4, with -mcpu=niagara4 as first variant), and define __sparc4__ for the preprocessor? I've scanned the documentation and there is no indication of any preprocessor predefines or anything like that. And keep in mind that __VIS__ is our very own invention. Sun's compilers never predefined this. I've found uses of e.g. __VIS = 0x200 in their Studio 12.3 headers (prod/include/cc/sys/vis_*.h), and strings on the cc binary reveals -D__VIS=0x100 -D__VIS=0x200 -D__VIS=0x300 -D__VIS=0x400 I haven't yet found if those are properly documented, though. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC PATCH] Add support for sparc compare-and-branch.
From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Mon, 15 Oct 2012 16:28:15 +0200 David Miller da...@davemloft.net writes: Could one of you help me get the solaris side correct? I made sure that binutils accepts the same options for this stuff, that's why I can unconditionally use '-xarch=sparc4' in the configure test. I assume this works because gas 2.22 had neither SPARC-T4 support nor did it accept -xarch=sparc4? I have a mainline binutils build installed on my system which does have support for all of these instructions, otherwise how would I have been able to run the testsuite and see the cbcond instructions working? :-) diff --git a/gcc/configure.ac b/gcc/configure.ac index b6c049b..9d2eb29 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3501,6 +3501,24 @@ foo: fnaddd %f10, %f12, %f14],, [AC_DEFINE(HAVE_AS_FMAF_HPC_VIS3, 1, [Define if your assembler supports FMAF, HPC, and VIS 3.0 instructions.])]) + +gcc_GAS_CHECK_FEATURE([SPARC4 instructions], + gcc_cv_as_sparc_fmaf,, Shouldn't reuse a cache variable here, but use e.g. gcc_cv_as_sparc_sparc4 instead. Thanks for catching that.
Re: [RFC PATCH] Add support for sparc compare-and-branch.
From: Rainer Orth r...@cebitec.uni-bielefeld.de Date: Mon, 15 Oct 2012 16:44:44 +0200 David Miller da...@davemloft.net writes: I'm just calling it VIS4 in GCC so that we can export intrinsics of, for example, the cryptographic instructions at some point using the __VIS__ version CPP tests. ...that's why I'm not sure we should invent VIS4 at this point. How is this done on the Solaris Studio side? Couldn't we add a new architecture to the compiler (-mcpu=sparc4, with -mcpu=niagara4 as first variant), and define __sparc4__ for the preprocessor? I've scanned the documentation and there is no indication of any preprocessor predefines or anything like that. And keep in mind that __VIS__ is our very own invention. Sun's compilers never predefined this. I've found uses of e.g. __VIS = 0x200 in their Studio 12.3 headers (prod/include/cc/sys/vis_*.h), and strings on the cc binary reveals -D__VIS=0x100 -D__VIS=0x200 -D__VIS=0x300 -D__VIS=0x400 I haven't yet found if those are properly documented, though. Strange, ok.
Re: [RFC PATCH] Add support for sparc compare-and-branch.
The trouble area, and where I need help from either Rainer or Eric,
is the Solaris2 bits.
I think we need to move the Solaris assembler stuff over to a model
where it passes:
-m{32,64} -xarch=sparcFOO
instead of using the v8plusX stuff to indicate 32bit. And that's
the direction I tried to move in here.
The only versions of the Solaris assembler I have access to only support
v8plusX according to the man page. Has that changed recently?
Could one of you help me get the solaris side correct? I made sure
that binutils accepts the same options for this stuff, that's why
I can unconditionally use '-xarch=sparc4' in the configure test.
sparc4 sounds very 1990-ish...
* config/sparc/sparc.opt (mvis4): New option.
* config/sparc/sparc-c.c (sparc_target_macros): When TARGET_VIS4,
define __VIS__ to 0x400.
What's the relationship between VIS4 and SPARC-T4 exactly? The above manual
only speaks of VIS3 as far as I can see. And the CBcond instructions are not
marked as belonging to VIS (3 or 4), so using -mvis4 for them seems strange.
Why not make them depend on -mcpu=niagara4 instead?
--
Eric Botcazou
Re: [RFC PATCH] Add support for sparc compare-and-branch.
From: Eric Botcazou ebotca...@adacore.com
Date: Sat, 13 Oct 2012 15:47:11 +0200
The trouble area, and where I need help from either Rainer or Eric,
is the Solaris2 bits.
I think we need to move the Solaris assembler stuff over to a model
where it passes:
-m{32,64} -xarch=sparcFOO
instead of using the v8plusX stuff to indicate 32bit. And that's
the direction I tried to move in here.
The only versions of the Solaris assembler I have access to only support
v8plusX according to the man page. Has that changed recently?
For the older stuff I mean doing something like -m32 -xarch=v9X
* config/sparc/sparc.opt (mvis4): New option.
* config/sparc/sparc-c.c (sparc_target_macros): When TARGET_VIS4,
define __VIS__ to 0x400.
What's the relationship between VIS4 and SPARC-T4 exactly? The above manual
only speaks of VIS3 as far as I can see. And the CBcond instructions are not
marked as belonging to VIS (3 or 4), so using -mvis4 for them seems strange.
Why not make them depend on -mcpu=niagara4 instead?
The current assembler in Solaris Studio (called 'fbe') calls this
stuff sparc4 which I guess means SPARC-T4 and later.
I'm just calling it VIS4 in GCC so that we can export intrinsics of,
for example, the cryptographic instructions at some point using the
__VIS__ version CPP tests.
