On Aug 19, 4:45 am, Sebastian Kaliszewski
It doesn't matter except in cases where it does
The names of the people who have actually been responsible for the
entire design (or enough of it to speak with authority) of a modern,
full-featured processor could probably be written on one sheet of a
yellow legal pad. The rest of us are observers, no matter what
classes you have taken at university.
What's behind decode stage is still strongly tied to ISA. Stuff like
retirement logic, memory ordering, or even such basic stuff like
execution pipeline arangement is dictated by ISA.
Dictated is such a strong word that I suspect this statement to be
false. From the discussions that take place from those who know much,
much more than I do or ever could, I conclude that details of memory
ordering are somewhat arbitrary and aren't even fully specified by the
ISA. As you would say, it doesn't matter until it does, and, when it
does, as in concurrency, I don't think anyone completely understands
what is guaranteed to work and what isn't.
I conclude those things from listening to the architects who do know
clarify what the situation actually is (as opposed to what the
programmers and others who don't necessarily know imagine it to be)
and following any number of long and baffling discussions among
programmers (in which there is never agreement) as to how to safely
handle concurrency. In the end, people seem to do whatever they have
to do and to use whatever works. To say that the ISA dictates in a
situation where so many details seem arbitrary seems not even
plausible to me.
Now, if you are trying to "emulate" an x86, you have to emulate what
processors now in the market actually do, and that is one hell of a
lot of things to keep track of and get right, and *would* include
mimicking the arbitrary details that probably only Intel is powerful
enough to dictate. That is to say, you are stuck duplicating
arbitrary things no matter whether you have an Intel license or not.
What having a real license will do for you is get you access to all
the NDA stuff that Intel tells AMD and Via and won't tell you or
anyone else without specific legal rights to the information. If you
want to say that such things are part of the ISA, then your statement
could be taken as in some sense correct, but those details appear to
me to be more dictated by how a particular manufacturer has chosen to
cope with cache coherency than by the ISA.
I can't even imagine how an ISA would dictate retirement logic. What
a computer must do, no matter if it's System/360 or x86, is to make it
appear that instructions have been executed in order. Life gets very
complicated, I'm sure, when the issue is not what one processor does,
but what two processors do when possibly in competition for the same
memory addresses. However your knock-off behaves, it has to emulate
enough of the right behavior in enough of the important situations
that very little software breaks. In that sense, I'm sure that
daytripper's advice is sound: good luck.
Neither Intel nor IBM, implementing different ISA's, can dictate all
details, regardless of the ISA. Important c code has to work across
across different processor lines. Then, for the dicey stuff, you are
into whether the behavior of c is well-defined, and the answer appears
to be that it isn't. In the end you do whatever you have to do to
get an acceptably low level of weird errors. That seems to mean lots
and lots of testing, as opposed to any kind of formal logic related to
the ISA. You have to do all that testing, no matter what ISA you are
implementing.
All of these details are somewhat of a problem for ARM in general, as
I gather, because the details of processor behavior are less well-
defined, as different manufacturers have made different arbitrary
decisions working with nominally the same ISA. Without even thinking
about emulating x86, there are lots of arbitrary things to get wrong
or to be in conflict about, but they aren't dictated by the ISA.
And the rest is
optimised for a particular ISA (or performance will be lousy). Even
transmeta chip was optimised for x86 ISA emulation -- without that
performance would be even lousier.
What doesn't matter beind decode is layout of various instructions (ie.
where is an opcode, where are registers described, etc.). That's
important stuff as that is the stuff distinguishing RISC from CISC. But
that's not all the stuff -- things like number of registers, memory
ordering requirements, etc *do* matter alot (and is stall part of an ISA)..
The disconnect between what the processor appears to be on the outside
and what it is actually doing is so profound that I don't even know
how to discuss this kind of thing. An architect has to make sure that
the architectural registers in the ISA appear actually to be there.
Behind every architectural register, there are now many, many
invisible registers that are dictated by the internal workings of the
processor and not by the ISA. Once again, even x86 is emulating
itself.
Summary: there are plenty enough details to get wrong that
daytripper's advice seems sound to me, but most of them really aren't
dictated by the ISA but by an installed code base.
Robert.
