Friday, April 29, 2005

Proposal?

The first time I saw you, I saw all stars
I was all woozie, I had the symptoms of SARS
My heart skipped a beat, I was warm and blue
It was then that I realized, I had the bird flu

On my heart you did a dlopen,
I found myself in 64-bit heaven
You've instrumented me, each and every line
Now all I need is a UI and win32 runtime

Without you, I am not complete,
You make my life a never-ending treat
By the gods of Linux, AIX and Solaris, show me the light
Will you be the kernel of my life?


---

Our gang collectively came up with this as a geeky proposal!

I wonder?!

I'm just wondering if data cache management can be made in a simple yet appealing way. Usually the cache usually maintains data in fixed sized pages so that the cache hit ratio is increased. When a request for even 1 byte comes, the whole page containing that byte is brought into the cache. This is usually done keeping in mind the principle of locality of reference. There's a likely chance that the forthcoming requests also want data within that page. Could this be made any simpler from an implementation point of view.

Lets say that we're really not bothered about the exact data. What we maintain in cache is just the addresses that are accessed. The request whose address is in the cache results in a cache hit and those which are'nt result in a cache miss. So, to implement this paging of the cache data, I use only the address range of a page in the cache. For example, if I assume the page size to be N Kb, then for any request that wants data from an address X, I just round off the address to the next N Kb aligned address. This is the higher end of my range. Subtract N Kb from this, now I have the lower end of the page range. The table itself can be implemented for fast lookup. I think that even though it eventually does the same thing as any other cache would do, this is a lot simpler from an implementation point of view.

split personality

...
He peered through his heavy eyelids to get a glimpse of the clock. It appeared to be 10:10. He finished the rest of the beer in the mug in front of him in a gulp and tried to get up. His own body seemed heavier than usual. Almost to his feet, he tripped and fell down. He could see images flashing in front of his eyes. He forced his eyes shut to send them off. No, they're still there. Now you see it... now you don't... its back, now you see it... oh no gone again... now you dont. Like an intermittant power failure, the flickering images danced in front of him. Eventually they faded away. He strolled down in a zig-zag trail to a nearby park. The night was silent. But he was keeping his ears closed. Sounds inside his head saying all sorts of things. His children crying, neighbours shouting all unpleasantries at him, and a lot of other scrambled noise.

"You did all this to yourself"
"Daddy don't leave us please"
"You stinkin rotten head of man..."

He was walking in circles, his step faltering every now and then. The path turned spiral and finally he collapsed on the grass.

3 hours later, he woke up with a start. There was a definite air about him. No longer was the indecision and confusion visible in him. He appeared completely in control of him. He got up and went away briskly...

...

Wednesday, April 27, 2005

He's here!

He came back from USA on monday night
He is extremely restless and cute!
Sleeps every half-hour for an hour and plays for the next one hour
Totally comfortable with strangers
Likes to be left on his own every now and then

Welcome my 8 month old nephew - Mukul!

Monday, April 25, 2005

Priority Vs Option

Don't make someone a *priority* who only makes you an *option*...

Read this line somewhere - seemed true to me - I mean a sensible thing to a rational mind. Or may be too rational. Its just a thin line that seperates a priority and an option. A priority must start out as a option. So, when you think that someone is a priority, it means that you've crossed the line bordering an option and priority. There might be a delta time difference between when the other person also might start thinking of you as a priority. Reminded me of the classic problem with a SMP system. It all boils down to the policy implemented by the scheduler to avoid spinlocks as far as possible. Well, let me not get into that. Basically, making a statement is like establishing a policy and how it is actually observed or put into use in the mechanism. And as most operating system books say - One must always seperate mechanisms from policies.

I've again succeeded in taking a philosophical point into the technical realm. Sorry for all you frustrated people - But then, this is just ME!

As I sat by the window
and gazed at the rain
with an ache in my heart
but never feeling the pain

If you would tell me
just what my life means
walking the long road
but never reaching the end...

Friday, April 22, 2005

Musings of a diverted mind

Okay, here I am at a training that's teaching me internals of the linux kernel implementation. Its almost 2 in the afternoon and the lunch break is about to end. I had lunch at the cafeteria with 2 people who were also from my building. Today is the last day of the training. There are some things that I learned apart from the course content.

