Let me come back to my original question.



As it is a binary shift operator we are working at a binary level. So if I take a look at 1<<12 which is approximated to 4096.

Let me explain what is happening.

Consider a number lets say 17, its binary representation is as below

0000000000010001

in a 16-bit form.

Now when we preform a shift we move the binary along 1 position. So if we shift 17 by one we get this,

0000000000100010

Which is doulbe 17 so 34. The shift i have just described would be done like this in C
so back to above code, 1<<12.

We start with the number 1, which in a 16bit binary value looks like this

0000000000000001

then we shift it by not 1 place but 12 places to the left

0001000000000000

which is the number 4096

What I am not getting is why is this number 4096 chosen here.

First of all, the word "approximated" is wrong. 2 ** 12 is exactly 4096.

Second, you are too fast jumping to particular value of 4096, and, I think the answer to the question why is it 4096 and not something else is elsewhere - probably in the protocol/algorithm which is supposed to be implemented by the code.

The question why 4096 was written as 1 << 12 still stands, and there are at least two possible (opposite) answers:

1. bad style;
2. good style.

The choice depends on the limitations (if any) on 'loops_per_jiffy' value, i.e. whether there is or not a requirement for 'loops_per_jiffy' to be a power of two.

Ok I shall search more on this though had searched I am yet to find the reason may be some one else can reply here.

Come to the second line

What is this line trying to do?

Do you know what, for example, the following mean:

?

If not, just grab a "C" book/tutorial and learn. All my three examples, as well as your

are of the same kind/essence.

No
I asked that while loop it is counting time till the value in loops_per_jiffy is zero
what I mean to ask is why is this condition being used here what purpose is that serving.What I understood from the program was it is reducing the
by shifting all bits left till the variable is zero all in each iteration but why is this variable being reduced and what logic is working behind so?
Is it trying to count time the timer has ticked 4096 times?
If so why?

The discussion up to this point looked confused enough that I think you are now asking the wrong questions.

So rather than answer those specific questions, I will quote the important lines of code that I think are confusing you and explain the aspects of them that I think (based on the thread up to this point) you don't understand.

If you still have specific questions after that, I can try to answer:


(1 << 12) is one doubled twelve times, which is exactly 4096.
The word approximation in the comment does not mean (1 << 12) is an approximation of 4096. It means 4096, which is the same as (1<<12) is a first estimate at the value of loops_per_jiffy. "Approximation" is being misused. "estimate" would be closer to the intended meaning.

4096 was chosen because it is a power of two and because the author thought it was a small enough power of two for this use (if the correct result were less than 4096, the loop would keep 4096 instead of the correct result). 4096 was written as (1<<12) to make clear which power of two it is.

First (loops_per_jiffy <<= 1) means to double loops_per_jiffy.
Second, the loop is ended when that doubling overflows, so that the result is zero. But that does not represent the normal termination of the loop. The loop is intended to be terminated by the later break instruction. The zero check is just a safety to avoid an infinite loop.

That means that it breaks out of the loop when the value of loops_per_jiffy is too large, meaning a __delay(loops_per_jiffy) took more than a tick.

So the loop normally computes the lowest power of two that is too big to be the correct loops_per_jiffy.

Then it cuts that in half, computing the power of two that is almost big enough to be the correct loops_per_jiffy.

Hat off to johnsfine ... very informative explanation. Thank you for bringing the discussion back on topic (I hope)

Thanks your explanation made sense and solved most of my doubts.
This is the original link from where it had started
http://kerneltrap.org/node/6857
Shall I put specific questions here in the same thread or a new thread.All that section of program was from
http://lxr.linux.no/#linux+v2.6.33/i...librate.c#L142
Right now I was not clear as between two timer ticks how does the kernel get the signal from.

I mean count of jiffy which is increasing with a frequency HZ
how is that detected by the kernel from hardware? If its reading a register then which register is it reading?

Kind of confusing that you marked this thread solved and then kept asking something here.

I wouldn't have marked it solved while I still had follow up questions.

Part of that was explained in the comment you quoted initially:

The code you quoted is intentionally not making any unnecessary assumptions about the hardware. This section of code should still be valid on other hardware platforms that would have entirely different answers to the hardware question you seem to be asking.

As for the details in a typical X86 or X86_64 computer for enabling and servicing the tick interrupt: I don't know. I've never looked at that part of the Linux source code. I've coded that feature myself a few time on very similar hardware running other (not Linux) software, so I could make some good guesses. But my guesses would not serve you as well as looking at the actual source code yourself.

[QUOTE=johnsfine;3920494]

You solved logic of the program which I wanted to understand.
Thanks.

Here is some thing which I am wondering not because of logic.
Till the start of next jiffy what is the processor busy with or how is the delay introduced here?
May be I am not clear with what I should search for.