Why do you say this? The post is quite clear that marking the memory region as NX fix the issue caused by speculative execution.

> the OS _writes_ unused memory pages to the swap file

The OS write unused memory pages to the swap file by default. But the 'constant memory' design is usually done with locking in memory both the executable and memory pages (also pinning the process to CPUs, using realtime priorities etc).

Read about the AF447 Rio-Paris crash. Input stick averaging?? That's a huge design mistake which contributed to the crash and AFAIK is still here..

What’s the alternative? I think averaging with a dual input alert is a pretty good solution. Otherwise you need to find a solution to transition from one stick to the other. You can’t just switch sticks with the press of a button because the input could jump from elevator up directly to elevator down for example.

You give them direct feedback and eliminate the need for this completely

You're phrasing this as if using an IDE was always an advantage, but unfortunately this isn't always the case:

-IDEs are more resources hungry, I remember when trying to use CLion on a big C++ codebase, until increasing the garbage collector maximum heap size all I had was a blank screen, after it was just unusably slow...

-even when IDE work, LSP for C++ codebase aren't very good, for example the caller hierarchy is usually very incomplete..

-I remember having been asked quite a few times, about "how do I use the IDE's integrated debugger to debug a target which was available only through ssh and then you had to telnet from one board to another?" My answer? Use gdb.

That said, I use VSCode now because its multiple tab handling is very nice, but I use it mostly as a glorified text editor (not by choice but because C++ is really IDE's unfriendly).

> It's a difficult coordination problem.

Well, it depends on the language: language which "capabilities" (both for the source code and for the building* ) could in theory really reduce a lot of the burden to identify supply chain attacks.

*: some research language have/had capabilities which would make supply chain attack "obvious" but for build systems I don't know if this exist.

So a VLIW, interesting but usually compressed instructions are at most two-registers..

Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary.

2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core registers (or something between where you do 3-register, but only on 16 registers). 20-bit also reduces some of the need for very large 15-bit immediates (especially jump which is upward of 10% of the total space on 32-bit designs) which could allow more 15-bit instructions further improving effective density.

Easy access to 40/60-bit instructions mean stuff like vsetvli could simply go away and very useful instructions like FMA4 (instead of FMA3) could be added. Vector masking is another big one. They don't have enough bytes for a full vector mask set resulting in some hacks.

The big question is about jumping and predicting inside packets. You can add 2 bits for what externally looks like 16-bit addressing (where the 2 bits indicate packet position to jump to) or have faster jumps that always hit the beginning of the packet (at the expense of code density due to nops). There might even be a hybrid approach where short jumps can jump within a packed, but long jumps must jump to packet boundaries (which makes sense as most compilers make functions align on cache line boundaries anyway). There is a point for eliminating 20-bit (and all that compression goodness) for 45+15-bit pairs instead) as branches inside packets are immediately calculable.

One thing I noticed with your clever encoding is that you can avoid some nops: instead of having 2 15 bits instructions followed by two nops, you could have two 30 bits instructions, saving maybe a little decoding energy.

Also the 60bit format will really help for loading immediates..

That said I wonder why normal ISA do not contain a 'Load Immediate on Next PC'? And if you want to allow parallel decoding the first byte of the immediate would be a 'special noop' and the first immediate byte would be inside the Load Immediate Next PC instruction instead.

I think this has to do with parallel decoding. How do you tell that the immediate is an immediate instead of an instruction? You have to carve out a very large part of the encoding space and you still can't fit a full immediate (eg, if you decided that all instructions starting with 1 were immediates, you'd be dedicating half of your encoding space to immediates and still be one bit short).

RISC-V does a 20-bit LUI (load upper immediate) then a 12-bit addi to the same register for the lower bits. Having access to 40-60 bit immediates makes 32-bit immediates a lot easier (with 64-bit immediates being multi-step, but quite uncommon).

If the language is Java which puts the GC in nearly everything you're f..., other languages have GCs and nonGC'd data so you go to the wonderfull world of manually managed objects with its use-after-free..

> Do you really think current LLMs can implement a large application in C as securely as they can in e.g. Go?

That's not my experience: I've seen an LLM generate a C++ use-after-free (1.5 month ago).

Congratulations your language is trying to solve an hard problem.

But .. your language mostly hide when you're doing an 'inside' function call or an 'external' function call. I'm not sure I like this; 1) the latency of both operation is very different so you want to minimise the number of 'external' function calls 2) what happens in case of 'timeout' for external function calls? I didn't see it in the doc, did I miss it?

> The car industry is constantly innovating trying to prevent accidents and make them less damaging to occupants

And at the same time, they make bigger and bigger cars which make more serious accidents for pedestrian, young children, etc.