1) Geeky people are cool (unlike what the general misconception is!)
2) Complete fugitives wrt humanity are more likely to find it easy to make aquaintances
3) Dark and mysterious nature is actually considered a turn-on
4) Making money on SP road, right beside the cheap hardware vendors is a matter of minutes if you know how to write simple device drivers in linux (contact me for more details on this!)
4) Last but not the least, I lost most of my respect I had towards malloc

Meanwhile the kgdb session has started and my mind has been brought back forcefully... ciao then!

Paranoia

There's something about linux kernel developers that puts them in a completely different league with all the aura around them. And, mind you, they really deserve every bit of that. They look upon their work as a divine creation and seldom tolerate the kernel being meddled around with in ways that are deemed unacceptable. The GPL is the most sacred thing that they look upon.

It is said that there are two categories of kernel developers.

1) Paranoid
2) Really paranoid (!!)

For guys writing linux device drivers, this might have beome evident. Any person who writes driver code without going under GPL, will have no support whatsoever from the kernel developers. More so, the kind of mockery you get when you load your module onto a running kernel - "tainted" - that's the word! The kernel would complain that its got tainted by a non-GPL module! And if your module crashes the kernel either due to a bug in the module or a bug in the kernel things would get even more troublesome. Suppose that a guy suspects that a kernel bug caused the crash, a bug filed against the kernel would not get more than a glancing eye by the "paranoid" group. And you might actually be flamed for filing a bug by the "really paranoid" gang!

Everyone's for a free world

Not alone with a dream
Just a want to be free
With a need to belong
I am the clansman
Freedom! Freedom!

Saturday, April 16, 2005

Deal?!

He was pacing impatiently on the desolated 13th floor of the new venture of Straumberger developers. It was unusually quiet that afternoon. As he was walking back and forth the long, unfloored corridor, all the old memories came rushing to his head. How he had absolutely enjoyed the media limelight and the flashing cameras. All the deafening noise that erupted when he made his signature entry onto the stage with a loud riff of his guitar... Patrick Jones was a very popular member of the forgotten band called Unforgotten. "WAS". It was almost 15 years ago but it all seemed like just yesterday to him.

'Why does Mr.Straumberger want to see me? Its making me nervous. Why.. WHY?!'.

He could not stop thinking, for, Mr.Straumberger was one of the most influential people in Germany. He had had Patrick picked up from his apartment in Austin, Texas in the middle of the night. Mr.Straumberer also had a good hand in the German underworld, or so the talk around the town said. He was interrupted by the screeching sound of the metal lift. As the door made way, He could see 4 heavily built people escorting a burly aristocratic man. Behind him was a man walking with a great swagger carrying a long case. Mr.Straumberger was burly and very snobbish.

'Hello Mr.Jones' said Mr.Straumberger in his curt professional tone.

'Mind telling me what this is all about?!' retorted Patrick. His eye constantly on the large case. 'Was it a rifle, a dragunov perhaps?!' he thought. His manner was very obvioulsy showing nervousness.

'Relax Mr.Jones. We just want to make a deal with you' said Mr.Straumberger with a gleam in his eyes.

'What sort of a deal?' inquired Patrick with raised eyebrows...

The guy writing all this had a wry smile on his face... :-)

Tuesday, April 12, 2005

Dependent name look-up

Yay! Learned something new. I came across this in the comp.lang.c++ newsgroups. One of the murkier corners of C++ I must say... Just for redundancy, I'll retype the snippet here...

template < typename T >
class A {
  protected:
    T n;
};

template < typename T >
class B : public A< T > { // A partial specialization
  public:
    void func() {
      n = 10;
    }
};

int main()
{
  B< int > obj;
  obj.func();
  return 0;
}

The problem here is that the compiler does not know anything about 'n' within the function 'func'. Why? This has something to do with the template instantiation. A template class is never instantiated unless there is a particular instantiation object that comes into the picture. So, only when the compiler sees 'B obj;' it creates an instantiation of class B with specialization for an int. But what seemed somewhat queer was that while instantiating class B for int, the compiler would face the public derivation from A. Then why is not class A instantiated for int?! The newsgroups say that in case of template classes the base class is not searched for dependent names' look-up. It also provides a solution for such a scenario.

