Quali sono le alternative all'utilizzo di uno stack per rappresentare la semantica della chiamata di funzione?

Sappiamo tutti e amiamo che le chiamate di funzione sono generalmente implementate usando lo stack; ci sono frame, indirizzi di ritorno, parametri, l'intero lotto.

Tuttavia, lo stack è un dettaglio di implementazione: le convenzioni di chiamata possono fare cose diverse (ad esempio x86 fastcall utilizza (alcuni) registri, MIPS e follower utilizzano finestre di registro e così via) e le ottimizzazioni possono fare anche altre cose (allineamento, omissione del puntatore di frame, ottimizzazione del tail-call ..).

Certo, la presenza di comode istruzioni di stack su molte macchine (macchine virtuali come JVM e CLR, ma anche macchine reali come x86 con il loro PUSH / POP ecc.) Rendono conveniente usarlo per le chiamate di funzione, ma in alcuni casi è possibile programmare in un modo in cui non è necessario uno stack di chiamate (sto pensando allo stile di passaggio di continuazione qui o agli attori in un sistema di passaggio di messaggi)

Quindi, stavo cominciando a chiedermi: è possibile implementare la semantica della chiamata di funzione senza uno stack, o meglio, usando una diversa struttura di dati (una coda, forse, o una mappa associativa?)
Naturalmente, capisco che uno stack è molto conveniente (c'è un motivo per cui è onnipresente) ma di recente mi sono imbattuto in un'implementazione che mi ha fatto meravigliare ..

Qualcuno di voi sa se è mai stato fatto in una lingua / macchina / macchina virtuale e, in tal caso, quali sono le differenze e le carenze che colpiscono?

EDIT: I miei sentimenti viscerali sono che diversi approcci di sub-computazione possono usare diverse strutture di dati. Ad esempio, il calcolo lambda non è basato sullo stack (l'idea di un'applicazione funzionale è catturata dalle riduzioni) ma stavo guardando un linguaggio / macchina / esempio reali. Ecco perché sto chiedendo ...

A seconda della lingua, potrebbe non essere necessario utilizzare uno stack di chiamate. Gli stack di chiamate sono necessari solo nelle lingue che consentono la ricorsione o la ricorsione reciproca. Se la lingua non consente la ricorsione, una sola invocazione di qualsiasi procedura può essere attiva in qualsiasi momento e le variabili locali per tale procedura possono essere allocate staticamente. Tali lingue devono prevedere modifiche al contesto, per la gestione degli interrupt, ma ciò non richiede ancora uno stack.

Fare riferimento a FORTRAN IV (e precedenti) e alle versioni precedenti di COBOL per esempi di lingue che non richiedono stack di chiamate.

Consultare Control Data 6600 (e precedenti macchine Control Data) per un esempio di supercomputer iniziale di grande successo che non ha fornito supporto hardware diretto per stack di chiamate. Fare riferimento al PDP-8 per un esempio di minicomputer iniziale di grande successo che non supportava gli stack di chiamate.

Per quanto ne so, le macchine stack Burroughs B5000 sono state le prime macchine con stack di chiamate hardware. Le macchine B5000 sono state progettate da zero per eseguire ALGOL, che ha richiesto la ricorsione. Avevano anche una delle prime architetture basate su descrittori, che ha gettato le basi per architetture di capacità.

Per quanto ne so, è stato il PDP-6 (che è diventato il DEC-10) a rendere popolare l'hardware dello stack di chiamate, quando la comunità di hacker del MIT ne ha preso in consegna uno e ha scoperto che l'operazione PUSHJ (Push Return Address and Jump) ha permesso di ridurre la routine di stampa decimale da 50 istruzioni a 10.

La funzione di base più semplice chiama la semantica in un linguaggio che consente la ricorsione richiede capacità che si abbinino perfettamente con uno stack. Se è tutto ciò di cui hai bisogno, uno stack di base è una buona e semplice corrispondenza. Se hai bisogno di qualcosa di più, la tua struttura dati deve fare di più.

Il miglior esempio di aver bisogno di più di quello che ho incontrato è la "continuazione", la capacità di sospendere un calcolo nel mezzo, salvarlo come una bolla di stato congelata e sparare di nuovo più tardi, probabilmente molte volte. Le continuazioni sono diventate popolari nel dialetto Scheme di LISP, come un modo per implementare, tra le altre cose, le uscite di errore. Le continuazioni richiedono la possibilità di creare un'istantanea dell'ambiente di esecuzione corrente e riprodurlo in un secondo momento, e uno stack è in qualche modo scomodo per questo.

La "Struttura e interpretazione dei programmi per computer" di Abelson & Sussman fornisce alcuni dettagli sulle continuazioni.

Non è possibile implementare la semantica della chiamata di funzione senza utilizzare una sorta di stack. È possibile giocare solo a giochi di parole (ad es. Usare un nome diverso, come "Buffo return buffer").

È possibile utilizzare qualcosa che non implementa la semantica di chiamata di funzione (ad es. Stile di passaggio di continuazione, attori) e quindi costruire sopra di essa una semantica di chiamata di funzione; ma ciò significa aggiungere una sorta di struttura di dati per tracciare dove viene passato il controllo quando la funzione ritorna, e quella struttura di dati sarebbe un tipo di stack (o uno stack con un nome / una descrizione diversi).

Immagina di avere molte funzioni che possono chiamarsi a vicenda. In fase di esecuzione, ogni funzione deve sapere dove tornare quando esce dalla funzione. Se firstchiama secondallora hai:

second returns to somewhere in first

Quindi, se hai delle secondchiamate third:

third returns to somewhere in second
second returns to somewhere in first

Quindi, se hai delle thirdchiamate fourth:

fourth returns to somewhere in third
third returns to somewhere in second
second returns to somewhere in first

Come viene chiamata ogni funzione, più informazioni "dove restituire" devono essere archiviate da qualche parte.

Se una funzione restituisce, vengono utilizzate le informazioni "dove restituire" e non sono più necessarie. Ad esempio, se fourthritorna da qualche parte, thirdla quantità di informazioni "dove tornare" diventerebbe:

third returns to somewhere in second
second returns to somewhere in first

Fondamentalmente; "semantica di chiamata di funzione" implica che:

• è necessario disporre delle informazioni "dove restituire"
• la quantità di informazioni aumenta quando vengono chiamate le funzioni e si riduce quando le funzioni ritornano
• il primo pezzo di informazioni "dove restituire" memorizzato sarà l'ultimo pezzo di informazioni "dove restituire" scartato

Descrive un buffer FILO / LIFO o uno stack.

Se si tenta di utilizzare un tipo di albero, tutti i nodi dell'albero non avranno mai più di un figlio. Nota: un nodo con più figli può verificarsi solo se una funzione chiama 2 o più funzioni contemporaneamente , il che richiede una sorta di concorrenza (ad esempio thread, fork (), ecc.) E non sarebbe "semantica di chiamata di funzione". Se ogni nodo dell'albero non avrà mai più di un figlio; quindi quell'albero sarebbe usato solo come buffer FILO / LIFO o stack; e poiché è usato solo come buffer FILO / LIFO o stack è corretto affermare che "albero" è uno stack (e l'unica differenza sono i giochi di parole e / o i dettagli di implementazione).

