That's a very interesting bug, and Fiora is a genius...
I too worked at Transmeta, although our recompiler was not on chip...
We designed the chip originally based on Spec benchmarks. This
turned out to be a mistake because Windows doesn't look a bit like
Spec.
For one thing, when booting Windows, 50% of all the instructions were
executed once only. When we found all of these instructions and
JITted their
basic blocks, it ran like a turtle. The solution was to put in an
X86 interpreter, and only JIT when the instruction was executed 5
times. The resulting performance
was more than acceptable. But there was a problem demonstrating this
with a number of benchmarks, namely those that
* Ran a small problem and timed it.
* Based on that, made a bigger problem that was scaled by #1 -- the
slower the small problem, the smaller the big problem.
* Added 1 and 2 to get the score.
The small problem often ran mostly in the interpreter. So the "big"
problem was really pretty small. That ran fast, but overall, #1
dominated.
If we actually ran the big problem from the getgo, we looked pretty
decent.
Among the interesting facts we learned: Windows executed a billion
instructions between detecting a reason to crash and putting up the
blue screen...
We also ran into problems with self modifying code. To their
credit, Microsoft quickly fixed the things we pointed out (most in
3rd-party drivers).
Transmeta actually had some of the most interesting technology I've
ever worked with as a compiler writer, including a checkpoint/restart
in hardware that let the JIT do out-of-order execution and then do it
over serially if a fault appeared.
Steve
----- Original Message -----
From: "Tony Finch" <dot(a)dotat.at>
To:"Nemo" <cym224(a)gmail.com>
Cc:"TUHS main list" <tuhs(a)minnie.tuhs.org>
Sent:Mon, 8 May 2017 14:39:36 +0100
Subject:Re: [TUHS] Discuss of style and design of computer programs
from a
Nemo <cym224(a)gmail.com> wrote:
On 6 May 2017 at 11:23, ron minnich
<rminnich(a)gmail.com> wrote (in
part):
[...]
> Lest you think things are better now, Linux uses self modifying
code to
> optimize certain critical operations, and at one
talk I heard the
speaker
> say that he'd like to put more self
modifying code into Linux,
"because it's
fun". Oh
boy.
Fun, indeed! Even self-modifying chips are being touted -- Yikes!
You reminded me of these comments on a bug in NVidia's Tegra
"Project Denver" dynamic JIT firmware:
https://twitter.com/FioraAeterna/status/855445075341398017
small brain: bug in your code
big brain: bug in the compiler
cosmic brain: bug in the cpu's on-chip recompiler
https://github.com/golang/go/issues/19809#issuecomment-290804472
https://twitter.com/eqe/status/855533948931252224
This happened with TransMeta back in the day, and now with Tegra. I
wonder if NVidia has a update deployment strategy...
(Marginally topical relevance is that Linus Torvalds worked for
Transmeta)
Tony.
--
f.anthony.n.finch <dot(a)dotat.at>
http://dotat.at/ - I xn--zr8h
punycode
Lundy, Fastnet, Irish Sea, Shannon, Rockall, Malin, South Hebrides:
Easterly
or northeasterly 4 or 5, occasionally 6 at first, becoming variable 3
at times
later. Slight or moderate. Fair. Good.