| Message ID | 4CE515CB.7080706@gaisler.com |
|---|---|
| State | New |
| Headers | show |
> 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 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
Quoting Konrad Eisele <konrad@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.
Joern Rennecke wrote: > Quoting Konrad Eisele <konrad@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
> 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.
Quoting Eric Botcazou <ebotcazou@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.)
> 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.
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. >
> 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).
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. Type Implementation issue-rate/latency 2-clocks 32x32 pipelined multiplier 1/2 4-clocks 16x16 standard multiplier 4/4 5-clocks 16x16 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
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. > Type Implementation issue-rate/latency > 2-clocks 32x32 pipelined multiplier 1/2 > 4-clocks 16x16 standard multiplier 4/4 > 5-clocks 16x16 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
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).
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
> 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.
>> * CONFIG_IU_MUL_LATENCY_2: Implementation options for the integer multiplier. >> Type Implementation issue-rate/latency >> 2-clocks 32x32 pipelined multiplier 1/2 >> 4-clocks 16x16 standard multiplier 4/4 >> 5-clocks 16x16 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
> 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 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
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
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.000000000 +0100 +++ gcc-4.4.2/gcc/config/sparc/leon.md 2010-10-19 11:56:58.000000000 +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.000000000 +0200 +++ gcc-4.4.2/gcc/config/sparc/sparc.c 2010-10-19 11:56:58.000000000 +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 */ + COSTS_N_INSNS (5), /* imulX */ + 0, /* imul bit factor */ + COSTS_N_INSNS (5), /* idiv */ + COSTS_N_INSNS (5), /* idivX */ + COSTS_N_INSNS (1), /* movcc/movr */ + 0, /* shift penalty */ +}; + const struct processor_costs *sparc_costs = &cypress_costs; #ifdef HAVE_AS_RELAX_OPTION @@ -651,6 +675,10 @@ { TARGET_CPU_ultrasparc3, "ultrasparc3" }, { TARGET_CPU_niagara, "niagara" }, { TARGET_CPU_niagara2, "niagara2" }, + { TARGET_CPU_sparchfleon, "sparchfleon" }, + { TARGET_CPU_sparchfleonv8, "sparchfleonv8" }, + { TARGET_CPU_sparcsfleon, "sparcsfleon" }, + { TARGET_CPU_sparcsfleonv8, "sparcsfleonv8" }, { 0, 0 } }; const struct cpu_default *def; @@ -689,6 +717,11 @@ /* UltraSPARC T1 */ { "niagara", PROCESSOR_NIAGARA, MASK_ISA, MASK_V9|MASK_DEPRECATED_V8_INSNS}, { "niagara2", PROCESSOR_NIAGARA, MASK_ISA, MASK_V9}, + /* SPARC-LEON */ + { "sparchfleon", PROCESSOR_LEON, MASK_ISA, MASK_FPU }, + { "sparchfleonv8", PROCESSOR_LEON, MASK_ISA & ~(MASK_V8), MASK_V8|MASK_FPU }, + { "sparcsfleon", PROCESSOR_LEON, MASK_ISA | MASK_FPU, 0 }, + { "sparcsfleonv8", PROCESSOR_LEON, (MASK_ISA | MASK_FPU) & ~(MASK_V8), MASK_V8 }, { 0, 0, 0, 0 } }; const struct cpu_table *cpu; @@ -855,6 +888,9 @@ case PROCESSOR_NIAGARA2: sparc_costs = &niagara2_costs; break; + case PROCESSOR_LEON: + sparc_costs = &leon_costs; + break; }; #ifdef TARGET_DEFAULT_LONG_DOUBLE_128 diff -Naurb gcc-4.4.2.ori/gcc/config/sparc/sparc.h gcc-4.4.2/gcc/config/sparc/sparc.h --- gcc-4.4.2.ori/gcc/config/sparc/sparc.h 2010-10-19 11:55:17.000000000 +0200 +++ gcc-4.4.2/gcc/config/sparc/sparc.h 2010-10-19 11:56:58.000000000 +0200 @@ -243,6 +243,10 @@ #define TARGET_CPU_ultrasparc3 9 #define TARGET_CPU_niagara 10 #define TARGET_CPU_niagara2 11 +#define TARGET_CPU_sparchfleon 12 +#define TARGET_CPU_sparchfleonv8 13 +#define TARGET_CPU_sparcsfleon 14 +#define TARGET_CPU_sparcsfleonv8 15 #if TARGET_CPU_DEFAULT == TARGET_CPU_v9 \ || TARGET_CPU_DEFAULT == TARGET_CPU_ultrasparc \ @@ -299,6 +303,26 @@ #define ASM_CPU32_DEFAULT_SPEC "-Asparclite" #endif +#if TARGET_CPU_DEFAULT == TARGET_CPU_sparchfleon +#define CPP_CPU32_DEFAULT_SPEC "-Dsparcleon" +#define ASM_CPU32_DEFAULT_SPEC "" +#endif + +#if TARGET_CPU_DEFAULT == TARGET_CPU_sparcsfleon +#define CPP_CPU32_DEFAULT_SPEC "-Dsparcleon -D_SOFT_FLOAT" +#define ASM_CPU32_DEFAULT_SPEC "" +#endif + +#if TARGET_CPU_DEFAULT == TARGET_CPU_sparchfleonv8 +#define CPP_CPU32_DEFAULT_SPEC "-Dsparcleon -D__sparc_v8__ " +#define ASM_CPU32_DEFAULT_SPEC "" +#endif + +#if TARGET_CPU_DEFAULT == TARGET_CPU_sparcsfleonv8 +#define CPP_CPU32_DEFAULT_SPEC "-Dsparcleon -D__sparc_v8__ -D_SOFT_FLOAT" +#define ASM_CPU32_DEFAULT_SPEC "" +#endif + #if TARGET_CPU_DEFAULT == TARGET_CPU_supersparc #define CPP_CPU32_DEFAULT_SPEC "-D__supersparc__ -D__sparc_v8__" #define ASM_CPU32_DEFAULT_SPEC "" @@ -369,6 +393,10 @@ %{mcpu=ultrasparc3:-D__sparc_v9__} \ %{mcpu=niagara:-D__sparc_v9__} \ %{mcpu=niagara2:-D__sparc_v9__} \ +%{mcpu=sparchfleon:-Dsparcleon} \ +%{mcpu=sparchfleonv8:-Dsparcleon -D__sparc_v8__} \ +%{mcpu=sparcsfleon:-Dsparcleon -D_SOFT_FLOAT} \ +%{mcpu=sparcsfleonv8:-Dsparcleon -D_SOFT_FLOAT -D__sparc_v8__} \ %{!mcpu*:%{!mcypress:%{!msparclite:%{!mf930:%{!mf934:%{!mv8:%{!msupersparc:%(cpp_cpu_default)}}}}}}} \ " #define CPP_ARCH32_SPEC "" @@ -533,6 +561,7 @@ PROCESSOR_V7, PROCESSOR_CYPRESS, PROCESSOR_V8, + PROCESSOR_LEON, PROCESSOR_SUPERSPARC, PROCESSOR_SPARCLITE, PROCESSOR_F930, diff -Naurb gcc-4.4.2.ori/gcc/config/sparc/sparc.md gcc-4.4.2/gcc/config/sparc/sparc.md --- gcc-4.4.2.ori/gcc/config/sparc/sparc.md 2010-10-19 11:55:17.000000000 +0200 +++ gcc-4.4.2/gcc/config/sparc/sparc.md 2010-10-19 11:56:58.000000000 +0200 @@ -89,6 +89,7 @@ "v7, cypress, v8, + leon, supersparc, sparclite,f930,f934, hypersparc,sparclite86x, @@ -320,6 +321,7 @@ (include "ultra3.md") (include "niagara.md") (include "niagara2.md") +(include "leon.md") ;; Operand and operator predicates and constraints diff -Naurb gcc-4.4.2.ori/gcc/config/sparc/t-leon gcc-4.4.2/gcc/config/sparc/t-leon --- gcc-4.4.2.ori/gcc/config/sparc/t-leon 1970-01-01 01:00:00.000000000 +0100 +++ gcc-4.4.2/gcc/config/sparc/t-leon 2010-10-19 11:56:58.000000000 +0200 @@ -0,0 +1,16 @@ +# configuration file for LEON cpu + +LIB1ASMSRC = sparc/lb1spc.asm +LIB1ASMFUNCS = _mulsi3 _divsi3 _modsi3 + +# We want fine grained libraries, so use the new code to build the +# floating point emulation libraries. +FPBIT = fp-bit.c +DPBIT = dp-bit.c + +dp-bit.c: $(srcdir)/config/fp-bit.c + cat $(srcdir)/config/fp-bit.c > dp-bit.c + +fp-bit.c: $(srcdir)/config/fp-bit.c + echo '#define FLOAT' > fp-bit.c + cat $(srcdir)/config/fp-bit.c >> fp-bit.c diff -Naurb gcc-4.4.2.ori/gcc/config.gcc gcc-4.4.2/gcc/config.gcc --- gcc-4.4.2.ori/gcc/config.gcc 2010-10-19 11:55:17.000000000 +0200 +++ gcc-4.4.2/gcc/config.gcc 2010-10-19 11:56:11.000000000 +0200 @@ -2978,6 +2978,9 @@ | v9 | ultrasparc | ultrasparc3 | niagara | niagara2) # OK ;; + sparchfleon | sparcsfleon | sparchfleonv8 | sparcsfleonv8 | leon) + tmake_file="${tmake_file} sparc/t-leon" + ;; *) echo "Unknown cpu used in --with-$which=$val" 1>&2 exit 1
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.