Modernizza un compilatore, passaggio ritardato del paradigma generazionale

0

Sono stati ingaggiati per modernizzare un vecchio compilatore binario che è stato dimenticato da alcuni anni da persone che sono già morte.

Il compilatore ha

  • un parser,
  • un objectmodel e
  • un generatore di bytecode.

Il problema principale è ora che la parte generatrice ha costruito il file binario dall'alto verso il basso in un unico passaggio.

while linkage
  while variables
    while read/write-lock
      while linkage
        while variables2
          while register2
            do write-header
        while variables3
          while range-check
             do write-introspection-info
      while linkage
        while variables3
          do reserve-memory
      while linkage
        while variables4
          do initialize
      while linkage
        while variables5
          do increase-stackcount (for later use)

Come puoi vedere, abbiamo cicli ripetuti per un oggetto che non è stato modificato nel frattempo.

Per ridurre i loop (mantenendo la funzionalità), ho bisogno di bufferizzare i risultati dei loop e dei buffer per scrivere in ...:

while linkage
  while variables
    do write-header > buffer 1
    do write-introspection-info > buffer 2
    do reserve-memory > buffer 3
    do initialize > buffer 4
    do incrementstackcount > buffer 5

... e combinalo in una nuova fase del processo di generazione come questo:

do write buffers 1-5

Ora il problema: il suo lavoro pericoloso senza risultati pratici.

Qualche suggerimento per un paradigma sicuro in questo processo?

    
posta Peter Rader 16.06.2016 - 09:58
fonte

2 risposte

1

Now the problem: Its dangerous work without practical results.

Questo è un problema, va bene.

Vuoi che qualcuno ti paghi [un sacco] di soldi per produrre pochi, se non nessun beneficio pratico?

Perché questo cambiamento è necessario ?
Certo, è un acaro inefficiente, ma stiamo parlando di secondi di sovraccarico o ore ? (O giorni?)

Se hai intenzione di fare questo, allora DEVE scrivere [esauriente] Test prima di iniziare. L'output che segue il tuo cambiamento deve essere assolutamente uguale a quello che è stato generato prima o qualsiasi differenza deve essere spiegabile.

    
risposta data 16.06.2016 - 14:03
fonte
0

Inizia con quello che sembra (1. più semplice, 2. più probabile che sia basso Ordine (O (N) non O (N ^ 3)). Diciamo che un ciclo e tutti i buffer sono più facili da iniziare, fare alcuni di questo sviluppo e test come descritto di seguito, e se la riscrittura del generatore di codice diventa troppo difficile, prova l'altro modo (un buffer e tutti i loop).

Vuoi cambiare una (complicata) cosa ed essere sicuro che la cosa faccia ancora ciò che la vecchia cosa ha fatto.

Per ridimensionare il tuo problema: stai provando a dimostrare che la compilazione con il nuovo compilatore genera lo stesso codice del vecchio compilatore, ma più veloce?

Questo è un problema di test.

  • Hai già un compilatore "noto bene" per la tua lingua di destinazione (il vecchio compilatore)

Quindi il test più semplice è una compilazione AUTOMATIC di Hello World del vecchio compilatore e quella nuova, quindi confronta i risultati.

Il motivo per rendere automatico il test è che eseguirai questo test ogni volta che pensi che il nuovo generatore di codice funzioni.

  • Probabilmente avrai bisogno di disassemblare i binari risultanti, quindi confrontarli per facilitare la ricerca dei problemi.
  • Probabilmente avrai anche bisogno di creare un "confronto intelligente" per lo smontaggio dell'output a cui non interessa se qualcosa di cui non ti interessa nei file di output cambia. Ad esempio, l'ordine delle variabili cambia,

Rendi il meccanismo per farlo completamente programmabile o automatico.   - Puoi testare il sistema di test usando il vecchio compilatore contro se stesso.   - E devi fare questo per essere sicuro che le build con il vecchio compilatore siano riproducibili, e se no, da cosa cambiano

Se riesci a eseguire tutto questo su una grande macchina moderna, puoi generare i tuoi restanti vettori di test passando a un buon fuzzer come American Fuzzy Lop.

  • I vettori di test sono gli input su cui metti alla prova il tuo nuovo compilatore. Il tuo vecchio compilatore servirà ovviamente come trasformazione dall'output di test in uscita a quello previsto.

Altrimenti avrai bisogno di programmi di prova da testare. Il codice base esistente che si desidera supportare sarebbe un set di campioni ragionevole.

    
risposta data 17.07.2016 - 01:03
fonte

Leggi altre domande sui tag