using A< T >::n;

This statement within class B would resolve the problem.

Its a sea out there!

Open (the) house?!

3 days of STSD open house. This event promises to achieve constructive interaction across different labs and getting hands-on experience with cutting edge technology that the respective labs are working on. Or so the organisers say...

I don't know the story from other labs. But the way its being organised here is not upto the mark. First of all it was a rather short notice for the people who'd be doing the presentations and demos. Then there were 3-4 "train the presenters" meets - all ending up with more questions than answers. The event starts tomorrow, and the people who are to conduct the demo are frantically going thru a document that gives step-by-step instructions as to how to use the different management applications. Also, the setup that is to be used for the demo is not a test setup but is an active setup that other people would be using for development and testing while the demo would be going on. One minor mistake could lead to those dev people chasing us down lavelle road!

I've got no words to describe this sort of event organisation.

I don't need no civil war...

P E A C E

Monday, April 11, 2005

Alloc callo(u)sness

For folks migrating from the realms of C to the expanse of C++ - don't be surprised if you seldom see malloc, calloc, realloc and free. The substitutes are new and delete. The key difference is while the alloc family are usually library level routines, new and delete are a language feature(They are 'operators' andnot functions).

Okay - Even beginner C++ programmers would know the usage of new and delete.

// C style
int * ptr = (int *)malloc(0x100000 * sizeof(int));

// C++ way of doing the same
int * ptr = new int[0x100000] ;

Notable differences between the 2 usages are -
1) No need to cast the pointer to appropriate type incase of new.
2) No need to specify the size of the type in case of new.

Pretty easy - huh?! Yes - that's all there is to that.But, if you're a seasoned C programmer, you'd definitely protect yourself from the untold misery of allocation failures by checking the pointer against NULL.

// C - I don't want to fall into a pit!
if( !ptr )
{
  // Sorry mate! Allocation has failed
  // Do the needful
}

Its the same in C++ too. Gods did not empower the language with unlimited memory space. Its the machine that the program runs on that its dependent on. But the way this is notified is by throwing an exception of type 'std::bad_alloc'. If you want to be safe,you'll have to catch that exception and deal with it.

// C++ - exception handling
try {
  int * ptr = new int[0x100000];
} catch( std::bad_alloc )
{
  // Alloc failed
  // If we can't do anything - propagate the
  // exception along. It'll cause an abort
  // down the line...
  throw;
}

"Hey this trying to allocate, catching an exception,handling it, if not propagating it, seems to be quite complicated for me. Is there something simpler?!" Yes there is. You know, you might be right. Exception handling can be quite expensive due to the unwinding semantics. Even I don't know what it means or does. Actually, before exceptions, this was the way, failed allocations were to be handled.

// C++ - older C style handling
int * ptr = new (std::nothrow) int[0x100000];
if (!ptr )
{
  // Same as C style handling!
}

Well - this is simple enough. Even though this is just a minute detail, not many people tend to know this.Well - now they do :-)

No leaf clover


...
Then it comes to be that the soothing light at the end of the tunnel, is just a freight train
coming your way...
...

Thursday, April 07, 2005

Constant confusion

There's so much confusion about const variables in C++. Yeah, they're meant to remain constant throughout their existance. But some people can always find smartass ways to fool the custodian compiler.

const int a = 10;
// Hey guys, I'm const. No one can ever change me!

"Just you wait const a, you won't be const anymore when I'm through with you! Just you wait and see!!!!"

int *ptr = const_cast< int * >(&a);
*ptr = 20;
// na na na naaaeh - You're modified dude!

"What's this guy trying to do?! He must be crazy to think that he can modify me! A const variable. Just wait till you see him watch the results :-)"

std::cout <<  a;

"What the faaak??!! It must have been 20 and not 10!!!! How the hell can this be?!?!"

Simple. Usually the compilers never allocate memory for const variables. They're held in the compile's symbol table. But when some smartass takes the address of a const variable, the compiler just allocates an int and provides him with its address. Just because the compiler provided you with a pointer to the const variable does not mean you can alter the const variable itself. All accesses to the const variable are substituted by the value held in the compiler symbol table and not the memory location that you managed to get. To be more precise, this kind of a thing is undefined behavior. You canNOT take a pointer to a const variable and hope to alter its value and get away with it all the times.

