Patchwork Adding Leon processor to the SPARC list of processors

login
register
mail settings
Submitter Konrad Eisele
Date Nov. 18, 2010, 12:02 p.m.
Message ID <4CE515CB.7080706@gaisler.com>
Download mbox | patch
Permalink /patch/72084/
State New
Headers show

Comments

Konrad Eisele - Nov. 18, 2010, 12:02 p.m.
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.
Eric Botcazou - Nov. 18, 2010, 1:16 p.m.
> 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.
Konrad Eisele - Nov. 18, 2010, 1:29 p.m.
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
Joern Rennecke - Nov. 18, 2010, 2:25 p.m.
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.
Konrad Eisele - Nov. 18, 2010, 2:31 p.m.
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
Eric Botcazou - Nov. 19, 2010, 8:45 a.m.
> 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.
Joern Rennecke - Nov. 19, 2010, 12:48 p.m.
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.)
Eric Botcazou - Nov. 19, 2010, 4:53 p.m.
> 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 - Nov. 19, 2010, 4:58 p.m.
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.
>
Eric Botcazou - Nov. 19, 2010, 5:16 p.m.
> 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).
Geert Bosch - Nov. 19, 2010, 7:06 p.m.
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
Jorge PEREZ - Nov. 22, 2010, 8:32 a.m.
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
Konrad Eisele - Nov. 22, 2010, 8:44 a.m.
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).
Konrad Eisele - Nov. 22, 2010, 8:50 a.m.
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
Eric Botcazou - Nov. 22, 2010, 8:52 a.m.
> 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.
Konrad Eisele - Nov. 22, 2010, 8:58 a.m.
>> * 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
Eric Botcazou - Nov. 22, 2010, 9:07 a.m.
> 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.
Konrad Eisele - Nov. 22, 2010, 9:59 a.m.
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
Konrad Eisele - Nov. 22, 2010, 10 a.m.
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

Patch

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