[EMAIL PROTECTED] wrote:
[ Sorry for the late reply, I was off-line for two weeks ... ]
> Anybody have handy an op-code/postbyte map for x86? I wouldn't mind if
> it included segment prefixes too :-). I had an illegal copy of the
> original IBM PC spec at one time, and I could sort of extrapolate 386
> from it, but it has fallen victim to domestic downsizing. If you want
> to give a lesson on why lcall is a privileged instruction in 16 bit
> mode, Ulrich, that would be good too, but without an opcode/postbyte map
> I am not sure what an lcall is :-). I would be glad of a pointer to
> something like the Principles of Operation fox ix86 if such exists, too.
Well, the official Intel architecture manuals (three volumes) can be
downloaded in PDF format from
http://developer.intel.com/design/PentiumIII/manuals/
Volume 2 ("Instruction Set Reference") contains an op-code map in the
appendix.
Another source of lots of handy maps is
http://www.sandpile.org/
Check out e.g.
http://www.sandpile.org/arch/opc_1.htm
http://www.sandpile.org/arch/opc_2.htm
http://www.sandpile.org/arch/opc_grp.htm
Note that the Intel op-code map does appear to contain the occasional
bug; check out the full instruction reference to be sure. (The Sandpile
maps would seem less buggy, b.t.w. :-/)
As to lcall, this is just the AT&T syntax for an inter-segment (or 'far')
call instruction. The difference is that not only the instruction pointer
(%[e]ip), but also the code segment register (%cs) is pushed onto the
stack and loaded from the operand.
Depending on just what the new %cs value is, the lcall instruction can
in fact perform a normal inter-segment call, or else a call via a call
gate, task gate, or to a task state segment.
Depending on the privilege levels of the target segment (or gate), the
lcall instruction might or might not be privileged. Normal Win16 apps
don't use any gates, and only ring-3 code segments, so under normal
circumstances the instruction is *not* privileged. If you get a GPF
at this point, this is typically because the pointer containing the
target segment/offset was corrupted ...
Bye,
Ulrich
