Le pile sono l'unico modo ragionevole per strutturare i programmi?

La maggior parte delle architetture che ho visto si basano su uno stack di chiamate per salvare / ripristinare il contesto prima delle chiamate di funzione. È un paradigma così comune che le operazioni push e pop sono integrate nella maggior parte dei processori. Ci sono sistemi che funzionano senza stack? In tal caso, come funzionano e a cosa servono?

Un'alternativa (piuttosto) popolare a uno stack di chiamate sono le continuazioni .

Parrot VM è basato sulla continuazione, ad esempio. È completamente senza stack: i dati sono conservati nei registri (come Dalvik o LuaVM, Parrot è basato su registri) e il flusso di controllo è rappresentato con continuazioni (a differenza di Dalvik o LuaVM, che hanno uno stack di chiamate).

Un'altra struttura di dati popolare, utilizzata tipicamente dalle VM Smalltalk e Lisp è lo spaghetti stack, che è un po 'come una rete di stack.

Come ha sottolineato @rwong , lo stile di passaggio di continuazione è un'alternativa a uno stack di chiamate. I programmi scritti in (o trasformati in) stile di passaggio di continuazione non ritornano mai, quindi non è necessario uno stack.

Rispondere alla tua domanda da una prospettiva diversa: è possibile avere uno stack di chiamate senza uno stack separato, allocando i frame dello stack sull'heap. Alcune implementazioni di Lisp e Scheme fanno questo.

Ai vecchi tempi, i processori non avevano istruzioni di stack e i linguaggi di programmazione non supportavano la ricorsione. Nel tempo, sempre più lingue scelgono di supportare la ricorsione e l'hardware ha seguito la suite con capacità di allocazione dei frame dello stack. Questo supporto è variato notevolmente nel corso degli anni con processori diversi. Alcuni processori hanno adottato i registri dello stack frame e / o del puntatore dello stack; alcune hanno adottato istruzioni che porterebbero a termine l'assegnazione dei frame dello stack in un'unica istruzione.

Man mano che i processori avanzavano con cache a livello singolo, quindi multilivello, un vantaggio fondamentale dello stack è quello della localizzazione della cache. La parte superiore dello stack è quasi sempre nella cache. Ogni volta che puoi fare qualcosa che ha un alto tasso di hit della cache, sei sulla strada giusta con i processori moderni. La cache applicata allo stack significa che le variabili locali, i parametri, ecc. Sono quasi sempre nella cache e godono del massimo livello di prestazioni.

In breve, l'utilizzo dello stack si è evoluto sia in hardware che in software. Esistono altri modelli (ad esempio il calcolo del flusso di dati è stato provato per un lungo periodo), tuttavia, la località dello stack lo fa funzionare davvero bene. Inoltre, il codice procedurale è proprio ciò che i processori vogliono, per prestazioni: un'istruzione che dice cosa fare dopo l'altra. Quando le istruzioni non sono in ordine lineare, il processore rallenta enormemente, almeno per il momento, dal momento che non abbiamo capito come rendere l'accesso casuale veloce come l'accesso sequenziale. (A proposito, ci sono problemi simili a ogni livello di memoria, dalla cache, alla memoria principale, al disco ...)

Tra le prestazioni dimostrate delle istruzioni di accesso sequenziale e il comportamento di memorizzazione nella cache utile dello stack di chiamate, abbiamo, almeno al momento, un modello di prestazioni vincente.

(Potremmo lanciare anche la mutabilità delle strutture dati nelle opere ...)

Ciò non significa che altri modelli di programmazione non possano funzionare, specialmente quando possono essere tradotti in istruzioni sequenziali e chiamare il modello stack dell'hardware di oggi. Ma c'è un netto vantaggio per i modelli che supportano l'hardware. Tuttavia, le cose non rimangono sempre le stesse, quindi potremmo vedere cambiamenti in futuro poiché diverse tecnologie di memoria e transistor consentono un maggiore parallelismo. È sempre un gioco di parole tra i linguaggi di programmazione e le capacità hardware, quindi vedremo!

TL; DR

• Stack di chiamate come meccanismo di chiamata di funzione:
  1. In genere è simulato dall'hardware ma non è fondamentale per la costruzione dell'hardware
  2. È fondamentale per la programmazione imperativa
  3. Non è fondamentale per la programmazione funzionale
