i thought about 8086 assembler
(same thing about tp and the assembler inside the tp).

i saw machine code of 8086.
i saw machine code of pentium.
8086 got 1 byte that define the command type.
pentium got 2 bytes to define command type.
all the rest is pritty much the same.

but how could be pentium computers work successfully with
borland 8086 tasm & tp?

thx
dolev

: i thought about 8086 assembler
: (same thing about tp and the assembler inside the tp).
:
: i saw machine code of 8086.
: i saw machine code of pentium.
: 8086 got 1 byte that define the command type.
: pentium got 2 bytes to define command type.
: all the rest is pritty much the same.
:
: but how could be pentium computers work successfully with
: borland 8086 tasm & tp?
:
: thx
: dolev
:
The following is conjecture, based on my knowledge of microprogramming and ideas how to solve such a problem.
That's because the 1 byte of the pentium command type is exactly the same as the 8086 byte. Thus the pentium recognizes the code from the program header and then reads 1 byte and patches a second to it (#0 most likely). This way the code is handled as having 2 bytes instead of 1.

This message was edited by dolev9 at 2005-4-26 12:18:17

---

i made out a closer look and it sims to be some codes (some of the old codes) take 1 byte to define the command type and on some new codes and some old codes 2 bytes to define it.

now it is more understanable but any way - the old commands that were expanded to 2 bytes long do not have any easy to find something in common but that they usualy got the same first byte as in the 8086.

well it could be nice to post the pentium machine code in codepedia or something. it could be nice to use it to learn manualy compile/decompile/exec.

well thx anyway
dolev

: This message was edited by dolev9 at 2005-4-26 12:18:17

---

: i made out a closer look and it sims to be some codes (some of the old codes) take 1 byte to define the command type and on some new codes and some old codes 2 bytes to define it.
:
: now it is more understanable but any way - the old commands that were expanded to 2 bytes long do not have any easy to find something in common but that they usualy got the same first byte as in the 8086.
:
: well it could be nice to post the pentium machine code in codepedia or something. it could be nice to use it to learn manualy compile/decompile/exec.
:
: well thx anyway
: dolev
:
:
:
:
:
Go ahead. You can add to the CodePedia yourself.

: This message was edited by dolev9 at 2005-4-26 12:18:17

---

: i made out a closer look and it sims to be some codes (some of the old codes) take 1 byte to define the command type and on some new codes and some old codes 2 bytes to define it.
:
: now it is more understanable but any way - the old commands that were expanded to 2 bytes long do not have any easy to find something in common but that they usualy got the same first byte as in the 8086.
:
: well it could be nice to post the pentium machine code in codepedia or something. it could be nice to use it to learn manualy compile/decompile/exec.
:
: well thx anyway
: dolev

Done enough assembly to know a little, but could be wrong ;)

The way it works is it uses the single byte codes as normal. It also has newly added codes and some are 2-byte. This was the case back for original Pentium anyways. Zibadian could be very right about the byte-padding to word align instructions.

I know for commands like copying memory (STOSB="Copy 1 byte" or STOSW="copy 2 bytes/1 word") could be used to call STOSD (Copy 4 bytes/1 LongInt) on a pentium by an older assembler (such as TP7) by first calling 66h.
For example:

ASM
   STOSW
   STOSW
END;

is the same as (but slower) than the pentium equivilant:

ASM
   DB $66    { Use pentium instruction }
   STOSW     { Now same as STOSD }
END;

Just my $0.02, but it can speed you code up quite a bit for large memory copies (such as graphics)

Phat Nat