--- On Wed, 12/1/11, Joel Sherrill wrote:
> From: Joel Sherrill
> Subject: Re: Adding Leon processor to the SPARC list of processors
> To: "David Paterson"
> Cc: "gcc@gcc.gnu.org"
> Date: Wednesday, 12 January, 2011, 16:31
> On 01/12/2011 09:17
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
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, o
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
> 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.
> 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 ol
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-fl
> 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
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=
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
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=h
> 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 |
--
>> * 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
> 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
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 defa
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.
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
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
> 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
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 c
> 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 straig
Quoting Eric Botcazou :
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 t
> 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
Joern Rennecke wrote:
> Quoting Konrad Eisele :
>
>> 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.
>
>
Quoting Konrad Eisele :
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.
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/g
> 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
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:
28 matches
Mail list logo
