Clem Cole
2018-01-29 16:00:28 UTC
a tad OT for simh ...l
Paul Winalski [3 of DEC more illustrious compiler folks for those that do
not recognize the names] have always claimed is that when they started
hacking on the Intel compiler, their were more open bug reports than ever
been reported bugs on Gem. That does not say it was a perfectly good
compiler.
Although the fact that Gem had been written in BLISS vs. C I think colored
the opinion/choice/was the reason given; but I've heard similar things
from the ex-K&A folks who had much of their technology in C.
To be honest, I think what drove Rich and the team nuts the most was not
the implementations as much as the lack of the support for things in IL
that DEC handled years ago. As you pointed out, GEM's IL was designed for
N input languages and Y backends ... AND ... supported CISC and
RISC architectures and even had support for parallel ops. Until LLVM came
on the scene, I'm not aware of any other compiler technology that was as
flexible - although like you, as an OS guy I follow compiler stuff as a
very interested user/observer -- much less lunch companion to the folks
building it all.
realities. LLVM is the current 'savior' for the community, but to
be honest, its still unproven. There is not yet a modern ''commercial
style'' FORTRAN or PL/1 front-ends and parallel ops are still a
work-in-progress. That may change. But as I have said here and in other
places, Fortran (and parallel Fortran in particular) pays my salary and I
don't think that is going to change for a long time because too
is Fortran Still in Use
<https://www.quora.com/Why-is-the-Fortran-language-still-in-use-and-most-importantly-relevant-in-HPC-Is-it-just-because-this-language-has-tremendous-numerical-calculation-capability-which-is-an-important-part-of-HPC/answer/Clem-Cole>
].
â
ever produced (Roger 'Fossil' Gourd) use to try to teach this lesson. I
miss his wisdom,â
although I fear not enough people that are writing new code read. Bless
you of trying to remember and get it down as a start.
Clem
á§
In the current STC, well, I saw a lot of NIH in Intel. I suspect that
what you report amounts to "Why tear up a "perfectly good compiler" to
incorporate technology from a "failed company", when the result isn't
directly marketable?"
âI understand. Although if I believe what Stan Whitlock, Dave âEklund, andwhat you report amounts to "Why tear up a "perfectly good compiler" to
incorporate technology from a "failed company", when the result isn't
directly marketable?"
Paul Winalski [3 of DEC more illustrious compiler folks for those that do
not recognize the names] have always claimed is that when they started
hacking on the Intel compiler, their were more open bug reports than ever
been reported bugs on Gem. That does not say it was a perfectly good
compiler.
Although the fact that Gem had been written in BLISS vs. C I think colored
the opinion/choice/was the reason given; but I've heard similar things
from the ex-K&A folks who had much of their technology in C.
To be honest, I think what drove Rich and the team nuts the most was not
the implementations as much as the lack of the support for things in IL
that DEC handled years ago. As you pointed out, GEM's IL was designed for
N input languages and Y backends ... AND ... supported CISC and
RISC architectures and even had support for parallel ops. Until LLVM came
on the scene, I'm not aware of any other compiler technology that was as
flexible - although like you, as an OS guy I follow compiler stuff as a
very interested user/observer -- much less lunch companion to the folks
building it all.
Of course, both share the same defect - a shortsighted world view. Which
is easy to see a few decades later.
âWell, I think there is pride of authorship/NIH; and then practicalis easy to see a few decades later.
realities. LLVM is the current 'savior' for the community, but to
be honest, its still unproven. There is not yet a modern ''commercial
style'' FORTRAN or PL/1 front-ends and parallel ops are still a
work-in-progress. That may change. But as I have said here and in other
places, Fortran (and parallel Fortran in particular) pays my salary and I
don't think that is going to change for a long time because too
production<< code is written in it [See: Clem-Cole's Quora Answer - Why
<https://www.quora.com/Why-is-the-Fortran-language-still-in-use-and-most-importantly-relevant-in-HPC-Is-it-just-because-this-language-has-tremendous-numerical-calculation-capability-which-is-an-important-part-of-HPC/answer/Clem-Cole>
].
â... â
GEM was built & evolved by engineers from the ground up to support
multiple languages at equivalent optimization levels. Most other ILs start
as an internal tool for one language; when extended, the rule is to make
minimal changes to support each additional language.
âExactly!!!âGEM was built & evolved by engineers from the ground up to support
multiple languages at equivalent optimization levels. Most other ILs start
as an internal tool for one language; when extended, the rule is to make
minimal changes to support each additional language.
This keeps short term costs down (regressions against and changes to the
first language - and tools), but you lose expressiveness (and
optimizations). And it ends up being warty and hackish. But the
incremental cost of the next wart/hack is always less than the cost of
rototilling. There's probably a formal proof to derive NIH from this
observation :-)
â+1 :-)first language - and tools), but you lose expressiveness (and
optimizations). And it ends up being warty and hackish. But the
incremental cost of the next wart/hack is always less than the cost of
rototilling. There's probably a formal proof to derive NIH from this
observation :-)
â
Old New England axiom: Never time to do it right; always time to do it
over.
Knuth's version: When writing software, do it once to understand the
problem. Then plan on throwing out what you built, and write it correctly
from scratch.
Neither is put to use in the technology world...at least not often.
âAmen -- IMO (and a many others) the best engineering manager the SW worldover.
Knuth's version: When writing software, do it once to understand the
problem. Then plan on throwing out what you built, and write it correctly
from scratch.
Neither is put to use in the technology world...at least not often.
ever produced (Roger 'Fossil' Gourd) use to try to teach this lesson. I
miss his wisdom,â
INTC studied software development with M$, adopting its practices. (Not
necessarily its best ones.)
Q.E.D.
â+1 ânecessarily its best ones.)
Q.E.D.
â... â
those who don't learn from history are doomed to repeat it?
SimH does a great job of preserving the ability to use the artifacts.
However, preserving the knowledge that created them is a different problem,
as yet unsolved.
âI hope these and pages like TUHS are a small attempt to do some of it,those who don't learn from history are doomed to repeat it?
SimH does a great job of preserving the ability to use the artifacts.
However, preserving the knowledge that created them is a different problem,
as yet unsolved.
although I fear not enough people that are writing new code read. Bless
you of trying to remember and get it down as a start.
Clem
á§