DataMuseum.dk

top - metrics - download

    Length: 4608 (0x1200)
    Types: TextFile
    Names: »840800-1.DSK«

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

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 for 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.

     Et helt andet spørgsmål, som det er pinligt, at jeg først stiller
nu, er, hvordan syntakseditoren skal kunne generere konsistente interne
repræsentationer for de brugerdefinerede symboler uden at bruge en
symboltabel? Ved at repræsentationen er konsistent forstås her, at samme
brugersymbol repræsentetres ved samme kode uanset hvor, det bruges.
     Jeg kan ikke se nogen udvej anden end at indføre symboltabellen i
syntakseditoren igen, og når dette sker er der ingen problemer i også at
lade denne tabel ndeholde typeinformation for symbolerne. Således kan
syntakseditoren bringes til at foretage typechecket af operanderne til
operationerne.

     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).



$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$


ON HOW TO DO IT.
----------------

     Vi er nu nået til det resultat, at syntakseditoren selv kan foretage
samtlige (SAMTLIGE?) checks. Ligeledes forudsættes, at oversættere kan
generere korrekt kode, og disse og syntakseditoren kan derfor ligestilles som
producenter af mellemkode. Klartekstrepræsenntationen (assembler source text)
skal først behandles af leksikalsk analyse og parser, men skulle da også
være på samme form som de øvrige.
     Mellemfilen skal derfor være en repræsentation af syntaktisk korrekte
programmer eller af fejlbehæftede programmer, hvori fejlene er udpeget.
Mellemfilen skal desuden være i intern repræsentation og kan f.eks. bestå
af en sekvens af syntakstræer for de enkelte linier i assemblerkildeteksten.

     Det skal afklares, hvordan fejlmarkeringer skal repræsenteres.

«eof»