Re: Adding Leon processor to the SPARC list of processors
--- On Wed, 12/1/11, Joel Sherrill joel.sherr...@oarcorp.com wrote: From: Joel Sherrill joel.sherr...@oarcorp.com Subject: Re: Adding Leon processor to the SPARC list of processors To: David Paterson david.pater...@btinternet.com Cc: gcc@gcc.gnu.org gcc@gcc.gnu.org Date: Wednesday, 12 January, 2011, 16:31 On 01/12/2011 09:17 AM, David Paterson wrote: Hi all, I'm in the early stages of a Leon-based project, and have been trying to put together a cross toolchain for it. I'm having some problems getting it configured and working correctly, and this proposed option would very likely help me a lot. Is there any time scale for implementation, or any plan for which release it'll make it into? The leon specific bare metal targets are in the SVN head. Thanks Joel, that's useful info. I'll update and give them a try. If you are using RTEMS, then you can use the RPMs we provide. At the moment however I'm trying to get a basic minimal system up and running, with no OS on the board. We might look at RTEMS (or other systems) later. Thanks for the link though - good to know about it. Regards, Dave
Re: Adding Leon processor to the SPARC list of processors
Hi all, I'm in the early stages of a Leon-based project, and have been trying to put together a cross toolchain for it. I'm having some problems getting it configured and working correctly, and this proposed option would very likely help me a lot. Is there any time scale for implementation, or any plan for which release it'll make it into? Regards, Dave
Re: Adding Leon processor to the SPARC list of processors
On 01/12/2011 09:17 AM, David Paterson wrote: Hi all, I'm in the early stages of a Leon-based project, and have been trying to put together a cross toolchain for it. I'm having some problems getting it configured and working correctly, and this proposed option would very likely help me a lot. Is there any time scale for implementation, or any plan for which release it'll make it into? The leon specific bare metal targets are in the SVN head. If you are using RTEMS, then you can use the RPMs we provide. Regards, Dave -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Adding Leon processor to the SPARC list of processors
Sorry, I didnt note the attachment that is already your implementation. I thought it was the old diff. So: I'm ok with all. Thanks for the effort. OK, thanks. I'm going to conduct a bit more testing before installing it. What are the contributors to the patch? This is for the ChangeLog. -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
On Thu, 25 Nov 2010 22:57:19 0100, Eric Botcazou wrote: Sorry, I didnt note the attachment that is already your implementation. I thought it was the old diff. So: I'm ok with all. Thanks for the effort. OK, thanks. I'm going to conduct a bit more testing before installing it. What are the contributors to the patch? This is for the ChangeLog. Contributor: Konrad Eisele kon...@gaisler.com -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
Eric Botcazou wrote:
Following the recent comments by Eric, the patch now sketches the
following setup:
If multi-lib is wanted:
configure --with-cpu=leon ... : creates multilib-dir soft|v8
combinations using [-msoft-float|-mcpu=sparcleonv8] (MULTILIB_OPTIONS =
msoft-float mcpu=sparcleonv8)
If Single-lib is wanted:
configure --with-cpu=sparcleonv7 --with-float=soft --disable-multilib ...
: (v7 | soft | no-multilib) configure --with-cpu=sparcleonv8
--with-float=soft --disable-multilib ... : (v8 | soft | no-multilib)
configure --with-cpu=sparcleonv7 --with-float=hard --disable-multilib ...
: (v7 | hard | no-multilib) configure --with-cpu=sparcleonv8
--with-float=hard --disable-multilib ... : (v8 | hard | no-multilib)
Using --with-cpu=leon|sparcleonv7|sparcleonv8 the the sparc_cpu is switched
to PROCESSOR_LEON.
I'm mostly OK, but I don't think we need sparcleonv7 or sparcleonv8.
Attached
You are right.
is another proposal, which:
1. Adds -mtune/--with-tune=leon for all SPARC targets. In particular, this
mean that if you configure --target=sparc-{elf,rtems} --with-tune=leon, you
get a multilib-ed compiler defaulting to V7/FPU and -mtune=leon, with V8 and
NO-FPU libraries.
Ok, this scheme seems best.
2. Adds new targets sparc-leon-{elf,linux}: multilib-ed compiler defaulting
to V8/FPU and -mtune=leon, with V7 and NO-FPU libraries.
Ok.
3. Adds new targets sparc-leon3-{elf,linux}: multilib-ed compiler defaulting
to V8/FPU and -mtune=leon, with NO-FPU libraries.
Singlelib-ed compilers are available through --disable-multilib and
--with=cpu={v7,v8} --with-float={soft,hard} --with-tune=leon
for sparc-{elf,rtems} or just
--with=cpu={v7,v8} --with-float={soft,hard}
for sparc-leon*-*.
The rationale is that --with-cpu shouldn't change the set of multilibs, it is
only the configure-time equivalent of -mcpu. This set of multilibs should
only depend on the target and the presence of --disable-multilib.
Ok, understood.
* config.gcc (sparc-*-elf*): Deal with sparc-leon specifically.
(sparc-*-linux*): Likewise.
(sparc*-*-*): Remove obsolete sparc86x setting.
(sparc-leon*): Default to --with-cpu=v8 and --with-tune=leon.
* doc/invoke.texi (SPARC Options): Document -mcpu/-mtune=leon.
* config/sparc/sparc.h (TARGET_CPU_leon): Define.
(TARGET_CPU_sparc86x): Delete.
(TARGET_CPU_cypress): Define as alias to TARGET_CPU_v7.
(TARGET_CPU_f930): Define as alias to TARGET_CPU_sparclite.
(TARGET_CPU_f934): Likewise.
(TARGET_CPU_tsc701): Define as alias to TARGET_CPU_sparclet.
(CPP_CPU_SPEC): Add entry for -mcpu=leon.
(enum processor_type): Add PROCESSOR_LEON.
* config/sparc/sparc.c (leon_costs): New cost array.
(sparc_option_override): Add entry for TARGET_CPU_leon and -mcpu=leon.
Initialize cost array to leon_costs if -mtune=leon.
* config/sparc/sparc.md (cpu attribute): Add leon.
Include leon.md scheduling description.
* config/sparc/leon.md: New file.
* config/sparc/t-elf: Do not assemble Solaris startup files.
* config/sparc/t-leon: New file.
* config/sparc/t-leon3: Likewise.
Is the list above an indication that you are already finished with
the modifications? :-)
Can you give me a note, otherwise I'll create a new patch that implements
the scheme you suggested.
-- Greetings Konrad
Re: Adding Leon processor to the SPARC list of processors
Is the list above an indication that you are already finished with the modifications? :-) Can you give me a note, otherwise I'll create a new patch that implements the scheme you suggested. Sorry, I didnt note the attachment that is already your implementation. I thought it was the old diff. So: I'm ok with all. Thanks for the effort. -- Greetings Konrad
Re: Adding Leon processor to the SPARC list of processors
Following the recent comments by Eric, the patch now sketches the
following setup:
If multi-lib is wanted:
configure --with-cpu=leon ... : creates multilib-dir soft|v8
combinations using [-msoft-float|-mcpu=sparcleonv8] (MULTILIB_OPTIONS =
msoft-float mcpu=sparcleonv8)
If Single-lib is wanted:
configure --with-cpu=sparcleonv7 --with-float=soft --disable-multilib ...
: (v7 | soft | no-multilib) configure --with-cpu=sparcleonv8
--with-float=soft --disable-multilib ... : (v8 | soft | no-multilib)
configure --with-cpu=sparcleonv7 --with-float=hard --disable-multilib ...
: (v7 | hard | no-multilib) configure --with-cpu=sparcleonv8
--with-float=hard --disable-multilib ... : (v8 | hard | no-multilib)
Using --with-cpu=leon|sparcleonv7|sparcleonv8 the the sparc_cpu is switched
to PROCESSOR_LEON.
I'm mostly OK, but I don't think we need sparcleonv7 or sparcleonv8. Attached
is another proposal, which:
1. Adds -mtune/--with-tune=leon for all SPARC targets. In particular, this
mean that if you configure --target=sparc-{elf,rtems} --with-tune=leon, you
get a multilib-ed compiler defaulting to V7/FPU and -mtune=leon, with V8 and
NO-FPU libraries.
2. Adds new targets sparc-leon-{elf,linux}: multilib-ed compiler defaulting
to V8/FPU and -mtune=leon, with V7 and NO-FPU libraries.
3. Adds new targets sparc-leon3-{elf,linux}: multilib-ed compiler defaulting
to V8/FPU and -mtune=leon, with NO-FPU libraries.
Singlelib-ed compilers are available through --disable-multilib and
--with=cpu={v7,v8} --with-float={soft,hard} --with-tune=leon
for sparc-{elf,rtems} or just
--with=cpu={v7,v8} --with-float={soft,hard}
for sparc-leon*-*.
The rationale is that --with-cpu shouldn't change the set of multilibs, it is
only the configure-time equivalent of -mcpu. This set of multilibs should
only depend on the target and the presence of --disable-multilib.
* config.gcc (sparc-*-elf*): Deal with sparc-leon specifically.
(sparc-*-linux*): Likewise.
(sparc*-*-*): Remove obsolete sparc86x setting.
(sparc-leon*): Default to --with-cpu=v8 and --with-tune=leon.
* doc/invoke.texi (SPARC Options): Document -mcpu/-mtune=leon.
* config/sparc/sparc.h (TARGET_CPU_leon): Define.
(TARGET_CPU_sparc86x): Delete.
(TARGET_CPU_cypress): Define as alias to TARGET_CPU_v7.
(TARGET_CPU_f930): Define as alias to TARGET_CPU_sparclite.
(TARGET_CPU_f934): Likewise.
(TARGET_CPU_tsc701): Define as alias to TARGET_CPU_sparclet.
(CPP_CPU_SPEC): Add entry for -mcpu=leon.
(enum processor_type): Add PROCESSOR_LEON.
* config/sparc/sparc.c (leon_costs): New cost array.
(sparc_option_override): Add entry for TARGET_CPU_leon and -mcpu=leon.
Initialize cost array to leon_costs if -mtune=leon.
* config/sparc/sparc.md (cpu attribute): Add leon.
Include leon.md scheduling description.
* config/sparc/leon.md: New file.
* config/sparc/t-elf: Do not assemble Solaris startup files.
* config/sparc/t-leon: New file.
* config/sparc/t-leon3: Likewise.
--
Eric Botcazou
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 167022)
+++ doc/invoke.texi (working copy)
@@ -16917,8 +16917,8 @@ the rules of the a...@.
@opindex mcpu
Set the instruction set, register set, and instruction scheduling parameters
for machine type @var{cpu_type}. Supported values for @var{cpu_type} are
-...@samp{v7}, @samp{cypress}, @samp{v8}, @samp{supersparc}, @samp{sparclite},
-...@samp{f930}, @samp{f934}, @samp{hypersparc}, @samp{sparclite86x},
+...@samp{v7}, @samp{cypress}, @samp{v8}, @samp{supersparc}, @samp{hypersparc},
+...@samp{leon}, @samp{sparclite}, @samp{f930}, @samp{f934}, @samp{sparclite86x},
@samp{sparclet}, @samp{tsc701}, @samp{v9}, @samp{ultrasparc},
@samp{ultrasparc3}, @samp{niagara} and @samp{niagara2}.
@@ -16931,7 +16931,7 @@ implementations.
@smallexample
v7: cypress
-v8: supersparc, hypersparc
+v8: supersparc, hypersparc, leon
sparclite: f930, f934, sparclite86x
sparclet: tsc701
v9: ultrasparc, ultrasparc3, niagara, niagara2
@@ -16984,9 +16984,9 @@ option @option{-mc...@var{cpu_type}} wou
The same values for @option{-mc...@var{cpu_type}} can be used for
@option{-mtu...@var{cpu_type}}, but the only useful values are those
that select a particular cpu implementation. Those are @samp{cypress},
-...@samp{supersparc}, @samp{hypersparc}, @samp{f930}, @samp{f934},
-...@samp{sparclite86x}, @samp{tsc701}, @samp{ultrasparc},
-...@samp{ultrasparc3}, @samp{niagara}, and @samp{niagara2}.
+...@samp{supersparc}, @samp{hypersparc}, @samp{leon}, @samp{f930}, @samp{f934},
+...@samp{sparclite86x}, @samp{tsc701}, @samp{ultrasparc}, @samp{ultrasparc3},
+...@samp{niagara}, and @samp{niagara2}.
@item -mv8plus
@itemx
Re: Adding Leon processor to the SPARC list of processors
Geert Bosch wrote: On Nov 19, 2010, at 11:53, Eric Botcazou wrote: Yes, if all the people who want only one set of libraries agree on what that set shall be (or this can be selected with existing configure flags), this is the simplest way. Yes, this can be selected at configure time with --with-cpu and --with-float. The default configuration is also straightforward: LEON is an implementation of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard. There is LEON2, which is V7, and LEON3/LEON4, which are V8. While LEON3 can support all of V8 in hardware, LEON3 is a configurable system-on-a-chip, targetting both FPGAs and ASICs, where users can configure and synthesize different aspects of the CPU: * CONFIG_PROC_NUM: The number of processor cores. * CONFIG_IU_V8MULDIV: Implements V8 multiply and divide instructions UMUL, UMULCC, SMUL, SMULCC, UDIV, UDIVCC, SDIV, SDIVCC. Costs about 8k gates. * CONFIG_IU_MUL_MAC: Implements the SPARC V8e UMAC/SMAC (multiply-accumulate) instructions with a 40-bits accumulator * CONFIG_FPU_ENABLE: Enable or disable floating point unit Apart from these settings that determine wether instructions are present at all, other settings allow selection of FPU implementation (trading off between cycle count, area and timing), such as: * CONFIG_IU_MUL_LATENCY_2: Implementation options for the integer multiplier. TypeImplementation issue-rate/latency 2-clocks32x32 pipelined multiplier 1/2 4-clocks16x16 standard multiplier 4/4 5-clocks16x16 pipelined multiplier 4/5 * CONFIG_IU_LDELAY: One cycle load delay for best performance, or 2-cycles to improve timing at the cost of about 5% reduced performance. CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7, is that correct? I think it would make sense to build these as multilibs, so the user can experiment to find out performance impacts of the various hardware configurations on generated code. I wonder if it also would be worthwhile to have compiler options for fpu=fast/slow and multiply=fast/slow, so we can schedule appropriately. For the FPU, issue-rate/latency are as follows: GR FPU: 1/4, with FDIV? 16 and FSQRT? 24 cycles, non-pipelined on separate unit GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles, non-pipelined on same unit While the FPU Lite is not pipelined, integer instructions can be executed in parallel with a FPU instruction as long as no new FPU instructions are pending. -Geert Just a humble opinion: Geert points out a very important fact, LEON's RTL is very configurable and if the compiler takes away such flexibility could be a bit of a pitty. Maybe the user should always have the choice to implement in software or hardware any given configuration. Jorge
Re: Adding Leon processor to the SPARC list of processors
Eric Botcazou wrote: How do you see this impacting the sparc-rtems target? We have v7/v8 with HW and SW FP multilibs now and leon is important to us. :-D Note that LEON will also be available as mere default cpu, i.e. you'll be able to configure sparc-rtems --with-tune=leon. The new multilib stuff is for the default target sparc-leon-elf (and maybe sparc-leon-linux if we want one). I agree. The patch I submitted only adds some extras. It shouldnt have a impact on the sparc-rtems target (or others).
Re: Adding Leon processor to the SPARC list of processors
Eric Botcazou wrote: Yes, if all the people who want only one set of libraries agree on what that set shall be (or this can be selected with existing configure flags), this is the simplest way. Yes, this can be selected at configure time with --with-cpu and --with-float. The default configuration is also straightforward: LEON is an implementation of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard. Also, it might happen that someone doesn't want one multilib dimension, but they want to keep another one. Indeed, being able to partially disable multilibs would be nice. I would suggest a simple solution: I can have 5 --with-cpu configure possibilies: 1. single-lib explicit selection: - --with-cpu=sfsparcleon: v7/soft | - --with-cpu=sfsparcleonv8 : v8/soft | - --with-cpu=hfsparcleon: v7/hard | - --with-cpu=hfsparcleonv8 : v8/hard | 2. generic multilib: - --with-cpu=leon : defaults to v7/hard use [-mcpu=v8 / -msoft-float ] at compile-time to select the hardware setting. Is this a practical approach? It would only require one extra file, say gcc/sparc/config/t-leon-multilib that enables multilib and is included with configure when --with-cpu=leon is given. I'll prepare a patch that provides such a setup. -- Greetings Konrad
Re: Adding Leon processor to the SPARC list of processors
CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7, is that correct? I think it would make sense to build these as multilibs, so the user can experiment to find out performance impacts of the various hardware configurations on generated code. I wonder if it also would be worthwhile to have compiler options for fpu=fast/slow and multiply=fast/slow, so we can schedule appropriately. For the FPU, issue-rate/latency are as follows: GR FPU: 1/4, with FDIV? 16 and FSQRT? 24 cycles, non-pipelined on separate unit GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles, non-pipelined on same unit Let's not make this too complex for a first try, the settings used at AdaCore seem a good starting point to me. -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
* CONFIG_IU_MUL_LATENCY_2: Implementation options for the integer multiplier. TypeImplementation issue-rate/latency 2-clocks32x32 pipelined multiplier 1/2 4-clocks16x16 standard multiplier 4/4 5-clocks16x16 pipelined multiplier 4/5 I'm not shure how I should model this in gcc. I'm not that familiar with the gcc internals. Maybe someone could assist me? GR FPU: 1/4, with FDIV? 16 and FSQRT? 24 cycles, non-pipelined on separate unit GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles, non-pipelined on same unit I could add a tune option that would switch the processor cost struct for FPU/FPU-lite. -- Greetings Konrad
Re: Adding Leon processor to the SPARC list of processors
I would suggest a simple solution: I can have 5 --with-cpu configure possibilies: 1. single-lib explicit selection: - --with-cpu=sfsparcleon: v7/soft | - --with-cpu=sfsparcleonv8 : v8/soft | - --with-cpu=hfsparcleon: v7/hard | - --with-cpu=hfsparcleonv8 : v8/hard | --with-cpu isn't really appropriate for this, we already have --with-cpu=v7/v8 and --with-float=soft/hard and --disable-multilib. 2. generic multilib: - --with-cpu=leon : defaults to v7/hard use [-mcpu=v8 / -msoft-float ] at compile-time to select the hardware setting. --with-cpu shouldn't change multilibs. Multilibs are a property of a target, e.g. sparc-leon-elf or sparc-rtems, not that of a cpu setting. -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
Eric Botcazou wrote: I would suggest a simple solution: I can have 5 --with-cpu configure possibilies: 1. single-lib explicit selection: - --with-cpu=sfsparcleon: v7/soft | - --with-cpu=sfsparcleonv8 : v8/soft | - --with-cpu=hfsparcleon: v7/hard | - --with-cpu=hfsparcleonv8 : v8/hard | --with-cpu isn't really appropriate for this, we already have --with-cpu=v7/v8 and --with-float=soft/hard and --disable-multilib. Still I need to select sparc_cpu and leon.md too. I could then add -mtune=leon at compiletime to switch sparc_cpu, but the I have to give -mtune=leon every time. I would like to be able to make it the default. With just [ --with-cpu=v7/v8 | --with-float=soft/hard | --disable-multilib ] to configure you cant. So then my suggestion would be to use tripple [ --with-cpu=sparcleonv7/sparcleonv8 | --with-float=soft/hard | --disable-multilib ] to configure. And add the 2 cpu types sparcleonv7,sparcleonv8 that would replace v7/v8. Does this sound good? -- Greetings Konrad
Re: Adding Leon processor to the SPARC list of processors
Eric Botcazou wrote: CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7, is that correct? I think it would make sense to build these as multilibs, so the user can experiment to find out performance impacts of the various hardware configurations on generated code. I wonder if it also would be worthwhile to have compiler options for fpu=fast/slow and multiply=fast/slow, so we can schedule appropriately. For the FPU, issue-rate/latency are as follows: GR FPU: 1/4, with FDIV? 16 and FSQRT? 24 cycles, non-pipelined on separate unit GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles, non-pipelined on same unit Let's not make this too complex for a first try, the settings used at AdaCore seem a good starting point to me. I Agree
Re: Adding Leon processor to the SPARC list of processors
Hi,
Appended is a new patch, this time against svn://gcc.gnu.org/svn/gcc/trunk.
Following the recent comments by Eric, the patch now sketches the
following setup:
If multi-lib is wanted:
configure --with-cpu=leon ... : creates multilib-dir soft|v8
combinations using [-msoft-float|-mcpu=sparcleonv8]
(MULTILIB_OPTIONS = msoft-float
mcpu=sparcleonv8)
If Single-lib is wanted:
configure --with-cpu=sparcleonv7 --with-float=soft --disable-multilib ... :
(v7 | soft | no-multilib)
configure --with-cpu=sparcleonv8 --with-float=soft --disable-multilib ... :
(v8 | soft | no-multilib)
configure --with-cpu=sparcleonv7 --with-float=hard --disable-multilib ... :
(v7 | hard | no-multilib)
configure --with-cpu=sparcleonv8 --with-float=hard --disable-multilib ... :
(v8 | hard | no-multilib)
Using --with-cpu=leon|sparcleonv7|sparcleonv8 the the sparc_cpu is switched to
PROCESSOR_LEON.
If this sheme is ok, i'll test it more thoroughly to check that the various
version
create the right output...
Please comment.
-- Greetings Konrad
Konrad Eisele wrote:
Hello,
Jiri Gaisler has now signed the FSF copyleft (it took quite long to get
through the procedure) and I was said that I could post the patches
now.
The patches are straightforward I think.
1. Adds machine description gcc-4.4.2/gcc/config/sparc/leon.md
2. gcc-4.4.2.ori/gcc/config/sparc/sparc.c:
+ adds leon_costs struct.
+ 4 target CPUs are added:
sparchfleon : hard float v7
sparchfleonv8: hard float v8
sparcsfleon : soft float v7
sparcsfleonv8: soft float v8
+ 1 cpu type: PROCESSOR_LEON
that is called leon in sparc.md
3. gcc-4.4.2.ori/gcc/config/sparc/sparc.h:
add the 4 target cpu defines
4. gcc-4.4.2.ori/gcc/config/sparc/sparc.md:
define cpu leon and include leon.md
5. gcc-4.4.2/gcc/config/sparc/t-leon:
makefile template for leon
6. gcc-4.4.2/gcc/config.gcc:
include t-leon for sparc[sf|hf]leon[v8].
They dont interfere with current code. If I should change something,
please let me know or maybe here is something I didnt think of...
Leon is a conforming implementation of the SPARC V7/V8 architecture so it
should be possible to support it alongside the other SPARC implementations in
the SPARC back-end of the mainline compiler. I'd be happy to review patches
to this effect (and I presume the other SPARC maintainers are OK with this).
So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and
then start to post their patches on the gcc-patches@ list. I'll sponsor them
for write access at that point.
-- Eric Botcazou
I come back to the offer of Eric: if the patches are approved I'd be
greatfull if you could check them in.
-- Thanks Konrad
To verify (if someone is interested):
I have created a crosstool-ng based install script that will build the 4
sparc-leon cross-compilers:
$wget ftp://gaisler.com/gaisler.com/linux/linuxbuild/linuxbuild-0.0.3.tar.bz2
$tar xvf linuxbuild-0.0.3.tar.bz2
$cd linuxbuild-0.0.3
$make help
$make cts
This will create /opt/sparc-linux-toolchains/{hfleon,hfleonv8,sfleon,sfleonv8}
(Write premissions needed for /opt/sparc-linux-toolchains/).
The crosstool-ng script uses --with-cpu=sparc[sf|hf]leon[v8] to select
the desired proc type.
Index: gcc/gcc/config.gcc
===
--- gcc/gcc/config.gcc (revision 167027)
+++ gcc/gcc/config.gcc (working copy)
@@ -3437,6 +3437,9 @@
| v9 | ultrasparc | ultrasparc3 | niagara | niagara2)
# OK
;;
+ sparcleonv7 | sparcleonv8 | leon)
+tmake_file=${tmake_file} sparc/t-leon
+;;
*)
echo Unknown cpu used in --with-$which=$val 12
exit 1
Index: gcc/gcc/config/sparc/sparc.md
===
--- gcc/gcc/config/sparc/sparc.md (revision 167027)
+++ gcc/gcc/config/sparc/sparc.md (working copy)
@@ -103,6 +103,7 @@
v7,
cypress,
v8,
+ leon,
supersparc,
sparclite,f930,f934,
hypersparc,sparclite86x,
@@ -344,6 +345,7 @@
(include ultra3.md)
(include niagara.md)
(include niagara2.md)
+(include leon.md)
;; Operand and operator predicates and constraints
Index: gcc/gcc/config/sparc/sparc.c
===
--- gcc/gcc/config/sparc/sparc.c (revision 167027)
+++ gcc/gcc/config/sparc/sparc.c (working copy)
@@ -249,6 +249,30 @@
0, /* shift penalty */
};
+static const
+struct processor_costs leon_costs = {
+ COSTS_N_INSNS (1), /* int load */
+ COSTS_N_INSNS (1), /* int signed load */
+ COSTS_N_INSNS (1), /* int zeroed load */
+ COSTS_N_INSNS (1), /* float load */
+ COSTS_N_INSNS (1), /* fmov, fneg, fabs */
+ COSTS_N_INSNS (1), /* fadd, fsub */
+ COSTS_N_INSNS (1), /* fcmp */
+ COSTS_N_INSNS (1), /* fmov, fmovr */
+ COSTS_N_INSNS (1), /* fmul */
+ COSTS_N_INSNS (15), /* fdivs */
+
Re: Adding Leon processor to the SPARC list of processors
However I also want a singlelib version to be able to compile. When createing a glibc crosscompiler, compiling 4 version of glibc makes it inpracticable. And crosscompiling user space apps I dont want the need to supply the extra switches explicitly all the time. Maybe there is a simple way to achieve both multilib and singlelib? You can pass --disable-multilib at configure time. -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
Quoting Eric Botcazou ebotca...@adacore.com: However I also want a singlelib version to be able to compile. When createing a glibc crosscompiler, compiling 4 version of glibc makes it inpracticable. And crosscompiling user space apps I dont want the need to supply the extra switches explicitly all the time. Maybe there is a simple way to achieve both multilib and singlelib? You can pass --disable-multilib at configure time. Yes, if all the people who want only one set of libraries agree on what that set shall be (or this can be selected with existing configure flags), this is the simplest way. But once you have different people wanting a different single library, this approach is not longer sufficient. Also, it might happen that someone doesn't want one multilib dimension, but they want to keep another one. E.g. they might say they don't want to support these different architecture variants, but they need support for both endiannesses (Or you might hear: hard and soft float, or glibc and uClibc.)
Re: Adding Leon processor to the SPARC list of processors
Yes, if all the people who want only one set of libraries agree on what that set shall be (or this can be selected with existing configure flags), this is the simplest way. Yes, this can be selected at configure time with --with-cpu and --with-float. The default configuration is also straightforward: LEON is an implementation of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard. Also, it might happen that someone doesn't want one multilib dimension, but they want to keep another one. Indeed, being able to partially disable multilibs would be nice. -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
Daniel, How do you see this impacting the sparc-rtems target? We have v7/v8 with HW and SW FP multilibs now and leon is important to us. :-D --joel On 11/19/2010 10:53 AM, Eric Botcazou wrote: Yes, if all the people who want only one set of libraries agree on what that set shall be (or this can be selected with existing configure flags), this is the simplest way. Yes, this can be selected at configure time with --with-cpu and --with-float. The default configuration is also straightforward: LEON is an implementation of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard. Also, it might happen that someone doesn't want one multilib dimension, but they want to keep another one. Indeed, being able to partially disable multilibs would be nice. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Adding Leon processor to the SPARC list of processors
How do you see this impacting the sparc-rtems target? We have v7/v8 with HW and SW FP multilibs now and leon is important to us. :-D Note that LEON will also be available as mere default cpu, i.e. you'll be able to configure sparc-rtems --with-tune=leon. The new multilib stuff is for the default target sparc-leon-elf (and maybe sparc-leon-linux if we want one). -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
On Nov 19, 2010, at 11:53, Eric Botcazou wrote: Yes, if all the people who want only one set of libraries agree on what that set shall be (or this can be selected with existing configure flags), this is the simplest way. Yes, this can be selected at configure time with --with-cpu and --with-float. The default configuration is also straightforward: LEON is an implementation of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard. There is LEON2, which is V7, and LEON3/LEON4, which are V8. While LEON3 can support all of V8 in hardware, LEON3 is a configurable system-on-a-chip, targetting both FPGAs and ASICs, where users can configure and synthesize different aspects of the CPU: * CONFIG_PROC_NUM: The number of processor cores. * CONFIG_IU_V8MULDIV: Implements V8 multiply and divide instructions UMUL, UMULCC, SMUL, SMULCC, UDIV, UDIVCC, SDIV, SDIVCC. Costs about 8k gates. * CONFIG_IU_MUL_MAC: Implements the SPARC V8e UMAC/SMAC (multiply-accumulate) instructions with a 40-bits accumulator * CONFIG_FPU_ENABLE: Enable or disable floating point unit Apart from these settings that determine wether instructions are present at all, other settings allow selection of FPU implementation (trading off between cycle count, area and timing), such as: * CONFIG_IU_MUL_LATENCY_2: Implementation options for the integer multiplier. TypeImplementation issue-rate/latency 2-clocks32x32 pipelined multiplier 1/2 4-clocks16x16 standard multiplier 4/4 5-clocks16x16 pipelined multiplier 4/5 * CONFIG_IU_LDELAY: One cycle load delay for best performance, or 2-cycles to improve timing at the cost of about 5% reduced performance. CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7, is that correct? I think it would make sense to build these as multilibs, so the user can experiment to find out performance impacts of the various hardware configurations on generated code. I wonder if it also would be worthwhile to have compiler options for fpu=fast/slow and multiply=fast/slow, so we can schedule appropriately. For the FPU, issue-rate/latency are as follows: GR FPU: 1/4, with FDIV? 16 and FSQRT? 24 cycles, non-pipelined on separate unit GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles, non-pipelined on same unit While the FPU Lite is not pipelined, integer instructions can be executed in parallel with a FPU instruction as long as no new FPU instructions are pending. -Geert
Adding Leon processor to the SPARC list of processors
Hello,
Jiri Gaisler has now signed the FSF copyleft (it took quite long to get
through the procedure) and I was said that I could post the patches
now.
The patches are straightforward I think.
1. Adds machine description gcc-4.4.2/gcc/config/sparc/leon.md
2. gcc-4.4.2.ori/gcc/config/sparc/sparc.c:
+ adds leon_costs struct.
+ 4 target CPUs are added:
sparchfleon : hard float v7
sparchfleonv8: hard float v8
sparcsfleon : soft float v7
sparcsfleonv8: soft float v8
+ 1 cpu type: PROCESSOR_LEON
that is called leon in sparc.md
3. gcc-4.4.2.ori/gcc/config/sparc/sparc.h:
add the 4 target cpu defines
4. gcc-4.4.2.ori/gcc/config/sparc/sparc.md:
define cpu leon and include leon.md
5. gcc-4.4.2/gcc/config/sparc/t-leon:
makefile template for leon
6. gcc-4.4.2/gcc/config.gcc:
include t-leon for sparc[sf|hf]leon[v8].
They dont interfere with current code. If I should change something,
please let me know or maybe here is something I didnt think of...
Leon is a conforming implementation of the SPARC V7/V8 architecture so it
should be possible to support it alongside the other SPARC implementations in
the SPARC back-end of the mainline compiler. I'd be happy to review patches
to this effect (and I presume the other SPARC maintainers are OK with this).
So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and
then start to post their patches on the gcc-patches@ list. I'll sponsor them
for write access at that point.
-- Eric Botcazou
I come back to the offer of Eric: if the patches are approved I'd be
greatfull if you could check them in.
-- Thanks Konrad
To verify (if someone is interested):
I have created a crosstool-ng based install script that will build the 4
sparc-leon cross-compilers:
$wget ftp://gaisler.com/gaisler.com/linux/linuxbuild/linuxbuild-0.0.3.tar.bz2
$tar xvf linuxbuild-0.0.3.tar.bz2
$cd linuxbuild-0.0.3
$make help
$make cts
This will create /opt/sparc-linux-toolchains/{hfleon,hfleonv8,sfleon,sfleonv8}
(Write premissions needed for /opt/sparc-linux-toolchains/).
The crosstool-ng script uses --with-cpu=sparc[sf|hf]leon[v8] to select
the desired proc type.
diff -Naurb gcc-4.4.2.ori/gcc/config/sparc/leon.md gcc-4.4.2/gcc/config/sparc/leon.md
--- gcc-4.4.2.ori/gcc/config/sparc/leon.md 1970-01-01 01:00:00.0 +0100
+++ gcc-4.4.2/gcc/config/sparc/leon.md 2010-10-19 11:56:58.0 +0200
@@ -0,0 +1,56 @@
+;; Scheduling description for Leon.
+;; Copyright (C) 2010 Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+;;
+;; GCC is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+;;
+;; GCC is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3. If not see
+;; http://www.gnu.org/licenses/.
+
+
+(define_automaton leon)
+
+(define_cpu_unit leon_memory, leon_fpalu leon)
+(define_cpu_unit leon_fpmds leon)
+(define_cpu_unit write_buf leon)
+
+(define_insn_reservation leon_load 1
+ (and (eq_attr cpu leon)
+(eq_attr type load,sload,fpload))
+ leon_memory)
+
+(define_insn_reservation leon_store 1
+ (and (eq_attr cpu leon)
+(eq_attr type store,fpstore))
+ leon_memory+write_buf)
+
+(define_insn_reservation leon_fp_alu 1
+ (and (eq_attr cpu leon)
+(eq_attr type fp,fpmove))
+ leon_fpalu, nothing)
+
+(define_insn_reservation leon_fp_mult 1
+ (and (eq_attr cpu leon)
+(eq_attr type fpmul))
+ leon_fpmds, nothing)
+
+(define_insn_reservation leon_fp_div 16
+ (and (eq_attr cpu leon)
+(eq_attr type fpdivs,fpdivd))
+ leon_fpmds, nothing*15)
+
+(define_insn_reservation leon_fp_sqrt 23
+ (and (eq_attr cpu leon)
+(eq_attr type fpsqrts,fpsqrtd))
+ leon_fpmds, nothing*21)
+
diff -Naurb gcc-4.4.2.ori/gcc/config/sparc/sparc.c gcc-4.4.2/gcc/config/sparc/sparc.c
--- gcc-4.4.2.ori/gcc/config/sparc/sparc.c 2010-10-19 11:55:17.0 +0200
+++ gcc-4.4.2/gcc/config/sparc/sparc.c 2010-10-19 11:56:58.0 +0200
@@ -246,6 +246,30 @@
0, /* shift penalty */
};
+static const
+struct processor_costs leon_costs = {
+ COSTS_N_INSNS (1), /* int load */
+ COSTS_N_INSNS (1), /* int signed load */
+ COSTS_N_INSNS (1), /* int zeroed load */
+ COSTS_N_INSNS (1), /* float load */
+ COSTS_N_INSNS (1), /* fmov, fneg, fabs */
+ COSTS_N_INSNS (1), /* fadd, fsub */
+ COSTS_N_INSNS (1), /* fcmp */
+ COSTS_N_INSNS (1), /* fmov, fmovr */
+ COSTS_N_INSNS (1), /* fmul */
+ COSTS_N_INSNS (15), /* fdivs */
+ COSTS_N_INSNS (15), /* fdivd */
+ COSTS_N_INSNS (23), /* fsqrts */
+ COSTS_N_INSNS (23), /* fsqrtd */
+ COSTS_N_INSNS (5), /* imul */
+
Re: Adding Leon processor to the SPARC list of processors
Jiri Gaisler has now signed the FSF copyleft (it took quite long to get through the procedure) and I was said that I could post the patches now. Thanks for your perseverance. The patches are straightforward I think. 1. Adds machine description gcc-4.4.2/gcc/config/sparc/leon.md 2. gcc-4.4.2.ori/gcc/config/sparc/sparc.c: + adds leon_costs struct. + 4 target CPUs are added: sparchfleon : hard float v7 sparchfleonv8: hard float v8 sparcsfleon : soft float v7 sparcsfleonv8: soft float v8 + 1 cpu type: PROCESSOR_LEON that is called leon in sparc.md 3. gcc-4.4.2.ori/gcc/config/sparc/sparc.h: add the 4 target cpu defines 4. gcc-4.4.2.ori/gcc/config/sparc/sparc.md: define cpu leon and include leon.md 5. gcc-4.4.2/gcc/config/sparc/t-leon: makefile template for leon 6. gcc-4.4.2/gcc/config.gcc: include t-leon for sparc[sf|hf]leon[v8]. They dont interfere with current code. If I should change something, please let me know or maybe here is something I didnt think of... The patches would need to be ported to the mainline tree as they will be merged there; we generally don't add support for new processors to branches. The patch doesn't contain a config/sparc/leon.h file, so it will use whatever default configuration it inherits; is that really intended? I think we want sparc-leon to be a stand-alone target, with multiple libraries for V7/V8/soft-float/hard-float, so that a single compiler can generate code for all the variants. That is to say, you configure --target=sparc-leon-elf and you pass -mcpu=v7/-/mcpu=v8/-mhard-float/-msoft-float to the resulting compiler to select the right variant. --with-cpu isn't appropriate for this. It turns out that we have ported GNAT (the GNU Ada compiler) to embedded LEON targets at AdaCore so we also have some material, mostly orthogonal to yours. Give me a few days to port your 4.4 patches and dig out ours, and I'll post a combined patch to serve as a basis for further discussions. -- Eric Botcazou
Re: Adding Leon processor to the SPARC list of processors
Eric Botcazou wrote: Jiri Gaisler has now signed the FSF copyleft (it took quite long to get through the procedure) and I was said that I could post the patches now. Thanks for your perseverance. The patches are straightforward I think. 1. Adds machine description gcc-4.4.2/gcc/config/sparc/leon.md 2. gcc-4.4.2.ori/gcc/config/sparc/sparc.c: + adds leon_costs struct. + 4 target CPUs are added: sparchfleon : hard float v7 sparchfleonv8: hard float v8 sparcsfleon : soft float v7 sparcsfleonv8: soft float v8 + 1 cpu type: PROCESSOR_LEON that is called leon in sparc.md 3. gcc-4.4.2.ori/gcc/config/sparc/sparc.h: add the 4 target cpu defines 4. gcc-4.4.2.ori/gcc/config/sparc/sparc.md: define cpu leon and include leon.md 5. gcc-4.4.2/gcc/config/sparc/t-leon: makefile template for leon 6. gcc-4.4.2/gcc/config.gcc: include t-leon for sparc[sf|hf]leon[v8]. They dont interfere with current code. If I should change something, please let me know or maybe here is something I didnt think of... The patches would need to be ported to the mainline tree as they will be merged there; we generally don't add support for new processors to branches. Which repository can I use to generate patches against. Is there a git repository that I can use? The patch doesn't contain a config/sparc/leon.h file, so it will use whatever default configuration it inherits; is that really intended? Maybe I shuould change that. Up to now I was using --with-cpu=xxx to configure to select the default cpu. I'll wait for AdaCore patches and see how you did it. I think we want sparc-leon to be a stand-alone target, with multiple libraries for V7/V8/soft-float/hard-float, so that a single compiler can generate code for all the variants. That is to say, you configure --target=sparc-leon-elf and you pass -mcpu=v7/-/mcpu=v8/-mhard-float/-msoft-float to the resulting compiler to select the right variant. --with-cpu isn't appropriate for this. I could add a multilib version. The BCC toolchain from the Gaisler homepage is multilibbed and uses -mv8/-mcpu=v8 -msoft-float to select which config to use. However I also want a singlelib version to be able to compile. When createing a glibc crosscompiler, compiling 4 version of glibc makes it inpracticable. And crosscompiling user space apps I dont want the need to supply the extra switches explicitly all the time. Maybe there is a simple way to achieve both multilib and singlelib? It turns out that we have ported GNAT (the GNU Ada compiler) to embedded LEON targets at AdaCore so we also have some material, mostly orthogonal to yours. Give me a few days to port your 4.4 patches and dig out ours, and I'll post a combined patch to serve as a basis for further discussions. Ok, I'll wait. -- Greetings Konrad
Re: Adding Leon processor to the SPARC list of processors
Quoting Konrad Eisele kon...@gaisler.com: Maybe there is a simple way to achieve both multilib and singlelib? The (short-term) simple way is to have two separate configurations. For a more flexible approach, look at how the SH port allows you to mix match your multilibs.
Re: Adding Leon processor to the SPARC list of processors
Joern Rennecke wrote: Quoting Konrad Eisele kon...@gaisler.com: Maybe there is a simple way to achieve both multilib and singlelib? The (short-term) simple way is to have two separate configurations. For a more flexible approach, look at how the SH port allows you to mix match your multilibs. Ok, I'll take a look into it. -- Konrad
