| |||||||||||||
Supporting 64-bit ARM systemsSupporting 64-bit ARM systemsPosted Jul 27, 2012 21:06 UTC (Fri) by marcH (subscriber, #57642)In reply to: Supporting 64-bit ARM systems by jzbiciak Parent article: Supporting 64-bit ARM systems
> I was going to say much the same thing: Hardware can adapt to dynamically changing conditions. The compiler can, at best, look at a set of profiling runs and try to shoot down the middle.
Not just hardware but self-modifying software too. This how "Hotspot" got its name. This looks like a more general compile-time versus run-time question rather than a hardware versus software one.
At this stage this thread could probably use an informed post about Transmeta?
(Log in to post comments)
Supporting 64-bit ARM systems Posted Jul 27, 2012 21:48 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]
That is true, although to a lesser extent. I'd say it gives you a point on the continuum.
JITs can use dynamic profile information (both block and path frequency) and specific details of the run environment to tailor the code, but they can't respond at the granularity of, say, re-ordering instructions due to cache misses, for example. If you have a purely statically scheduled instruction set like EPIC, no amount of JIT will help reorder loads if the miss patterns are data dependent and dynamically changing. (Speculate/Check loads can help, but only so much.)
Speaking of the ultimate JIT platform Transmeta: Even Transmeta has some hardware patents for hardware memory access speculation mechanisms. I recall one which was a speculative store buffer: The software would queue up stores for a predicted path, and then another instruction would either commit the queue or discard it. Or something like that... Ah, I think this might be the one: http://www.freepatentsonline.com/7225299.html
|
|||||||||||||