Live data from Hacker News

What's new in CPUs since the 80s and how does it affect programmers?

danluu.com

71–72 of 72 posts

Re: What's new in CPUs since the 80s and how does it affect programmers?

#71
post #58
post #25

Earlier quoted context omitted.

All: I had a negative reaction to this comment too at first, but on reflection it reads less like a jab and more like a rueful lament about mainstream programming culture. The fact that mgrennan loved the article and was so perfectly wrong about it not being appreciated here suggests that he or she just hasn't realized yet how much passion this community shares for the craft. It's depressing to feel like you're the o…

I'm coining a new term! dang charitable : being charitable in interpretation even in the face of aggressive uncharitableness.

It's really just a question of absorbing the hit of one's initial reflex and then looking again.

Re: What's new in CPUs since the 80s and how does it affect programmers?

#72
post #51
post #50

Earlier quoted context omitted.

Software compatibility is both good and bad. If we were in the habit of recompiling from source with each CPU generation (this presumes source is available), that would allow much more innovation in machine language. And then the design of that machine language would more closely resemble the actual design of the CPU. But there are such significant advantage to remaining binary compatible, that I'm not surprised with…

This is an interesting design question - which layer should be backwards compatible and under which significant freedom of design is allowed. I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice. Particularly if the source is C…

I'm not at all sure that the best answer is "source code". For x86 CPUs the compatible layer has been the ISA and that has turned out pretty damn well, suggesting that source compatibility is not the only and may not be the most effective choice.

I disagree, though I see your point.

If the x86 instruction set had been designed to be implemented in various ways depending on the available semiconductor technology, then that would be a much better situation. However, the basics of x86 were designed in the 1980s to be directly implemented in the hardware of the time.

If you were designing an ISA expressly to insulate software from the hardware, I'm sure there are dozens of design choices that would be made differently. Ditto for amd-64.

Post reply on HN