The relevant piece of code is this

    if (GIMME == G_ARRAY) {
    MARK++;
    while (MARK < SP) {
        tmp = *MARK;
        *MARK++ = *SP;
        *SP-- = tmp;
    }
    /* safe as long as stack cannot get extended in the above */
    SP = oldsp;
    }
[download]

which is roughly equivalent to

( $MARK, $SP ) = ( 0, $#array );
while( $MARK < $SP ) {
    $tmp = $array[ $mark ];
    $array[ $MARK++ } = $array[ $SP ];
    $array[ $SP-- ] = tmp;
}
[download]

which suggests that if the argument to reverse is a single array, rather than stack the array to create @_, the stack pointer is effectively pointed at the top of the array. This is born out (but not confirmed--I can;t find the relevant part of the source) by doing

@r = reverse 1, @r;
[download]

when substantial memory growth occurs. In this case, @_ has to be built fresh to incorporate the extra element.

Goodness knows, there are optimizations lurking that are hard to spot, and there may be one for the @r = reverse @r, but if so I don't see it.

The above (in pp_reverse) is only executed after the array has been moved onto the stack, and in your pseudo-code, @array represents the stack, not the array being reversed. What you quote is the general code for any list-context reverse, which just reverses everything from the MARK showing the beginning of reverse's arguments to the SP stack pointer at the top of the stack.

I'm intrigued that @r = reverse 1,@r seems to take more memory; how much more?