[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: for loops in C style
From: |
Laurence Finston |
Subject: |
Re: for loops in C style |
Date: |
Fri, 29 Feb 2008 12:05:51 +0100 (CET) |
On Fri, 29 Feb 2008, Ilyes Gouta wrote:
>
> > fexpr: /* Empty */
> > {
> > /* Action for empty case */
> > };
> >
> > fexpr: expr
> > {
> > /* Action for `expr' case */
> > };
>
> I wasn't aware the one could duplicate a rule so that it has two
> possible bodies. But it's alright, there is a second, much prettier
> approach.
Duplicating the left-hand side of a rule and using `|' are completely
equivalent. I use the CWEB package for my Bison input files
and have a lot of log entries and TeX code for the documentation, so
the different alternatives can be widely separated in my source
files. I therefore prefer to duplicate the left-hand side. In
addition, there's no rule that says all of the rules with the same
left-hand side need to be consecutive in your input file or files.
>
> > I'm not sure about your `block'. It may make sense from the point of
> > view of a formal grammar, but in practice, it means parsing the same
> > input multiple times. Have you got a solution for this yet?
>
> Well, my purpose is to construct an abstract syntax tree given a
> script. The block rule in may grammar is defined as following:
>
> block: '{' {ctx->scope++;} declarations statements '}' {ctx->scope--;
> fancy_stuff();} ;
Yes, I figured it would be something along these lines. The
consequence is that all your `declarations' and `statements', which
might contain nested loops, have to be processed before the `block'
rule can be reduced. This may not be a problem, but it might cause
stack overflow. I think my way of doing it is simpler. However, it's
not that simple to explain and it's not C-like, so I will just refer
you to previous postings where I have explained it, if you want to
know the details. If you search for "loops" in the archive, you
should find the previous discussions.
> Basically, parsing the input multiple time isn't really an issue for
> my case (actually I don't understand your point here), since what I'm
> doing is just recognizing/reducing the different script components,
> building the ast nodes (filling the right information) and linking
> these nodes properly to form the final tree once everything is reduced
> to the primary block. I've got pretty much everything working (this
> includes nodes for identifiers, unary and binary operations, array
> fetches and stores (indexed accesses), jumps and conditional jumps).
> Once the ast is constructed, I switch off flex/bison and all the
> remaining work is done using that tree, this includes types
> propagation (for the float and int conversions), registers allocations
> and then native opcode emitters.
Oh, I see. I thought you were writing a C-like interpreter that
would actually execute the loop. In that case, you're right, and my
point is irrelevant. I suppose what ultimately gets output is
machine-code or assembler with a branch and a goto for the loop?
Laurence
- for loops in C style, Ilyes Gouta, 2008/02/28
- Re: for loops in C style, Bob Rossi, 2008/02/28
- Re: for loops in C style, Hans Aberg, 2008/02/28
- Re: for loops in C style, Ilyes Gouta, 2008/02/29
- Re: for loops in C style, Ilyes Gouta, 2008/02/29
- Re: for loops in C style, Laurence Finston, 2008/02/29
- Re: for loops in C style, Ilyes Gouta, 2008/02/29
- Re: for loops in C style,
Laurence Finston <=
- Re: for loops in C style, Ilyes Gouta, 2008/02/29
- Re: for loops in C style, lfinsto1, 2008/02/29
- Re: for loops in C style, Evan Lavelle, 2008/02/29