One domain where stack machines shine is code density because of no need for register encoding. Instruction lengths aren't measured in bytes, but rather in bits. With some form of binary coding, one can reduce code size even further, 1-7 bits per instruction is not uncommon with rather elaborate instruction set which includes a handful of "macro" instructions for common tasks such as initializing array of data and random number generation and some others.
If implementing a stack based VM within a program, the stack machine has some overhead(because it has to be implemented with all the functionality and interfacing with the rest of the program) but that is mainly a curiosity - one can implement a less-well scaling ISA without binary coding and fixed opcode length with far fewer bytes for the VM, but then the cheap cost will be offset with worse code density. On the other hand a more advanced VM takes far more space, but the greater code densty pays off after certain amount of code.
Bit-aligned instructions are a really horrible idea if you ever want to make a CPU implementing that instruction set actually fast. When you want to decode multiple instructions in parallel, having more possible locations for the beginning of the next instruction adds a lot of latency and power on a very critical path. Getting more cache to fit instructions and more bandwidth from it to the cpu is a problem that can be solved by Moore's law, having to put more muxes in front of your decoder isn't, now that Moore's law just buys you more transistors and less power, but not faster transistors.
x86 is now considered to be extremely hard to decode because it's byte-aligned instructions, and basically all modern instruction sets prefer fixed-width instructions. ARM used to tout how space-efficient it's THUMB-2/ARMv7 instruction set was compared to other RISC instruction sets because it had 2 possible instruction lengths (16b and 32b), but now that they got to (had to) reboot the ISA for 64-bit, ARMv8 is fixed-width.
For clarity for those who aren't exactly clear with all this, this only applies when the instruction set is actually compressed somehow - not for stack based machines in general.
In a more general sense, I see benefit outside of just demoscene. If code density makes programs small enough to fit in cache it makes diskless, RAM-based systems potentially faster.
One could easily think so, but it's not quite true.
While x86 processors have relied on caching the instructions for some two decades now the overhead of decoding the VM bytecode instruction bitstream of the VM is certainly too high(especially if it's compressed) to outweigh the possibly reduced stalls due to instruction cache miss because of greater code density.
Of course, one could translate the VM bytecode bitstream to equivalent x86 code upon running, but without some really smart heuristic optimizer there wouldn't be much to gain in speed over simple x86 implementation, although it'd very probably be faster than the VM.
Either my comment was mistunderstood (e.g. we are each referring to different caches) or I am suffering from a fundamental misunderstanding.
Let's say you have a diskless RAM-based system. Swapless.
Now you launch a large program, say firefox or some other "modern web browser". That is going to require page caching, correct? This program cannot fit into the CPU cache, specifically what the Wikipedia entry (to use a common point of reference) calls the "data cache" (cf. what it calls the "instruction cache").
Now say you launch another large program. Depending on how much main memory you have, the OS is going to have to do some decision-making. Which program (or parts thereof) need to be "immediately available"?
Now imagine you have a small program constructed from very dense code, say a few K in size, and it fits entirely within the data cache. Correct me if I'm wrong, but in that case there is no page caching or OS decision-making. The program is "immediately available" as long as it's in the data cache.
OK, now I'm sure someone will take this comment apart piece by piece. But keep in mind the general idea I am suggesting is: code density lends itself to smaller programs, smaller programs lend themselves to fitting in the data cache, and fitting entirely within the CPU's data cache lends itself to running faster in a diskless RAM-based system. If this is wrong, then you need to explain why, specifically.
You seem to be mixing up several different levels of caching. Firstly, instructions are primarily fit in the instruction cache, not the data cache.
Secondly, there is no signifcant address translation overhead and the os doesn't need to do any decision making (or well, it does, but it is cached in the TLB and code TLBs are so efficienct nowadays that you can expect the cost to be null) so long as the resident set fits in the main ram -- whether it fits in the cache or not is irrelevant.
Thirdly, just how does the disklessness of the system have any influence? I am not entirely sure but it seems you are somehow mixing up the page cache and the CPU cache, which are completely different things.
If implementing a stack based VM within a program, the stack machine has some overhead(because it has to be implemented with all the functionality and interfacing with the rest of the program) but that is mainly a curiosity - one can implement a less-well scaling ISA without binary coding and fixed opcode length with far fewer bytes for the VM, but then the cheap cost will be offset with worse code density. On the other hand a more advanced VM takes far more space, but the greater code densty pays off after certain amount of code.
Where this matters is of course demoscene. ;)