renox

Nobody forces you to use unchecked build! And some people want maximum performances, I've read that bound checking can hurt SIMDification..

Or that reasonable people may disagree on when to make signed/unsigned overflow undefined: Zig didn't only make it an UB on unchecked build they also trigger an "abort on overflow" in checked build.

Zig disagree with you: they even made unsigned OV undefined (in unchecked mode)

> The same goes for its "Code Density" argument: nope, code density is very important.

Sure, but ARM's thumb has shown that you can get a RISC which has the same code density as current CISCs.

Of course, it's because current CISCs are bad due to backward compatibility but..

It isn't a toy for sure, but I doubt that it has good scalability stories when using SMP.. I'd love to be wrong given that even phones are multicores, so feel free to correct me.

'data oriented' doesn't mean 'just use SoA' it means use data structures which correspond to your data access pattern. Which is quite difficult to know in complex applications and which can change..

> hands are wrung that communication will become rife with error and misunderstanding because unlike the telegraph, the newfangled telephone leaves no written record!

Well let's not forget that early phone communication quality was ahem not-very-good, so of course errors were an issue.

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

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.

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.