One of my worry about the presented ideas, and this is present in RISC-V vector ISA if I'm not mistaken, is that register-size-independent vector instructions have random execution times depending on hardware register width.

I remember seeing presentations of extensions to AVX (during probably a supercomputing related event in Spain years ago ?) that some complex, matrix to matrix instructions could have data dependent execution time, in addition to possible hardware register size dependencies.

In some contexts, and for overall security, this could be very problematic. Has this been discussed?

RISC-V does have a Zvkt extension that requires that the set of instructions useful for crypto have data-independent timing. (it includes requiring that shuffle timings are independent of table data, but allows timings to vary across different index inputs)

An old attempt to this was SWAR-C, (SIMD within a register - C), that could target Neon, altivec and MMX/SSE.

I think SWAR-C nailed the syntax (a vector ?: operator, for example).

(https://aggregate.ece.engr.uky.edu/SWAR/Swarc/Scc.html)

As pointed out: it's done, look for algorithmics over grammar-based compression. Querying and search is one of the operation that is doable on compressed data.

See Algorithmics on SLP-compressed strings: A survey (Markus Lohrey) (https://www.degruyter.com/document/doi/10.1515/gcc-2012-0016...)

Implementation-wise, you probably loose on the first goal, gain on the second and third (simpler, faster implementations), if you make the fourth one easy to implement.

I'd say there are some possibilities in compression formats that are transparent to certain operations, that is compressed data you can process as is (without decompressing).

For example, look at Algorithmics on SLP-compressed strings: A survey (https://www.degruyter.com/document/doi/10.1515/gcc-2012-0016...).

A few years ago, before the advent of Copilot (and ChatGPT), I was telling my students their future as programmer was bleak, because most coding is either interfacing stuff, or creating an often incorrect heuristic to solve a single instance of a well known class of problem -- and all those activities could well soon be automated thanks to datasets like StackOverflow.

I now consider that ChatGPT for programming is a confirmation of my intuition back then.

Now, I understand that article as being too shallow again, by defining short term strategies for working with ChatGPT without considering a long term view on what it means for programming overall.

And I'm sure I'm not alone in finding the impact of ChatGPT (and future generative AI) on programming as obvious...