Hi All,

I just wanted to send along a progress report on the new parser. Some
of this may be a repeat from my last email so may be more for me to
keep things clear in my head than for everyone else. =)

Hope this doesn't detract from the 5.03 release coming out which I'm
very happy to see! (Very big thanks all!)

I've gotten a bit further along in getting structs for CSOUND compiled
from the AST, but still no sound.  I spent a good amount of time last
week getting acquainted with more of the internals and how things are
getting setup for the engine to run and am slowly moving along in
getting things compiled.  I haven't touched the parser part in the
past week at all so it is still in roughly the same basic state as it
was.

I've been trying to document all of the functions I've been creating;
this is in hopes that it will be easier to understand and work with
for those who haven't looked at that code or the old parser yet.  I've
also been making notes for myself on what I'm learning from studying
the old parser/compiler in the To-fix-and-do file (for lack of a
better place) as I'm going along which may be of interest to those
interested in getting into the parser.

The new parser/compiler is working a little bit differently than the
old one by parsing to an AST first, then compiling those into INSTRTXT
and OPTXT structs and building the necessary TEXT structs to go along
with those.  Ultimately the new parser should build the same
linked-list/array of INSTRTXT as the old parser for it all to work
with the rest of Csound's Engine, as far as I can tell currently.

The phases of the parsing compiling have been separated into separate functions:

csound_orc_parse - uses Bison to parse the code which Flex tokenizes
to build the AST

csound_orc_verify - still just a stub and might not be necessary as I
think that csound_orc_compile should be able to verify all semantics
are correct as the AST is being built

csound_orc_optimize - still just a stub, but will run down the AST to
perform optmizations; hopes are to be able to look at standard
compiler literature to implement optimizations of the AST

csound_orc_compile - takes the produced AST and compiles down to
structs and sets values in CSOUND *

After this, I am thinking things should be setup to be in the same
state as after running otran in the old parser/compiler.  There is a
csound_orc_load function I put in as originally I thought oload would
need to be redone, but I am thinking that things will be setup the
same by the end of csound_orc_compile as they are after otran, so
oload may be able to be used exactly as-is.  I haven't quite gotten
far enough to really know yet.

For tests I am still using the very basic test.csd file I have here (a
VCO2 outputting to outs).  Most of the work right now is being done in
csound_orc_compile.  As mentioned before, when this test file can
start outputting sound, I am planning to write a test suite to use to
drive the development, adding a new feature and breaking Csound and
then coding until the test will pass.

Also to note, by having the AST, alternative frontend orc languages
could be added with only the responsibility of building a valid AST,
as the rest of the compiler chain would continue to work.

Thanks!
steven

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net