Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardware Stockholm Syndrome

programmingsimplicity.substack.com

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Hardware Stockholm Syndrome

#31

Post by kstenerud »

rendall wrote: post #30

The article is no more about transistors or literal frame-pointer hardware than a discussion about the QWERTY keyboard layout is about the metallurgy and mechanics of typewriter arms. It's about how early design choices, once reinforced by tooling and habit, shape the whole ecosystem's assumptions about what’s "normal" or "efficient." The only logical refutation of the article would be to demonstrate that any other c…

The article is railing against how things are without offering even a glimpse of what could be improved in an alternate design (other than some nebulous talk about message passing - which I'm assuming he's meaning to be something akin to FPGAs?)

The alternatives are niche because they're not compelling replacements. A Colemak keyboard isn't going to improve my productivity enough to matter.

A DSP improves performance enough to matter. A hardware video decoding circuit improves performance enough to matter. A GPU improves performance enough to matter. Thus, they exist and are mainstream.

When we've found better abstractions that actually make a compelling difference, we've implemented them. Modern programming languages like Kotlin have advanced enough abstractions that they could actually be applied in exotically architectured CPUs. And yet such things are not used.

Big players with with their own silicon like Apple and Google aren't sticking to the current general CPU architecture out of stubbornness. They look at the bottom line.

And the bottom line is that modern CPUs are efficient enough at their tasks that no alternative has disrupted them yet.

Re: Hardware Stockholm Syndrome

#32

Post by jebarker »

> …and has more computing power than the machines that sent humans to the moon.

We’ve all read this comparison many times. Is there any reason to think of sending people to the moon as a difficult computational problem though? Conversely, just because relatively little computation was needed to send someone to the moon does that necessarily mean that more computational power is a necessary path to doing something we’d all agree is more impressive, e.g. sending someone to Mars?

Re: Hardware Stockholm Syndrome

#33

Post by constantcrying »

I agree with the conclusion, but nothing about the arguments to arrive at that conclusion sound true at all.

Hardware does not have a Stockholm Syndrome. Making Chips that are better at things people use these Chips for is the correct thing to do. The CPU architecture is relatively static because making hardware for software which does not exist is a terrible idea. Look at Itanium, a total failure.

The C paradigm which the author bemoans never was the only one, but it was good, it worked well and that is why it is the default to this day. It is also good enough to emulate message passing and parallelism, it is totally non-obvious that throwing out this paradigm is in any way beneficial over the current status quo. There is no reason for the abstractions we want to also to be the abstractions the hardware uses.

Re: Hardware Stockholm Syndrome

#35

Post by dooglius »

Animats wrote: post #4

If you disallow recursion, or put an upper bound on recursion depth, you can statically allocate all "stack based" objects at compile time. Modula I did this, allowing multithreading on machines which did not have enough memory to allow stack growth. Statically analyzing worst case stack depth is still a thing in real time control. Not clear that this would speed things up much today.

I think you would also need to ban threading and reentrancy (from signals)? Also, if you had function pointers, you would have to pessimize to storing each such function's stack memory separately I think (since the compiler wouldn't be able to figure out the call graph, in general)

Re: Hardware Stockholm Syndrome

#36

Post by woadwarrior01 »

lukeh wrote: post #8
wrs wrote: post #6

Given this is rewinding to the 1970s, I expected a mention of CSP [0], or Transputers [1], or systolic arrays [2], or Connection Machines [3], or... The history wasn't quite as one-dimensional as this makes it seem. [0] https://en.wikipedia.org/wiki/Communicating_sequential_proce... [1] https://en.wikipedia.org/wiki/Transputer [2] https://en.wikipedia.org/wiki/Systolic_array [3] https://en.wikipedia.org/wiki/Connecti…

XMOS still very much alive. But CSP comes with its own set of challenges which ironically have force one back to using shared memory.

As are systolic arrays, see Google's TPUs.

Re: Hardware Stockholm Syndrome

#37

Post by rolandog »

rendall wrote: post #28
flohofwoe wrote: post #9

Weird article. Hasn't most code that's been compiled in the last few decades using the x86 frame pointer register (ebp) as a regular register? And C also worked just fine on CPUs that didn't have a dedicated frame pointer. AFAIK the concepts of the stack and 'subroutine call instructions' existed before C because those concepts are also useful when writing assembly code (subroutines which return to the caller locatio…

You raise fair points about the history and flexibility of hardware design. Stacks and subroutines definitely predate C, and C has run well on many architectures without dedicated frame pointers. Those are valid technical observations. But the article is about conceptual lock-in: how decades of mutual optimization between C-style abstractions and mainstream CPUs have made certain design assumptions feel "natural" or…

Yes! Finally a comment addressing the article. I think it would be nice to explore what the hardware would end up looking like if people had optimized it to mainly run Lisp, FORTRAN, Go, etc.

Would it have been better, faster, cheaper, more flexible, etc?

Re: Hardware Stockholm Syndrome

#39

Post by magicalhippo »

rolandog wrote: post #37
rendall wrote: post #28

Earlier quoted context omitted.

You raise fair points about the history and flexibility of hardware design. Stacks and subroutines definitely predate C, and C has run well on many architectures without dedicated frame pointers. Those are valid technical observations. But the article is about conceptual lock-in: how decades of mutual optimization between C-style abstractions and mainstream CPUs have made certain design assumptions feel "natural" or…

Yes! Finally a comment addressing the article. I think it would be nice to explore what the hardware would end up looking like if people had optimized it to mainly run Lisp, FORTRAN, Go, etc. Would it have been better, faster, cheaper, more flexible, etc?

Get yourself a FPGA dev board and get cracking. You can get useful ones for like $50 or less.

I've made a couple of simple soft-CPUs for self-designed instruction sets, aling with some compilers. Really fun to try to think of which instructions to include and how it interacts with the compiler.

Re: Hardware Stockholm Syndrome

#40

Post by heisenbit »

MichaelRo wrote: post #24
tdeck wrote: post #11

Earlier quoted context omitted.

It's because the historical perspective in this article is really lacking, despite that being the premise of the article. Not only does the author seem to believe that C was the first popular high-level language, but the claim that hardware provided stack based CALL and RETURN instructions was not universally true. Many systems had no call/return stack, or supported only a single level of subroutine calls (essentiall…

I recall starting to program in BASIC on CP/M and ZX-Spectrum machines and they didn't have procedures, only GOTO. Just like assembler, you can use all the JMP you want and not use structured programming and procedures but ... it will all become an unmaintainable mess in short time. Very likely in a number of alternate futures (if not all of them), given the original set of CPU instructions, people would gravitate na…

I remember jumping out of gosub on the Apple ][ and eventually running into an out of memory error as the stack on the 255 byte page $01 overflowed. As math was also done on the stack math functions broke. Simplifying expressions only delayed the inevitable doom. I had to abandon the project and only later understood my first encounter with a memory leak.
Post reply on HN