[LIR Compiler]Bison Works, Finally

I finally got Bison to work for the first time for LIR Compiler.
The error was in the makefile itself - a statement, though incorrect skipped my notice since it worked for the earlier version using only flex.
What I was doing for making main.o was -
$(CC) $(CFLAGS) $^ -0 $@.
where the dependencies were a .cc file, and a library.
Due to a strange coincidence, this makefile worked fine with my earlier attempts using only flex. With bison also included, things got a little messier, since I had to include the token header tok.h in the dependencies for main.cc. The above line broke down in that case.
The remedy was to replace this line with what should have been there in the first place -
$(CC) $(CFLAGS) -c main.cc -o main.c

and then, include the other libraries in the linking phase when all the .o files were linked.
The makefile and compilation process is starting to make more sense now, although I still don't know what lies inside the .a files.

Once the build is working fine, remains the task of building the parser, which is the fun part. So I should be making good progress with the project in the coming days.

Updates

I have been trying to get Bison to work along with flex using the basic 4 line snippet that was used initially, but I haven't had much success. I haven't been able to devote much time to the project, since nearing the end of the semester, all projects in the curriculum are in a kind of rush, plus alot of practical vivas and presentations are due. I will try to get some time and write some code this weekend, but the coming month is going to be very hectic.

Updates - LIR Compiler

I am currently reading on Bison. I have today and tomorrow off, so I can get alot of reading done in these two days, and hopefully I have sufficient skills to write the parser.
I am really enjoying reading Bison - the way it parses is very natural yet error free.

Name Directory - Beta Implementation

So after about 4-5 hours of slogging it out to implement the Name Directory I mentioned in my previous post, I got its working implementation, in a not so beautiful piece of code, but it works!
Take this LIR snippet for instance -

start
two = int 2
twoPlusTwo = add two, two
three = int 3
threePlusThree = add three, three
five = int 5
fpf = add five, five
threePlusFive = add three, five
ret threePlusFive

It uses three named immediates, two, three, and five, alongwith other values calculated upon using these immediates. From the parser now, you can reference any value(which should have been the case in the first place), from anywhere in the snippet, and use it. For example, here, we use immediates three and five in threePlusFive, and return that value. The earlier problem of the most immediate result staying in the result variable has also been removed. The parser scans the named variable in the directory, and if found, returns it.

I will illustrate this with another example.Take this LIR for instance -

start
two = int 2
twoPlusTwo = add two, two
three = int 3
threePlusThree = add three, three
five = int 5
fpf = add five, five
threePlusFive = add three, five
temp = add threePlusFive, three
ret temp

As it should, the temp variable returns 11.

The code snippet can be found here.
Would surely love to hear on this.

Name Directory

I am currently trying to implement a name directory - basically, each expression in JIT is named. It is customary to implement a name(label) array, linked with the expression value, so that whenever a label is referenced, it can be searched within that array, and if found, the resulting expression can be used in the context of the call.
I am basically trying to get this LIR snippet to work -

start
two = int 2
twoPlusTwo = add two, two
three = int 3
threePlusThree = add three, three

ret twoPlusTwo

The current version of the parser will return the output from the latest computation only, since it uses only one variable. What needs to be done is usage of a name directory - whenever an instruction like two = int 2 is seen, or in general,
[a-zA-Z]+" = " are expressions of the assignment form. On seeing this, the parser should create an entry in the directory with this parameter name if it doesn't already exist, and then write the corresponding expression value in the parameter value array. If the value exists, the new value should be overwritten.
Hence, searching must be implemented so as to figure out whether a given value exists or not.
As for the return statement, it must return a variable name. Hence, searching must be employed there as well, to search for the given parameter name, and if found, the desired value is returned via the LIR_ret command, otherwise, an error occurs.
This is the basic outline I will try to implement currently.