rwmj

I'm trying to work out what this means. The "millions" employed at Meta?

However you can do what Airbus do and formally prove your C code and use a formally proven toolchain like compcert to compile it. Or you can take a performance hit and add bounds checking to the C code[1]. Aircraft systems are probably the best chance that CHERI has, and that's pretty niche, small runs and very expensive, and still better solved in software.

[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

ARM and Microsoft don't "care" enough to do anything beyond a bit of token research. Maybe there will be some extremely niche chips one day, or maybe not because the problem can be solved 90% as well in software on ordinary hardware.

The problems with CHERI are not whether it's technically good or not, it's organizational. It's an academic project that requires everyone to boil the ocean. They tried to get ARM interested and that didn't go anywhere and now they're trying to get RISC-V interested. But they haven't addressed any of the problems of why manufacturers would ever make a complex and completely incompatible chip for a problem that they (the manufacturers) don't have and don't care about, that can probably be solved 90% as well in software.

Rivos was competitive. Sadly bought by Meta and "disappeared" into the company.

is what every company that didn't understand disruption said.

There's zero chance CHERI will go anywhere, I wouldn't worry about it.

Krste wasn't even saying anything controversial. It's obvious that manufacturers will use the cheapest (free) least legally entangled option, and that this adoption will happen first amongst those with the tightest margins. And - Clayton's law[1] - it will eventually extend to the rest of the market (albeit over a very long time).

https://en.wikipedia.org/wiki/Clayton_Christensen

In the UK you pay income tax on the initial price; then if you hold the shares before selling capital gains tax on any gains. However CGT is a much lower rate than income tax so I guess it could be a bit advantageous. But you have to factor that against the risk of holding a single company's shares (also the company you work for), against selling and buying into the whole market.

The amp is this one: https://www.amazon.co.uk/dp/B098JTSJTH

As far as I could tell the cable is dumb. If you plug the cable into a regular USB-C socket (which I do not recommend) then the tip is +5V and the rest is ground.

In fact it's designed to plug into the plug marked "mobile" on the amp and the 3.5mm end goes into the line out of something else, providing AUX input, which is mixed straight through to the output of the amp (which is thankfully a regular 3.5mm headphone jack).

I guess they over-ordered USB-C sockets and decided to yolo it, or else for some reason only USB-C footprints fit into the space on the PCB. (But they still had to manufacture or were able to obtain these cursed cables ... it doesn't make a lot of sense.)

Sure, but a prediction made 3 months ago turns out to be short by a few percent at most, and that leads to a 25%+ drop in the share price? That seems weird to me.

Great meaning bad?

The press release: https://newsroom.ibm.com/2026-07-14-Arvind-Krishnas-Letter-t...

With the caveat that I work for IBM but have no inside knowledge about anything important, it doesn't seem very bad to me? Overall profit is going to be down a tiny amount below expectations.

Recently bought a guitar amp which came with a cursed USB-C cable:

http://oirase.annexia.org/tmp/IMG_20260709_123740.jpg

You've still no idea. Who is going to certify it? No auditor will certify vibe coded slop. Who will provide the indemnity for it? No insurer will touch it. It doesn't even save significant money. The cost of writing the code is a tiny fraction of the total cost of ownership.

This is such a nonsense take. You have no idea how the companies that use mainframes actually operate. There's no world in which they will vibecode a solution.

Press release: https://newsroom.ibm.com/2026-07-14-Arvind-Krishnas-Letter-t...

Aarch64 dropped thumb instructions.

I don't think you're going to find a single benchmark on the effectiveness of compressed instructions since it really depends deeply on both the workload and the whole system. For example, memory bandwidth and cache pressure are both important for whether smaller text sizes matter, and that may depend on what else is running at the same time.

Note your assembler may be automatically compressing instructions without you asking. You'll have to disassemble the binary to find out.

If you have some specific question I may be able to answer it, since I've been involved with RISC-V for over a decade, dealt with all the main companies involved, written papers, etc. but so far I see no actual question or concrete objection.

High performance RISC-V chips exist from Rivos, Ventana and others, and high performance variable length chips also exist in general (AMD, Intel). So in actual reality it increases complexity somewhat, but is not a problem.

Compressed is necessary to reduce code size which is important for performance.

A bunch of vendors have done high performance server chips which support compressed (Rivos, Ventana, some Chinese vendors), so in actual reality this was only a problem for Qualcomm. And that's only because Qualcomm bought Nuvia and they wanted to do the cheap thing (minimally change the front end) rather than the right thing.

Yes, fixed-length instructions are easier to decode, but that also means a hard upper limit on the number of instructions that could ever be supported. Which is obviously a problem for a future-proof architecture.

The rationale for this and also for confining the base set to 32 bit is explained here: https://docs.riscv.org/reference/isa/v20250508/unpriv/extend...

RISC-V definitely does support instructions longer than 32 bits, starting at 48 bits (ie. 32 + 16), and going much longer. They are much easier to decode than x86 because the length is evident from the first byte. No ratified extension uses them now, but you're going to need to deal with them as the extension space gets more crowded. Including dealing with instructions split across cache lines and pages, and instructions aligned to 16 bits.

I'm not sure what point you're making TBH.

I'm not directly involved in the day to day activity around this, but as I understand it, it's about triaging related crashes together and associating them with prior bugs and suggesting fixes, else escalating.

I broadly agree with your points except one.

Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C. There's no practical way for such binaries to detect this and work around it at runtime as they can with other extensions. And emulation would be super-slow given a large proportion of instructions are compressed.

Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it. Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem.

Also interested in the problems you see in Zicond. It claims at least to give you most of the benefit of conditional moves using only two instructions, but I've not actually tried using it. (https://docs.riscv.org/reference/isa/extensions/zicond/_atta...)

I wonder how it's possible for a developer to assign profit. The article mentions Uber's $1500 limit per developer per month. At work we're using an LLM to analyze Windows crash dumps, which turns out to be quite expensive -- several dollars per dump, and you might analyze many every hour. Others don't use AIs very much. Should those not using so many tokens donate them to the crash dump people? And back to your point, how can we assign a profit to this? Customers love having their crash dumps analyzed quickly, but that's not the same as it being profitable.

I do have working arms and hands, so for the lights and fans in my house I don't need to assume otherwise.

Pretty relevant because I've never seen the reason for "smart" gadgets at all. Physical switches are simply better.

I ran a gitweb server which was battered by bots so I eventually had to take it down. Gitweb! You can just connect using the git protocol and download everything vastly more efficiently!

In other words, they don't care at all. For them, residential bandwidth is completely free.

Even worse, not blocked, shadowbanned.