Lo stesso vale per qualsiasi altra struttura di dati che potrebbe essere plausibilmente utilizzata per implementare la "semantica della chiamata di funzione" - sarà usata come una pila (e l'unica differenza sono i giochi di parole e / oi dettagli di implementazione); a meno che non interrompa la "semantica della funzione chiamata". Nota: fornirei esempi per altre strutture di dati se potessi, ma non riesco a pensare a nessuna altra struttura leggermente plausibile.

Naturalmente come viene implementato uno stack è un dettaglio di implementazione. Potrebbe essere un'area di memoria (in cui si tiene traccia di uno "stack top corrente"), potrebbe essere una sorta di elenco collegato (in cui si tiene traccia di "voce corrente nell'elenco"), oppure potrebbe essere implementato in alcuni altro modo. Inoltre, non importa se l'hardware ha il supporto integrato o meno.

Nota: se una sola invocazione di una procedura può essere attiva in qualsiasi momento; quindi è possibile allocare staticamente lo spazio per le informazioni "dove tornare". Questo è ancora uno stack (ad esempio un elenco collegato di voci allocate staticamente utilizzate in modo FILO / LIFO).

Si noti inoltre che ci sono alcune cose che non seguono la "semantica della chiamata di funzione". Queste cose includono "semantica potenzialmente molto diversa" (ad es. Continuazione che passa, modello dell'attore); e include anche estensioni comuni a "semantica di chiamate di funzioni" come concorrenza (thread, fibre, qualunque cosa), setjmp/ longjmp, gestione delle eccezioni, ecc.

Il linguaggio concatenativo del giocattolo XY utilizza una coda di chiamata e uno stack di dati per l'esecuzione.

Ogni fase di calcolo implica semplicemente la dequizione della parola successiva da eseguire e, nel caso dei builtin, alimentare la sua funzione interna dello stack di dati e della coda di chiamata come argomenti, o con userdefs, spingendo le parole che la compongono in primo piano.

Quindi, se abbiamo una funzione per raddoppiare l'elemento superiore:

; double dup + ;
// defines 'double' to be composed of 'dup' followed by '+'
// dup duplicates the top element of the data stack
// + pops the top two elements and push their sum

Quindi le funzioni di composizione +e duphanno le seguenti firme di tipo stack / coda:

// X is arbitraty stack, Y is arbitrary queue, ^ is concatenation
+      [X^a^b Y] -> [X^(a + b) Y]
dup    [X^a Y] -> [X^a^a Y]

E paradossalmente, doublesarà simile a questo:

double [X Y] -> [X dup^+^Y]

Quindi, in un certo senso, XY è impilabile.