The reason why, the already low traffic of this journal has become even lower, is because I'm now doing my phd, which means "slavery made legal" :)

I'm slowly progressing on my beloved vARCH, but it's now taking longer.
I did some structural changes to the memory addressing and instruction coding, which require a major rewrite of the compiler.

I hope I will be able to post about it, and to push upstream the new version!

In the meanwhile, I will keep on fighting against the 3rd party library that I'm using during my PhD :)

Following the previous update: http://genio-del-male.livejournal.com/9372.html

I managed to implement at least the register allocation logic. It works pretty well now. Still I'm not doing coalescing or proper spilling (it just terminates if spilling is required), but in most of the cases, it is enough.

Actually this was a big work, and require one month full time to implement things decently, since I am a beginner in compiler business, and I lost some time on some python tests (about graph colouring).

I added also some utilities (still not usable autonomously), like a debug symbols generator and a partial/simple disassembler.
Everything enabled me to do a good job on the auto allocation logic side.

In future I plan to make the disassembler autonomously usable, and at least implement spilling and coalescing.
The infrastructure is there. I simply need to hook things in it.

In the last 8 months I was not very active on my personal projects, since I've been employed in the software group of the ESRF (Grenoble, France).

When I came back home, I made some nice changes to the new assembler for the vArch project.
As always, you can check them out on: https://github.com/Obi-Wan

The changes can be summarized in two big different chunks:
- Enhanced error reporting infrastructure.
- Added includes, and enhanced flexibility of the assembler.

More useful errors are now reported (still not 100% foolproof but better than before) and made the coding a bit less tedious.
You can now divide code in multiple files, and have globals declared whenever you like, instead of having a strict scheme. Error reporting tries also to cope with enhanced freedom, since freedom means also headaches :)

I don't plan to add new features very soon. However, what I really plan to do is a little step forward the implementation of a real compiler. I won't be doing real syntax analysis, but starting from an Abstract Semantic Tree, or even more roughly from an Intermediate Representation and implement a register allocator, and an instruction selector.
Anyway, I'm not sure yet HOW and WHEN I will do it :)

Cheers :)

Some days ago I noticed that my slim log file: /var/log/slim.log was cluttered by useless and spurious messages from other applications.
In some months it became 626MB large! :-O

Again, after my previous incursion in SLiM code, when I implemented the autologin ( http://genio-del-male.livejournal.com/3301.html ), I was digging in it.

After looking at the logging code, I noticed that slim is reopening stderr and stdout into the log file.
This is one of the most stupid things a programmer can do!
Ever program that was going to write to the stdout or stderr, was going to be logged in the slim log file!!

Many thanks to God, that inspired the authors of logrotate :) but still I don't want my slim messages to be messed up with every sort of shit.

So I posted two patches on the slim patch page: http://developer.berlios.de/patch/?group_id=2663
Issues: 003157 and 003158

This patches, if applied to a vanilla slim 1.3.2 will start to do the right logging.

Sadly enough, the SLiM project on berlios just rarely shows signs of life, and I noticed that some svn changes conflict with my work.
So I now need to sync with SVN and modify my patches in order to apply to slim-svn.

I would also like to add syslog optional support, but the maintainer needs to answer to my emails before I can do something else :)

The initial of the new assembler now works and assembles correctly. On the other hand, the old assembler has stopped working after some changes I made some months ago.

It doesn't worries me: tomorrow (well today, but later during the day: just after sleeping) I'll be fixing (if not too long) the old assembler, and then polish out the new one to be more user friendly.

After that I may publish the new code, and then start working on enhancements like: new syntax (a new assembler format) with more constructs and ability to give directives to the assembler. Basic usage analysis of variables and likes.
I'm not sure about direction to take: I will decide during the work (just like you may deduce from the difference between this and the precious post).

Be ready to check http://github.com/Obi-Wan/vARCH out for updates.

It seems like I'm back on the vARCH project.
I'm spending some vacations in programming... uhm it may seem not so intelligent.
Well I must admit it was too much I was studying just physics: some good old C/C++ programming ain't that bad!

So why Flex and Bison? may I be working on a compiler? no no, I wouldn't be able to finish before the next Sunday, so I'm just rewriting the assembler in a new fashion.
Well, I was quite happy with the old assembler but I took the chance to learn flex and bison, so I tried something I already did, so I was sure to be able to manage it.

It's getting along quite nicely. It's not elegant at 100% now, but I'm still experimenting.
In particular it already generates a proper semantic tree. I should just add code generation phase, and label definition, and it would be ready.

Error handling is quite lacking, but who cares now? I didn't publish any line of code yet!
I will merge it to the code base once finished.
My idea is to keep both the old, completely manually spawned, and the new one; and give the choice to the user.
A mixture of both may happen: it depends on my mood tomorrow :)

It looks like I'll be giving a talk about Parallel FFT to my classmates this Friday morning.
It will give some bonus for the exam of "Advanced Algorithms".

So I had to make some slides about this nice algorithm, and I'm sharing them with you. Unfortunately they're in Italian. If someone is interested, he should just raise his hand and say: "Hey, can you translate them?" and "in harmony with my spare time" I will translate them to English.

You can get them at http://vighy.altervista.org/data/SlideSeminarioFFT.pdf

Have a nice read.

As you may see on my public repository web interface: http://github.com/Obi-Wan lately I've been working a bit on this nice java project: http://github.com/Obi-Wan/cash-desk
I'm preparing it to be ready for "production" in September.

On last September it ran like a charm for 10 days without reported problems. This year I want to replicate.
I've been ironing away some bugs, and I've been working on some new nice (tiny) features.
It should not look so much different from the previous version to an end user, but frankly it's been evolving a lot since last September.

Let's hope it will replicate success.

If you fine some ideas let me know. Meanwhile I would like to produce some documentation, and produce a bit more testing units.

If you ever thought geometric optics ain't that bad, you may be just ignoring how boring and bothering it could be.

It seems clear to me now that opticians (not those that sell glasses :) ) are just translating the length of penis into the length of formulas they use :)

Take for example the gaussian beams, they are the solutions to both an integral and a differential problem of propagation of a beam into a resonant cavity.
Formulas to derive those solutions are enormous and extremely boring.
The thing that I cannot understand is how could some people try to remember them by heart, since they never use them in everyday calculus!!!

Go out and have a beer instead!
(Or if you, like me, don't drink alcohol, go to meet your girlfriend :) )

I'm learning much, learning something I will not probably use in the near future (who knows about far future?)

One of those crazy projects I'm working lately is vARCH http://github.com/Obi-Wan/vARCH

What's that?? simply a virtual machine for a not existing architecture. Nice! :)
You should now ask yourself why would anybody work on something that has clearly no future?
Answer is simple: to learn!!

There's a fundamental difference between theory and practice, and you could know everything on how to handle an interrupt in theory. Now implement interrupts in practice, implement an Assembler, a byte-code interpreter and related virtual devices.

This is what my code does. It's not perfect, it's not complete but it works, well sort of :)
Needs to be improved, needs a compiler needs so many things it's obvious it will never be finished.
What's for sure is that I learned a lot :)