• Lo stack come astrazione di "last-in, first-out" (LIFO) è fondamentale per l'informatica, gli algoritmi e persino alcuni domini non tecnici.
• Alcuni esempi di organizzazione del programma che non utilizzano stack di chiamate:
  • Stile di continuazione (CPS)
  • Macchina statale: un anello gigante, con tutto in linea. (Presumibilmente ispirato all'architettura del firmware Saab Gripen e attribuito a una comunicazione di Henry Spencer e riprodotto da John Carmack.) ^{(Nota n. 1)}
  • Architettura del flusso di dati - una rete di attori collegati da code (FIFO). Le code sono talvolta chiamate canali.

Il resto di questa risposta è una raccolta casuale di pensieri e aneddoti, e quindi in qualche modo disorganizzata.

Lo stack che hai descritto (come meccanismo di chiamata di funzione) è specifico della programmazione imperativa.

Sotto la programmazione imperativa, troverai il codice macchina. Il codice macchina può emulare lo stack di chiamate eseguendo una piccola sequenza di istruzioni.

Sotto il codice macchina, troverai l'hardware responsabile dell'esecuzione del software. Mentre il moderno microprocessore è troppo complesso per essere descritto qui, si può immaginare che esiste un design molto semplice che è lento ma è ancora in grado di eseguire lo stesso codice macchina. Un design così semplice utilizzerà gli elementi di base della logica digitale:

1. Logica combinatoria, cioè una connessione di porte logiche (e, o, non, ...) Notare che la "logica combinatoria" esclude i feedback.
2. Memoria, ad esempio infradito, chiavistelli, registri, SRAM, DRAM, ecc.
3. Una macchina a stati che consiste di una logica combinatoria e di una memoria, quel tanto che basta per poter implementare un "controller" che gestisce il resto dell'hardware.

Le seguenti discussioni contenevano numerosi esempi di modi alternativi di strutturare i programmi imperativi.

• http://number-none.com/blow/john_carmack_on_inlined_code.html
• https://news.ycombinator.com/item?id=8374345

La struttura di tale programma sarà simile a questa:

void main(void)
{
    do
    {
        // validate inputs for task 1
        // execute task 1, inlined, 
        // must complete in a deterministically short amount of time
        // and limited to a statically allocated amount of memory
        // ...
        // validate inputs for task 2
        // execute task 2, inlined
        // ...
        // validate inputs for task N
        // execute task N, inlined
    }
    while (true);
    // if this line is reached, tell the programmers to prepare
    // themselves to appear before an accident investigation board.
    return 0; 
}

Questo stile sarebbe appropriato per i microcontrollori, vale a dire per coloro che vedono il software come un compagno delle funzioni dell'hardware.

No, non necessariamente.

Leggi la vecchia carta di Appel Garbage Collection può essere più veloce di Stack Allocation . Utilizza lo stile di passaggio di continuazione e mostra un'implementazione senza stack.

Si noti inoltre che le vecchie architetture di computer (ad es. IBM / 360 ) non avevano alcun registro stack hardware. Ma il sistema operativo e il compilatore hanno riservato un registro per il puntatore dello stack per convenzione (relativo alle convenzioni di chiamata ) in modo che potessero avere uno stack di chiamate software .

In linea di principio, un compilatore e un ottimizzatore C dell'intero programma potrebbero rilevare il caso (un po 'comune per i sistemi embedded) in cui il grafico della chiamata è staticamente noto e senza ricorsioni (o puntatori a funzioni). In un tale sistema, ogni funzione poteva mantenere il suo indirizzo di ritorno in una posizione statica fissa (ed era così che Fortran77 lavorava nei computer dell'era 1970).

In questi giorni, i processori hanno anche stack di chiamate (e istruzioni di chiamata e restituzione della macchina) consapevoli delle cache della CPU .

Finora hai delle buone risposte; lascia che ti dia un esempio poco pratico ma altamente educativo di come potresti progettare una lingua senza la nozione di stack o "flusso di controllo". Ecco un programma che determina i fattoriali:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = f(3)

Inseriamo questo programma in una stringa e valutiamo il programma mediante sostituzione testuale. Quindi, quando stiamo valutando f(3), facciamo una ricerca e sostituiamo con 3 per i, in questo modo:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = if 3 == 0 then 1 else 3 * f(3 - 1)

Grande. Ora eseguiamo un'altra sostituzione testuale: vediamo che la condizione del "if" è falsa e facciamo sostituire un'altra stringa, producendo il programma:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = 3 * f(3 - 1)

Ora facciamo un'altra sostituzione di stringa su tutte le sottoespressioni che coinvolgono costanti:

function f(i) => if i == 0 then 1 else i * f(i - 1)
let x = 3 * f(2)

E vedi come va; Non affronterò ulteriormente il punto. Potremmo continuare a fare una serie di sostituzioni di stringhe fino a quando non avremo finito let x = 6e avremmo finito.

Usiamo lo stack tradizionalmente per variabili locali e informazioni di continuazione; ricorda, uno stack non ti dice da dove vieni, ti dice dove andrai dopo con quel valore di ritorno in mano.

Nel modello di programmazione della sostituzione di stringhe, non ci sono "variabili locali" nello stack; i parametri formali vengono sostituiti con i loro valori quando la funzione viene applicata al suo argomento, anziché essere inserita in una tabella di ricerca nello stack. E non c'è "andare da qualche parte dopo" perché la valutazione del programma sta semplicemente applicando regole semplici per la sostituzione delle stringhe per produrre un programma diverso ma equivalente.

Ora, ovviamente, fare delle sostituzioni di stringhe probabilmente non è la strada da percorrere. Ma i linguaggi di programmazione che supportano il "ragionamento equazionale" (come Haskell) usano logicamente questa tecnica.

Dalla pubblicazione da parte di Parnas nel 1972 di On dei criteri da utilizzare per scomporre i sistemi in moduli , è stato ragionevolmente accettato che nascondere le informazioni nel software è una buona cosa. Ciò segue un lungo dibattito durante gli anni '60 sulla decomposizione strutturale e sulla programmazione modulare.

modularità

Un risultato necessario delle relazioni black-box tra moduli implementati da diversi gruppi in qualsiasi sistema multi-thread richiede un meccanismo per consentire il rientro e un mezzo per tracciare il grafico dinamico delle chiamate del sistema. Il flusso di esecuzione controllato deve passare sia dentro che fuori da più moduli.

Scoping dinamico

Non appena lo scoping lessicale è insufficiente per tenere traccia del comportamento dinamico, è necessaria una contabilità di runtime per tenere traccia della differenza.

Dato che qualsiasi thread (per definizione) ha solo un singolo puntatore di istruzioni corrente, uno stack LIFO è appropriato per tenere traccia di ogni invocazione.

eccezioni

Quindi, mentre il modello di continuazione non mantiene esplicitamente una struttura di dati per lo stack, c'è ancora la chiamata nidificata dei moduli che deve essere mantenuta da qualche parte!

Anche i linguaggi dichiarativi mantengono la cronologia delle valutazioni o, al contrario, appiattiscono il piano di esecuzione per motivi di prestazioni e mantengono i progressi in qualche altro modo.

La struttura ad anello infinito identificata da rwong è comune nelle applicazioni ad alta affidabilità con programmazione statica che non consente molte strutture di programmazione comuni ma richiede che l'intera applicazione sia considerata una casella bianca senza informazioni significative nascoste.

I cicli infiniti simultanei multipli non richiedono alcuna struttura per contenere gli indirizzi di ritorno in quanto non chiamano funzioni, rendendo discutibile la domanda. Se comunicano utilizzando variabili condivise, queste possono facilmente degenerare in analoghi di indirizzi di ritorno in stile Fortran legacy.

Tutti i vecchi mainframe (IBM System / 360) non avevano alcuna idea di uno stack. Sul 260, ad esempio, i parametri sono stati costruiti in una posizione fissa in memoria e quando è stata chiamata una subroutine, è stata chiamata R1indicando il blocco di parametri e R14contenente l'indirizzo di ritorno. La routine chiamata, se si desidera chiamare un'altra subroutine, dovrebbe essere memorizzata R14in una posizione nota prima di effettuare quella chiamata.

Questo è molto più affidabile di uno stack perché tutto può essere archiviato in posizioni di memoria fisse stabilite al momento della compilazione e si può garantire al 100% che i processi non si esauriranno mai nello stack. Non esiste nessuno degli "Assegna 1 MB e incrocia le dita" che dobbiamo fare al giorno d'oggi.

Le chiamate di subroutine ricorsive sono state consentite in PL / I specificando la parola chiave RECURSIVE. Intendevano dire che la memoria utilizzata dalla subroutine era allocata dinamicamente anziché staticamente. Ma le chiamate ricorsive erano rare come allora.

Il funzionamento senza stack rende inoltre molto più semplice il multi-threading di massa, motivo per cui vengono spesso fatti tentativi per rendere le lingue moderne prive di significato. Non vi è alcun motivo, ad esempio, perché un compilatore C ++ non possa essere modificato in back-end per utilizzare la memoria allocata dinamicamente anziché gli stack.