OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

[Mouse]

>> 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		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B