4 ms·
Related: excellent article on IA64/x64 etc: https://github.com/tpn/pdfs/blob/master/A%20History%20of%20Modern%2064-bit%20Computing%20-%20Feb%202007%20(CSEP590A
by trentnelson 9y ago
Related: excellent article on IA64/x64 etc:
https://github.com/tpn/pdfs/blob/master/A%20History%20of%20Modern%2064-bit%20Computing%20-%20Feb%202007%20(CSEP590A).pdf https://github.com/tpn/pdfs/blob/master/A%20History%20of%20M...
Features quotes from various interviews with folks like David Cutler. Fascinating (and not surprising) to connect the dots between the NT x64 calling conventions + SEH + RIP-relative addressing and Dave Cutler's initial input.
Regarding the Itanium itself, I've always found this excerpt quite interesting:
"Davidson also pointed out two areas where academic research could create a blind spot for
architecture developers. First, most contemporary academic research ignored CISC
architectures, in part due to the appeal of RISC as an architecture that could be taught in a
semester-long course. Since graduate students feed the research pipeline, their initial areas of
learning frequently define the future research agenda, which remained focused on RISC.
Second, VLIW research tended to be driven by instruction traces generated from scientific or
numerical applications. These traces are different in two key ways from the average systemwide
non-scientific trace: the numerical traces often have more consistent sequential memory
access patterns, and the numerical traces often reflect a greater degree of instruction-level
parallelism (ILP). Assuming these traces were typical could lead architecture designers to
optimize for cases found more rarely in commercial computing workloads. Fred Weber echoed
this latter point in a phone interview. Bhandarkar also speculated that the decision to pursue
VLIW was driven by the prejudices of a few researchers, rather than by sound technical
analysis."
(Page 6 of cited PDF.)
- martinpw 9y ago> Assuming these traces were typical could lead architecture designers to optimize for cases found more rarely in commercial computing workloads. At the time Itanium was actively being pushed by Intel I was working for a company building content creation software. Intel was very interested in us porting to Itanium and provided considerable help to that effort. One of the big reasons was that they were interested in being able to see the traces, precisely for the reason you state - most of their existing test code was not representative of typical large scale commercial software. We got it running but never released it - the binaries were huge (3x x86) which was a big issue back then, and the performance just wasn't there.