SQLite already compiles queries into opcodes and then uses its own VM to interpret them. You would have to reimplement the internal VM.
No, it doesn't. C does not even assume a stack. A platform where function call frames are allocated on the heap would not be incompatible with C.
You could say that some C code assumes a stack, but that's pretty exceptional.
> Although I imagine that currently, in most cases, you'll want to avoid C for software reasons,
Yes.
> rather than hardware reasons
Hard to imagine hardware on which C could not run. Maybe a JVM chip, but even then, you could compile C to bytecode.
The problem is not with call frames being on the stack or on the heap; even a spaghetti stack would be problematic. One of the problems is that return addresses and data are interleaved in C-style frames, whereas multiple stack machines require them to be separate. It's not that you couldn't write an implementation of C for a stack machine, it's just that it would be probably very primitive and slow. Yes, you can run C at the very least the way it was done on Lisp machines, by allocating a large byte array and treating it as your physical memory, but surely you would want to avoid it if you could. There really is a reason why stack machines historically ran somewhat exotic languages like Forth.
HLSL and CUDA have C-like syntax, but underneath the syntax these things are very different from C.
On GPU almost nothing has an address, there's no stack, no malloc/free, no files or printf, and every instruction runs on 32+ threads in lockstep.
And here you're proposing Zig while someone else will prefer Rust, and someone else Go. So you'll need N>1 rewrites.
This is why SQLite3 is written in C then, because for all the ways in which C sucks, it is the most common (lowest) denominator that ticks the portability checkbox.
Language runtimes that want to not have a C runtime embedded are the hardest hit. The best thing to do for those in the short-term is to talk to a C-coded IPC service that runs the C-coded thing that otherwise can't be run.
This is actually something that Zig is supposed to do as well. There should be nothing that you can do in C but can't do in Zig. So hypothetically, in the future (say, twenty years from now), a Zig implementation of SQLite could be a preferred one since you're not losing anything with it. (With the additional benefit that should you want to, you might be able to compile application-specific queries into it.)