[fetter-devel] Re: Ping Summer of Code

[Rayiner Hashem]

Okay, I've packaged up the frontend and modified the driver a bit to
print the IR. The output isn't pretty, but its fairly complete. Usage
is fairly simple. Make sure you have the dependencies. I'm using

Debian unstable on amd64
SBCL 0.9.2 for x86-64
cl-s-xml (s-xml XML parser)
cl-asdf (ASDF)
cl-split-sequence (sequence splitting utility)
GCC-XML 0.7-CVS (current CVS version) 

Just uncompress and unpack the tarball, cd into the main directory,
and type 'sbcl --load testsuite/test-basic.lisp'. This will run the
basic test script I've been using, which parses the OpenGL headers.
There is a file testsuite/opengl.binding that holds the config file
for that test. You can modify the script and the binding file to test
other things if you want. It should be robust, but the only things
I've tested it on so far is SDL, OpenGL, and the little test-simple.c
file I have in the testsuite directory.  From an SBCL prompt, you can
also do 'asdf:operate 'asdf:load-op 'fetter' then run
'frontend:create-binding <binding-file>".

A little description of the source tree:

fetter - the main program
fetter/frontend - the frontend code
                  driver.lisp - The overall driver program (like a
compiler driver)
                  frontend.lisp - Various definitions for the
front-end. Contains the IR classes.
                  package.lisp - Definition of the 'frontend' package
                  parser.lisp - The GCC-XML parser
                  simplifier.lisp - The simplification passes
                  utility.lisp - Various utility routines for handling
the L-XML format

The parser is the interesting part, so its worth describing here. The
main function is parse-gccxml-output, which reads the XML file then
calls convert-xml-nodes to convert it to the IR. The conversion
process works as follows:

- There are three main data structures, the ir-index and the
xml-index. Each is a hash-table indexed by GCC-XML 'id' attribute and
mapping to either an XML node or an IR node. The edge-queue is a
vector containing a list of edges that should be added to the IR graph
once all the nodes are constructed. This delayed construction of edges
is necessary because GCC-XML nodes aren't in any particular order.
Thus, when a given IR node is being constructed, it can't count on any
nodes its definition refers to already existing in the ir-index.

- The basic control flow is the dolist in convert-xml-nodes. It goes
through each top-level XML node in the GCC-XML tree, looks up the type
of the element ('Function' or 'PointerType') and calls the appropriate
handler function. The handler map is defined in the big assoc list at
the top of the file. Each of the handler functions create an IR node
corresponding to the XML node, and queues any edges that will exist in
the graph in the edge-queue.

- Once all the nodes are converted and entered into the index, the
function build-graph connects all the nodes with the edges specified
in edge-queue, creates a root node, and adds an edge from that to the
root namespace. It then returns the root node.

- The indices (ir-index and xml-index) are not exposed to anything
outside of the parser. Their view of the IR is just a pointer to the
root node.

Well, that's that. Please contact me if you have trouble with anything. 

Sincerely,
    Rayiner Hashem

On 7/29/05, Kenny Tilton <ktilton at nyc.rr.com> wrote:
> 
> 
> Rayiner Hashem wrote:
> 
> >Sorry for being dodgy with the e-mails the last several days. I'm kind
> >of in a finals crunch and have been almost living in the library. I'll
> >be 100% free after the beginning of next week as soon as they're over.
> >In any case, I'll send you and Luis a copy of the front-end as soon as
> >I have time to go home and package things up. Probably Friday evening,
> >after classes and review sessions...
> >
> OK. Keep me posted. Thx.
> 
> kt
> 
> 
> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fetter-frontend.tar.gz
Type: application/x-gzip
Size: 85821 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/fetter-devel/attachments/20050730/557c21b8/attachment.bin>