porting gcc

porting gcc

[Grégoire Dooms]

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.

porting gcc

[Grégoire Dooms]

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.

Re: porting gcc

[Mike Stump]

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.

porting gcc

[Andrew Haley]

=?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.

Re: porting gcc

[Michael Matz]

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.

Re: porting gcc

[Svein E. Seldal]

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

Re: porting gcc

[Denis Chertykov]

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.

Re: porting gcc

[Mike Stump]

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.

Re: porting gcc

[Andrew Haley]

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.

Re: porting gcc

[Ian Lance Taylor]

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

porting gcc

[Aurélien Buhrig]

Hi,

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?

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

Re: Porting gcc

[Ben Elliston]

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

Porting gcc

[Schmave]

Hi I would luke to know what I need to do to port gcc to a new  
architecture

Thanks

RE: Porting GCC

[Gyle Yearsley]

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

Re: Porting GCC

[Richard Sandiford]

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

Porting GCC

[Gyle Yearsley]

> 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
> 
> 

RE: Porting gcc

[Dave Korn]

> -----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....

Porting gcc

[Mile Davidovic]

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

Re: Porting gcc

[Ben Elliston]

"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

Porting gcc

[Petar Penchev]

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

Re: porting gcc

[Fergus Henderson]

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.

porting gcc

[Filippo Basso]

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

Re: porting GCC

[Richard Earnshaw]

> ----- 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.

Re: porting GCC

[Krzysztof Matula]

----- 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

Re: porting 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
> 
> 
> 

Re: porting GCC

[Krzysztof Matula]

----- 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

Re: porting 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.

porting GCC

[Krzysztof Matula]

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