Home | Notifications | New Note | Local | Federated | Search | Logout
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange
I am Director of System Architecture at SCI Semiconductor and a Visiting Researcher at the University of Cambridge Computer Laboratory. I remain actively involved in the #CHERI project, where I led the early language / compiler strand of the research, and am the maintainer of the #CHERIoT Platform.
I was on the FreeBSD Core Team for two terms, have been an LLVM developer since 2008, am the author of the GNUstep Objective-C runtime (libobjc2 and associated clang support), and am responsible for libcxxrt and the BSD-licensed device tree compiler.
Opinions expressed by me are not necessarily opinions. In all probability they are random ramblings and should be ignored. Failure to ignore may result in severe boredom and / or confusion. Shake well before opening. Keep refrigerated.
Warning: May contain greater than the recommended daily allowance of sarcasm.
No license, implied or explicit, is granted to use any of my posts for training AI models.
Joined: 2026-07-21 00:31:10
15 notes, 0 following, 0 followers
Reply to @koakuma@uwu.social
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-10-06 17:28:31)
@koakuma Nobel Prize awarding season.
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-10-06 17:23:51)
Ah, apparently it is the time of the year when we identify and honour the best self publicists among hundreds of people who contributed to scientific discoveries.
Reply to @whitequark@social.treehouse.systems
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-09-21 19:24:48)
@whitequark
this causes the base system to be updated from 15.1 to 15.1p3
This is a pkgbase system then? This includes a kernel update, so rebooting is the correct thing to do.
If you're using a pkgbase system and don't want to update the base system, you should add -r to specify only the built-from-ports repos.
Pkgbase is still marked as experimental, so if you're using it then please report issues upstream!
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-09-15 00:57:32)
For people who still believe the GPL influences corporations in a meaningful way:
When I was at Microsoft, I worked on a product that used Linux. The product was cancelled for largely unrelated reasons before it shipped, so the exact details are irrelevant but anything that links Linux needs to loop in lawyers, so I spent a lot of time talking to them.
Maybe 10% of the total time was spent with the technicalities of the GPL. The fact that the GPL is ambiguous and poorly written and the Linux syscall exemption is even worse made me expect long discussions about the legalese. But instead the conclusion of the GPL-focused discussions was basically:
No one really knows what the GPL can actually enforce and half of the stuff that's done with Linux is technically in violation. Microsoft ships Linux images for Azure that come with a click-through license that prohibits running them on any other cloud and no one cares. We can make a convincing argument that this is okay. Only a handful of companies can afford a protracted legal battle with Microsoft and none of them are sufficiently motivated to take us to court over this, so it's unlikely to come up.
The remaining 90% of the discussions were around how the product would be perceived by Linux maintainers, the wider Linux community, and the broader F/OSS ecosystem. Microsoft had put a lot of effort into the 'Microsoft <3 Linux' marketing things. The Ballmer-era alienation of the most active developer communities had cost the company a lot of ecosystem market share. The risk of pushing developers away from Microsoft products and platforms was something that the lawyers regarded as a huge risk. If two of the senior Linux maintainers had said 'we think this is not an acceptable use of Linux' then that would have torpedoed the project instantly.
The moral of this story is that, if positive engagement with your community is perceived as valuable, you have an enormous amount of leverage over big companies. At the
Reply to @koakuma@uwu.social
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-26 01:02:45)
@koakuma @krono @whitequark
The first thing I'd want to do with SPARC register windows is make the spilling fully asynchronous with explicit serialisation. Define the spill region in memory as part of the state. Whenever the load-store unit has spare cycles, push out older windows and also reload newer ones.
Now, when you add register rename, you have a bunch of rename registers that you can discard because they are stored in memory. Keep the spill fully asynchronous. As soon as a function call exits speculation, push the values in the newly left window out to memory. When you run out of rename registers, discard the ones associated with the oldest still-in-rename-registers window and reuse them immediately. When you have more than a threshold number of available rename registers, load ones from the nearest frame.
Now you've got an architecture that should (no actual experiments were done to validate this, someone really should do them) scale nicely to systems with register rename. Fewer explicit load / store instructions for register spills and reloads and explicit information about when to speculatively reload values.
Reply to @me_@sueden.social
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-24 23:52:54)
@me_ @krono @whitequark
As I recall, the main difference was more FPU pipelines (one per core rather than a shared one?). It looked like a fairly minor tweak.
Reply to @krono@toot.berlin
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-24 21:38:21)
@krono @whitequark
SPARC had an open ISA. Leon was a series of 32-bit SPARC backed by ESA. Sun also opened the UltraSPARC T1. Both were fairly low-end cores (the T1 was okay in aggregate but pretty slow per core).
SPARC had a bunch of interesting ideas. Register windows are one of those ideas that was good on simple cores, annoying on more complex ones, but I think would actually be nice on a very high-end core if you nicely integrate it with register rename and asynchronous spill, but not quite the way SPARC specifies it. SPARC had a simple SIMD extension, but it was roughly comparable to MMX, nothing newer.
SPARC at Sun / Oracle stagnated because the Rock team (building high-per-thread performance cores) and the Niagara team (building massively multithreaded systems) hated each other. To add anything new to the architecture required both to agree, but if one agreed the other would disagree on principle. So the architecture is quite a nice '90s design that hasn't evolved.
After the Oracle acquisition, everyone got quite nervous that Oracle probably had some patents on things that might be necessary for good SPARC implementations and would be very aggressive about enforcing them.
POWER is more fun. When I was at Microsoft, we had a choice for first-party cores for Azure (later cancelled in favour of first-party SoCs using Arm-licensed cores) of:
Buy AMD and do x86. AMD's market cap was $30 B, so easily affordable (Microsofts' was around $850 B), but probably impossible to get past the regulators. They were already tested at-scale in Azure and Xbox, not clear what would be useful differentiation.
An in-house ISA. We went a really long way along this and concluded that we could do 0-20% (depending on workload) better performance than AArch64 by learning from their experience. The cost of this would be huge for the software ecosystem and most customers weren't willing to pay for performance so the business case wasn't there.
AArch64 is a nice matur
Reply to @whitequark@social.treehouse.systems
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-24 17:16:27)
@whitequark
RISC-V gained a lot of early adoption by replacing weird in-house ISAs that people were using for control-plane things. Most of these didn’t really have serious PPA requirements. They were a tiny fraction of a total chip so even doubling the area or power made a negligible impact on the total chip.
When I was at MS, I worked with a team to replace an Arm core with a RISC-V core. The core was around 1% of the total area of the subsystem, the subsystem was around 1% of the total area of the SoCs that it went in. The choices were:
Arm
Some bespoke in-house ISA.
Some other licensed core.
RISC-V
RISC-V won because we could get (or build) cores that we could integrate in the subsystem and license onwards (Arm would not allow us to sublicense one of their cores in the subsystem, their lawyers don’t like money unless they’re allowed to lick it first). Anything else came with toolchain-maintenance expenses which would easily be more than the cost of a core license.
The big win for RISC-V was that someone else paid for the toolchain and the licenses were lower than anything else where that was the case.
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-21 15:49:16)
Investors: Facebook needs to stop jumping on bandwagons and get back to its roots.
Facebook: *releases a device to enable wannabe frat bros to perv at women*
Investors: We walked into that one, didn’t we?
Reply to @koakuma@uwu.social
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-08-17 01:53:18)
@koakuma
SPARC had a few things for working with Smalltalk-like tagged integers. I wonder if Smalltalk on SPARC used this. You could load the values unconditionally early on in a function and then use them after the tag checks.
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-07-29 21:00:58)
When Arm introduced AArch64, they removed most predication. Conditional moves are very useful (and they added a fairly rich selection of these) and can significantly reduce the amount of branch predictor state that you need, but most other predicated instructions aren't that useful on modern pipelines. The cost of an ALU operation is so low that doing an ALU operation followed by a conditional move is still a big win over a branch in a lot of cases.
The one exception that caused a lot of discussion was memory operations. Predicated loads are really useful because you can replace a load of null-guarded things with them: do the null check and conditionally load if the check failed, and avoid the branch.
I've been pondering a few alternatives for a while and one I keep coming back to is a non-trapping load. A load that will give 0 and set a bit in the condition codes register if it would trap. This requires burning a PTE bit in not-present PTEs, because you need to differentiate between not-present-physically-but-present-logically pages (e.g. lazily allocated or swapped out pages), which should trap, and really-not-present pages (which should not trap in this mechanism).
I'm not 100% sure it would be a win, because a lot of TLBs don't bother caching not-present mappings, so you might trigger a page-table walk, but if a non-trapping load were followed by a conditional move, it could retire immediately once the condition was known and skip the load.
I still think there's probably a better approach somewhere.
Reply to @catsalad@infosec.exchange
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-07-20 22:01:04)
@catsalad Cyberquantum cloud!
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-07-20 20:08:13)
Are you doing quantum AI on the blockchain 4.0 yet?
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-07-17 05:15:44)
The Free Software movement never escaped from its origins: the early ‘80s MIT AI Lab. Two things were true in this environment:
Back when most computers had tens of KiBs of RAM and 1 MiB was a huge amount, programs were simple. Very few programs were so complex that one person could not completely understand them.
The AI Lab was full of some of the most talented programmers in the world.
This meant that the only obstacles for these people being able to fix bugs and add features to any program were access to the source code and the legal rights to modify it. Once you have those, any program was understandable by that group and they could modify it however they wished.
For the next 40 years, the FSF focused on these two things. The world around them changed. These two prerequisites were never enough for most people (what do 90% of computer users do if you give them even a modest 10,000 line C codebase and tell them they can change it however they like?) and now they aren’t enough even for competent programmers.
When Linus says ‘fork it’ to folks who don’t want LLM-extruded code in their kernel, he knows full well that it is almost impossible to fork a 40 MLoC C (and Rust now) codebase that averages more than one CVE per day and have something useful.
The Free Software movement is struggling now because it obsessed over licenses, which was never a path that would succeed, and ignored the hard problems:
How do you design environments that enable end users to modify their software?
How do you engineer software so that it is cheap and easy for a random user to maintain a fork that meets their specific needs?
How do you foster communities where people want to share improvements, so forks don’t proliferate even when it’s easy?
How do you create an environment where everyone sees the benefits of user-modifiable code to such a degree that trying to sell anything that doesn’t come with these rights is commercially impossible?
Instead of tackling any of these problems, t
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchange (2026-04-24 19:05:41)
Fun thing I've learned about RISC-V recently:
There is no easy way of writing a 32-bit nop in RISC-V assembly.
RISC-V tries to make the C extension transparent. You don't need to write compressed variants of instructions, you just write as if you're targeting the 32-bit encoding and the assembler transparently shrinks some things for you. The C extension is entirely duplicated instructions: every 16-bit instruction in the C extension can also be written as a 32-bit instruction and this leaves it to the assembler to figure out which.
The exact same logic is applied to NOPs (which aren't really nops, they're add 0 to 0 and store the result in the zero register). There is a NOP and a C.NOP variant, but because NOP is an alias for ADDI x0, x0, 0 and C.NOP is an alias for C.ADDI x0, 0 (which is equivalent), the assembler will always emit C.NOP (a.k.a. C.ADDI x0, 0) if you write NOP. You can generate a non-canonical nop by doing something like ADDI x0, x15, 0x200, which can't be compressed (currently), but that's fragile.
This is an issue if you want to guarantee padding space in the instruction stream for later patching or linker relaxations.
As far as I am aware, RISC-V is the only variable-length architecture whose assembler makes this mistake. x86 and Thumb-2, for example, both have explicit mnemonics for longer nops. Thumb-2 has NOP and NOP.W. x86 has a baroque list of arguments you add to NOP to make it 2-15 bytes (it's one byte with no operands).