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

41–50 of 62 posts

Re: Hardware Stockholm Syndrome

#41

Post by flohofwoe »

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?

Just look at the Intel iAPX 432 [1] as example for such an alternative CPU design, this was supposed to be the actual 8080 successor and 8086 was just supposed to be a temporary throwaway solution until the 432 was ready. The rest is history as they say ;)

Meanwhile, the C programming model turned out a pretty good fit for very different hardware architectures. All 3D API shader languages have a C heritage for instance, despite GPUs being radically different than traditional CPUs. In the end only three things matter in hardware design: throughput, throughput and throughput ;)

[1] https://en.wikipedia.org/wiki/Intel_iAPX_432

Re: Hardware Stockholm Syndrome

#42

Post by zyxzevn »

Check out Transputers, that were programmed via Occam. They do most of the stuff that the article desires. Though its hardware is restricted to a matrix orientation.

Another option is Erlang. On the top level it is organized with micro-services instead of functions.

None of them are system languages. The old hardware had weird data and memory formats. With C a lot of assembler could be avoided to program this hardware. It came as a default with Unix and some other operating systems. Fortran and Pascal were kind of similar.

The most used default languages on most systems were for interpreters. So you got LISP and BASIC. There is no fast hardware for that. To get stuff fast, one needed to program assembler, unless there was a C-compiler available.

Re: Hardware Stockholm Syndrome

#43

Post by rendall »

kstenerud wrote: post #31
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…

The article argues that our very sense of what counts as "better" or "compelling" is shaped by the assumptions baked into C-style hardware. Saying no alternative has disrupted them because modern CPUs are efficient enough just restates that bias. It assumes the current definition of efficiency is neutral, when that's exactly what’s being questioned.

The examples of GPUs, DSPs, and hardware video decoders don’t really contradict the article's point. Those are domain-specific accelerators that still live comfortably inside the same sequential, imperative model the author critiques. They expand the ecosystem, but don't escape its paradigm.

Your Colemak analogy cuts the other way: alternatives remain niche because the surrounding ecosystem of software, conventions, and training makes switching costly whether or not they are actually "better." That is the path dependence the article calls out.

As to the article's not proposing an alternative, it reads like a diagnosis of conceptual lock-in, not a design proposal. Its point is to highlight how tightly our notion of "good design" is bound to one lineage of thought. It is explicitly labeled as part two, so it may be laying groundwork for later design discussion. In any case, I think calling attention to invisible constraints is valuable in itself.

Re: Hardware Stockholm Syndrome

#44

Post by kstenerud »

rendall wrote: post #43
kstenerud wrote: post #31

Earlier quoted context omitted.

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…

The article argues that our very sense of what counts as "better" or "compelling" is shaped by the assumptions baked into C-style hardware. Saying no alternative has disrupted them because modern CPUs are efficient enough just restates that bias. It assumes the current definition of efficiency is neutral, when that's exactly what’s being questioned. The examples of GPUs, DSPs, and hardware video decoders don’t really…

> The article argues that our very sense of what counts as "better" or "compelling" is shaped by the assumptions baked into C-style hardware.

And this is where I disagree. History is rife with disruptive technologies that blew the existing systems out of the water.

When we do find compelling efficiencies in new designs, we adopt them, such as DSPs and GPUs - which are NOT sequential or imperative - they are functional and internally parallel, and offer massive real-world gains; thus their success in the marketplace.

We also experiment with new ways of computing, such as quantum computers.

There's no shortage of attempts to disrupt the CPU, but none caught on because none were able to show compelling efficiencies over the status-quo, same as for Colemak and DVORAK: they are technically more efficient, but there's not enough of a real-world difference to justify the switching cost.

And that's fine. I don't want to be disruptively changing things at a fundamental level just for a few percent improvement in real-world efficiencies. And neither are the big boys who are actively developing not only their own silicon, but also their own software to go with it.

The article itself reads a lot like a Post hoc ergo propter hoc, in that it only allows for the path of technological progress to exist within the bounds of the C programming language (while also misattributing a number of things to C in the process), but completely discounts the possibility that how CPUs are designed is in fact a very efficient way to do general purpose computing.

Re: Hardware Stockholm Syndrome

#45

Post by weinzierl »

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…

"AFAIK the concepts of the stack and 'subroutine call instructions' existed before C because those concepts are also useful when writing assembly code [..]"

The stack principle was patented in 1957 by Friedrich L. Bauer. It was well known before C but in 1957 it was considered noteworthy enough to justify a patent.

Re: Hardware Stockholm Syndrome

#46

Post by weinzierl »

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…

The BASICs of the time often had GOSUB which remembered the return address. Also, while the stack not being prominent in the high level language, they very well used one on the assembly level. For example on the C64 (probably other 6502/6510 based systems) it always started at $100 ($ being the old convention of writing hex), right after the zeropage.

Re: Hardware Stockholm Syndrome

#47

Post by varjag »

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…

GOSUB was definitely there.

Re: Hardware Stockholm Syndrome

#48

Post by herculator »

mrheosuper wrote: post #5

>Pong had no software. Zero. It was built entirely from hardware logic chips - flip-flops, counters, comparators. Massively parallel. And that is what FPGA for. This strikes me the author lack of hardware knowledge but still try to write a post about hardware.

Feel like FPGAs are typically used as stand-ins for lack of dedicated hardware. There are niches that use them in a more permanent setting, but not as common. Definitely not used to emulate pong

Re: Hardware Stockholm Syndrome

#49

Post by TinkersW »

Article doesn't make much sense, rambles on about frame stacks and calling convention etc, when these don't matter very much on modern hardware, and are hardly standardized(windows and linux don't use the same CC).

Modern hardware is about keeping the compute as busy as possible with as fast as possible access to memory, pretty much the opposite of the proposed solution..message passing.

Re: Hardware Stockholm Syndrome

#50

Post by rendall »

kstenerud wrote: post #44
rendall wrote: post #43

Earlier quoted context omitted.

The article argues that our very sense of what counts as "better" or "compelling" is shaped by the assumptions baked into C-style hardware. Saying no alternative has disrupted them because modern CPUs are efficient enough just restates that bias. It assumes the current definition of efficiency is neutral, when that's exactly what’s being questioned. The examples of GPUs, DSPs, and hardware video decoders don’t really…

> The article argues that our very sense of what counts as "better" or "compelling" is shaped by the assumptions baked into C-style hardware. And this is where I disagree. History is rife with disruptive technologies that blew the existing systems out of the water. When we do find compelling efficiencies in new designs, we adopt them, such as DSPs and GPUs - which are NOT sequential or imperative - they are functiona…

Market success does not necessarily prove conceptual neutrality; it just shows which designs fit best within the existing ecosystem of compilers, toolchains, and developer expectations. That is the lock-in the article describes.

Calling the argument post hoc ergo propter hoc also misses the mark. The author is not saying CPUs look this way because of C in a simple cause-effect sense, but that C-style abstractions and hardware co-evolved in a feedback loop that reinforced each other’s assumptions about efficiency.

And I do not think anyone is advocating "disruption for disruption's sake." The point is that our definition of what counts as a worthwhile improvement is already conditioned by that same co-evolution, which makes truly different paradigms seem uneconomical long before they're fully explored.

Post reply on HN