DataMuseum.dk

top - metrics - download

    Length: 3072 (0xc00)
    Types: TextFile
    Names: »MAKRO.BAK«

└─⟦9dfa17898⟧ Bits:30009789/_.ft.Ibm2.50007352.imd Mogens Pelles Zilog 80,000 / EOS projekt
    └─⟦this⟧ »MAKRO.BAK« 
└─⟦bfec2519f⟧ Bits:30009789/_.ft.Ibm2.50007346.imd Mogens Pelles Zilog 80,000 / EOS projekt
    └─⟦this⟧ »MAKRO.BAK« 

TextFile

    Denne tekst er et forsøg på at afklare begreberne omkring assemblerens
kompakte inputfil. Spørgsmålet er, hvorvidt makroer og betingelser skal
ekspanderes/reduceres før eller efter mellemfilen skrives. Følgende
synspunkter eksisterer:

1)  Hvis det skal være muligt senere at ændre værdien af de symboler, som
    indgår i betingelser, f.eks. således, at en tidligere reduceret betingelse
    ikke længere skal udgå, skal samtlige grene af samtlige betingelser fore-
    findes i syntakseditorens output/input-fil.
         Hvis denne skal være
    sammenfaldende med assemblerens kompakte inputfil, må assembleren følgelig
    reducere betingelser. Da betingelsesreduktion og makroekspansion p.g.a.
    rekursion i makroerne skal foretages samlet, skal makroer følgelig ikke
    skrives ekspanderede i mellemfilen.

2)  Når assemblerens input stammer fra en almindelig editor, skal der skrives
    en ny kompaktfil (for at undgå gentagen leksikalsk analyse), og spørgsmålet
    er her, i hvilken grad, denne kompakte fil skal være korrekt.

3)  Stammer input fra en oversætter, går vi ud fra, at koden er korrekt. Over-
    sætteren genererer kompakt kode, fordi dette er nemmere for den end at
    danne tekstsymboler, og fordi leksikalsk analyse undgås.


Det store spørgsmål er åbenbart, hvor syntaksanalysen skal foretages og
hvori den skal bestå. Det er ønskværdigt, at syntakseditoren genererer
syntaktisk korrekt kode, men det er også ønskværdigt, at de ekspanderede
makroer syntaksanalyseres. Desuden er der ingen grund til at analysere de
dele af betingelser, som bortreduceres, bl.a. fordi disse ikke nødvendigvis
skal give mening. Konflikten og problemerne opstår,
fordi makroer først ekspanderes efter at være skrevet i syntakseditorens
output/input-fil. Makroekspansioner kan derfor ikke syntakssanalyseres af
syntakseditoren.

     Det der virker generende er, at problemerne ved syntakseditorens
syntaksannalyse (at den har brug foe at vedligeholde en symboltabel
under editeringen for at kunne validere makroekspansioner) løses ved
at "udvande" syntaksannalysen, således, at man faktisk ikke har megen
sikkerhed for, at ens program vil kunne assembleres uden fejlmeldingerr.
     Det, der nok virker skørt, er, at man ikke får fanget ALLE fejl
under editering. Som det er (foreslået) forestilller jeg mig snarere
syntakseditoren som et irriterende mellemled, fordi hovedparten af de
fejlmeldinger, der må forventes, alligevel først kommer under
assembleringen. Når dette er tilfældet, kan man lige så godt konstatere
og rette ALLE fejl på dette tidspunkt.

     En udvej er at udskyde valideringen af operanders type til semantisk
analyse, og dermed kun checke at udtryk er velformede, og at operatorer har det
korrekte antal operander.





Regel for makro-parametre: De skal være udformet, så det er ligegyldigt,
om de omgives med blanktegn, når de indsættes i teksten.

Aktuelle makro-parametre skal i sig selv være udtryk (eng: expressions).
«eof»