std::cout << *ptr;

This would give you the altered value(20). But most compilers guarantee constness of the variable if the access is made strictly thru the same variable and not the pointer to it.

Hope most of the confusion is cleared?!
Btw who am I telling this to?! :-)

PS: This has been tried with the GNU C++ compier ver-2.96 and with the Microsoft optimising C++ compiler ver-13.10.3077.

Tuesday, April 05, 2005

Efficiency maniac

I could be such an efficeincy maniac at times!

Valuable lesson for someone who's teaching/guiding
people in programming. Don't stress too much on
efficiency. So much so, it blinds people into a frenzy
where they can't see correctness before efficiency.
What's the use of a highly efficient code that does not
do what is expected?!

Look at this girl... I give her an assignment to write
some code that would poll for a signal on a bus and notify
the client. There already was some code in place that was
doing the polling stuff - only thing she had to do was to
write the partthat notifies the client. The only grave
mistake that I did was to ask her to keep an eye on
efficiency! Damn me!

// code that was doing the polling...
extern volatile UInt8 *isrSigTable;
// ...

UInt8 sigMask;
for(UInt8 step = 0;
    step <= MAX_INTERVAL;
    step += pollInterval
   )
{
  sigMask = reinterpret_cast< SigTable >(isrSigTable[0x10]).mask;
  // do other necessary stuff...
}
As per my instructions, she gave more than an eye
towards this piece of code and changed it to...

// code that was doing the polling...
extern volatile UInt8 *isrSigTable;
// ...

UInt8 sigMask = reinterpret_cast< SigTable >(isrSigTable[0x10]).mask;
for(UInt8 step = 0;
    step <= MAX_INTERVAL;
    step += pollInterval
   )
{
  // do other necessary stuff...
}

No PhD required to say that the code won't work as
expected. I must hand it to her for recognising what
might look like a loop invariant. But in an embedded
interrupt driven environment and when the variable
is declared volatile, shewould have been better off
without taking pains to optimise it. You tell the compiler
- "Don't you look at that for anyo f your darn optimisations",
and you go and do it yourself?!

"Just a suggestion - listen to some heavy music while
coding. Research has it that it enhances awareness and
concentration. I've got a CD if you want...". I told her this
jokingly - did not want to tell all that's said above to her.
She's still a student - I was the same a year ago. But it
feels good to be guiding students. I've always liked it. :-)

Sunday, April 03, 2005

Experiments of a techie mind...

Yey!

Got a spare 2G hard disk which I decided
to use for testing purposes. A very ambitious
idea is to make a minimal filesystem
implementation. Now I am frantically searching
for my OS book. To begin with, I decided to
write a generic free pool manager. Pretty
simple linked list implementation.

Half-Me: No wait! This might not be very efficient.

Other half: Okay, let me templatize this thing so
that it'll work with any sort of
linked list implementation.

Half-me: Sounds good. As one of the specializations,
Make a bitset implementation of the list.

Other half: Great idea. Man! Where were you all
these days?!

That was me conversing with myself :-)

So now I have a List template class. And 2
specializations. One is a normal PointerList
that makes use of pointers as iterators. Other
is a BitList using std::bitset to use memory
sparingly. And I wrote a test program to test
all the functions of both specialized classes.

Something seemed wrong! While debugging...

Me: Okay, until here its ok. Lets step into
this PointerList::getNumNodes() function.

Debugger: Hello Srinivas. You're now in
BitList::getNumNodes() function.

Me: Aye?! You must be mistaken. I've called
it from a PointerList object. Lets try
again...

Debugger: Hello Srinivas. You're now in
BitList::getNumNodes() function.


Me: What the !$#@%$^&%$@?!?!

Half-me: Wait dood! Remember what the MSDN
blog said. If two function are
similar, the compiler could have
generated only a single copy of it
and the debugger can show any of
the function names.

Other half: Ya. Thats right. You know, this
might be a design flaw. If both
functions are similar, I can move
it to the super class. Silly me!

Now the stuff is working as expected. Still
have not thought about what to tackle next.
Probably the allocation manager.

More later.