"Nimai" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
On Jul 5, 3:00 pm, "BGB / cr88192" < XXXX@XXXXX.COM >
Theories are nice, but where's the proof? I need word of god on this.
you can't prove anything...
it is like, one can ask themselves how can they be certain they exist.
the best answer would seem to be that one can look at their hand, and infer
that only someone who exists can raise the question as to whether or not
they exist. but, at best, this is the hueristic...
how about this view of the world:
there are no guerantees, and there are no absolutes;
all is, at best, probability, hueristics, and guesswork.
really, it is a world build up in the air, a world built of words and
so we take these guesses and arbitrary statements, and simply pretend as if
they were the truth, and at any moment the specifics may be changed and
revised, and then we have some new "absolute" reality...
one can assert that reality is absolute, but how can one prove it?...
how can one prove what, if anything, then, is absolute?...
for all it matters, all that has been seen thus far could be instead
synthetic behavior, the world we see instead being a piece of machinery
built on top of some other, almost entirely different, universe.
and, one can ask, really, what does it matter?...
the world we live in could just as easily be folded up into a paper crane
for what it matters.
Also, your method works for fixed instruction lengths, but it doesn't
describe what happens to extra bytes trailing after an invalid opcode
is encountered. What if the modr/m byte is screwed up? Does it treat
immediate/displacement data as an additional, invalid opcodes, or does
it throw them away? What if an opcode is corrupted, and its immediate
data or displacement contains a valid opcode?
ModR/M can't be screwed up...
why?... because all possible encodings are valid.
likewise for SIB and displacement...
one gets different results, but nothing can be "wrong" with these bytes as
far as the CPU is concerned (except when part of the opcode goes into "reg",
but then it is a UD as before...).
These are all boundary conditions, sure, and probably useless to most
people, but I need to know!
I want to be able to take any possible stream of bits, no matter how
full of garbage, and be able to know EXACTLY what will happen.
I do NOT want to have to fuzz test my CPU. These things should be
Again, my question is this: Where is this documented?
Where does Intel specifically say, "instructions are parsed according
to these rules:"?
but, anyways, besides what is documented, the CPU is free to do whatever,
and really this depends a lot on the CPU.
after all, if the CPU had "absolute" behavior, where would there be all the
special edge-cases left to hack over and redefine as new behavior?...
there are almost always little specific details depending on the specific
vendor and model of processor, and before CPUID this was commonly how people
identified which version of which processor was in use...