OPCODE & memory 
Author Message
 OPCODE & memory

Does anyone know how to understand, reading the opcode of the next
instruction of a program loaded in memory, if that instruction will
read/write the memory?

Thank you very much!!

PK



Mon, 27 Jun 2005 01:10:29 GMT  
 OPCODE & memory

Quote:
> Does anyone know how to understand, reading the opcode of the next
> instruction of a program loaded in memory, if that instruction will
> read/write the memory?

Of course.  By deconstructing the opcode you can determine exactly what the
assembly instruction was that made it up.

Are you asking if this can be done at runtime in advance of execution by
some means?  If so, then the only way I know of is to single-step through
your program and have some logic intercept each instruction and determine
what's coming next.

It would basically be a modified de{*filter*} you're after.

- Rick C. Hodgin



Mon, 27 Jun 2005 10:52:30 GMT  
 OPCODE & memory

Quote:
> > Does anyone know how to understand, reading the opcode of the next
> > instruction of a program loaded in memory, if that instruction will
> > read/write the memory?

> Of course.  By deconstructing the opcode you can determine exactly what the
> assembly instruction was that made it up.

> Are you asking if this can be done at runtime in advance of execution by
> some means?  If so, then the only way I know of is to single-step through
> your program and have some logic intercept each instruction and determine
> what's coming next.

> It would basically be a modified de{*filter*} you're after.

   There is a simpler and better way. You can write a simple decoder,
all it can do is find out instruction length  and whether the
instruction is a branch. There is always privilege level and other
issues with single-stepping (not all instructions will allow a trap,
e.g. mov ss, [temp_ss] won't).

/BP



Mon, 27 Jun 2005 18:36:15 GMT  
 OPCODE & memory

"Paperinik" asked:

| Does anyone know how to understand, reading the opcode of the next
| instruction of a program loaded in memory, if that instruction will
| read/write the memory?

| Thank you very much!!
|
| PK

If I understand your question correct and

---if you need this for exception-handling  
 (ignore/correct/skip and continue):
[as I use this for ignore div/0,....]

The IA-xx code organisation for most instructions show as:
 any prefix-bytes followed by opcode-bytes followed by the
 "RM-addressing"-byte  
which is split into three main sections:

b7,b6       RM-addressing mode  
            00 = memory operand
            01 = memory operand +displacement8-bit
            10 = memory operand +displacement16/32-bit
            11 = operand is a register [both if two operands]
b5..b3      3 bit R/M-operand# or sub-code#
b2..b1      3 bit R/M-operand# or SIB

So to find out for the following instruction contains a memory operand or not,
a partial disassembly is required.

To find the RM-byte:
1. notify the mode [real/p16/p32]
2. check and count all possible prefix-bytes, note 16/32 (oper/addr) changes,
3. check the opcode field(s) [one or two bytes]
4. test bit 6 and 7 [AND x,C0h ; CMP x,C0h ; JNZ__]
   if both aren't set then a memory operand is involved.
before someone ask: I don't see the "0F" as prefix.
===

Note: most incl FPU, but not all instructions work that way!
For more details look at Intel-docs; volume2, appendix code-org  

__
wolfgang



Tue, 28 Jun 2005 06:25:12 GMT  
 OPCODE & memory

Quote:

>Does anyone know how to understand, reading the opcode of the next
>instruction of a program loaded in memory, if that instruction will
>read/write the memory?

You need to make a table so for each op-code you have;

  (i) DOES read/write memory

For cases like LODSB, CALL, RET, LEAVE, LIDT,.....

 (ii) CANNOT read/write memory

For cases like Jcc, CLC, STC, BSWAP, CBW, DAA,....

(iii) CAN read/write memory

For example, ADD, SUB, XCHG, INC,....

Any instructions where the r/m bits need to be analysed to determine
if one of the operands is a memory reference, i.e: the op-code is not
sufficient information to determine these instructions reference memory
you need to look at further bytes of the machine code.

This way you can read the op-code, look it up in the table, and if it
is (i) or (ii) and then you know whether it it reads or writes memory.
If it is (iii) then you have to have some more code to look at what
the operands for the instructions are and if they refer to memory or
not.

There are a few things to beware of (or that may need to be spec'ed out
before you start) and that is;

+ REP prefix on instructions like LODSB. If (E)CX is 0 at run-time then this
  instruction should not read/write memory at all.

+ CMOVcc again the operation of this instruction is dependent on run-time
  machine state. The logical operation of CMOVC AX,[100] is to read [100]
  if CF=1 and otherwise not, although....

Of course what the CPU actually reads may be a different story also from
what the code is supposed to do due to speculative reads.

+ Instructions that have (run-time state dependent) side effects of causing
  memory reads/writes... This is probably not worth trying to catch because
  it can get very system specific but for example, writing to CR4 causing
  PDPTR's to be read from memory, writing the certain MSR that cause the
  CPU to load micro-code from memory,,

All of these problems can be overcome in one fell swoop of course if you
specify the code design to assume simple/sensible defaults and not try
to deal exactly with the behaviour of run-time code ;-) OTOH,If you do need
some sort of accuracy and have the current registers/flags available to read
the you can deal with most of the problems by special casing them.

Quote:

>Thank you very much!!

>PK

bestwishes
laura


Fri, 01 Jul 2005 04:00:22 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. OPCODE & memory

2. Movl & Mov Opcode Question

3. memory usage && TclDOM

4. Memory faults, translators, and amps

5. memory managers & APL2/PC

6. VW2.0 & Real Memory Usage

7. Filemapping & Named Shared Memory

8. Memory & Libs

9. VW & C interface - memory mgmt

10. Insufficient Memory 2.1 & warplink

11. Free memory & DOS Extender

 

 
Powered by phpBB® Forum Software