I used to write for digital signal processors and custom video chips and accelerators. What you're proposing sounds a lot like that, where the algorithm was strategically mapped to the hardware for a single purpose and maximum efficiency. It was great fun to do, and matched a time when hardware was always on the critical path of feasibility. We sometimes tried kernels that essentially virtualized the accelerators, and always returned to managing that by hand as you're proposing. The challenge was twofold. One was that the optimal hardware became very sensitive to small changes in the system requirements. It wasn't possible to "just" add memory or increase clock for the next chip, because tying the hardware and software architectures often moved the performance bottlenecks a lot when the requirements changed a little, and led to significant hardware revision. The second was that it became increasingly hard to find people that liked working in this mode, while at the same time the hardware improvements outstripped the software needs. This eventually pushed everything back towards fewer accelerators and more powerful CPU. You may be right that AI has flipped this back in the other direction. Firstly because problems are now again very much performance limited, and more interestingly because AI itself might solve the availability of programmers. AI is great at solving the kinds of tricky puzzles encountered while aligning software and hardware architectures, *if* the problems are well enough modeled. So I suspect that this will put you into a new situation where you're not just codesigning hardware and software, but also compiler and (this is the new part) programmer. What a time to be alive.
Before Linux replaced Unix, I was applying Control Flow Analysis techniques originally developed for compiler backend optimization to a programming tool predecessor of IDEs. I love the idea of compile time optimization. I've been retired for ten years, and although I used Linux right up to my retirement, my last foray into the kernel was on Unix in the 90's. So I sort of understood your post, but not entirely. What exactly does the kernel extension do, and what aspect of the kernel is it extending? It sounds like the gcc -mcontract=scalar produces something in an application executable that informs this extension of whether it needs to manage state or can just produce an execution fault. Did I get that right?
How does your extension work with dynamic library linking? Would a RTE have to provide both -mcontract=scalar and standard versions of misc. libraries? Does the -mcontract=scalar on the main executable inform the RTE as to what libraries it's permitted to dynamically link?
Or am I asking a totally obsolete question and embarrassing myself?
And last but not least, I don't see how this translates into an experiment in system paradigm shift in general. I'm interested to see how it would generalize.
For anybody interested, the code is all going up on GitHub. I'll post a link when it's live.
I used to write for digital signal processors and custom video chips and accelerators. What you're proposing sounds a lot like that, where the algorithm was strategically mapped to the hardware for a single purpose and maximum efficiency. It was great fun to do, and matched a time when hardware was always on the critical path of feasibility. We sometimes tried kernels that essentially virtualized the accelerators, and always returned to managing that by hand as you're proposing. The challenge was twofold. One was that the optimal hardware became very sensitive to small changes in the system requirements. It wasn't possible to "just" add memory or increase clock for the next chip, because tying the hardware and software architectures often moved the performance bottlenecks a lot when the requirements changed a little, and led to significant hardware revision. The second was that it became increasingly hard to find people that liked working in this mode, while at the same time the hardware improvements outstripped the software needs. This eventually pushed everything back towards fewer accelerators and more powerful CPU. You may be right that AI has flipped this back in the other direction. Firstly because problems are now again very much performance limited, and more interestingly because AI itself might solve the availability of programmers. AI is great at solving the kinds of tricky puzzles encountered while aligning software and hardware architectures, *if* the problems are well enough modeled. So I suspect that this will put you into a new situation where you're not just codesigning hardware and software, but also compiler and (this is the new part) programmer. What a time to be alive.
You are certainly an original mind Steven, one who tests his readers to expand theirs.
/usr/x86c-scalar-linux-gnux32/lib/ld-linux-x86c-x32.so.2 /usr/x86c-scalar-linux-gnux32/lib/libc.so.6
GNU C Library (Gentoo 2.43-r2 (patchset 3)) stable release version 2.43.
Copyright (C) 2026 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 16.1.1 20260718.
libc ABIs: UNIQUE IFUNC ABSOLUTE
Minimum supported kernel: 3.4.0
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
New ABIs (x86c-scalar-linux-gnux32, x86c-scalar-linux-gnu).
A new execution model (scalar contract).
A new toolchain (binutils, GCC, glibc).
A new kernel (with contract enforcement).
I'll be creating a GitHub project page shortly. This has been a lot of work. Apologies for it taking all of my time!
Before Linux replaced Unix, I was applying Control Flow Analysis techniques originally developed for compiler backend optimization to a programming tool predecessor of IDEs. I love the idea of compile time optimization. I've been retired for ten years, and although I used Linux right up to my retirement, my last foray into the kernel was on Unix in the 90's. So I sort of understood your post, but not entirely. What exactly does the kernel extension do, and what aspect of the kernel is it extending? It sounds like the gcc -mcontract=scalar produces something in an application executable that informs this extension of whether it needs to manage state or can just produce an execution fault. Did I get that right?
How does your extension work with dynamic library linking? Would a RTE have to provide both -mcontract=scalar and standard versions of misc. libraries? Does the -mcontract=scalar on the main executable inform the RTE as to what libraries it's permitted to dynamically link?
Or am I asking a totally obsolete question and embarrassing myself?
And last but not least, I don't see how this translates into an experiment in system paradigm shift in general. I'm interested to see how it would generalize.