Thank you very much for the clear and concise technical
explanations. I found it fascinating, and found it made perfect sense. I
only wish I could reciprocate in some way.
MIPS, eh? That's interesting. I'm guessing Intel's PC-based (as
in program counter) approach may have been historical; it's hard to stop
a historical juggernaut once it's got enough steam.
I also appreciated the words of someone from a well-known
engineering laboratory whom had additional insight into the subject,
just as we happened to be discussing it here. :-)
Incidentally, this reminds me of how Sun chose to implement
their Niagara processors differently (from an architectural
They can save all registers (for all threads) and related
context switch information with a single call since they sized it to be
big enough to do it all in one gulp. This is one of the reasons why
thread-switching (up to 8 hardware threads per core) is a cheap
operation on Niagara. It's roughly along the lines of changing a pointer
to another area of what I informally call 'thread information block'.
No criticism of other architectures; just merely mentioning a
different approach. Of course, Sun's first Niagara implementation also
had an absymal FP engine (corrected in second generation). It also had
the benefit of hindsight as it is newer than most architectures today.
I will be sure to keep I64 issues in mind when writing code.
Thanks! I also found it interesting to read about how architectural
design choices affects real world apps, even indirectly. From my
reading, it does indeed sound like quite a challenge for the HP folks to
try and improve performance in some way, to the extent possible.