Agner`s CPU blog

The pipelined-string idea is a bit new and strange, that's true. I'll try to explain it a bit more.

There is only one stack, and it is only used at pipeline-setup time. It's really a stack of pointers into the vector register bank, which exists only as rename registers and is not directly accessible (which is why user programs won't need to know how big it is). The pipeline-setup engine essentially converts the pipeline instructions into an SSA basic block - in hardware - and stores the resulting uops (or whatever) in an internal buffer. Because this is only done at setup time, it can be relatively slow - one to three cycles per instruction, say - with the goal of maximum execution speed subsequently. The stack can thus be as large as can be justified, and will certainly be smaller than the actual register bank.

Memory addresses are collected from the scalar register bank at pipeline-execution time, and auto-increment versions of memory access instructions would be provided in the pipeline, inherently providing unambiguous prefetch hints. The same can be done with scalar arguments to the vector operation. If the updated version of auto-incremented scalars/addresses is defined to be written back to the scalar register bank after pipeline execution is complete, this might simplify restarting the pipeline after an interruption. If intermediate values in the pipeline can *also* be used as memory addresses, this would facilitate fast scatter/gather operations, which is a major weak spot of present SIMD architectures.

Complex pipelines will often need to use common-subexpressions and so on. The standard way to deal with this in a stack architecture is "duplicate" and "exchange" instructions, which should be familiar from x87. Because these would be handled entirely by renaming registers, which is done at setup time only, this would not affect throughput as it does with x87.

Obviously there are many details glossed over, but hopefully the gist of it is now clear.