Question regarding EIP instruction pointer

Question regarding EIP instruction pointer

[A D]

I know that EIP register is the instruction pointer. But how does it know
how many bytes it needs to increment to the next instruction? Thanks.

_________________________________________________________________
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!399

Re: Question regarding EIP instruction pointer

[leslie.polzer]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Fri, Mar 30, 2007 at 09:38:41AM -0400, A D wrote:

> I know that EIP register is the instruction pointer. But how does it
> know how many bytes it needs to increment to the next instruction?
In order to execute the current instruction, the CPU must determine its
format, which also means finding out how many bytes the command takes.

Next command is at eip+sizeof(command).  Of course, this only holds for
subsequent execution, branching is another thing.

  Leslie

-- 
NEW homepage: https://viridian.dnsalias.net/~sky/homepage/
gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Question regarding EIP instruction pointer

[A D]

leslie.polzer wrote:
>In order to execute the current instruction, the CPU must determine its
>format, which also means finding out how many bytes the command takes.
>
>Next command is at eip+sizeof(command).  Of course, this only holds for
>subsequent execution, branching is another thing.

Thanks for your insight. You mentioned the process is different for 
branching.                     Is it possible to explain a little(I'm a bit 
curious)?

_________________________________________________________________
Your Space. Your Friends. Your Stories. Share your world with Windows Live 
Spaces. http://spaces.live.com/?mkt=en-ca

Re: Question regarding EIP instruction pointer

[Robert Plantz]

On Fri, 2007-03-30 at 10:29 -0400, A D wrote:
> leslie.polzer wrote:
> >In order to execute the current instruction, the CPU must determine its
> >format, which also means finding out how many bytes the command takes.
> >
> >Next command is at eip+sizeof(command).  Of course, this only holds for
> >subsequent execution, branching is another thing.
> 
> Thanks for your insight. You mentioned the process is different for 
> branching.                     Is it possible to explain a little(I'm a bit 
> curious)?
> 

Here are some instructions from an assembly language program:
  30 0009 803B00   cmpb    $0, (%ebx)      # at null character?      
  31 000c 7410     je      getResp         # yes, get response    
  32              	
  33 000e 6A01     pushl   $1              # no, send one byte    
  34 0010 53       pushl   %ebx            #    at this location  
  35 0011 6A01     pushl   $STDOUT         #        to screen.    
  36 0013 E8FCFFFF call    write
  36      FF
  37 0018 83C40C   addl    $12,%esp
  38              	
  39 001b 43       incl    %ebx            # increment pointer    
  40 001c EBEB     jmp     queryLoop       # check at top of loop 
  41            getResp:
  42 001e 6A01     pushl   $1              # read one byte

The first column is the line number of the original source code. The
second column is the relative (from beginning of this function) address
of the instruction, in hex. The third column is the machine language of
the instruction, also in hex. The remaining stuff on the line is the
original assembly language source code that I wrote.

Look at the instruction on line #31, je getResp. The machine code for je
is 0x74. The second byte of this instruction is the distance, in bytes,
of the jump if it takes. (je means "jump if equal"; more precisely, it
will jump if the zero flag in the eflags register is true (one).)

Now, assume that this function begins at 0x1000. If the eip contains
0x100c, the CPU will fetch the byte at this address and automatically
add one to the eip so that it now contains 0x100d. The 0x74 tells the
CPU that it needs to fetch one more byte. So it fetches the 0x10 and
dutifully increments the eip so it now contains 0x100e.

Next, the CPU executes the instruction. If the jump should not be taken,
the eip is all set with the address of the pushl $1 instruction on line
#33.

However, if the jump should be taken, the CPU adds 0x0010 (the second
byte that it fetched when dealing with this instruction) to the value in
the eip. That gives 0x101e in the eip. If you look at the code above,
you will see that this is the address of the getResp label in line #41.
This label is on a line by itself so takes up no memory. Effectively,
getResp applies to the instruction on line #42, which you can see is at
memory address 0x101e.

Hope you are able to follow this explanation. The main thing to keep in
mind is that computers are very stupid. They can only do very simple
things. The reason they are so useful is that they do LOTS of very
simple things in a VERY short period of time.

Re: Question regarding EIP instruction pointer

[Brian Raiter]

> I know that EIP register is the instruction pointer. But how does it
> know how many bytes it needs to increment to the next instruction?

It doesn't "know", per se. The processor simply decodes the current
instruction. As the instruction is unpacked, it fetches bytes from
memory as they are called for. When it's done, the EIP register will
be pointing at the next instruction.

Of course, the above description is only notional. With the highly
parallel processing that goes on in the Pentium family of processors,
there is special circuitry whose job it is to pull instructions out of
memory ahead of time and prepare them for decoding. This circuitry
knows just enough about each instruction to work out how long it is.

b

Re: Question regarding EIP instruction pointer

[A D]

Thank to you all for taking time to answer my question. I really appreciate 
it. I got my answer from all of your replies. Again thanks.

_________________________________________________________________
RealLiveMoms: Share your experience with Real Live Moms just like you 
http://www.reallivemoms.ca/