Pass#2 half finished

I’ve been working hard on CoolBasic V3 for the past few months. I have a regular job (as a programmer), so development time limits to weekends, evenings, and nights. Basically, I spend around 4-5 hours on average developing the CoolBasic Compiler every day, 8-12 hours aday during weekends and hallows. That being said, I thought that some vacation coudn’t possible be bad at all… So I kept 4 “days off” during the Easter, trying to clear my mind. But still I’m getting the feeling that I’m slacking. I finished the Expression Processor the day after I returned. As you may recall, I characterized this entity as for being the most complex procedure of the entire compiler so far. I’m very pleased that this enormous job is finally done. A few small things still remain to be taken care of, like handling access to Shared members and verifying legal type casting, but the outlines are now solid and the system seems to be working with the current (fairly sophisticated) algorithm.

There’s also something special worth mentioning: While I was creating the latest back-up copy, I noticed that there’s now exactly 1 Megabyte of pure source code. That means roughly 1 million key strokes! To visualize, count to 100 in your mind as if you were typing relatively fast. When you’re done, imagine to do it again for 10,000 more times! Yep, that’s a lot of code! Now, one could think that this can be explained with extensive copy-pasting, but that is not the case; in fact, the compiler architecture is designed to make extensive use of functional approach, meaning that practically speaking all of the procedures are so specialized that they don’t recycle code at all.

To illustrate, remember when I said that the type resolver and the identifier resolver would look alike and function similarly? That was the assumption I had before I actually got started with the Expression Processor. Well that assumption is no more, I turned things pretty much upside-down (there’s a lot more into it for the Expression Processor when compared to the Type Resolver where certain assumptions about the expression’s structure can be made). To sum up, Type Resolver is now fully operational, Name Resolution is now fully operational, Overload Resolution is now fully operational, Constant Value pre-calculator is now fully operational, and semantic checks are nearly finished. I’m also testing an idea of my own, to solve the grouping issue explained here.

One day I was pondering which way would be better. The original approach was to make the compiler a Dynamic Linked Library, but bundle it with a Commandline Compiler (which would ultimately call the DLL anyways). If one wanted to create, say, an own IDE – or just access the compiler without CoolBasic being fully installed, there would be 2 choises depending on the situation and personal preference. However, a DLL cannot write to Standard Output Stream (well, this is actually not true, but there’s another reason why it’s a bad idea to try doing that), so compiling progress would have to either be completely silent, or the compiler would have to create a window equipped with a progression bar or at least a label with a description. Also, what *if* the compiler would crash (which of course doesn’t happen)… the entire IDE would crash, too. On the other hand, A DLL function could return a string with embedded metainfo about the end result whereas an executable can only return an error code back to the system. And then there’s the unpredictable memory and resource management of an attached DLL. Even though the CoolBasic Compiler is very well designed to free all resources after compilation, I’m still hesitating. A safe executable just ends, freeing all reserved memory 100% guaranteed. Going always through the Commandline Compiler would overcome that problem, but what’s the point of a DLL then in the first place?

As it stands now, I think I’m going to end up with Commandline Compiler only (which the IDE will silently call, meaning no visible console window will be created). This way the compiler can message back straight to the IDE, as well as provide with a log file for more details. It will also operate in an independent manner and free all its resources 100% sure. Possible OS porting will be easier in the future, too. There may be some priviledge issues involved, but let’s examine those more closely when the matter becomes more relevant.

Closing words
I’ll tweak the Expression Processor some more by fine-tuning its functionality and fixing any remaining bugs. While anything can always suddenly arise, at this point I’m confident that I can soon start thinking of the next steps. That would be something like processing all those code lines that execute program logic, and to generate appropriate IL for them. I’d say we’re half-a-way into Pass#2 now (and yet Pass#2 has more code than Pass#1 has).

Comments are closed.

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress