Tuesday, May 26, 2009

How to use Loads and Stores in LIR

Well, if you read the Wiki on LIR, and if you aren't previously familiar with LIR, then you might not have gotten the hang of pointers.

Pointers - are like integers in the way that they contain addresses, and can be used anywhere where an integer can(LIR has only one type).
What is different is that you cannot create a pointer(that is get a memory address, unless you are extremely lucky!) by yourself.

Thats where alloc instruction comes in.
Alloc - The wiki will give you the more technical information. Alloc is basically like calloc() in C - it allocates a specified amount of space for your usage later, and returns a pointer to it. Hence the instruction format is:
p = alloc size
Illustration

I will illustrate this with an example straight from jorendorff's desk -
addr = alloc 4;
zero = int 0;
st addr[0] = zero ... (that's roughly how it's intended to be used)
That stores the value 0 at the memory address specified by addr pointer. Now you can load that value into a variable, store another value, etc.


Going one step further, if you allocate 8 bytes of memory
addr = alloc 8;
zero = int 0;
one = int 1;
st addr[0] = zero;
st addr[4] = one;
Note the offset 4 in the second store. The offset is the number of bytes to be offset from the base, as expected.Now, you can load the two bytes in separate variables, or mess up stuff by specifying an offset not divisible by 4!

Having implemented basic loads and stores today, and consolidated my code which looks much more readable now, I am hoping to get information on:
1. Jumps and labels and how to handle those(Are labels solely the responsibility of the parser?).
2. Subroutine calls.
3. Guards

I will go about them in the above order.

Sunday, May 24, 2009

[LIR Compiler]Progress and Issues

I have added support for a number of instructions(mostly, floating points and guards, and 64 bit instructions are left). The project feels pretty robust currently.
I need to add code for reporting errors in a more informative manner(currently, I use the trivial "syntax error at line number ...." format. I will need to look into YYLOC and the related token locating parameters.
Also, I need information on how/what do display as output. Currently, I am using the program here as the base program, and modifying it to suit my needs.
Also, I am not aware how loads and stores work - for instance, what addresses are we providing to the compiler - if we store an integer using store, where is it actually getting stored. Are we directly addressing memory words, or is it stored in some LIns * pointer like other data is stored.

Wednesday, April 22, 2009

[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.

Friday, April 17, 2009

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.

Saturday, April 11, 2009

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.

Monday, April 6, 2009

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.

Sunday, April 5, 2009

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.