Hi Anthony,

Thanks for the reply! As for the #include and macro system, I am
wondering if we shouldn't make it its own pass, but I would venture to
say probably better to just process it inline like it is doing now.

I haven't really though too deeply about the linecount stuff.  Some
thing tells me we may not need to add the info the the TREE structs as
the parser will detect an error and report as it's parsing, and it
should have that linecount/file struct stack to use to report that.
Need to think about it some more though and I might be off on this. =)

As for dead-code elimination, I think we will have certain limitations
yes, but some things like detecting unnecessary assignments (which
often happens when parsing expressions which may generate unnecessary
temp variables) and things like Istvan's expression-opt (which should
probably be done automatically by the parser) could be detected.  I am
really interested to learn more about SSA
(http://en.wikipedia.org/wiki/Static_single_assignment_form) and
eventually would like to see Csound internally move over to that as it
seems most every compiler these days uses it and we could likely not
reinvent the wheel and use code from other projects to our advantage.

steven



On Dec 12, 2007 6:46 AM, Anthony Kozar
<mailing-lists-1001@anthonykozar.net> wrote:
> Congratulations Steven!
>
> You are doing great work on getting the UDOs and if/thens, etc. working for
> the new parser!  Your tech guide to the orchestra parser is very useful too.
> I have been looking in that region myself recently because of the line count
> issues.
>
> A few comments:
>
> Your tech guide asks whether the orch preprocessing happens in the lexer or
> parser stage.  You may have since figured this out, but it all occurs in
> rdorch.c (rdorchfile) and it seems to trump nearly all other syntax
> structures.
>
> I am thinking that one possible solution for correct error line numbers with
> the new parser would be to add a line count member to every node in the AST
> (and it may be necessary to associate line numbers with every lexer token as
> well).  The reason is that individual arguments to an opcode may be on
> different "physical" lines (or even files?) when using line continuations.
>
> Finally, I am wondering what your thoughts on dead code elimination are?  It
> seems that some opcodes produce side effects other than their outputs (and
> some change their inputs!).  I wonder if this makes dead code identification
> more difficult?
>
> Thanks for all the work!
>
> Anthony
>
> Steven Yi wrote on 12/12/07 3:08 AM:
>
> > I'm very happy to report that after a couple hours of debugging I
> > found out what was wrong with the UDO parsing/compiling with the new
> > parser and the new parser is now able to parse/compile/run with UDO's!
> > This was one of the biggest language features left which I had on my
> > list.
>
> > I have attached a PDF version of a technical document I have been
> > writing as I have been working on the parser.
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net