>> Such as every x86 processor since, what, the Pentium? They're all >> RISC cores (designed for and) running an x86 emulator.
> I've been told this more than a few times and read it in various > places. It always make me wonder, could we not allow a mode in > modern Intel processors that lets us bypass the x86 code > emulation/translation and run "directly on the metal" (if there were > such a thing). > The purpose, of course, would be to gain performance. Yes...but. The first objection that occurs to me is that it's reasonably likely the "underlying RISC core" is not a very good general-purpose machine. That's what the "(designed for and)" was alluding to: the underlying machine, to the extent that there is one, is designed for running exactly one thing, that being the x86 emulator. It would, for example, not surprise me if it did not have the user/kernel privilege mode distinction that approximately all OSes depend on these days. Others have also raised the point that doing this would require the vendor to document and support the underlying machine. This is only somewhat true, but it's doubtless at least part of the explanation. (The documentation probably exists, for internal use if nothing else, but likely contains things the vendor is unwilling to release. I don't recall details, but I recall thinking, in reaction to a vendor leak, that it might have been the vendor wanting to release documentation but wanting to retain plausible deniability about having done so....) And, of course, there are probably other forces at work too. But it's still annoying and disappointing that only the letter agencies and the black-hat community are competent to rewrite the microcode in modern peecees. (Well, and the vendors, of course.) I just recently (mostly-)finished transcribing the VAX architecture manual into text (I am doing final proofreading before letting the result out; I'll announce it here once I have it ready). One of the subsections says | C.3.1 Publishing Architecture Discrepancies | | The Systems Architecture group maintains the lists of known | architecture discrepancies. These lists are made available to ARG | members for distribution within their organizations. The lists are | submitted to publications that are readily accessible to customers if | the discrepancies are visible to customers. All discrepancies that | have been waived will be published in the architecture specification, | either as a note in an appropriate section, or in an appendix for | waivers. | | The single exception is that we will not publish the list of "system | killers" outside of Digital. All questions about "system killers", | even ones asking if there are any, will be answered "No Comment". The | reason for this is to protect customers (from their users) by | providing absolutely no information on the subject. In addition, this | "no comment" policy will be published along with the lists of | architecture discrepancies. This evidences a vast faith - now shown to be misplaced - in the inability of the black hats to discover things without DEC's help; the notion that such a policy _would_ protect customers from their users depends on DEC being the only source of such information. My point here is not to reawaken the "full disclosure" question; it's just that it would not surprise me if -- no, it would surprise me if not -- there were a component of this attitude in modern CPU vendors' failure to release documentation on the real hardware, despite all the history showing that such policies just give the black hats an advantage.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B