* Porting gcc
@ 2008-03-12 6:11 Schmave
2008-03-12 6:15 ` Ben Elliston
0 siblings, 1 reply; 28+ messages in thread
From: Schmave @ 2008-03-12 6:11 UTC (permalink / raw)
To: gcc
Hi I would luke to know what I need to do to port gcc to a new
architecture
Thanks
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Porting gcc
2008-03-12 6:11 Porting gcc Schmave
@ 2008-03-12 6:15 ` Ben Elliston
0 siblings, 0 replies; 28+ messages in thread
From: Ben Elliston @ 2008-03-12 6:15 UTC (permalink / raw)
To: Schmave; +Cc: gcc
On Wed, 2008-03-12 at 16:56 +1100, Schmave wrote:
> Hi I would luke to know what I need to do to port gcc to a new
> architecture
You can start by reading the GCC internals documentation:
http://gcc.gnu.org/onlinedocs/gccint/
You can also look at the source code, in particular, the gcc/config
directory.
Finally, you have the option of hiring someone to do the port for you:
http://www.fsf.org/resources/service
Cheers, Ben
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2008-10-20 10:20 porting gcc Aurélien Buhrig
@ 2008-10-20 19:34 ` Ian Lance Taylor
0 siblings, 0 replies; 28+ messages in thread
From: Ian Lance Taylor @ 2008-10-20 19:34 UTC (permalink / raw)
To: Aurélien Buhrig; +Cc: gcc
Aurélien Buhrig <Aurelien.Buhrig@tiempo-ic.com> writes:
> We are designing a 16-bit asynchronous microcontroller. I’ve already ported
> bfd, binutils (including sid simulator) using cgen, and part of gdb (for asm
> debug only) and we are now investigating the best way to have C compiler.
> So my questions are:
>
> 1- How much time do you think it will take to port gcc for this platform
> with a quite simple instruction set, with a good porting guide?
My answer the last time I answered this question:
http://gcc.gnu.org/ml/gcc-help/2008-04/msg00117.html
> 2- What about optimizations? I suppose most of them are platform-independent
> and performed at RTL level, aren't they? But, generally speaking, are there
> many platform-dependent optimizations (I would have to do)? And is it
> possible or how is it complex to have a level of optimization (code
> compactness...) as good as commercial compiler ones (such as IAR, Keil,
> ACE...)?
Most optimizations are platform independent. The hardest platform
specific one to implement is scheduling; you will have to write a
description of your pipeline. Some peepholes may be appropriate.
Other than that, you will only need platform specific code if your
processor is unusual in some respect. Unfortunately, my experience is
that every processor has some unusual aspects.
gcc is a commercial compiler. If you mean: how does gcc compare to a
proprietary compiler, the answer is that it is very competitive for
conventional processors.
> 3- Finally, some companies may port gcc for us (perhaps in this mailing
> list?). An idea of how much it could be?
I have no idea what the rates are these days, sorry. In any case the
precise details of your processor make a big difference to the price.
Ian
^ permalink raw reply [flat|nested] 28+ messages in thread
* porting gcc
@ 2008-10-20 10:20 Aurélien Buhrig
2008-10-20 19:34 ` Ian Lance Taylor
0 siblings, 1 reply; 28+ messages in thread
From: Aurélien Buhrig @ 2008-10-20 10:20 UTC (permalink / raw)
To: gcc
Hi,
We are designing a 16-bit asynchronous microcontroller. Ive already ported
bfd, binutils (including sid simulator) using cgen, and part of gdb (for asm
debug only) and we are now investigating the best way to have C compiler.
So my questions are:
1- How much time do you think it will take to port gcc for this platform
with a quite simple instruction set, with a good porting guide?
2- What about optimizations? I suppose most of them are platform-independent
and performed at RTL level, aren't they? But, generally speaking, are there
many platform-dependent optimizations (I would have to do)? And is it
possible or how is it complex to have a level of optimization (code
compactness...) as good as commercial compiler ones (such as IAR, Keil,
ACE...)?
3- Finally, some companies may port gcc for us (perhaps in this mailing
list?). An idea of how much it could be?
Many thanks,
Aurelien
^ permalink raw reply [flat|nested] 28+ messages in thread
* RE: Porting GCC
@ 2004-06-04 15:24 Gyle Yearsley
0 siblings, 0 replies; 28+ messages in thread
From: Gyle Yearsley @ 2004-06-04 15:24 UTC (permalink / raw)
To: 'Richard Sandiford'; +Cc: 'gcc@gcc.gnu.org'
Thanks Richard,
I will check that.
Gyle
-----Original Message-----
From: Richard Sandiford [mailto:rsandifo@redhat.com]
Sent: Thursday, June 03, 2004 9:38 AM
To: Gyle Yearsley
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Porting GCC
Gyle Yearsley <gyearsley@zilog.com> writes:
>> (insn 15 13 16 (nil) (set (mem/f:SI (pre_dec:SI (reg/f:SI 16 sp)) [0 S4
>> A8])
>> (mem/f:SI (plus:SI (reg/f:SI 18 virtual-stack-vars)
>> (const_int -20 [0xffffffec])) [0 e+0 S4 A32])) -1 (nil)
>> (nil))
>>
>>
>> (define_insn "pushsi"
>> [(set:SI (mem:SI (pre_dec:SI (reg:SI 16)))
>> (match_operand:SI 0 "general_operand" "r,m"))]
>> ""
>> "@
>> push.q %0
>> push.q %0"
>> )
One thing to check is that GO_IF_LEGITIMATE_ADDRESS accepts:
(plus:SI (reg/f:SI 18 virtual-stack-vars)
(const_int -20 [0xffffffec]))
as a valid address for SImode.
Richard
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Porting GCC
2004-06-02 16:49 Gyle Yearsley
@ 2004-06-03 15:38 ` Richard Sandiford
0 siblings, 0 replies; 28+ messages in thread
From: Richard Sandiford @ 2004-06-03 15:38 UTC (permalink / raw)
To: Gyle Yearsley; +Cc: 'gcc@gcc.gnu.org'
Gyle Yearsley <gyearsley@zilog.com> writes:
>> (insn 15 13 16 (nil) (set (mem/f:SI (pre_dec:SI (reg/f:SI 16 sp)) [0 S4
>> A8])
>> (mem/f:SI (plus:SI (reg/f:SI 18 virtual-stack-vars)
>> (const_int -20 [0xffffffec])) [0 e+0 S4 A32])) -1 (nil)
>> (nil))
>>
>>
>> (define_insn "pushsi"
>> [(set:SI (mem:SI (pre_dec:SI (reg:SI 16)))
>> (match_operand:SI 0 "general_operand" "r,m"))]
>> ""
>> "@
>> push.q %0
>> push.q %0"
>> )
One thing to check is that GO_IF_LEGITIMATE_ADDRESS accepts:
(plus:SI (reg/f:SI 18 virtual-stack-vars)
(const_int -20 [0xffffffec]))
as a valid address for SImode.
Richard
^ permalink raw reply [flat|nested] 28+ messages in thread
* Porting GCC
@ 2004-06-02 16:49 Gyle Yearsley
2004-06-03 15:38 ` Richard Sandiford
0 siblings, 1 reply; 28+ messages in thread
From: Gyle Yearsley @ 2004-06-02 16:49 UTC (permalink / raw)
To: 'gcc@gcc.gnu.org'
> I have been working on a gcc cross-compiler for a new processor that I am
> designing. I am
> in the process of setting up the ABI. Currently I am having a problem with
> pushing arguments
> on the stack when calling a function. I have allocoated three registers to
> hold function arguments.
> When I use three or less arguments the code will compile properly. Once I
> exceed the three args gcc
> will abort. I hae traced this to the function instantiate_virtual_regs. I
> assume this is due to the push
> instruction not matching. The processor has a stack pointer with a push
> instruction. Below is the output
> from the -dr debug option and the push insn from the machine descritption
> file.
>
> (insn 15 13 16 (nil) (set (mem/f:SI (pre_dec:SI (reg/f:SI 16 sp)) [0 S4
> A8])
> (mem/f:SI (plus:SI (reg/f:SI 18 virtual-stack-vars)
> (const_int -20 [0xffffffec])) [0 e+0 S4 A32])) -1 (nil)
> (nil))
>
>
> (define_insn "pushsi"
> [(set:SI (mem:SI (pre_dec:SI (reg:SI 16)))
> (match_operand:SI 0 "general_operand" "r,m"))]
> ""
> "@
> push.q %0
> push.q %0"
> )
>
> Any help would be appreciated.
>
> Gyle Yearsley
> Principal Design Engineer
> gyearsley@zilog.com
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* RE: Porting gcc
2004-05-21 13:09 Porting gcc Mile Davidovic
@ 2004-05-21 13:43 ` Dave Korn
0 siblings, 0 replies; 28+ messages in thread
From: Dave Korn @ 2004-05-21 13:43 UTC (permalink / raw)
To: gcc
> -----Original Message-----
> From: gcc-owner On Behalf Of Mile Davidovic
> Sent: 21 May 2004 14:02
> I have questions regarding support new MIPS based processor,
> MDE950xx. In the
> basic it is same as R3000 but except one thing, this
> processor does not support
> lwl and lwr instructions, what is best way to support this "feature"?
The MIPS port already supports multiple cpu types; you'd just need to
extend what's already there. Look at gcc/config/mips/mips.h; you'd need to
add a new element to the enum processor_type (taking care to keep it
matching up with the definition of the cpu attribute in mips.md); you'd also
define corresponding TARGET_MIPSxxx and TUNE_MIPSxxx definitions.
Further down mips.h you'll see loads of feature-test macros called
ISA_HAS_xxxxx, which are used to test which instructions do or don't exist
on various mips versions; you could define one called ISA_HAS_LWLR for
instance. Then you could use that macro as a feature test in the insn
patterns in mips.md that use those instructions.
Not being familiar with the mips port myself, that's the most advice I can
give you. You'll have to familiarise yourself well enough with the mips
backend to be sure whether or not there were any other things you had to
keep consistent or extend to know about the new cpu type. Maybe some of the
specs, for instance. And mips.c has a structure called mips_cpu_info_table
which you'd need to add an entry to. Finding the remaining stuff you'd need
to implement is up to you.
> We want to use latest gcc version, 3.4. What is necessary
> steps for porting gcc?
Like I say, you don't need to port it; just modify the existing port.
> If we have success to support what is best way to add patches to gcc?
Check out a copy of gcc from the gnu CVS server; you would want to use the
3.4 branch rather than work against the head. Develop your modifications,
test them, ensure the compiler passes the testsuite with no regressions, use
"cvs diff" to generate a patch and send it to the gcc-patches list. Pretty
much exactly what it says at http://gcc.gnu.org/contribute.html really!
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply [flat|nested] 28+ messages in thread
* Porting gcc
@ 2004-05-21 13:09 Mile Davidovic
2004-05-21 13:43 ` Dave Korn
0 siblings, 1 reply; 28+ messages in thread
From: Mile Davidovic @ 2004-05-21 13:09 UTC (permalink / raw)
To: gcc
Hi everybody
I have questions regarding support new MIPS based processor, MDE950xx. In the
basic it is same as R3000 but except one thing, this processor does not support
lwl and lwr instructions, what is best way to support this "feature"?
We want to use latest gcc version, 3.4. What is necessary steps for porting gcc?
If we have success to support what is best way to add patches to gcc?
Best regards Mile
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Porting gcc
2003-08-13 11:15 Petar Penchev
@ 2003-08-13 16:07 ` Ben Elliston
0 siblings, 0 replies; 28+ messages in thread
From: Ben Elliston @ 2003-08-13 16:07 UTC (permalink / raw)
To: gcc
"Petar Penchev" <ptr@sd-bul.bg> writes:
> Target.c target.h and target.md files are complementary to one
> another. I mean they have common purpose (to define target
> machine). I am wondering are there any tools which could help me to
> create /or better to generate / these files or I have to write them
> from scratch ?
There are no automatic generators, although there was some discussion
once about using CGEN to assist in the generation of the machine
description file. The usual approach is to take the most similar
existing port, copy those files and start with those.
> And second question in Amazon.com I found some books on porting GCC,
> does anybody know something about on-line version of these books ?
If the one you are looking at is the one published by the FSF, then
the book's contents are available in the GCC source tree. Also, see:
http://gcc.gnu.org/onlinedocs/
Ben
^ permalink raw reply [flat|nested] 28+ messages in thread
* Porting gcc
@ 2003-08-13 11:15 Petar Penchev
2003-08-13 16:07 ` Ben Elliston
0 siblings, 1 reply; 28+ messages in thread
From: Petar Penchev @ 2003-08-13 11:15 UTC (permalink / raw)
To: gcc
Hello All,
I started porting GCC for new target. I read the documentation I have found
and I have couple questions I can't find answers.
Target.c target.h and target.md files are complementary to one another. I
mean they have common purpose (to define target machine). I am wondering are
there any tools which could help me to create /or better to generate / these
files or I have to write them from scratch ?
And second question in Amazon.com I found some books on porting GCC, does
anybody know something about on-line version of these books ?
Regards Petar
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2002-10-22 18:02 ` Mike Stump
@ 2002-10-23 10:05 ` Andrew Haley
0 siblings, 0 replies; 28+ messages in thread
From: Andrew Haley @ 2002-10-23 10:05 UTC (permalink / raw)
To: Mike Stump; +Cc: Grégoire Dooms, gcc
Mike Stump writes:
> On Tuesday, October 22, 2002, at 12:09 PM, Andrew Haley wrote:
> > =?iso-8859-1?Q?Gr=E9goire=5FDooms?= writes:
> >> I'd like to port gcc to the Microchip PIC 8 bit microcontroller
> >> familly.
> >
> > Ouch. Are you really sure that you want to do this?
>
> Sure. They aren't going to run gtk+ on it, promise, but I don't see
> any reason why:
>
> char c1, c2, c3;
>
> main() {
> c1 = c2 + c3;
> }
>
> can't work at least as well as the existing compilers for PIC.
Sure, but at some point you're going to spill and then you'll need some
reasonably efficient mechanism to index a stack frame.
I guess it depends on which PIC variant we're talking about -- it
looks as though the new PIC18CXXX will work quite well, but I wasn't
aware of that variant when I posted.
Andrew.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2002-10-22 14:43 ` Andrew Haley
2002-10-22 15:16 ` Michael Matz
2002-10-22 15:27 ` Svein E. Seldal
@ 2002-10-22 18:02 ` Mike Stump
2002-10-23 10:05 ` Andrew Haley
2 siblings, 1 reply; 28+ messages in thread
From: Mike Stump @ 2002-10-22 18:02 UTC (permalink / raw)
To: Andrew Haley; +Cc: Grégoire Dooms, gcc
On Tuesday, October 22, 2002, at 12:09 PM, Andrew Haley wrote:
> =?iso-8859-1?Q?Gr=E9goire=5FDooms?= writes:
>> I'd like to port gcc to the Microchip PIC 8 bit microcontroller
>> familly.
>
> Ouch. Are you really sure that you want to do this?
Sure. They aren't going to run gtk+ on it, promise, but I don't see
any reason why:
char c1, c2, c3;
main() {
c1 = c2 + c3;
}
can't work at least as well as the existing compilers for PIC. They
don't care if all of java doesn't work. For the above program, it
isn't that hard to get gcc to generate and emit code.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2002-10-22 9:53 porting gcc Grégoire Dooms
` (2 preceding siblings ...)
2002-10-22 14:43 ` Andrew Haley
@ 2002-10-22 15:50 ` Denis Chertykov
3 siblings, 0 replies; 28+ messages in thread
From: Denis Chertykov @ 2002-10-22 15:50 UTC (permalink / raw)
To: Grщgoire Dooms; +Cc: gcc
Grégoire Dooms <dooms@student.info.ucl.ac.be> writes:
> I'd like to port gcc to the Microchip PIC 8 bit microcontroller familly.
>
> I've read all the documentation (Passes, Machine Description, ...) and the
> AVR (other 8bit uc) files (.md .c .h).
Probably better look to ip2k port it's more limited than AVR.
>
> What should I do now?
> Is it possible to incrementally write those files ?
> Is there a document explaining that process?
> Who should I ask about a few not-understood stuff in the AVR files?
I'm an AVR port maintainer. I can answer your questions, but I havn't
free time. Also ip2k.
Denis.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2002-10-22 14:43 ` Andrew Haley
2002-10-22 15:16 ` Michael Matz
@ 2002-10-22 15:27 ` Svein E. Seldal
2002-10-22 18:02 ` Mike Stump
2 siblings, 0 replies; 28+ messages in thread
From: Svein E. Seldal @ 2002-10-22 15:27 UTC (permalink / raw)
To: Andrew Haley; +Cc: Grégoire Dooms, gcc
Andrew Haley wrote:
> =?iso-8859-1?Q?Gr=E9goire=5FDooms?= writes:
> > I'd like to port gcc to the Microchip PIC 8 bit microcontroller familly.
>
> Ouch. Are you really sure that you want to do this? Gcc requires
> reasonably efficient addressing of stack frames in order to spill and
> fill when there are insufficient physical registers. This might be
> hard to do on the PIC. gcc has been [orted to some 16-bitters, but a
> microcontroller is a stretch.
Well yes, but remember that gcc has been ported to run on AVR (and quite
successfully IMHO). AVR is the "sibling"-product for PIC's. It is a
8-bit microcontroller, with some limited 16-bit extensions. I do not
know anything about PIC's, but I think the target should be able to
handle gcc code.
I must remember anyone of the mission statement that states that gcc
wants more new targets :) We mustn't discurage newcomers... ;) I have
experienced that several of these small gcc targets (like AVR's)
produces better quality code than its commercial tools. We should
encourage development of gcc for small microcontrollers as well as the
big mainframe targets. gcc is a great product!
I have been thinking about porting 8051 to gcc, but I wont do so until I
need it in a project (if I need it at all). Porting gcc to new targets
is a fairly extensive job.
Svein
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2002-10-22 14:43 ` Andrew Haley
@ 2002-10-22 15:16 ` Michael Matz
2002-10-22 15:27 ` Svein E. Seldal
2002-10-22 18:02 ` Mike Stump
2 siblings, 0 replies; 28+ messages in thread
From: Michael Matz @ 2002-10-22 15:16 UTC (permalink / raw)
To: Andrew Haley; +Cc: Grégoire Dooms, gcc
On Tue, 22 Oct 2002, Andrew Haley wrote:
> =?iso-8859-1?Q?Gr=E9goire=5FDooms?= writes:
> > I'd like to port gcc to the Microchip PIC 8 bit microcontroller familly.
>
> Ouch. Are you really sure that you want to do this? Gcc requires
> reasonably efficient addressing of stack frames in order to spill and
> fill when there are insufficient physical registers. This might be
> hard to do on the PIC. gcc has been [orted to some 16-bitters, but a
> microcontroller is a stretch.
The AVR _is_ a 8 bit microcontroller, and is supported by gcc (it also
supports it with 16bit integers). Sure, it has around 30 free registers.
And yes, the stack pointer (like all its 16 bit pointers) actually are two
registers.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 28+ messages in thread
* porting gcc
2002-10-22 9:53 porting gcc Grégoire Dooms
2002-10-22 9:56 ` Grégoire Dooms
2002-10-22 14:40 ` Mike Stump
@ 2002-10-22 14:43 ` Andrew Haley
2002-10-22 15:16 ` Michael Matz
` (2 more replies)
2002-10-22 15:50 ` Denis Chertykov
3 siblings, 3 replies; 28+ messages in thread
From: Andrew Haley @ 2002-10-22 14:43 UTC (permalink / raw)
To: Grégoire Dooms; +Cc: gcc
=?iso-8859-1?Q?Gr=E9goire=5FDooms?= writes:
> I'd like to port gcc to the Microchip PIC 8 bit microcontroller familly.
Ouch. Are you really sure that you want to do this? Gcc requires
reasonably efficient addressing of stack frames in order to spill and
fill when there are insufficient physical registers. This might be
hard to do on the PIC. gcc has been [orted to some 16-bitters, but a
microcontroller is a stretch.
Andrew.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2002-10-22 9:53 porting gcc Grégoire Dooms
2002-10-22 9:56 ` Grégoire Dooms
@ 2002-10-22 14:40 ` Mike Stump
2002-10-22 14:43 ` Andrew Haley
2002-10-22 15:50 ` Denis Chertykov
3 siblings, 0 replies; 28+ messages in thread
From: Mike Stump @ 2002-10-22 14:40 UTC (permalink / raw)
To: Grégoire Dooms; +Cc: gcc
On Tuesday, October 22, 2002, at 05:55 AM, Grégoire Dooms wrote:
> I've read all the documentation (Passes, Machine Description, ...) and
> the
> AVR (other 8bit uc) files (.md .c .h).
>
> What should I do now?
File your paperwork, and port it.
> Is it possible to incrementally write those files ?
Yes. I find it convenient to copy some working port, and then modify
it until done. I maintained a working compiler that generated
progressively more correct code. This why I would tell how close I
was, and if the compiler started to not work, I knew it was related to
the last edit, thus shortening my search space. Sometimes the way sin
which the compiler can fail are non-obvious, but being able to fall
back on the temporal information was handy.
> Is there a document explaining that process?
Just what's on our web site.
> Who should I ask about a few not-understood stuff in the AVR files?
I'd just ignore it, maybe the trickery won't be needed in your port.
Or, maybe you'll understand it better when you have 90% of the easy
stuff done.
^ permalink raw reply [flat|nested] 28+ messages in thread
* porting gcc
2002-10-22 9:53 porting gcc Grégoire Dooms
@ 2002-10-22 9:56 ` Grégoire Dooms
2002-10-22 14:40 ` Mike Stump
` (2 subsequent siblings)
3 siblings, 0 replies; 28+ messages in thread
From: Grégoire Dooms @ 2002-10-22 9:56 UTC (permalink / raw)
To: gcc
I'd like to port gcc to the Microchip PIC 8 bit microcontroller familly.
I've read all the documentation (Passes, Machine Description, ...) and the
AVR (other 8bit uc) files (.md .c .h).
What should I do now?
Is it possible to incrementally write those files ?
Is there a document explaining that process?
Who should I ask about a few not-understood stuff in the AVR files?
Thank you for your help.
Grégoire Dooms.
^ permalink raw reply [flat|nested] 28+ messages in thread
* porting gcc
@ 2002-10-22 9:53 Grégoire Dooms
2002-10-22 9:56 ` Grégoire Dooms
` (3 more replies)
0 siblings, 4 replies; 28+ messages in thread
From: Grégoire Dooms @ 2002-10-22 9:53 UTC (permalink / raw)
To: gcc
I'd like to port gcc to the Microchip PIC 8 bit microcontroller familly.
I've read all the documentation (Passes, Machine Description, ...) and the
AVR (other 8bit uc) files (.md .c .h).
What should I do now?
Is it possible to incrementally write those files ?
Is there a document explaining that process?
Who should I ask about a few not-understood stuff in the AVR files?
Thank you for your help.
Grégoire Dooms.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting gcc
2001-02-15 8:41 Filippo Basso
@ 2001-02-15 9:50 ` Fergus Henderson
0 siblings, 0 replies; 28+ messages in thread
From: Fergus Henderson @ 2001-02-15 9:50 UTC (permalink / raw)
To: Filippo Basso; +Cc: gcc
On 15-Feb-2001, Filippo Basso <filippo@zirak.it> wrote:
> Hi, I'm filippo from Italy,
> and I'm trying to port Linux 2.0.38 under a DSP-multiRISC architecture, with the uCLinux fellows...
> Now, Alessandro Rubini told me that it will be better to have first GCC ported to this architecture...
> Is it possible ?
Almost certainly.
> Where do I have to start from ?
I suggest reading the GCC manual, "Using and porting the GNU Compiler
Collection (GCC)", in particular the second half, starting with the
"GCC and portability" chapter. The GCC manual is distributed with GCC,
and is also available at < http://gcc.gnu.org/onlinedocs/ >.
Good luck,
Fergus.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh > | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 28+ messages in thread
* porting gcc
@ 2001-02-15 8:41 Filippo Basso
2001-02-15 9:50 ` Fergus Henderson
0 siblings, 1 reply; 28+ messages in thread
From: Filippo Basso @ 2001-02-15 8:41 UTC (permalink / raw)
To: gcc
Hi, I'm filippo from Italy,
and I'm trying to port Linux 2.0.38 under a DSP-multiRISC architecture, with the uCLinux fellows...
Now, Alessandro Rubini told me that it will be better to have first GCC ported to this architecture...
Is it possible ?
Where do I have to start from ?
Is there some guy that have some time to ask stupid questions ?
(n.b. for this processor, I have an ansi-C compiler (well, a quasi-ansi), an assembler, and a linker,... some tools. I need only to
do the scalar port (using the DSP, the multiRISC I'll think the day after ! ;-))
really thanks,
phy
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting GCC
2001-02-02 6:07 ` Krzysztof Matula
@ 2001-02-02 7:08 ` Richard Earnshaw
0 siblings, 0 replies; 28+ messages in thread
From: Richard Earnshaw @ 2001-02-02 7:08 UTC (permalink / raw)
To: Krzysztof Matula; +Cc: Richard.Earnshaw, gcc
> ----- Original Message -----
> From: "Richard Earnshaw" <rearnsha@arm.com>
> Sent: Friday, February 02, 2001 13:00
>
>
> > > I am generating several insn-s inside define_expand. The meaning of the
> code
> > > is not exactly the same, as the rtl matched. The problem is that GCC
> always
> > > notes the last insn I generate with REG_EQUAL expression, corresponding
> to
> > > the ORIGINAL code... I don't know how to avoid this...
> >
> > Why is this a problem? Gcc annotates the end of the sequence with a note
> > of the equivalent it collapses to. If you think of (symbol_ref
> > ("__clz_tab")) as the final address that will be dereferenced then the
> > expression
> >
> > (unspec [(symbol_ref ("__clz_tab"))] 3)
> > should be thought of as being equivalent to
> >
> > (minus (symbol_ref ("__clz_tab")) (reg:SI base_reg))
>
> I'm not sure if I understand this... Maybe there's something wrong that GCC
> thinks of (symbol_ref ("__clz_tab")) as absolute address and the assembly
> instructions not:
>
> (expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 9))
> (symbol_ref/v:SI ("__clz_tab")))
>
> (reg:SI 9) here represents the index to the __clz_tab, not the segment
> base...
> Referencing an element requires addition of segment base ((reg:SI 14) in the
> example below), the index (reg:SI 9) and the relative starting offset of the
> array: (symbol_ref/v:SI ("__clz_tab")). When I write the __clz_tab reference
> into otput file I get the offset only...
Try to think of it from a different perspective...
Let (symbol_ref/v:SI ("__clz_tab")) be the ABSOLUTE address in memory
where the information will finally reside (forget that the symbol you
eventually write to the assembly will be called __clz_tab).
Given the above
(symbol_ref ("__clz_tab")) = (plus:SI (base_reg) (XXX))
where XXX is some other expression. So by basic algebra
(XXX) = (minus:SI (symbol_ref ("__clz_tab")) (base_reg))
However, if we put this expression directly in the RTL, gcc would get
confused and try to optimize it away. to prevent this we represent the
expression with the unspec sequence
(unspec:SI [(symbol_ref ("__clz_tab"))] 3)
And when we finally come to write out the assembly code, we simply use the
name "__clz_tab" there, since the assembler knows that this is an offset
from some implied segment register.
> The segment base is not a single register. It is always accessible as first
> hidden argument to every function. It always needs to execute code to get it
> into register... I don't think I can do this inside define_insn...
>
> When I compile my example with -O2 GCC makes use of the REG_EQUAL and
> produces rlt that doesn't match any insn (and in fact is incorrect):
>
> (insn 10 8 11 (set (reg:SI 15)
> (plus:SI (reg/v:SI 13)
> (symbol_ref/v:SI ("__clz_tab")))) -1 (nil)
> (nil))
>
> (reg/v:SI 13) stands here for the index to the array. No segment base
> addition takes place.
This is because you have some rule elsewhere in your machine description
that says that such a statement is valid. Does LEGITIMATE_CONSTANT allow
symbol_ref? In your machine description an unwrapped symbol_ref must
never be allowed anywhere or you will run into problems of this nature.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting GCC
2001-02-02 4:00 ` Richard Earnshaw
@ 2001-02-02 6:07 ` Krzysztof Matula
2001-02-02 7:08 ` Richard Earnshaw
0 siblings, 1 reply; 28+ messages in thread
From: Krzysztof Matula @ 2001-02-02 6:07 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: gcc
----- Original Message -----
From: "Richard Earnshaw" <rearnsha@arm.com>
Sent: Friday, February 02, 2001 13:00
> > I am generating several insn-s inside define_expand. The meaning of the
code
> > is not exactly the same, as the rtl matched. The problem is that GCC
always
> > notes the last insn I generate with REG_EQUAL expression, corresponding
to
> > the ORIGINAL code... I don't know how to avoid this...
>
> Why is this a problem? Gcc annotates the end of the sequence with a note
> of the equivalent it collapses to. If you think of (symbol_ref
> ("__clz_tab")) as the final address that will be dereferenced then the
> expression
>
> (unspec [(symbol_ref ("__clz_tab"))] 3)
> should be thought of as being equivalent to
>
> (minus (symbol_ref ("__clz_tab")) (reg:SI base_reg))
I'm not sure if I understand this... Maybe there's something wrong that GCC
thinks of (symbol_ref ("__clz_tab")) as absolute address and the assembly
instructions not:
(expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 9))
(symbol_ref/v:SI ("__clz_tab")))
(reg:SI 9) here represents the index to the __clz_tab, not the segment
base...
Referencing an element requires addition of segment base ((reg:SI 14) in the
example below), the index (reg:SI 9) and the relative starting offset of the
array: (symbol_ref/v:SI ("__clz_tab")). When I write the __clz_tab reference
into otput file I get the offset only...
The segment base is not a single register. It is always accessible as first
hidden argument to every function. It always needs to execute code to get it
into register... I don't think I can do this inside define_insn...
When I compile my example with -O2 GCC makes use of the REG_EQUAL and
produces rlt that doesn't match any insn (and in fact is incorrect):
(insn 10 8 11 (set (reg:SI 15)
(plus:SI (reg/v:SI 13)
(symbol_ref/v:SI ("__clz_tab")))) -1 (nil)
(nil))
(reg/v:SI 13) stands here for the index to the array. No segment base
addition takes place.
> [we don't express it this way since then the compiler might try to
> simplify the expression in a way that would be incorrect, but
> mathematically when the base_reg value is added back on we end up with the
> address we really want.]
If only the value is added...
> >
> > (insn 9 8 11 (set (reg:SI 15) ;;real array address
> > (plus:SI (reg:SI 14) ;;segment base
> >
pec:SI[
> > (symbol_ref/v:SI ("__clz_tab"))
> > ] 3))) -1 (nil)
> > (nil))
> >
> > (insn 11 9 12 (set (reg:SI 16) ;;index to the array
> > (mem:SI (reg:SI 9))) -1 (nil)
> > (nil))
> >
> > (insn 12 11 14 (set (reg:SI 13)
> > (plus:SI (reg:SI 16)
> > (reg:SI 15))) -1 (nil)
> > (nil))
> >
> > (insn 14 12 16 (set (reg:SI 13)
> > (reg:SI 13)) -1 (nil)
> > (expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 9))
> > (symbol_ref/v:SI ("__clz_tab")))
> > (nil)))
> >
KM
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting GCC
2001-02-02 3:43 ` Krzysztof Matula
@ 2001-02-02 4:00 ` Richard Earnshaw
2001-02-02 6:07 ` Krzysztof Matula
0 siblings, 1 reply; 28+ messages in thread
From: Richard Earnshaw @ 2001-02-02 4:00 UTC (permalink / raw)
To: Krzysztof Matula; +Cc: gcc, Richard.Earnshaw
> It worked :)
Good.
> But soon I reached another problem...
>
> I am generating several insn-s inside define_expand. The meaning of the code
> is not exactly the same, as the rtl matched. The problem is that GCC always
> notes the last insn I generate with REG_EQUAL expression, corresponding to
> the ORIGINAL code... I don't know how to avoid this...
Why is this a problem? Gcc annotates the end of the sequence with a note
of the equivalent it collapses to. If you think of (symbol_ref
("__clz_tab")) as the final address that will be dereferenced then the
expression
(unspec [(symbol_ref ("__clz_tab"))] 3)
should be thought of as being equivalent to
(minus (symbol_ref ("__clz_tab")) (reg:SI base_reg))
[we don't express it this way since then the compiler might try to
simplify the expression in a way that would be incorrect, but
mathematically when the base_reg value is added back on we end up with the
address we really want.]
>
> (insn 9 8 11 (set (reg:SI 15)
> (plus:SI (reg:SI 14)
>
> spec:SI[
> (symbol_ref/v:SI ("__clz_tab"))
> ] 3))) -1 (nil)
> (nil))
>
> (insn 11 9 12 (set (reg:SI 16)
> (mem:SI (reg:SI 9))) -1 (nil)
> (nil))
>
> (insn 12 11 14 (set (reg:SI 13)
> (plus:SI (reg:SI 16)
> (reg:SI 15))) -1 (nil)
> (nil))
>
> (insn 14 12 16 (set (reg:SI 13)
> (reg:SI 13)) -1 (nil)
> (expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 9))
> (symbol_ref/v:SI ("__clz_tab")))
> (nil)))
>
> KM
>
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting GCC
2001-02-01 3:10 ` Richard Earnshaw
@ 2001-02-02 3:43 ` Krzysztof Matula
2001-02-02 4:00 ` Richard Earnshaw
0 siblings, 1 reply; 28+ messages in thread
From: Krzysztof Matula @ 2001-02-02 3:43 UTC (permalink / raw)
To: gcc
----- Original Message -----
From: "Richard Earnshaw" <rearnsha@arm.com>
To: "Krzysztof Matula" <km@taboo.eu.org>
Cc: <gcc@gcc.gnu.org>; <Richard.Earnshaw@arm.com>
Sent: Thursday, February 01, 2001 12:09
Subject: Re: porting GCC
> > I am extending one of GCC ports an I have the following problem:
> >
> > I need to detect all references to to objects in data segment
(SYMBOL_REF/v)
> > and modify rtx in such way, that the segment base address is added to
the
> > offset (represented by the symbol itself). Generating such rtx is not a
[...]
> > I think I have to flag the rtx generated in define_expand in some way
and
> > setup the predicate used in define_insn to reject unflagged symbol
refs...
> >
> This is similar to the problem faced by many ports when generating PIC
> code. The normal approach is to wrap symbol refs in an UNSPEC and then
> restrict the recognizer rules to only allow such wrapped symbols. Take a
> look at how other machines handle this case for PIC.
It worked :)
But soon I reached another problem...
I am generating several insn-s inside define_expand. The meaning of the code
is not exactly the same, as the rtl matched. The problem is that GCC always
notes the last insn I generate with REG_EQUAL expression, corresponding to
the ORIGINAL code... I don't know how to avoid this...
(insn 9 8 11 (set (reg:SI 15)
(plus:SI (reg:SI 14)
spec:SI[
(symbol_ref/v:SI ("__clz_tab"))
] 3))) -1 (nil)
(nil))
(insn 11 9 12 (set (reg:SI 16)
(mem:SI (reg:SI 9))) -1 (nil)
(nil))
(insn 12 11 14 (set (reg:SI 13)
(plus:SI (reg:SI 16)
(reg:SI 15))) -1 (nil)
(nil))
(insn 14 12 16 (set (reg:SI 13)
(reg:SI 13)) -1 (nil)
(expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 9))
(symbol_ref/v:SI ("__clz_tab")))
(nil)))
KM
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: porting GCC
2001-02-01 2:37 porting GCC Krzysztof Matula
@ 2001-02-01 3:10 ` Richard Earnshaw
2001-02-02 3:43 ` Krzysztof Matula
0 siblings, 1 reply; 28+ messages in thread
From: Richard Earnshaw @ 2001-02-01 3:10 UTC (permalink / raw)
To: Krzysztof Matula; +Cc: gcc, Richard.Earnshaw
> Hi!
>
> I am extending one of GCC ports an I have the following problem:
>
> I need to detect all references to to objects in data segment (SYMBOL_REF/v)
> and modify rtx in such way, that the segment base address is added to the
> offset (represented by the symbol itself). Generating such rtx is not a
> problem, but I don't know where to connect this. In the code I am extending
> such replacement is made in two "define_expand"-s. One of them looks like
> this:
>
> set(reg)(plus:SI((general_operand)(general_operand)))
>
> As a result new rtx is generated that takes the segment base address and
> adds a symbol offset:
>
> set(reg)(plus:SI((reg)(SYMBOL_REF)))
>
> ...such rtl matches one of the "define_insn"-s.
>
> The problm is that sometimes during optimizations GCC creates exactly the
> same rtl, and it matches the same "define_insn" without going through
> "define_expand". The rtl modification for proper data segment access is not
> performed...
>
> I think I have to flag the rtx generated in define_expand in some way and
> setup the predicate used in define_insn to reject unflagged symbol refs...
>
> Is that the right way??? If so, how can I flag the rtx??? Or, maybe I should
> do this in a different way???
>
> KM
>
>
This is similar to the problem faced by many ports when generating PIC
code. The normal approach is to wrap symbol refs in an UNSPEC and then
restrict the recognizer rules to only allow such wrapped symbols. Take a
look at how other machines handle this case for PIC.
R.
^ permalink raw reply [flat|nested] 28+ messages in thread
* porting GCC
@ 2001-02-01 2:37 Krzysztof Matula
2001-02-01 3:10 ` Richard Earnshaw
0 siblings, 1 reply; 28+ messages in thread
From: Krzysztof Matula @ 2001-02-01 2:37 UTC (permalink / raw)
To: gcc
Hi!
I am extending one of GCC ports an I have the following problem:
I need to detect all references to to objects in data segment (SYMBOL_REF/v)
and modify rtx in such way, that the segment base address is added to the
offset (represented by the symbol itself). Generating such rtx is not a
problem, but I don't know where to connect this. In the code I am extending
such replacement is made in two "define_expand"-s. One of them looks like
this:
set(reg)(plus:SI((general_operand)(general_operand)))
As a result new rtx is generated that takes the segment base address and
adds a symbol offset:
set(reg)(plus:SI((reg)(SYMBOL_REF)))
...such rtl matches one of the "define_insn"-s.
The problm is that sometimes during optimizations GCC creates exactly the
same rtl, and it matches the same "define_insn" without going through
"define_expand". The rtl modification for proper data segment access is not
performed...
I think I have to flag the rtx generated in define_expand in some way and
setup the predicate used in define_insn to reject unflagged symbol refs...
Is that the right way??? If so, how can I flag the rtx??? Or, maybe I should
do this in a different way???
KM
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2008-10-20 19:34 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-12 6:11 Porting gcc Schmave
2008-03-12 6:15 ` Ben Elliston
-- strict thread matches above, loose matches on Subject: below --
2008-10-20 10:20 porting gcc Aurélien Buhrig
2008-10-20 19:34 ` Ian Lance Taylor
2004-06-04 15:24 Porting GCC Gyle Yearsley
2004-06-02 16:49 Gyle Yearsley
2004-06-03 15:38 ` Richard Sandiford
2004-05-21 13:09 Porting gcc Mile Davidovic
2004-05-21 13:43 ` Dave Korn
2003-08-13 11:15 Petar Penchev
2003-08-13 16:07 ` Ben Elliston
2002-10-22 9:53 porting gcc Grégoire Dooms
2002-10-22 9:56 ` Grégoire Dooms
2002-10-22 14:40 ` Mike Stump
2002-10-22 14:43 ` Andrew Haley
2002-10-22 15:16 ` Michael Matz
2002-10-22 15:27 ` Svein E. Seldal
2002-10-22 18:02 ` Mike Stump
2002-10-23 10:05 ` Andrew Haley
2002-10-22 15:50 ` Denis Chertykov
2001-02-15 8:41 Filippo Basso
2001-02-15 9:50 ` Fergus Henderson
2001-02-01 2:37 porting GCC Krzysztof Matula
2001-02-01 3:10 ` Richard Earnshaw
2001-02-02 3:43 ` Krzysztof Matula
2001-02-02 4:00 ` Richard Earnshaw
2001-02-02 6:07 ` Krzysztof Matula
2001-02-02 7:08 ` Richard Earnshaw
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).