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

51–60 of 62 posts

Re: Hardware Stockholm Syndrome

#51

Post by eqvinox »

killerstorm wrote: post #20

This is poorly written nonsense article. "In the beginning, CPUs gave you the basics: registers, memory access, CALL and RETURN instructions." Well, CALL and RETURN need a stack: RETURN would need an address to return to. So there you go. A concept of subroutine was definitely not introduced by C. It was an essential part of older languages like Algol and Fortran, and is inherently a good way to organize computation.…

> Well, CALL and RETURN need a stack: RETURN would need an address to return to. So there you go.

I agree with the sentiment but you're making an impermissible contraction here. Look at how ARM calls work—the instructions are "bl " (branch and link) and "bx lr" (branch to register, lr). "bl" just stores the return address in the link register. The stack is something the machine code does on top of that. Of course the CPUs are optimised for standard ways of doing that, but it's not inherent to the system.

Re: Hardware Stockholm Syndrome

#52

Post by kstenerud »

rendall wrote: post #50
kstenerud wrote: post #44

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. 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…

We'll have to agree to disagree, then. Technologies such as the GPU provided such massive improvements that you either had to get on-board or be left behind. It was the same with assembly line vehicle production, and then robot vehicle production. Some technological enhancements are so significant that disruption is inevitable, despite current "lock-ins".

And that's fine. We're never going to reach 100% efficiency in anything, ever (or 90% for that matter). We're always going to go with what works now, and what requires the least amount of retooling - UNLESS it's such a radical efficiency change that we simply must go along. THOSE are the innovations people actually care about. The 10-20% efficiency improvements, not so much (and rightly so).

Re: Hardware Stockholm Syndrome

#53

Post by eqvinox »

The article (and a lot of comments here) confuse C with the psABI (platform specific ABI, which is what really defines conventions —more than just calling— for executable code.)

Due to history, yes, most psABIs are "do what C does". But the real problem isn't C rigidly frozen, it's psABIs designed around these "classical" programming models. E.g. none of the Linux psABIs even have a concept of "message passing", let alone more creative deviations from 'good ole' imperative code.

Re: Hardware Stockholm Syndrome

#54

Post by estimator7292 »

astrobe_ wrote: post #27
burnt-resistor wrote: post #10

Earlier quoted context omitted.

This. They're shouting at the sky from whatever squirrels are running around their brains without understanding anything about real CPUs. It's somewhere between a shitpost and AI slop. They offered no better alternative except to bitch about how "imperfect" things are that work. I'd like to see their FOSHW RTL design, test bench, and formal verification for a green field multicore, pipelined, superscalar, SIMD RISC d…

Maybe Mill' CPU [1] or GreenArray's CPU [2] ? The sad thing is that nobody is going to buy these chips aside from niche products. You won't see them run a desktop or a smartphone, because if a CPU doesn't have a C compiler or a Javascript JIT "out of the box" so to speak, it has no hope to enter mass market products. Even Java had no chance. Some older ARM CPUs used to support for "Java bytecode execution" [3] but it…

Jazelle shambled a lot further into the future than any of us want to admit. I think there are still a few ARM chips in production with java bytecode executuin still tacked on. Most of them only dropped it a few years ago.

Re: Hardware Stockholm Syndrome

#55

Post by estimator7292 »

eqvinox wrote: post #51
killerstorm wrote: post #20

This is poorly written nonsense article. "In the beginning, CPUs gave you the basics: registers, memory access, CALL and RETURN instructions." Well, CALL and RETURN need a stack: RETURN would need an address to return to. So there you go. A concept of subroutine was definitely not introduced by C. It was an essential part of older languages like Algol and Fortran, and is inherently a good way to organize computation.…

> Well, CALL and RETURN need a stack: RETURN would need an address to return to. So there you go. I agree with the sentiment but you're making an impermissible contraction here. Look at how ARM calls work—the instructions are "bl " (branch and link) and "bx lr" (branch to register, lr). "bl" just stores the return address in the link register. The stack is something the machine code does on top of that. Of course the…

We're talking about historic CPUs

Re: Hardware Stockholm Syndrome

#56

Post by MichaelRo »

varjag wrote: post #47
MichaelRo wrote: post #24

Earlier quoted context omitted.

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.

Yeah, I think it was but I was just starting in programming and GOSUB didn't made much sense to me as it's not a proper structured programming procedure with input and output params but more like a hack with data passed through global variables. And by the time I learned structured programming I already moved to Pascal (HiSoft Pascal : https://www.cpcwiki.eu/index.php/Hisoft_Pascal ) and there was no turning back to BASIC.

Re: Hardware Stockholm Syndrome

#58

Post by PeterStuer »

MichaelRo wrote: post #56
varjag wrote: post #47

Earlier quoted context omitted.

GOSUB was definitely there.

Yeah, I think it was but I was just starting in programming and GOSUB didn't made much sense to me as it's not a proper structured programming procedure with input and output params but more like a hack with data passed through global variables. And by the time I learned structured programming I already moved to Pascal (HiSoft Pascal : https://www.cpcwiki.eu/index.php/Hisoft_Pascal ) and there was no turning back to…

First thing Hisoft Pascal did when you ran it was ask how much memory you wanted to reserve for the stack. (Or was that only in HiSoft C? I had both).

Re: Hardware Stockholm Syndrome

#59

Post by Veserv »

estimator7292 wrote: post #55
eqvinox wrote: post #51

Earlier quoted context omitted.

> Well, CALL and RETURN need a stack: RETURN would need an address to return to. So there you go. I agree with the sentiment but you're making an impermissible contraction here. Look at how ARM calls work—the instructions are "bl " (branch and link) and "bx lr" (branch to register, lr). "bl" just stores the return address in the link register. The stack is something the machine code does on top of that. Of course the…

We're talking about historic CPUs

ARMv1 in 1985 had branch and link [1].

[1] https://en.wikichip.org/wiki/arm/armv1

Re: Hardware Stockholm Syndrome

#60

Post by dooglius »

Pretty clueless. When hardware with a new paradigm is invented that provides value, new software has been created for it. GPUs are a great example, TPUs/systolic arrays and the Cerebras device are others; all of these are pretty successful. CPUs architecture is what it is because it's the best approach anyone has come up with for it's domain, and C is built around that, not the other way around. If you want to claim CPUs can be done better, you're going to give something much more concrete than vague gesturing at how things could be different. How, specifically, do you intend to build an abstraction around Pong's approach? What does the programming model look like? Seems to me that this is a pretty difficult way to build anything, and Pong only managed out of its simplicity.
Post reply on HN