Re: Design Considerations of GIMPLE Front End

2010-06-03 Thread Sebastian Pop
Hi, On Mon, May 17, 2010 at 15:15, Sandeep Soni wrote: > Hi, > > As part of GSoC 2010, I am developing a front end for GIMPLE. > You can find the basic theme of the project at: > http://gcc.gnu.org/wiki/GimpleFrontEnd > > One of the most important components in this GIMPLE Front End is to > conve

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Sandeep Soni
On Tue, May 18, 2010 at 8:33 PM, Diego Novillo wrote: > Yup.  This shade of blue can be changed later.  Sandi, let's start > with the S-expression syntax for everything.  Richard is correct in > pointing out that even gimple expressions have metadata associated > with them that will need to be re

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Diego Novillo
[ apologies for the duplicate message. My previous reply was bounced by the ML. ] > On Tue, May 18, 2010 at 10:52, Andrew Haley wrote: >> >> On 05/18/2010 04:05 PM, Dave Korn wrote: >> > On 18/05/2010 15:17, Steven Bosscher wrote: >> > >> >> IMHO, ideally we would have a syntax that is human rea

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Andrew Haley
On 05/18/2010 04:05 PM, Dave Korn wrote: > On 18/05/2010 15:17, Steven Bosscher wrote: > >> IMHO, ideally we would have a syntax that is human readable and human >> writable. S-expressions are not as easy to read for me as something >> that resembles C. > > I'd like it that way too, but I ackno

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Steven Bosscher
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch wrote: > BTW, is it possible today to have a GCC plugin providing a front-end to > GCC? [last time I looked, I believe the answer is no] This is one of the reasons for my patches to better hide the middle-end details from the front ends. Ciao

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Dave Korn
On 18/05/2010 15:17, Steven Bosscher wrote: > IMHO, ideally we would have a syntax that is human readable and human > writable. S-expressions are not as easy to read for me as something > that resembles C. I'd like it that way too, but I acknowledge that it would be more work and it's not me wh

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Richard Guenther
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch wrote: > On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote: >> Hi, >> >> On Tue, 18 May 2010, Diego Novillo wrote: >> >> > On Mon, May 17, 2010 at 16:15, Sandeep Soni >> > wrote: >> > >> > > 1. What should be the format of representation

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Basile Starynkevitch
On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote: > Hi, > > On Tue, 18 May 2010, Diego Novillo wrote: > > > On Mon, May 17, 2010 at 16:15, Sandeep Soni wrote: > > > > > 1. What should be the format of representation of the GIMPLE tuples in > > >text? > > > > I liked Andrew's suggesti

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Steven Bosscher
On Tue, May 18, 2010 at 4:09 PM, Diego Novillo wrote: > On Tue, May 18, 2010 at 09:59, Michael Matz wrote: > >> I don't see how that is much easier to parse compared to >>  i_1 = k_1 + m_1 >>  j_1 = func (arg1, arg2) > > Well, it would make the parser almost trivial to implement.  But you > have

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Diego Novillo
On Tue, May 18, 2010 at 09:59, Michael Matz wrote: > I don't see how that is much easier to parse compared to >  i_1 = k_1 + m_1 >  j_1 = func (arg1, arg2) Well, it would make the parser almost trivial to implement. But you have a point, the only structurally complex objects we need to parse ar

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Michael Matz
Hi, On Tue, 18 May 2010, Diego Novillo wrote: > On Mon, May 17, 2010 at 16:15, Sandeep Soni wrote: > > > 1. What should be the format of representation of the GIMPLE tuples in > >text? > > I liked Andrew's suggestion about S-expressions. I can see that for describing types, maybe. But i

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Diego Novillo
On Mon, May 17, 2010 at 16:15, Sandeep Soni wrote: > 1. What should be the format of representation of the GIMPLE tuples in text? I liked Andrew's suggestion about S-expressions. It looks like a good balance between ease of parsing/writing. We can always tweak the format as we go. As for poin

Re: Design Considerations of GIMPLE Front End

2010-05-18 Thread Andrew Haley
On 05/18/2010 04:24 AM, Sandeep Soni wrote: > On Tue, May 18, 2010 at 2:34 AM, Andrew Haley wrote: > >>>For example: >>>A textual GIMPLE tuple for the statement a=b+c can be like >>>> (As demonstrated by the internal >>> manual also). >>>Is such a representation easy to parse? >>

Re: Design Considerations of GIMPLE Front End

2010-05-17 Thread Sandeep Soni
On Tue, May 18, 2010 at 2:34 AM, Andrew Haley wrote: >>    For example: >>    A textual GIMPLE tuple for the statement a=b+c can be like >>    >  (As demonstrated by the internal >> manual also). >>    Is such a representation easy to parse? > > S-expressions are easier to parse and more compact,

Re: Design Considerations of GIMPLE Front End

2010-05-17 Thread Andrew Haley
On 05/17/2010 09:15 PM, Sandeep Soni wrote: > Hi, > > As part of GSoC 2010, I am developing a front end for GIMPLE. > You can find the basic theme of the project at: > http://gcc.gnu.org/wiki/GimpleFrontEnd > > One of the most important components in this GIMPLE Front End is to > convert the GIMP

Design Considerations of GIMPLE Front End

2010-05-17 Thread Sandeep Soni
Hi, As part of GSoC 2010, I am developing a front end for GIMPLE. You can find the basic theme of the project at: http://gcc.gnu.org/wiki/GimpleFrontEnd One of the most important components in this GIMPLE Front End is to convert the GIMPLE tuples into text. How such a textual representation shoul