In practice, the difference between LLVM and a stack machine like CLR or JVM is quite small.

LLVM SSA, modulo phi nodes, encodes expressions as DAGs in a completely straightforward sense: every operation names its arguments, and those names serve as unique references to a sub-DAG, since they cannot be reassigned. So given the final operation, you can follow the arguments recursively all the way through, completely transparently. Stack machines like the CLR and JVM encode expressions as trees serialized in a post-order - and to the extent that they use 'dup', they also encode expressions as DAGs.

A symbolic interpretation of a CLR or JVM instruction flow, or LLVM SSA instruction flow, can reconstruct the source expression DAG/tree; at which point you can re-encode it using the other approach.

And producing output targeting LLVM is even easier than it appears, because you don't need to worry about SSA yourself; just allocate stack locals (with alloca) and use the mem2reg pass to turn it into valid SSA.

Yes, LLVM is a register machine and CPUs are register machines. My point really was that one shouldn't avoid stack-based languages or virtual machines because CPUs don't work that way, since some of the most used and most popular virtual machines are stack machines and get by just fine. (AFAIK both JVM and CLR are stack-based)

The big difference between FORTH and other stack machines (e.g., the JVM) is the runtime.

FORTH doesn't have one to speak of. No dynamic memory management, no garbage collection. It's about as bare-bones as you can get.

PostScript, the JVM, the CLR and so forth are all backed by runtimes with powerful functionality.

ACtually LLVM isn't a virtual machine, it's a compiler intermediate representation.

And when JVM bytecodes are compiled to machine code by the hotspot optimizer, what is the JVM?

JVM bytecode is runnable on the JVM. LLVM bytecode is runnable on what?