⟦97db78252⟧

TextFile

>fo üInstruktionsindkodning i RC3502.ü
>a1 INDLEDNING.

Der har i de seneste år været en stigende interesse for emnet:
effektive pro_gram_mer. Pro_gram_effek_tivi_tet^
er ikke kun et spørgs_mål om, hvor hur_tigt et pro_gram kan
afvikles. Det drejer sig snarere om, i hvor høj grad følgende mål hver
især er opfyldt.

- Programmer skal være pålidelige (@korrekte@).

- Programmer skal være læsbare.

- Programmer skal afvikles hurtigt.

- Programmer skal fylde så lidt som muligt.

Disse mål er stærkt korrelerede. Interessen har på det seneste mest
samlet sig om at nedsætte programmers pladsforbrug uden at slække på
de tre første mål. Denne inter_esse skyl_des blandt an_det, at lager er
en mere kritisk res_sour_ce end "CPU-cycles", ikke så me_get på grund
af de økono_miske aspek_ter, men mere på grund af, at begræns_ninger i
ord_størrel_se indskræn_ker rime_lig adgang til sto_re lager_områ_der
(@Tan78@).

>a2 SPECIALETS INDHOLD.

Denne specialeopgave omhandler en konkret
effek_ti_vi_se_ring af et in_struk_tions_sæt
ved indkodninger baserede på må_lin_ger, først og fremmest 
med henblik på pladsbe_spa_rel_se; men med øget afvik_lings_has_tig_hed
som et sekun_dært mål.

Udgangspunk_tet er et ek_si_ste_ren_de in_struk_tions_sæt, som det fin_des
på en RC3502 datamaskine. Instruktions_sættet er bl.a. designet til at 
under_støtte et struk_tu_re_ret høj_niveau sprog til pa_ral_lel_program_me_ring
, PASCAL80, eller som det siden er omdøbt til, REAL TIME PASCAL. 
Instruktionssættet er i øvrigt in_spireret af USCD-PASCAL p-code og
endvidere af ideer fremsat af bl.a. Tanenbaum (@Tan78@) vedrørende design
af in_struk_tionssæt.

Design af et in_struk_tionssæt^ omfatter i princippet to adskilte beslutninger
(@Ste79@):

- Hvilke funktioner skal in_struk_tionssættet ud_fø_re.

- Hvorledes skal in_struk_tionerne indkodes.

Dette skrift omhandler, hvorledes det sid_ste punkt er grebet an i det
konkrete tilfælde, og præsenterer de opnåede re_sultater. De an_vend_te
me_to_der er i før_ste om_gang in_spi_re_ret af Steven_son og Tanen_baum
(@Ste79@) og (@Tan78@), men er udvidet til også at om_fat_te må_lin_ger
af pro_gram_mers dyna_mis_ke in_struk_tions_an_ven_del_se i for_bin_del_se
med for_øget program_af_vik_lings_has_tig_hed, der op_træ_der som et
sekun_dært mål i det_te ar_bej_de.

Specialet er bygget op, så der først med udgangspunkt i et over_ord_net
mål om "performance" foretages en problem_afgræns_ning. Der_ef_ter
drøftes gene_relle me_to_der. Det aktuelle valg af me_to_de præsen_te_res
og den praktiske fremgangs_må_de frem_lægges. De empiriske re_sul_tater
statisk og dynamisk, er bag_grund for en kandidat_liste til indkod_ning.
Denne liste diskutte_res med hen_blik på even_tu_elle ændrin_ger bl.a.
for_år_saget af hyp_pigt fore_kommen_de sekven_ser af instruk_tioner, der
ønskes ind_ko_det til en in_struk_tion pr. sekvens. Endelig frem_kom_mer der her_af en
kandi_dat_lis_te over in_struk_tio_n^er, hvoraf de bedste ind_ko_des. Den sta_tis_ke effekt er
kendt; men den dy_na_mis_ke ef_fekt efter_kon_trol_le_res, da det
even_tuelt kan være nød_ven_digt med fle_re itera_tio_ner før de bed_ste
dy_na_mis_ke kan_di_da_ter er fun_det.

>a2 LÆSER FORUDSÆTNINGER.

For at få det ful_de ud_byt_te af spe_cia_let, er det nød_ven_digt at
have et gene_relt kend_skab til in_struk_tions_opti_mali_serin_ger i
form af ind_kod_ninger. Dette kan f.@eks. opnås ved at læ_se referen_cerne
(@Ste79@), (@Wilc80@). Læseren bør end_vi_dere have et kend_skab til struk_turere_de
højni_veau pro_gram_me_rings_sprog, (@Tan78@), (@Den74@), (@Dij69b@), og spe_cielt væ_re
for_tro_lig med program_af_vik_ling i for_bin_del_se med stak_ke (@stak_ma_ski_ner@),
(@Joh71@).
En_delig er det nød_ven_digt at ha_ve spe_ci_fik vi_den om PASCAL80 og
RC3502, da dette skrift beskæf_ti_ger sig ekspli_cit med disse produk_ter,
uden at re_de_gø_re for de_res struk_tur i de_tal_jer. Referen_cerne (@Lau80@) og
(@Sta80@) kan danne bag_grund her_for, og refe_ren_cen (@Møl81@) vil kunne
an_ven_des som op_slags_værk i de_tail_spørgs_mål ved_rø_ren_de RC3502.

Jeg har bestræbt mig på at anvende dansk terminologi som den fremgår af
Dansk Standardise_rings_råds: EDB_ordbogen (@DSt75@), samt i nogen grad 
sup_ple_ret af Forslag til
Dansk Standard (@DSt80@), vel vi_den_de, at disse for_slag end_nu ikke er
kano_ni_se_ret. Det er dog ikke al_tid mu_ligt at fin_de dæk_kende
dan_ske fag_ud_tryk, og i så_dan_ne til_fæl_de vil jeg benyt_te engel_sk
fag_sprog, der så vil op_træ_de i anførl_ses_tegn.
>a1 PROBLEMSTILLING.
 
RC3502^ er en minidatamat, der er designet spe_cielt med hen_blik
på realisation af strukture_rede høj_ni_veau_sprog^ (@Den74@),
(@Dij60@), (@Dij69a@), (@Dij69b@), (@Tan78@).
Dette af_spej_ler sig især i den måde, mi_kro_pro_grammet er ud_for_met på,
her_under det valg_te instruk_tions_sæt^.
 
>a2 OVERORDNET MÅL.
 
For enhver kommerciel maskine vil konkurrencehensyn  
medføre ønsket om en mere salgbar maskine, hvilket vil sige,
at maskinens pris/ydeevne^ skal forbedres.
 
Tilsvarende har erfaringen ( og Parkinson med Parkinsons Lov )
belært os om, at hvis der findes en række begrænsninger, der danner
en ramme inden for hvilken, et system kan udvikle sig, så vil
systemet hurtigt fylde rammen helt ud. Dette velkendte udviklingsmønster 
betyder for en datamaskine, at dens kapacitet ( lager, central enhed m.m )
vil blive udnyttet til det yderste. Også i sådanne situationer opstår ønsket
om maskinforbedringer, så de snærende rammer vides ud.
 
Pris/ydeevne betyder kort og godt: forholdet mellen em 
maskines pris og dens ydeevne. Mens prisen er noget håndfast
, uanset hvil_ket grund_lag, den er fast_sat på, så er
ydeevne^ et noget mere vagt begreb. Der er adskillige, der har 
forsøgt sig med definitioner af ydeevnen for en datamaskine^.
Det har imidlertid ingen mening at beskæftige sig med ydeevnen som
et totalt begreb. En maskines ydeevne er sammensat af en hel række 
kom_po_nen_ter (@Fer78@), ofte
indbyrdes afhængige, så en forbedring af en komponent medfører
en forringelse af en anden. En forbedring skal altså 
vurderes ud fra nogle rammer, inden for hvilke de enkelte komponenter
kan variere.
 
Jeg vil ikke gå videre i betragtningerne omkring begrebet ydeevne
men i stedet nævne en række komponenter, som ydeevne^n for en RC3502
afhænger af:

- programafviklingshastighed^
 
- lagerforbrug^ ved programafvikling
 
- datamaskinens fysiske adresserum^ ( lager_kapa_ci_tet^@)
 
- fejlhyppighed^ for materiel^
 
- fejlhyppighed^ for programmel^
 
- programudvikling^shastighed og effektivitet

- programlæsbarhed^ ( fleksibilitet^@)
 
- anvendelsesområde^r
 
 
>a2 PRIS/YDEEVNE - FORBEDRINGER.   
 
Forbedringer af pris/ydeevne^ kan opnås på en lang række måder og
på mange forskellige niveauer.
 
Jeg vil i det følgende komme med en række eksempler, der anskueliggør
dette, og samtidig giver en fornemmelse af det enorme omfang og den
emnemæssige spændvidde, en fyldestgørende gennemgang af hele
pris/ydeevne problematikken ville føre med sig. Eksemplerne
er på ingen måde dækkende for hele emnet.
 
>a3 MATERIEL FORBEDRINGER.
 
Indførelsen af nye komponenter i materiellet kan give forskellige former
for forbedringer.
 
- prisreduktion, hvis de er billigere
 
- prisreduktion, hvis de kan udføre mere komplekse funktioner og kan
erstatte et større antal komponenter, der samlet er dyrere. ( Her skal
produktions omkostningerne selvfølgelig også tages i betragtning ).

- hurtigere programafvikling ved indførelse
af hurtigere komponenter. Dette er selvfølgelig afhængig af en række
faktorer - f.eks. om der eksisterer en eller flere flaskehalse
i systemet, som ikke bliver berørt af en komponentforbedring.

- hvis der indføres komponenter, der indeholder
mere lager. Denne forbedring kræver naturligvis, at det 
implementerede system, in_struk_tionsformat m.v., kan gøre brug af den 
øgede lagerkapacitet. Hvis det fysiske lager_rum er bygget modulært op,
som i RC3502, vil færre lagermoduler kunne klare de samme opgaver, 
hvilket giver en prisforbedring.

Hvis frekvens^en af datamaskinens taktsignal kan øges vil yde_ev_nen
nor_malt for_bed_res.

Mi_kromaskine^ns arkitektur kan evt. forbedres ved at tage
udgangs_punkt i de funk_tio_ner, som mi_kro_pro_gram^_met skal
ud_fø_re. For RC3502 er
dette punkt væsentligt. Der er forventninger om, at 
programafviklingen vil kunne foregå 1.5-2 gange så hurtigt med
en mere optimal mi_kro-maskin-arkitektur opbygget over de samme
kredse som nu.
>sp0
 
>a3 SOFTWARE SYSTEM.

På systemsiden kan man nævne betydningen af, at det (@eller de@)
anvendte programmeringssprog tilbyder det nødvendige
værktøj til programmøren og transformerer 
(@over_sæt_ter^@), så de opga_ver ma_ski_nen er bereg_net til kan
løses:

- sikkert

- simpelt ( og dermed hurtigt at programmere )

- effektivt

Dette kan give anledning til forbedringer i sproget og optimaliseringer
i oversætteren. Forbedringerne kan som før nævnt ikke ses løsrevet fra
hinanden. F. eks. vil øget sikkerhed oftest medføre formindsket 
afviklingshastighed, så der er brug for en prioritering af de mål,
der op_stil_les, og en afgræns_ning af de opga_ver, som ma_ski_nen
(@spro_get@) skal anvendes til.

Det basale system skal være effektivt og sikkert. Det er vigtigt, at
det er afpasset til de opgaver, som maskinen er tiltænkt.
Raffinementer i basal_system^et vil ofte med_føre et øget tids_for_brug
i det generelle til_fæl_de, dvs. en lang_som_me_re
programafvikling, f.eks. fordi det basale system er designet med 
henblik på en række specielle funk_tio_ner, som rent faktisk ikke 
bruges.

>a3 INSTRUKTIONSSÆTTET.

Instruktionssæt^tet har stor betydning for yde_ev_ne^n, eller rettere
for en hel række af de komponenter, der tilsammen udgør yde_ev_nen.

Instruktionssættet ( evt. et macrosprog opbygget af in_struk_tionssættets
elementer ) skal være velegnet som 
mål_sprog^
for det eller de sprog, der skal anvendes som programmeringssprog
(Tan78@), (@Cra79@).
En forbedring i denne retning vil muliggøre:

- mere pålidelige oversætter^e og dermed pålidelige programmer

- simplere kodegenerering, og in_struk_tioner, der er dikteret af 
sproglige elementer, vil være mere effektive ( hurtigere at udføre ),
end hvis de skulle erstattes af en hel række in_struk_tioner, for at udføre 
funktionen

- den producerede kode er mere kompakt, så lager_forbruget er mindre

Instruktionssættet skal understøtte det basalsystem, der væl_ges.
Typisk vil det basale system skulle foretage ind- og udkædninger
i køstrukturer. Der kan dels være behov for, at sådanne funktioner foregår
udeleligt, og dels behov for, at funktionerne udføres hurtigt, fordi
de optræder i forbindelse med tidskritiske opgaver, varetaget
af det basale system. Som eksempel kan nævnes afvik_lings_skift mellem
paralelle proceser, hvor proces in_kar_na_tions beskri_vel_sen skal sættes 
ind/tages ud af diverse prioriterede aktivkøer. Til bl.a. dette formål
er der indført in_struk_tioner, som kan indsætte et ele_ment sidst i en kø, hhv. 
udtage et ele_ment for_rest fra en kø. Hvis hele strategien for afviklings_skift^ er fastlagt,
kan man gå et skridt videre og lade en in_struk_tion finde næste proces
in_kar_na_tion, der skal have tildelt køre_tid, for på denne måde at
effektivisere afvik_lings_skift. I RC3502 er netop så_dan_ne funk_tioner indført
i praksis, og afvik_lings_skift mellem proces in_kar_na_tioner, der kører på
niveau 0 ( Lau80 ), hvilket er tilfældet for 'normale' proces
in_kar_na_tioner, er ved denne om_læg_ning (@indkod_ning@) blevet ca. en faktor 10 hurtigere.

Det er væsentligt, at in_struk_tionsformat^et er i overensstemmelse med den
mi_kro maskine, som udfører in_struk_tionerne. Hermed sikres, at en effektiv
afkodning^ af in_struk_tionerne kan finde sted.

Antallet af in_struk_tioner ( in_struk_tions_kom_plek_si_tet^en@) er ligele_des
et vigtigt område, der har nøje sam_men_hæng med:

- in_struk_tionsformatet

- hvilke opgaver, der skal understøttes

- hvilke tids- og pladsmæssige krav, mi_kro_pro_grammet er underlagt

Så længe det drejer sig om velkendte generelle
strukturer/sammenhænge, der skal understøttes i in_struk_tionssættet,
er det forholdsvis enkelt at afgøre, hvorledes dette skal gøres, 
og at vurdere om det er rimeligt at medtage en given facilitet
i in_struk_tionssættet. Men har man først dannet et vist minimalt
( nødvendigt ) in_struk_tionssæt, kan det være vanskeligt at fastlægge,
hvorledes man bedst udvider det_te.

Opgaven går altså ud på , ud fra et givet in_struk_tionssæt, hvormed
implementering er mulig (@in_struk_tionssættet er tilstrække_ligt@), at
op_stil_le mål og begræns_ninger for ud_vi_del_ser.
Herefter at finde kandidater til nye in_struk_tioner og at vurdere, 
hvilke af disse der opfylder målene bedst inden for de givne rammer
( dvs. plads til mi_kroprogram ). Endelig udvides in_struk_tionssættet
med de udvalgte kandidater og de vurderede resultater efterkontrolleres.

Med henblik på mindre lagerforbrug^ og hurtigere programafvikling^
vil mulige kandidater være hyppigt forekommende sekvens^er af
in_struk_tion^er, der kan erstattes af en enkelt in_struk_tion -
sekvens_ind_kod_ning^, og end_vi_de_re
vil hyppigt forekommende in_struk_tioner i forbindelse med bestemte
para_me_ter_vær_di_^er kunne erstattes af nye in_struk_tioner med 
pa_ra_me_terværdien indlejre^t i in_struk_tionskode^n - 
pa_ra_me_ter_ind_kod_ning^. Dette skal ses på
baggrund af et in_struk_tionssæt, hvor in_struk_tionerne har varierende
længde og endvidere er struktureret som en ope_ra_tions_ko_de^ evt. med
efterfølgende parametre.

>a1 PROBLEM AFGRÆNSNING.

I kapitel 2 afdækkede kravet til pris/ydeevne forbedringer en
hel træstruktur af delområder, der hver især kunne være genstand for 
nærmere under_søgel_ser med hen_blik på forbed_ringer.

Jeg vil i det følgende koncentrere mig om den del af problematikken,
der har med forbedringer af in_struk_tionssættet at gøre, og inden for
dette område vil jeg yderligere begrænse mig til spe_cielt  at se på

  - pa_ra_me_terindkodning^

og i beskedent omfang desuden på

  - sekvensindkodning^

>a2 RAMMER OG MÅL.

Jeg vil i det følgende skitsere de rammer som en RC3502^ udgør, samt
op_stil_le de konkrete mål.

>a3 RC3502 RAMMER FOR INSTRUKTIONSSÆTTET.

I det konkrete tilfælde drejer det sig altså om en RC3502 data_maskine^
med et såkaldt "Base Instruction Set" ( Møl81 ). Dette in_struk_tionssæt^
er stort set det nødvendige minimale in_struk_tionssæt. Der er således
ikke foretaget in_struk_tionstilføjelser på baggrund af
pa_ra_me_terindkodning, og kun ganske få, sprogligt bund_ne, sekvens_forekomster er medtaget som
in_struk_tioner (@f.eks. signal, wait, push, pop, lock m.m.@).

Instruktionerne er alle struktureret med en oktet (@8@bit@) til operationskoden.
Hver in_struk_tion^ kan have et antal parametre ( fra 0 og opefter ), der
hver især kan fylde en oktet, et ord (@16 bit@) eller et dobbeltord
(@32 bit@). Parametre
kan enten forekomme i koden (@som direkte parametre@) eller de kan findes
via specielle adresseringsveje (@f.eks. på eksekveringsstakken@)
(@Tan78@), (@Møl81@).

RC3502 har en række registersæt^ (@124@), der hver 
består af 8 16-bit ord.

>ne 24
>fd 18 53
>nf
>ta 20 24
>fb
!TM:!"Max stack displacement"
>fb
!PS:!"Flag bits"
>fb
!LU:!"Last used displacement"
>fb
!LF:!"Local frame displacement"
>fb
!GF:!"Global frame displacement"
>fb
!PB:!"Global frame base"
>fb
!IC:!Instruction base"
>fb
!IB:!"Instruction displacement"
>fe
>fi

>fg RC3502 registersæt.

>tc #
De 6 af disse ord
danner, i forskellige kombinationer, i alt 4 adresser, der har
tilknytning til eksekveringsstak^ken - herunder proces in_kar_na_tions
be_skri_vel_sen, samt til programmet, der udføres.
De sidste to ord bruges til kontrol af stak-overløb samt til diverse
bitflag.

Det bemærkes, at der ikke er nogen form for traditionelt registersæt med 
arbejdsregistre. Der er heller ikke en repræsentation af stakkens
øverste elementer i registersættet. I en tidligere fase var RC3502
forsynet med en 4-ords registerrepræsentation (@"cache"@) af stakken; men
administrationen heraf slugte hastighedsgevinsten i form af
hurtigere tilgang til register_sæt_tene. Der er en hel række af ideer
til registerudnyttelse, der kunne komme på tale i RC3502; men jeg vil
ikke yderligere beskæftige mig med denne problemkreds; men i stedet
konstatere, at registersættet indeholder de nødvendige pege_pin_de til
lage_ret, og at hentning af in_struk_tioner og parame_tre, samt lagring af
resultatet altid foregår til/fra lageret. Med en lagertil_gangs_tid^ på
432 ns i forhold til en registertilgangstid^ på 217 ns,
hvilket vil være den normale forskel,
er der ikke mulighed for med fordel at anvende ret meget tid på at
administrere en eller anden form for regi_ster_re_præ_sen_ta_tion.

Adressering^smæssigt er den mindste enhed, der kan adresse^res en 
oktet. Dette er den væsentligste grund til at operationskoden for en 
in_struk_tion^ fast optager en oktet. Man kunne tænke sig kortere in_struk_tioner
f.eks. 4-bit in_struk_tionskoder, men der ville ikke være sparet noget i
hastighed, idet der skal hen_tes det samme antal bit, som før og oven i
købet vil afkodning^en i mi_kroprogram^met gå langsommere. Desuden vil det 
være nødvendigt at lade en bit indikere, om formatet er 4-bit eller
8-bit, hvilket kraf_tigt begrænser antallet af in_struk_tioner, der kan repræsenteres
(@128 + 8 ved 4- og 8-bits repræsentation mod 256 ved kun 8-bits
repræsentation@).

Der er i "Base Instruction Set" før optimaliseringer i alt ca. 170
in_struk_tioner, hvilket peger på en fast 8-bit repræsentation af 
operationskoden, idet de ca. 86 mulige udvidelser overstiger
de tilføjelser, der i praksis vil komme på tale.

Mi_kroprogrammet findes i et 60 bit bredt 2096 ords permanent lager_område
(@"60 bit 2K PROM"@). Der er kun ret be_græn_se_de
muligheder for at tilføje nye in_struk_tioner. Den type nye in_struk_tioner,
der fylder mindst, er dem, der fremkommer ved pa_ra_me_ter_indkodning, idet
in_struk_tionen uden pa_ra_me_ter^indkodningen i al væsentlighed kan genbruges.
Det at tilføje nye in_struk_tioner er altså en metode, der er kraftigt 
begrænset af pladsen, som mi_kroprogram^met skal
holdes inden for, og det er derfor vigtigt, at det er de rigtige 
kandidater, der vælges som nye in_struk_tioner.

>a3 MÅL MED INSTRUKTIONSTILFØJELSER I RC3502.

Det overordnede mål^ for in_struk_tionstilføjelserne er som nævnt i
kapitel 2 pris/yde_ev_ne forbedringer. Dette mål kan i denne forbindelse
udtrykkes ved følgende:

  - mindre lagerforbrug^

  - hurtigere programafvikling^

I det føl_gende skal disse mål være vejledende i val_get
af kandidater.

For at kunne vurdere hvilke in_struk_tion^er med tilhørende pa_ra_me_terværdier,
hhv. in_struk_tions_sekvenser, der bør være kandidater, er det nødvendigt at
kende noget til in_struk_tions_hyppighed^er i forbindelse med pa_ra_me_terværdier,
samt til instruk_tions_se_kvens_hyppighed^er.

De to opstillede mål er ikke umiddelbart forenelige, idet mindre
lagerforbrug hænger nøje sammen med den statiske in_struk_tionshyppighed,
hvorimod hurtigere programafvikling hænger nøje sammen med den dynamiske
in_struk_tionshyppighed. Det er altså ikke givet, at det er de samme
kandidater, der viser sig at tilgodese de to mål.

Vi skal siden se på, at kandidater, der pa_ra_me_terindkodes, bidrager
mest til pladsreduktion, hvorimod kandidater, der sekvensindkodes i
højere grad bidrager til en hurtigere programafvikling.

Jeg vil i det føl_gende mest beskæftige mig med parame_ter_ind_kod_ning.

>a1 PARAMETERINDKODNING - METODE.

Selve indkodningsmetode^n er velkendt og bl.a. beskrevet af Tanenbaum
og Stevenson
( Ste79 ). Den går i store træk ud på at danne nye in_struk_tion^er ud fra
allerede eksisterende in_struk_tioner ved at lade en værdi af en eller flere 
parametre være implicit indlejret i operationskodeværdien.

>a2 EKSEMPEL PÅ PARAMETERINDKODNING I RC3502.

Fra RC3502 kunne man som eksempel nævne in_struk_tionen RECHW (@"REtrieve
Constant Here Word"@), der som pa_ra_me_ter har konstanten 1. Denne in_struk_tion
med tilhørende pa_ra_me_ter vil i koden fremtræde som (@i hexadecimal notation
@): 82 00 01. 

Hvis RECHW skal bruges til pa_ra_me_terindkodning, vil der altså 
fremkomme en ny in_struk_tion, der f.eks. kunne fremtræde som ( i hexadecimal
notation ): 8F.

>a3 BETRAGTNINGER I FORBINDELSE MED EFFEKTEN.

Der er tale om en besparelse på to ud af tre oktetter.  
Man kan altså spa_re et ord (@16 bit@), dvs. 66@% pr. gang
in_struk_tionen forekommer i den kode, der er placeret i lageret
på RC3502 (@statisk fore_komst@).
Hvad angår en forøget hastighed i programafviklingen, kan man se,
at der spares en hentning fra la_ger af pa_ra_me_teren, der nu i stedet
skal afkodes ud fra in_struk_tionskoden. Den nye in_struk_tion vil i øvrigt
forløbe som den oprindelige in_struk_tion. I eksemplet med RECHW
kan man beregne, at den nye in_struk_tion vil tage ca. 4,3 mi_krosek. mod
oprindeligt 6,0 mi_krosek. Der er altså tale om en besparelse på ca. 28,3 %
på denne in_struk_tion. Med min_dre det viser sig, at in_struk_tionen ud_fø_res
(@dynamisk fore_komst@) relativt langt hyp_pi_ge_re end den fore_kom_mer
statisk, vil en pa_ra_me_ter_ind_kod_ning
altså have størst indflydelse på lagerforbruget.

>a2 EFFEKTVURDERING OG BAGGRUND FOR KANDIDATVALG.

Hvor stor en effekt en pa_ra_me_terindkodning vil få på lagerfor_bru_g^et,
kan vurderes ud fra den hyppighed, hvormed in_struk_tionen med tilhørende
pa_ra_me_ter_vær_di_kon_stel_lation forekommer i den sta_tis_ke ko_de, som
over_sæt_teren genererer. Opsamlingen af en sådan hyppighed
kan foretages i over_sæt_teren, der skal være i stand til, pa_ra_me_terstyret,
at lave en regi_stre_ring af instruk_tions_hyp_pig_he_d^er, og endvidere skal det
være muligt at angive pa_ra_me_ter_in_ter_val^_ler, så de få kandidater, det
kan komme på tale at indkode, relativt nemt kan indkredses. En mere 
detaljeret beskrivelse af en sådan opsamling følger senere (@kapitel 5@).

Når effekten af en pa_ra_me_terindkodning med hensyn til en hurtigere
program_af_vik_ling^ skal vurderes, er det som før omtalt antallet af gange,
den pågældende in_struk_tion med den bestemte para_me_ter_værdi_kon_stel_la_tion^
udføres i forhold til andre in_struk_tioner, der kan give grundlaget for
vurderingen, og hvis det af forskellige grunde er en hastighedsgevinst,
der prioriteres højest i forhold til en besparelse i lagerforbrug, er 
det altså nødvendigt at tilvejebringe information om den dynamiske
hyppighed for in_struk_tioner opdelt passende på forskellige 
para_me_ter_vær_di_kon_stel_la_tio_ner,
for at kunne udvælge de kandidater, der bedst 
opfylder målsætningen.

Det skal her bemærkes, at kandidatudvælgelsen både i det statiske og i
det dynamiske tilfælde også involverer en vurdering af pladsforbruget
i mi_kro_pro_gram^met, idet kandidater nede i rækken meget vel
sammenlagt kan give en større gevinst end tilsyneladende mere
oplagte kandidater, hvis de er tilstrækkeligt billige, pladsmæssigt, at
indføre i mi_kroprogrammet.

>a2 GRUNDLAGET FOR OPSAMLING.

Der rejser sig en hel række spørgsmål og problemer, der skal tages
stilling til både i forbindelse med den statiske opsamling og især i
forbindelse med den dynamiske opsamling.

En hel række komponenter kan have inflydelse
på resultatet af de opsamlinger og vurderinger, der danner grundlag for
kandidat_ud_væl_gel_se^n. Det er vigtigt at finde frem til disse komponenter
og dernæst sikre, at de komponentfastsættelser, der er foretaget i
forbindelse med opsamlingerne, er rimelige i forhold til de anvendelser,
RC3502 er tiltænkt, samt eventuelt vurdere, hvorledes resultaterne 
ændrer sig i forhold til variationer på de enkelte komponenter.

I det følgende vil jeg fremhæve, hvilke komponenter, der kan formodes
at have en betydning for resultaterne af de statiske og dynamiske 
opsamlinger. Samtidig vil jeg forsøge at trække paralleller til 
tilsvarende undersøgelser, der har relevans for pa_ra_me_terindkodning 
mere generelt.

>a3 PROGRAMGRUNDLAGET.

Forskellige programmer kan give hvert sit bil_le_de af den sta_tisk^e
henholdsvis den dy_na_mis_k^e in_struk_tionsfor_de_ling^. Det er f.eks. klart, at 
der vil være forskel på anvendelse af "I/O"-in_struk_tioner i programmer, der
foretager "I/O" og programmer, der ikke gør det. Når programmer til under_sø_gel_se af 
pa_ra_me_terindkodning skal findes, er det således vigtigt, at programmerne
i en eller anden forstand er repræsentative for de anvendelsesområder,
som indkodningen skal have størst effekt på. Det er dog muligt, at denne
problemstilling er for enkel, for det er tænkeligt, at også den 
programmeringsstil, der anvendes, kan have indflydelse.
 
Da disse afhængigheder i denne sammenhæng kun har relevans for nogle få
særligt hyppigt forekommende in_struk_tioner og herunder forekomst med
bestemte pa_ra_me_ter_vær_di_kon_stel_la_tioner, er det imidlertid langt fra
givet, at disse afhængigheder spiller nogen nævneværdig rolle for
de resulterende kandidater.

>a4 PROGRAMKLASSER.

Når man taler om programklasse^r, må man gøre sig klart, hvor_le_des det
af_gø_res, om pro_gram_mer er i samme klas_se el_ler ej. For at kun_ne
gø_re det_te må man for det før_ste be_stemme ni_veau_et for
sammen_lig_nin_gen og der_næst fast_læg_ge kri_te_rier for for_skel 
henholds_vis lig_hed mel_lem pro_gram_mer.

Val_get af niveau består, lidt mere formelt udtrykt, i at væl_ge en model
hvori mæng_den af pro_gram_mer kan para_me_tri_se_res med hen_blik på
en under_sø_gel_se af for_skel/lig_hed. Valget af ni_veau, der
sam_men_lig_nes på (@valg af para_me_tri_se_ring@), kan være af_gø_rende
for, hvor_le_des re_sul_ta_tet af sam_men_lig_nin_gen fal_der ud. Med
andre ord kan pro_grammer, der er ens på et ni_veau af para_me_tri_sering,
vi_se sig at være for_skel_li_ge på et an_det, og pro_grammer, der
på et ni_veau er for_skel_lige kan vi_se sig at væ_re ens på et an_det.
Der kan være man_ge mu_lig_he_der for mo_del_valg med til_høren_de
para_me_tri_se_ring. Disse mo_del_ler kan i prak_sis ord_nes  ef_ter
detal_je_rings_grad med yder_punk_ter_ne: mængden af PASCAL80 programmer
henholds_vis en total opsplitning af pro_gram_mer ef_ter an_ven_del_se
af instruk_tions_para_me_ter_vær_di_er. (@begge yder_punk_ter er
uan_ven_de_li_ge i prak_sis@).

Ved overgang fra en mindre til en mere detaljeret model vil jeg ved
fu_sion^ for_stå, at pro_gram_mer, der før over_gan_gen var for_skel_li_ge,
bli_ver ens, og ved dif_fu_sion^ vil jeg for_stå, at pro_gram_mer, der
før over_gan_gen var ens, bli_ver for_skel_li_ge. Neden_stå_en_de fi_gur
illu_stre_rer begre_ber_ne på nog_le til_fæl_digt valg_te ni_veau_er.
>ne 20
>in 4
>ti 10
repræsentationsniveau

>ti 20
!
>sp0
in_struk_tionsniveau@@!@@@@@@@@@@@o@@o@@o@@o
>in 20
!
>sp0
!
>in-20
passagemellemsprog@@!@@@@@@@@o@@o@@o@@o
>in 20
!
>sp0
!
>in-20
sprogkomponentniveau!@@@@@o@@o@@o@@o
>in 20
!
>sp0
!
>in-20
sprogniveau@@@@@@@@@!@@o@@o@@o@@o
>in 20
!
>sp0
!
>in-20
 -------------------+----------------> program
>in 39
klasser
>in-39

>fg Klassefu_sion/klassediffu_sion
>in-4

Diffu_sion må for_ventes, og hvis de enkelte para_me_tre er kor_re_le_rede
(@i for_bin_del_se med senere detal_je_ring af mo_del_len@), kan fu_sion
og_så fore_kom_me.

Ved undersøgelsen af om programunderlaget er funk_tions- og/eller
per_son_af_hæn_gigt, vil ud_gangs_punk_tet væ_re pro_gram_mø_rens valg
af sprog_li_ge kon_struk_tio_ner, der i en sammen_sæt_ning kan lø_se
de funktio_nel_le krav, der er stil_let. For_skel/lig_hed mel_lem
pro_gram_mer_ne ta_ger alt_så sit ud_gangs_punkt i anven_del_sen af
sprog_li_ge kom_po_nen_ter (@pro_gram_mets sprog_pro_fil^@), i en eller
anden fast_lagt detal_je_rings_grad.

Set i lyset af fu_sion/dif_fu_sion vil en sprog_pro_fil sammen_lig_ning
dog ik_ke være til_stræk_ke_lig til at af_gø_re, om pro_gram_mer
an_ven_der de hyp_pigst fore_kom_men_de para_me_ter_vær_di_kon_stel_la_tioner
ens eller for_skel_ligt. Model_len der sam_men_lig_nes i må væ_re 
me_re de_tal_je_ret, dvs. tæt_te_re på den mo_del, hvori re_sul_ta_terne
skal an_ven_des. En sammen_lig_ning på grund_lag af pro_gram_mers sta_tiske
an_ven_del_se af de enkel_te in_struk_tio_n^er er bed_re. Denne gi_ver en
mo_del, der er til at arbej_de med, og para_me_tri_se_rin_gen er
ukor_re_leret i rela_tion til en yder_lige_re de_tal_je_ring af model_len.

Det skal bemærkes, at programmers sprog_pro_fil^_er kan have inter_esse
af an_dre grunde end program_grup_pe_rin_ger:

- Med kend_skab til pro_grammers sprog_pro_fil og til sprog_kom_po_menters
omsæt_ning til ko_de, er der mu_ligt at af_dæk_ke se_kven_ser af (@eller
kob_lin_ger mel_lem@) instruk_tioner, der med for_del kan ind_ko_des.

- Ved sprogre_vi_sio_ner er det mu_ligt at for_ud_si_ge ind_virk_nin_gen
på alle_rede fore_tag_ne se_kvens- og para_me_ter_ind_kod_nin_ger.

Hvis fu_sion/dif_fu_sion mellem sprog_kompo_nent_ni_veau_et og
instruk_tions_ni_veau_et er fuldt af_dæk_ket, kan det ved pro_gram_me_ring
af nye sy_ste_mer være lette_re at under_søge, om der er ta_le om en ny
program_klas_se (@evt. med krav til nye ind_kod_nin_ger@) eller ej.

Programmers sprogprofiler kan op_sam_les både sta_tisk og dy_na_misk.
Andre under_sø_gel_ser ((Knu71) for FORTRAN og (Der74) for BCPL) viser
stor sammen_hæng mel_lem pro_gram_mers dy_na_mis_ke og statis_ke
pro_gram_pro_filer, så der er god grund til at tro, at det_te og_så
gæl_der for PASCAL80 på RC3502. Jeg vil i det føl_gen_de ikke kom_me
yder_li_ge_re ind på pro_gram_mers sprog_pro_fi_ler, men over_lade det_te
em_ne til vi_de_re stu_di_er.

>a3 PROGRAMMERINGSSPROGET.

Det er klart, at programmerings_sprog^et kan have indflydelse på, 
hvilke kandidater, der skal udvælges til pa_ra_me_terindkodning. Ved at
se på undersøgelser foretaget på forskellige sprog, FORTRAN (@Knu71@),
COBOL (@Sal75@), XPL (@Ale75@), SAL (@Tan78@), BCPL (@Der74@) viser
det sig således, at der er markante forskelle i programprofiler
specielt mellem procedure- og ikke-procedureorienterede sprog, men der
er ingen undersøgelser der har fastslået, hvordan sprogdesign hænger 
sammen med programprofiler - endsige med in_struk_tionsanvendelsen.

Der eksisterer kun et systemsprog, PASCAL80^, til RC3502^. Dette betyder,
at kandidater til pa_ra_me_terindkodning i RC3502 ikke påvirkes af
forskellige sprog, med deraf følgende eventuelle forskellige 
in_struk_tionsanvendelser. Ved sprogæn_drin_g^er kan fornyede 
kandidatundersøgelser være nødvendige med mindre, der er af_dæk_ket
en sam_men_hæng mel_lem sprog_kom_po_nen_ter og kan_di_da_ter, så
virk_nin_gen af sprog_æn_drin_ger evt. kan for_ud_si_ges.

Det er værd at nævne, at den indflydelse som sprogdesignet kan have
på en kandidatudvælgelse er en væsentlig årsag til overhovedet at foretage
analyser af in_struk_tionsopsamlinger fra RC3502 programmer, idet man ellers
kunne overføre de resultater, som andre har fundet, direkte til RC3502
programmer.

>a3 DET BASALE SYSTEM.

Det basale system kan have indflydelse på kandidater til 
pa_ra_me_terindkodning på flere måder:

- Det er programmeret i PASCAL80^ og indgår som sådan i det, der i afsnit
4.3.1 kaldtes programunderlaget, og vil blive behandlet herunder.

- Det basale systems struktur kan tænkes at påvirke in_struk_tionsanvendelsen.
Adresseringspa_ra_me_terværdier kan f.@eks. påvirkes af den
lager_til_de_ling, der anvendes. Her tænkes specielt på adressering
relativt til staktoppen - f.@eks. "REVSA <displacement>" (@MØL81@) - hvorimod
adresseparametre er uinteressante, fordi koden er flytbar og adres_se^r først
tillægges værdier på ind_læs_ningstidspunktet (@el_ler ved "crosslink_ing"@). Den
dynamiske in_struk_tionshyppighed vil sikkert være ret afhængig af, hvilke
in_struk_tioner der indgår i "monitor dummy-loop", uden at det i sig selv
må få indflydelse på valget af kandidater.

- I lighed med sprog kan det basale system bruges på forskellig vis.
Det er f.@eks. uforudsigeligt, hvordan prioriteringssystemet for proces
in_kar_na_tioners afvikling vil blive brugt. Denne variationsmulighed i 
anvendelsen får specielt betydning for den dynamiske opsamling.

For så vidt at det basale system for RC3502 er fastlagt, vil de to sidts_nævn_te
punkter nævnt ovenfor stort set ikke indgå som komponenter, der påvirker
kandidatanalysen. Dette skyldes, dels at nogle af påvirkningerne med
det basale systems fastlæggelse bliver konstante, dels at andre af 
påvirkningerne kun berører den dynamiske opsamling, og det er for
pa_ra_me_terindkodningen specielt den statiske opsamling, der lægges vægt
på. Desuden vil den dynamiske påvirkning indgå som en del af den
dynamiske analyse af in_struk_tionsanvendelser. Hvad angår det første
af ovenstående punkter, vil det basale system indgå som et led i
program_un_der_sø_gelserne.

Det skal bemærkes at ændringer i det basale system kan medføre, at der
bør foretages nye op_sam_lin_ger af statis_tisk mate_ria_le.

>a3 MATERIEL STRUKTUR.

I lighed med det basale system, kan ma_te_ri_ellets struk_tur have betydning for 
in_struk_tionsanvendelsen. Dels er der i in_struk_tionssættet in_struk_tioner,
der direkte understøtter ma_teri_ellets struk_tur, f.eks register_sæts 
manipulationer, dels kan der i forbindelse med f.eks. "I/O" ske det, at
enkelte in_struk_tioner indgår hver gang, der skal sættes omgivelser op
til "I/O" in_struk_tioner, uden at disse in_struk_tioner ellers direkte afspejler
en ma_te_ri_el betinget funktion.

Som for det basale system gælder det for mate_riellets struk_tur, at den
er en konstant påvirkning, der ikke bliver behandlet yderligere i
forbindelse med disse undersøgelser; men ændringer i ma_te_riel_let kan medføre,
at der skal foretages nye opsamlinger.

>a3 KODEGENERERINGEN.

Det er klart, at over_sæt_terens kode_gene_rering^ har indflydelse på 
in_struk_tionsanvendelsen. Jeg vil imidlertid gå ud fra, at den genererede
kode er den nødvendige og optimale, hvad angår plads- og tidsforbrug på
grundlag af det basale in_struk_tionssæt.

Under arbejdet med at finde kandidater, vil over_sæt_teren være en konstant
komponent, og de indkodningsændringer, der bliver indført, vil hver især
bevirke en opsplitning af en enkelt in_struk_tion^s hyppighed i to 
in_struk_tioner, hvis samlede hyppighed er den samme som den oprindelige
in_struk_tions hyppighed var før indkodningen. Der er altså ingen 
sideeffekter, der kan påvirke andre kandidaters hyppigheder og dermed
ingen grund til fornyede undersøgelser ved ændringer i forbindelse med
pa_ra_me_terindkodning.

På den anden side kan ændringer i kodegenereringen derudover få 
indflydelse på kan_di_dat_valg^, og det er her nødvendigt i hvert enkelt
tilfælde at overveje, om en ændring kan fjerne grund_laget for en 
pa_ra_me_terindkodning. Et eksempel kan belyse dette.

>ex Indkodningsinterferens^.

følgende kode er produceret af over_sæt_teren:

>in4
RECHW 2           ( "retrieve constant" 2 )
>sp0
ADD
>in-4

Sekvensen

>in4
RECHW <a>         ( "retrieve constant" <a> )
>sp0
ADD
>in-4

viser sig måske generelt at forekomme så hyppigt, at der er basis for
at indføre in_struk_tionen

>in4
ADDCONST "a"
>in-4

Lad os antage, at in_struk_tionen

>in4
RECHW 1           ( "retrieve constant" 1 )
>in-4

er blevet pa_ra_me_terindkodet til

>in4
RECONE
>in-4

Desuden viser det sig, at sekvensen

>in4
RECONE
>sp0
ADD
>in-4

med fordel kan sekvensindkodes til 

>in 4
ADDONE
>in-4

Vi har altså følgende nye in_struk_tioner

>in4
RECONE
>sp0
ADDCONST <a>
>sp0
ADDONE
>in-4

Situationen kan nu meget vel være den, at begrundelsen for at 
pa_ra_me_terindkode RECONE falder bort med indførelsen af ADDONE, hvis
forekomsten af RECHW 1 uden efterfølgende ADD er sjælden.

Det skal bemærkes, at pa_ra_me_terindkodningen kan have en uheldig indvirkning
på sekvensindkodninger. I det foregående eksempel endte vi op med at
fjerne RECONE igen. Da ADDONE er en delmængde af ADDCONST "a" kunne
det være tilfældet, at tilføjelsen ADDCONST "a" var tilstrækkelig, idet
indkodning af andre kandidater ville give større effekt end udsplitningen
i ADDCONST <a> (@a<>1@) og ADDONE.

Omvendt kan sekvens_indkodning før para_meter_ind_kod_ning være uhel_dig.
Hvis sekvens_ind_kod_ningen ADDONE er indført, kan det be_ty_de, at
RECONE ikke ind_føres til trods for, at plads_be_sparel_sen ved at væl_ge
RECONE uden ADDONE kunne væ_re stør_re.

Eksemplet viser også, at der er en risiko for, at en mere generel sekvens
ikke opdages som kandidat. Dette ville være tilfældet hvis ADDCONST
hvor (@a<>1@) ikke var hyppig nok til at være kandidat, men
dog hyppig nok til at sekvensindkodningen ADDCONST "a" (@for alle a@)
er at foretrække frem for kun at tilføje ADDONE.

Alt i alt viser ovenstående, at skønt pa_ra_me_terindkodning set isoleret
i forbindelse med kode_ge_ne_rering ikke volder problemer, så er der al 
mulig grund til omtanke i sam_men_hæng med se_kvens_ind_kod_ning.

>a2 STATISKE OG DYNAMISKE OPSAMLINGSMETODER.

Der findes i litteraturen mange eksempler på statiske og dynamiske
opsamlingsmetoder. Opsamlinger af den sta_tisk^e for_de_ling af
in_struk_tions_hyppighed^_er volder ikke de store problemer og vil f.eks. kunne
bygges sammen med over_sæt_terens kodegenerering. Der er ingen usikkerhed
introduceret af måleforstyrrelser, så det er enkelt at lade opsamlingen
være dikteret af forskellige kriterier (@f.eks. fastlæggelse af
pa_ra_me_terværdiforekomster@). Det er straks mere problematisk at foretage
dynami_sk^e målinger. Resultaterne vil være dataafhængige, og hvis
målingerne gøres mere differentierede, forøges risikoen for at selve
målingen forstyrrer resultatet. De dynamiske målinger, der er eksempler
på i litteraturen er da også meget simple, og der er i stedet etableret
en sammenhæng mellem den statiske og den dynamiske opsamling. Den hyppigst
anvendte metode er tilsyneladende "blok-tæl_ling^s-me_to_den" (@Der74, Knu71@)
der vil blive præsenteret herunder.

>a3 BLOK-TÆLLINGS-METODEN.

Metoden bygger på, at et oversat program består af en række fundamen_tal_blok^_ke
(@på in_struk_tionsniveau@) med den egenskab at samtlige in_struk_tion^er
i en fundamentalblok udføres lige mange gange. Det er muligt statisk at
afdække denne blokstruktur (@f.eks. i over_sæt_teren@).

Metoden består ganske enkelt i, at der i hver fundamentalblok indsættes
in_struk_tioner, der identificerer blokken og tæller op hver gang blokken
udføres. Med en tilsvarende identifikation og med disse tællere kendt
kan det statiske opsamlingsprogram (@f.eks. over_sæt_teren@) foretage alle
mulige statiske analyser, hvorefter den dynamiske analyse blot består
i at gange passende op med de opsamlede tællere.

>a4 DISKUSSION AF BLOKTÆLLINGSMETODEN.

Metodens mest oplagte fordel er at har man først en gang foretaget
den dynamiske opsamling af tællere, så vil der til enhver nok så
differentieret statisk opsamling straks kunne produceres den tilhørende
dynamiske opsamling.

Måleforstyrrelserne i den dynamiske opsamling er konstante, og det
ekstra bi_drag, der introduceres af målingerne er ret beskedent. (@Der74@)
vurderer metoden anvendt i BCPL til at påvirke programafviklingen
med mindre end en faktor 3 . I et tidstro system må man dog være
opmærksom på, at resultatet kan være forvrænget af målingen. Hvis
in_struk_tions_sættet er udvidet med en speciel in_struk_tion
der foretager iden_ti_fika_tion og optæl_ling, kan program_afviklings_hastigheden
holdes noget mere tids_tro. (@Der74@) angiver en hastighedsreducering
på 30-50 % i de BCPL undersøgelser, der er foretaget under sådanne
omstæn_dig_heder.

Metoden har den ulempe, at det er nødvendigt at gen_over_sæt_te
de programmer, der ønskes målt, og desuden vil den producerede kode 
fylde mere. Hvis læng_den af den gennemsnitlige fundamentalblok fra BCPL på
ca. 5 in_struk_tioner kan overføres og optællingen består af 4 in_struk_tioner
der fylder 13 oktetter, så nærmer stigningen i lagerforbruget sig de 100 %.
Dette kan i visse tilfælde medføre, at forskellige fysiske begrænsninger
overskrides (@f.eks. lagerkapacitet@), så den dynamiske måling er
umulig. Specialin_struk_tioner til optællingen kan også bringe det ekstra
pladsforbrug i koden ned. (@Der74@) angiver således et øget lagerforbrug på
30-50 % ved undersøgelser af BCPL under sådanne omstændigheder.

>a3 MATERIEL SNUSER.

Det er muligt, at konstruere ma_te_ri_el, der kan tilkobles mi_kromaskinen
og parallelt med hent_ning af instruk_tion^er_ne lave opsam_ling over de
dynamiske anvendelser.

Et sådant materiel kan afhængig af in_struk_tionen anvendes til dynamisk
opsamling af in_struk_tionshyppigheder med forskellige betingelser på
opsamlingen. Det opsamlede materiale skal herefter kunne be_ar_bej_des med
henblik på statistiske analyser.

Metoden har den oplagte fordel, at programafviklingen ikke forstyrres,
samt at et kørende program kan udsættes for statistikopsamling uden
at programmerne skal gen_over_sæt_tes. Det er til gengæld vanskeligt at få
en måling fordelt på de indgående proceser, og det vanskeliggør muligheden
for at sammenholde de dynamiske opsamlinger med de statiske.

Metoden kræver som nævnt materieludvikling, og det er uden for mine
muligheder at skaffe et sådant udstyr.

>a3 OPSAMLING FRA MIKROPROGRAMMET.

RC3502^ er mi_kroprogrammerbar^, og en opsam_ling^ foretaget af mi_kroprogrammet er derfor
en mulighed. Det er ikke umiddelbart klart, hvor mange opsamlingskriterier
der skal kunne styre opsamlingen; men for at knytte forbindelsen til den
statiske opsamling, er det nødvendigt at kunne styre opsamlingen på
proces-in_kar_na_tions-niveau.

I lighed med bloktællingsmetoden introduceres en ændring i
afviklingshastigheden. Da der er tale om et tidstro system, er det 
vigtigt at holde denne forsinkelse nede på et minimum. Endvidere er det
vigtigt at kontrollere, at forsinkelsen ikke influerer 'drastisk'
på proces afviklingen. En sådan kontrol kan evt. fås ved at sammenholde 
"I/O"-af_vik_lingen med og uden opsamling; men med øvrige forhold konstante.
Endvidere kan man sammenholde opsamlinger fra den samme proces, hvor
der kun er varieret på antallet af øvrige proceser, der foretages 
opsamling fra. Sådanne opsamlinger skal helst være sammenfaldende.

Metodens styrke ligger i øvrigt først og fremmest i at opsamlingen kan
foretages uden gen_over_sæt_tel_ser. Der skal derimod foretages en 
mi_kro_pro_gram_ud_skift_ning^ og en sikring af lagerkapacitet til opsamlingen.
Dette kan i en RC3502^ gøres meget nemt.

>a3 ØJEBILKSBILLEDER.

Opsamlingen af in_struk_tionshyppigheder under diverse betingelser kan
foretages, som øjebliks_bil_lede^r, ved med 'jævne' mellemrum at lade en proces 
opsam_le in_struk_tionshyppigheder, under de anførte be_tin_gelser, ved at se på
den in_struk_tion, som in_struk_tionspegepinden udpeger ( for RC3502 er der
en pr. registersæt ), og så optælle på basis heraf.

Fordelen er, at måleforstyrrelsen kan formindskes ved at lade tidsrummene
mellem opsamlingerne være længere, og desuden kan en øget nøjagtighed
opnås ved at opsamle over en længere periode.

Der er imidlertid et par problemer forbundet med metoden:

- In_struk_tioner har forskellige udførelsestider, så hvis processen, der 
opsamler in_struk_tionshyppigheder, aktiveres tidsafhængigt, skal 
resultatet korrigeres i forhold til in_struk_tionens udførelsestid. Dette
er f.eks. ikke let ved "I/O"-blokin_struk_tioner, hvis samlede in_struk_tionstid
er dataafhængig. Opsamlingen bør derfor kobles til hent_ning af in_struk_tio_ner, hvis
dette er muligt ( dette er ikke tilfældet i RC3502@).

- Opsamlingstidspunkterne skal være uafhængige af procesafviklingen i
øvrigt, så man ikke risikerer en skæv fordeling f.eks. fordi opsamlingen
kunne være korreleret med bestemte basal-sy_stem-opgaver eller bestemte dele
af en løkke. En opsamling, der udføres for hver N'te in_struk_tions hent_ning,
virker i den forbindelse rimelig; men antal_let af udførte in_struk_tioner er ikke
program_til_gængelig i en RC3502.

- Metoden er ik_ke ek_sakt. Det kan være svært at afgøre hvilke fejlgrænser
en måling er behæftet med, hhv. hvor læn_ge, der skal op_sam_les.

>a2 STATISKE OG DYNAMISKE INSTRUKTIONSHYPPIGHEDER.

Sammenhængen mellem et programs statisk^e udseende og den dyna_misk^e 
afvikling er ikke umiddelbar indlysende. I det hele taget er den dynamiske
afvikling i et multiproces-sy_stem^ alt andet end overskuelig. Jeg vil i
det følgende se lidt nærmere på disse emner.

I afsnit 4.4.1 blev blok-tælling^s_metoden præsenteret. Med denne som 
udgangspunkt kan den statiske og den dynamiske in_struk_tionshyppighed
formaliseres:

Lad in_struk_tionerne være betegnet

 Ij,  j c M

hvor M = (mængden af in_struk_tionskodeværdier).
Lad
an_tal_let af funda_men_tal_blok_ke være B. Lad
Sj være den statiske forekomst af in_struk_tionen Ij og
Sjk være den statiske forekomst af in_struk_tionen Ij i den k'te
fundamentalblok (@jvf. 4.4.1@).

Lad tilsvarende den dynamiske forekomst af in_struk_tionen Ij, hhv. totalt
og i den k'te fundamentalblok være:

 Dj   hhv   Djk

Vi har da:
      B
 Sj =    Sjk
     k=1
Lad nu Nk være det antal gange den k'te fundamentalblok udføres, så gælder:
      B         B
 Dj =    Djk  =    (Nk * Sjk)
     k=1       k=1
Med hensyn til pa_ra_me_teranvendelse gælder der videre:

Det er muligt at nummerere alle kombinationer af pa_ra_me_terværdier hørende
til en in_struk_tion Ij. Lad l symbolisere denne nummerering i det følgende,
hvor

 0 = l = pa_ra_me_terkombinationsantallet for Ij = P

Vi definerer Sjkl hhv. Djkl som antallet af forekomster af in_struk_tionen
Ij i den k'te fundamentalblok med pa_ra_me_terværdikonstellationen l i det
statiske hhv. det dynamiske tilfælde.

Vi har

>ne5
        P

 Sjk =@@@@@Sjkl

       l=0

henholdsvis

>ne5
        P               P
 
Djk =@@@@@Djkl = Nk *@@@@@Sjkl

       l=0             l=0

Indføres dette, fås:

>ne5
       B@@@@@@@@@B@@@@@P

 Sj =@@@@@Sjk =@@@@@@@@@@@Sjkl@@@@@@@og

      k=1@@@@@@@k=1@@@l=0

>ne5
       B@@@@@@@@@@@@@@B@@@@@@@@P

 Dj =@@@@@Nk * Sjk =@@@@@Nk *@@@@@Sjkl

      k=1@@@@@@@@@@@@k=1@@@@@@l=0


Når det drejer sig om at vælge kandidater til pa_ra_me_terindkodning, er
det som tidligere omtalt i afsnit 4.4.1 de hyppigt forekommende 
para_me_ter_værdier (@eller evt. klasser af pa_ra_me_terværdier@) i den statiske 
opsamling, der har interesse. Dette vil i den indførte terminologi
sige, at interessen samler sig om:

>ne5
        B

 Sjl =@@@@@Sjkl

       k=0

eller eventuelt om summen over klasser af kombinationer. Lad f.eks.
U være en sådan klasse. Det drejer sig så om

>ne5
                 B

>ti5
Sjl =@@@@@@@@@@Sjkl

>ti1
l@U@@@@@@@l@U@ k=0

Skal man vurdere effekten af en pa_ra_me_terindkodning med henblik på
en hastighedsgevinst, skal man have viden om

>ne5
                 B               B

>ti5
Djl =@@@@@@@@@@Djkl = @@@@@@@@@(Nk * Sjkl)

>ti1
l@U@@@@@@@l@U@ k=0@@@@@@@@@l@U@@k=0

En sådan vurdering er altså kun mulig med kendskab til Nm m=0,...,B.
Tilsvarende, hvis hastig_heds_for_ø_gel_sen prioriteres højt, vil et kendskab
til Nm, m@=@0,...,B, også danne grundlaget for kandidat_udvæl_gelsen.

Det er imidlertid et spørgsmål, hvor stabil den dynamiske statistik er.
De optalte faktorer Nm, m = 0,...,B for fundamentalblokkene har sprogligt
set sammenhæng med antallet af kald af procedurer / funktioner, antal
gange repeterende konstruktioner udføres (@f.eks. i FOR- og REPEAT-sætninger@).
Disse antal bliver igen for det enkelte program ofte bestemt
af omgivelserne og dynamiske målinger på det enkelte program kan derfor
forventes at variere inden for ret vide grænser. Denne variation kan
blive endnu mere udpræget når der er tale om forskellige programmer,
der f.eks tilhører samme programklasse.

På baggrund af disse overvejelser finder jeg, at det kan være direkte
fejlagtigt at basere sig på ind_vik_lede dynamiske opsamlingsmetoder.
Der i vir_ke_lig_heden er usikre og måske med fordel kan er_stat_tes af 
estimeringer i forbindelse med efterkontrol.
>a1 PARAMETERINDKODNING I RC3502.

Parameterindkodning^ens tre faser består i kandidatudvælg_el_se^, udvidelse
af in_struk_tionssættet med de udvalgte indkodning^er og efterkon_trol^ af
effekten sammenholdt med den forventede effekt.

>a2 KANDIDATUDVÆLGELSEN.

Det har i det foregående været diskutteret, om der fandtes en række 
programklasser med hver deres kandidater. Dette vil blive undersøgt
for en række af de typiske anvendelser af RC3502^. Fundamentet herfor
er en kandidatudvælgelse for det enkelte program. Jeg vil i det følgende
beskrive og begrunde den metode, der er valgt.

>a3 OPSAMLING I RC3502.

Hovedvægten er lagt på den statisk^e opsamling, da det især er 
lagerforbrug, der kan reduceres.

Det skal være muligt at opsamle oplysninger om et program for:

- in_struk_tionshyppigheder

- enkelte in_struk_tioner med specificerede pa_ra_me_ter_vær_di_om_råder.

Da pa_ra_me_terindkodningen også har en vis, omend beskeden, virkning på
programafviklingshastigheden, foretages der også en dynamisk^ opsamling.
Da den dynamiske opsamling må forventes at være med meget stor 
usikkerhedsmargen og da komplicerede opsamlingsmetoder forøger risikoen
for at påvirke resultatet med selve målingen, er der kun planlagt en
simpel dynamisk opsamling for in_struk_tionshyppigheder.

I vurderingen af den effekt, en pa_ra_me_terindkodning kan have, bruges en
antagelse om at fordelingen på pa_ra_me_terværdiområder for den enkelte
in_struk_tion^, observeret i det statiske tilfælde 
også gæl_der for den dy_na_mis_ke af_vik_ling. Antal_let af fore_kom_ster
i et para_me_ter_vær_di_om_rå_de, vil alt_så billed_ligt talt bli_ve
proji_ceret op i an_tal_let af fore_kom_ster ved den
dynamiske afvikling (@se figur@3@)
>ne 22


         Statisk              Dynamisk

                                ---
                                I I
                                ---
                                IXI
           ---                  IXI
           I I                  IXI  Djl  Dj
           I I                  IXI
           ---                  IXI
           IXI                  ---
   Sj  Sjl IXI                  I I
           IXI                  I I
           ---                  I I
           I I                  I I
    ------------------------------------------

           Ij                   Ij

>fg Proportionalitetsantagelsen.

Denne antagelse om proportionali_tet^ er meget grov. Med den terminologi,
der blev indført i kapitel 4 kan den udtrykkes ved:

>ne5
  Sjl   Djl     Sj   Sjl
  --- = --- <=> -- = ---
  Sj    Dj      Dj   Djl

Dette vil være tilfældet hvis N1@=@N2@=@....@=NB

En sådan betingelse er dog ikke en nødvendig betingelse for at 
proportionaliteten kan gælde. Jeg vil lade et par konstruerede eksempler
vise at antagelsen kan være grov.

>ex Analyse af proportionalitet.

Der er 3 fundamentalblokke.
For in_struk_tionen Ij er der fire pa_ra_me_terværdiområder. 
Den statiske op_sam_ling giver

>ne11
 -------------------------------------------
  k  j.l I Sjk0 I Sjk1 I Sjk2 I Sjk3 I Sjk I
 -------------------------------------------
  blok1  I  5   I  2   I  3   I  0   I  10 I
 -------------------------------------------
  blok2  I  1   I  4   I  1   I  2   I   8 I
 -------------------------------------------
  blok3  I  0   I  2   I  6   I  0   I   8 I
 -------------------------------------------
  sum    I  6   I  8   I 10   I  2   I  26 I
 -------------------------------------------

Med (N1,N2,N3) = (1,5,2) i det dynamiske tilfælde fås:

>ne11
 -------------------------------------------
  k  j.l I Sjk0 I Sjk1 I Sjk2 I Sjk3 I Sjk I
 -------------------------------------------
  blok1  I  5   I  2   I  3   I  0   I  10 I
 -------------------------------------------
  blok2  I  5   I 20   I  5   I 10   I  40 I
 -------------------------------------------
  blok3  I  0   I  4   I 12   I  0   I  16 I
 -------------------------------------------
  sum    I 10   I 26   I 20   I 10   I  66 I
 -------------------------------------------

Vi har

>ne3
 Dj   66
 -- = --
 Sj   26

henholdsvis

>ne3
 Djl                       10   26   20   10
 ---  for l=1,2,3,4 giver  -- , -- , -- , --
 Sjl                       6    8    10   2

Antagelsen om proportionalitet gælder altså ikke i dette tilfælde.

>ex Konstrueret opsamlingseksempel.

Der er 2 fundamentalblokke.
>sp0
For in_struk_tionen Ij er der 4 pa_ra_me_terværdi_inter_val_kombinationer.
>sp0
Den statiske opsamling giver

>ne11
 -------------------------------------------
  k  j.l I Sjk0 I Sjk1 I Sjk2 I Sjk3 I Sjk I
 -------------------------------------------
  blok1  I  5   I  4   I  1   I  0   I  10 I
 -------------------------------------------
  blok2  I  1   I  4   I  9   I  2   I  16 I
 -------------------------------------------
  sum    I  6   I  8   I 10   I  2   I  26 I
 -------------------------------------------

Med (N1,N2) = (5,1) fås følgende dynamiske statistik:

>ne11
 -------------------------------------------
  k  j.l I Sjk0 I Sjk1 I Sjk2 I Sjk3 I Sjk I
 -------------------------------------------
  blok1  I  25  I  20  I   5  I   0  I  50 I
 -------------------------------------------
  blok2  I   1  I   4  I   9  I   2  I  16 I
 -------------------------------------------
  sum    I  26  I  24  I  14  I   2  I  66 I
 -------------------------------------------

>ne3
 Dj   66
 -- = --  ( som i forrige eksempel )
 Sj   26

>ne3
 Djl                        26   24   14   2
 ---  for l = 1,2,3,4 giver -- , -- , -- , -
 Sjl                         6    8   10   2

Heller ikke i dette eksempel er der proportionalitet.

De to eksempler har den egenskab at

 Dj , Sj , Sj0 , Sj1 , Sj2 , Sj3 

har de samme værdier i begge eksempler.
Under antagelse om proportionalitet ville man forvente at også

Dj0 , Dj1 , Dj2 , Dj3

er ens; men dette er ikke tilfældet. Den statiske opsam_ling vil udpege
Ij2 som emne for en ny in_struk_tion, hvorimod Ij1 hhv. Ij0 vil være 
kandidaterne fra eksemplerne i den dynamiske statistiks kandidatliste.
Der behøver altså ikke at være nogen proportionalitet, og selv 
sammenfaldende statiske målinger og ens dynamiske totalværdier kan 
have forskellige kandidater. Det skal også bemærkes, at hvis (@N1,N2,N3@)
i det første eksempel f.eks havde været (@5,1,1@) så ville det samme
program med en anden afvikling ( (@N1,N2,N3@) er f.eks. dataafhængige@)
give en helt anden kandidat end før, nemlig Ij0. Det sidste skal nævnes
blot for at understrege den usikkerhed, den dynamiske opsamling er
behæftet med.

Jeg bemærkede, at hvis N1 = N2 = .... = NB, vil der være proportionalitet.
Dette vil sige at alle fundamentalblokke bliver udført lige mange gange.
Dette er ikke så interessant i praksis (@det skal bemærkes at, N1 = N2 =
.... = NB = 1 er resultatet af den statiske opsamling@). Det er derimod mere interessant
at proportionaliteten også vil være sikret hvis der gælder

>ne3
 Sjkl   Sjl
 ---- = ---
 Sjk    Sj

Dette betyder, at hyppigheden for pa_ra_me_tervær_di_om_rå_de_forekomsten inden
for en fundamentalblok følger hyppigheden for selve in_struk_tionen. Dette
var klart ikke tilfældet i de to eksempler; men antagelsen kan dog
være brug_bar i prak_sis.

At ovenstående betingelse er tilstrækkelig til at give proportionalitet
kan indses på følgende måde:

Vi har

>ne3
 Sjkl   Sjl
 ---- = ---   for k = 1,2,....,B og l = 0,1....,P
 Sjk    Sj

>ne3
        Sjkl   Sjl
 => K = ---- = ---
        Sjk    Sj

 => K * Sjk = Sjkl

>ne3
            Djl
Ser vi på @@---@@ fås
            Dj

>ne12
         B               B
           Nk * Sjkl       Nk * ( K * Sjk )
 Djl    k=1             k=1
 --- = ------------- = --------------------
 Dj      B               B
           Nk * Sjk        Nk * Sjk
        k=1             k=1


       Sjl
 = K = ---
       Sj

hvilket netop giver betingelsen for proportionalitet.

Med kendskab til j, Dj samt Sj0, Sj1, .... SjP og antagelse om
proportionalitet kan Dj0, Dj1, ... DjP estimeres og effekten af en 
pa_ra_me_terindkodning kan herefter forudsiges.

Der er selvfølgelig stor usikkerhed på denne effektforudsigelse. Der
er dog en række forhold, der taler for denne metode:

- Der er tale om at finde nogle få kandidater. Det er altså nok, hvis 
antagelsen holder for en lille del af in_struk_tionerne.

- Muligvis vil rækkefølgen i den prioriterede kandidatliste
i virkeligheden være lidt forkert. Der skal altså blot en større liste til, for
at være sikke på at have de 'rigtige' kandidater med, end det var 
nød_ven_digt med et fuldt kendskab til den dynamiske fordeling på 
para_me_ter_værdiområder.

- Ved efterkontrol bestående i, at en dynamisk statistik opsamles, efter at 
en eller flere af de første kandidater på listen er indkodet, kan de 
valgte kandidater vurderes ved at de opsamlede hyppigheder for de nye
in_struk_tioner sammenholdes med de forventede ud fra proportionalitets
antagelsen. Hvis den opsamlede hyppighed er lig med eller stør_re end det forventede, er
kandidatvalget vellykket. Hvis det er mindre, vurderes om en af de
øvrige kandidater kan forekomme hyppigere. Skønt antagelsen om 
proportionalitet forekommer lidt stram, vil metoden ved få forsøg med
efterkontrol indkredse de (@måske 10 - 20@) kandidater, der skal bruges.

- Det er ikke så væsentligt, at det er de rigtige kandidater 
effektivitetsmæssigt, der udvælges, fordi det først og fremmest er
pladsbesparelse, der er målet.

- Den dynamiske opsamling kan forventes at være ret usikker (@en 
stor spredning@), og specielt er den dataafhængig. Kandidatprioriteringen
på dette grundlag må altså ikke tages mere højtidelig end den spredning,
der er i opsam_lin_gen, berettiger til. Den usikkerhed der er i kandidat
udvælgelsen er altså i det dynamiske tilfælde allerede stor, og den
valgte metode virker derfor tilstrækkelig tillokkende at forsøge sig
med.

>a3 PROGRAMKLASSER.

Niveauet for undersøgelsen af program_klas_se^r er pro_gram_mers
sta_tis_ke instruk_tions_anven_del_se. Der er fle_re grun_de til det_te
valg.

- De enkelte instruktion^er er uaf_hæn_gige med hen_syn til
parameter_værdi_anven_del_se (@dvs. ingen fu_sion af pro_gram_mer ved
over_gang til para_me_ter_ni_veau_et@).

- Niveauet ligger meget tæt ved parame_ter_vær_di_niveau_et, hvor sel_ve 
ind_kod_nin_gen hø_rer hjem_me. Risi_ko_en
for diffu_sion er ikke sær_lig stor. Man_ge para_me_tre vil væ_re fast_lagt
som føl_ge af sy_stem_de_fi_ni_tio_ner/kon_ven_tio_ner, som al_le 
pro_gram_mer er un_der_lagt. Der er alt_så god grund til at tro, at en
under_søgel_se på instruk_tions_niveau_et vil være dæk_ken_de.

- En undersøgelse på et niveau svarende til de enkel_te parame_ter_værdier
, vil væ_re umu_lig at hånd_te_re, hvor_imod under_sø_gel_sen på 
instruk_tions_ni_veau_et er hånd_ter_bar.

- Hvis der er be_ret_ti_get frygt for dif_fu_sion i anven_del_sen af
en ræk_ke kan_di_da_ter, kan det_te un_der_sø_ges eks_pli_cit.

- Det vil væ_re til_stræk_ke_ligt at under_sø_ge den sta_tis_ke
an_ven_del_se med hen_blik på pro_gram_klas_ser, da ind_kod_nin_gen af
para_me_tre har for_mind_sket lager_krav som mål. Kun ved lige gode
statiske kandi_da_ter kan den dy_na_miske in_struk_tions_anven_del_se
få ind_fly_del_se.

For at afgøre, om der er forskel på de programmer, der udvikles til
at klare de opgaver, som RC3502 er tiltænkt, må man først definere
hvad det vil sige, at sammenligne programmer, eller rettere, hvornår
to programmer anses for at være ens i deres an_ven_delse af instruk_tio_ner.

Programmer er ens hvis:

- den relative statiske anvendelse af instruk_tio_ner er den sam_me.

Nu er det lidt restriktivt, at forlange en nøjagtig overensstemmelse.
Det vil være mere rimeligt, at tillade en vis variation på de enkelte
fore_kom_ster. I kapitel@7 præ_sen_te_res en sta_tis_tisk mo_del til
af_test_ning af "hypo_te_sen om ens pro_gram_mer". For at få en
ri_me_lig for_nem_mel_se af ma_te_ria_let, har jeg dog lagt vægt på
mu_lig_he_den for visuel sam_men_lig_ning af gra_fis_ke
repræsen_tatio_ner af re_sul_ta_ter_ne.

Hvis der viser sig flere klasser, må man finde kandidater til 
para_me_ter_indkodning inden for hver en_kelt klasse, og skal RC3502 forbedres 
målrettet mod samtlige klasser, må alle de forskellige klassers 
top-kandidater medtages.

>a2 PARAMETERINDKODNINGEN.

Stevenson og Tanenbaum (@Ste79@) skit_se_rer en me_to_de til at fin_de
en liste af kan_di_da_t^er, sor_teret ef_ter den plads_re_duk_tion, de
kan med_fø_re ved ind_kod_ning. Alle in_struk_tio_ner op_fat_tes som en
sam_ling af ok_tet_^ter (@opfattes i grundtal 256. Se (@Wilc80@)
vedrø_rende mind_re grund_tal@). Hvis en para_me_ter
består af f.eks et ord på 16 bit, be_trag_tes denne som to uaf_hæn_gi_ge
ok_tet_ter (@høj_re og ven_stre ok_tet@).

Instruktioner, der har en enkelt ok_tet som para_me_ter^, er tri_vi_elle
at ind_pla_ce_re i kandi_dat_lis_ten.

Instruktioner, der har to oktetter som para_me_tre kan trans_for_me_res^
til nye in_struk_tio_ner på tre må_der:

- Den nye instruk_tion dannes af en spe_ci_fik parame_ter_vær_di. Der op_nås
en plads_be_spa_rel_se på an_tal fore_kom_ster@*@2@ok_tet_ter.

- Den nye instruk_tion dan_nes ved at fast_hol_de en speci_fik vær_di
for før_ste para_me_ter og lade an_den para_me_ter va_ri_e_re. Der op_nås
en plads_be_spa_rel_se på et antal ok_tetter sva_ren_de til det sam_lede
antal fore_koms_ter sum_me_ret over anden para_me_ter (@søjle sum@).

- Den nye instruk_tion dannes ved at fasthol_de en spe_ci_fik vær_di for
an_den para_me_ter og lade før_ste para_me_ter vari_ere. Der op_nås en
plads_be_spa_rel_se på et antal ok_tet_ter sva_ren_de til det sam_lede
an_tal fore_kom_ster sum_me_ret over før_ste para_me_ter (@ræk_ke_sum@).

Sorteringen fremkommer da ved at be_trag_te fore_kom_ster op_stil_let i
en 256@X@256 kryds_ta_bel med ræk_ke- og søj_le_sum_mer ud_reg_net, og
op_stil_le kan_di_da_ter_ne, der frem_kom_mer  ved de to sidst om_tal_te
me_to_der, ef_ter fal_den_de søj_le/ræk_ke_summer. Når en søj_le/række
er med_ta_get som kan_di_dat træk_kes de en_kel_te vær_di_er i
søj_len/ræk_ken fra søj_le/række_sum_men. Alle de her frem_kom_ne
kan_di_da_ter har en ok_tet som para_me_ter og kan gø_res til gen_stand
for yder_lige_re ind_kod_ning som enkelt_para_me_ter instruk_tion og
indsæt_tes i kandi_dat_lis_ten. Be_mærk, at en kandidat, der
vide_re_ind_ko_des al_tid vil op_træ_de læn_ge_re ne_de på lis_ten
end den kan_di_dat, den stam_mer fra.

Instruk_tioner med mere end to oktetter kan trans_for_me_res ef_ter en
tilsva_ren_de gene_ra_li_se_ret me_to_de, som anven_des på in_struk_tio_ner
med to para_me_tre. Jeg vil gøre op_mærk_som på, at den skit_se_re_de
me_to_de ikke helt er i over_ens_stem_mel_se med refe_ren_cen (@Ste79,
eksemp_let side 13-14@), der des_værre er fejl_be_hæf_tet på det_te
punkt; men jeg tilla_der mig at tro, at oven_stå_en_de er hvad for_fatterne
har ment.

Der kan heref_ter dannes en total sor_teret kandi_dat_lis_te^. Ud fra
denne kan tilføjel_ser af nye in_struk_tio_ner udfø_res i en grund_tal
256 Huffman kode (@Huf52@), for at sik_re den kor_test mu_lige gen_nem_snitlige
in_struk_tions_læng_de.

I rela_tion til RC3502 er den an_før_te me_to_de disku_ta_bel. Først
og frem_mest fordi op_ga_ven går ud på at til_fø_je plads_be_spa_ren_de
instruk_tio_ner (@parame_ter_ind_kod_ning@) med en størrel_se på 
mi_kro_pro_gram_met fast_lagt så lil_le, at der kun er plads til me_get
få ind_kod_nin_ger. Dette be_tyder, at Huffman indkod_ning i grund_tal
256 ikke er rele_vant, da der bli_ver fær_re end 256 instruk_tio_ner
totalt.
Analyser på mindre en_he_der end ok_tet_ter (@Wilc80@) har_mo_ne_rer på
den an_den si_de ikke med, at RC3502 ope_re_rer med oktet_ter som
mind_ste a_dres_se_en_hed, så en ind_kod_ning i et mind_re grund_tal
vil give af_kod_nings_pro_ble_mer i mi_kro_pro_gram_met. Det er alt_så
nød_ven_digt at operationskoden ligger på oktetgræn_ser i lage_ret. Hvis
dette er op_fyldt er der ikke no_get i vejen for, at parame_ter_vær_di_en
kan af_ko_des ud fra ope_ra_tions_ko_den, som det siden vil frem_gå af
re_sul_ta_ter_ne.
Med hensyn til ned_bryd_nin_gen af instruk_tio_ner i en sam_ling af 
ok_tet_ter, fin_der jeg det f.eks. uhel_digt at ned_bry_de en para_me_ter
på 16 bit i en ven_stre ok_tet og en høj_re ok_tet. Be_stem_te
vær_di_fore_kom_ster i høj_re ok_tet, sva_rer til ækvi_di_stan_te 
para_me_ter_vær_di_er med en af_stand på 256. Denne op_de_ling er absurd
, når para_me_teren stort set al_tid inde_hol_der en vær_di, der an_gi_ver
en af_stand re_la_tivt til en lager_adres_se^.
Bestem_te vær_di_er af ven_stre ok_tet er mere rele_van_te, idet der så er
ta_le om et in_ter_val i om_rå_det:

(venstreoktet)*256<parameter<(venstreoktet+1)*256-1

Den mest natur_lige opfattelse af paramete_ren er føl_gen_de:

 PARAMETER = KONSTANT + X, hvor 0 < X < 255

En så_dan op_fattelse spo_le_res ved op_de_lin_gen i ven_stre hhv.
høj_re ok_tet.

Når kandidatliste^n udformes er det ikke nok alene at tage hen_syn til
be_spa_rel_sen. Sor_te_rings_kri_te_riet må væ_re plads_be_spa_rel_se
pr. mi_kro_pro_gram_trin^, da det vi_ser sig, at plad_sen til 
mi_kro_pro_ram_met er den be_græn_sen_de fak_tor.

Man skal være opmærksom på, at instruk_tio_ner på grund af den fak_tis_ke
im_plemen_ta_tion ikke al_tid er uaf_hæn_gi_ge. Men tvært_imod kan optræ_de
i 'fami_li_er'.

Jeg har ta_get disse tre hen_syn i ud_form_nin_gen af kandi_dat_lis_te^n
for RC3502^. Se kapi_tel 8 for nær_me_re de_taljer.

Ud over disse bemærk_ninger vil jeg gøre op_mærk_som på at
resul_taterne fra (@Ste79@) ikke direk_te kan over_fø_res til RC3502
in_struk_tionssættet. Der er f.eks i RC3502 tale om et adresserum udpe_get af 32 bit,
men da koden er flytbar vil samtlige parametre, der danner
adresse^r, ikke kunne indkodes, da deres værdi først bliver fastlagt
på ind_læs_nings_tid_spunktet. Den slags 5 oktetter, 
dvs. instruk_tio_ner på 40 bit, som ikke kan ind_kodes, vil
gø_re den nedre grænse for den gennemsnitlige in_struk_tionslængde^
stør_re end an_ført af Tanenbaum og Stevenson (@Ste79@).

Hvad angår pladsbesparelse som mål, kan kandidaterne, som før omtalt, 
udpe_ges di_rek_te, og effek_ten kan vur_de_res helt præ_cist. Med hen_syn
ef_fek_ti_vi_se_ring af program_afvik_lings_has_tig_he_den er der
stør_re usik_ker_hed på
prioriteringen af kandidaterne, og det vil formodentlig blive nødvendigt
med flere forsøg, før de rigtige kandidater er fundet. Det må formodes,
at mæng_den af til_føjel_serK påvirer antal forsøg. Det er imidlertid ikke muligt,
at forudsige denne sammenhæng.

>a2 EFTERKONTROL.

Efterkontrol^len af effekten af pa_ra_me_ter_ind_kod_ning_en har specielt
interesse for program^_effek_tivi_tets_for_bed_rin_gen.

En fornyet dynamisk opsamling med de ekstra in_struk_tion^er sammenholdt
med de forventede tal ud fra en proportionalitetsantagelse, vil for
hver enkelt af de K nye in_struk_tioner vise om prioriteringen var rigtig,
eller om der kan være grundlag for omprioritering.

Med M in_struk_tioner oprindelig, vil sammenhængen mellem en gammel og
en ny in_struk_tion kunne formaliseres på følgende måde:

Lad in_struk_tionen Ij
forekommer statisk Sjl gange og dynamisk Djl gange, hvor Djl er estimeret.
Den nye in_struk_tion kan hedde In, n@@@L hvor L er defineret ved

 L = ( x@c@Z I 0 < x < 255 )   MI   hvor

 MI = ( mængden af in_struk_tionskodeværdier )

Fornyede opsamlinger giver nu Sn hhv. Dn. Der vil gælde, at Sjl@=@Sn
Med hensyn til Dn og Djl er der to forskellige situationer:

>ti-3
>in4
 Dn > Djl

Kandidaten er endnu mere effektfuld end antaget. Den skulle måske
være prioriteret højere; men da den er medtaget er dette irrelevant.

>ti-2
 Dn < Djl

Kandidaten bør måske prioriteres lavere. Det skal bemærkes, at da

 Djl = Dj og Dn < Djl,

så må Djl - Dn skulle fordeles på de øvrige P-1 pa_ra_me_terværdiintervaller.

Lad Dje være den næst største forekomst af in_struk_tionen Ij med
en pa_ra_me_terværdiinterval kombination. Hvis

 Dje > Dn

vil det umiddelbart være fornuftigt at medtage Ije som kandidat i stedet
for Ijl. Ellers undersøges om andre vragede kandidater er estimeret
bedre end Dn.

I princippet kan alle øvrige intervaller komme på ta_le hvis

       Dj
 Dn < ----
       2

for så kan et andet interval have "vokset sig stor".
Det vil dog være for_nuf_tigt at lade den næst_stør_ste
få 'chancen' og så frem_de_les.
>in-4

>a1 RC3502 OPSAMLING I PRAKSIS.

Opsamlingen af in_struk_tionshyppighed^er for RC3502 er som omtalt foretaget
både dynamisk og statisk. Den dynamiske opsamling har involveret 
mi_kroprogram tilføjelser og udvikling af et opsamlingsprogram. Den
statiske opsamling er koblet sammen med over_sæt_terens passage 6, der
bl.a. tager sig af "assemblering" fra symbolsk "base instruction set"
til flyt_bar binær "actual instruction set" (@Møl81@).

I det følgende omtales i  meget korte træk, hvordan den praktiske
im_plemen_tation er struk_tu_re_ret.

>a2 DYNAMISK OPSAMLING I RC3502.

Kravene til den dynamisk^e opsamlingsmetode har først og fremmest været:

- målingerne skal kunne foretages på et kørende system uden at programmer 
skal genover_sæt_tes.

- målingerne skal kunne foretages på proces in_kar_na_tions niveau.

- målingerne skal kunne slås til/fra kommandostyret.

- målingerne skal være simple, så måle_for_styr_rel_ser be_græn_ses.

>ti-2
- resultaterne skal kunne præsenteres, så de er direkte læsbare, og så
resultater fra forskellige opsamlinger let kan sammenlignes (@visuelt@).

- der skal være mulighed for at opsamlinger fra flere proces 
in_kar_na_tioner kan slås sammen.

>a3 MIKROPROGRAM ÆNDRINGER.

For at kunne opsamle på proces_inkarna_tions_niveau uden at gen_over_sætte
er der behov for nog_le simp_le æn_drin_ger i mi_kro_pro_gram_^met.

- Mi_kroprogrammet skal kunne afgøre om statistikopsamling er slået
til eller fra. Dette opnås ved, at der under hent_ning af næste instruk_tion testes på
et felt (@en bit@) i "W-registerarrayet" (@se Møl81@). Dette felt kan ændres af
opsamlingsprogrammet.

- Registersættenes PS - ord (@Møl81@) udvides med et felt (@en bit@),
der fortæller om den tilhørende proces in_kar_na_tioner tilmeldt 
statistikopsamlingen eller ej. Dette felt testes af mi_kroprogrammet,
hvis det globale statistik til/fra felt er slået til. Her er det 
ligeledes opsamlingsprogrammet, der kan initialisere PS-registrets
statistik felt. Feltet føres med ved aflevering/hent_ning af registersættet til/fra
proces_in_kar_na_tions_be_skri_vel_sen.

- Mi_kroprogrammet tæller op i en tabel, der er udpe_get af op_tæl_lings_pro_gram_met.
Optæl_lingen fore_tages i 4-oktet en_he_der, der i
PASCAL80 notation er defineret således:

TYPE
  long : RECORD
           most : INTEGER;
           least : INTEGER;
         END;

Den aktuelle "long", som mi_kroprogrammet skal optælle, er bestemt
ud fra

- Startadresse på tabellen.

- Proces in_kar_na_tions index.

- Instruktionens operationskode.

Mi_kroprogrammet beregner adresse^n på den aktuelle "long" ved at hente
en 'forberedt adresse' (@stykket sammen fra "Wregisterarrayet" og proces
in_kar_na_tions be_skri_vel_sen@), og her indsætte operations_kodeværdien i
"displacement" delen af adressen. Den forberedende adresseberegning 
foretages af opsamlingsprogrammet.

>a3 OPSAMLINGSPROGRAMMET.

Opsamlingsprogram^met reagerer på en hel række kommandoer, der f.@eks.
kan indtastes fra en operatør konsol. Kommandoerne grupperer sig
funktionelt i følgende klasser:

>in 6
>ti-5
a@@@@Informative kommandoer, der kan være til hjælp for operatøren ved
den øvrige interaktive kommando styring. (@f.eks h(epl) udskriver en
samlet vejledning over kommandoer til opsamlingsprogrammet@).

>ti-5
b@@@@Styringskommandoer i forbindelse med statistikopsamlings
til-/afmelding.

>ti-5
c@@@@Udskriftskommandoer, der kan præsentere resultaterne på forskellige
måder afhængig af hvilket problem, resultatet skal belyse. Der er
lagt vægt på, at resultaterne kan præsenteres så følgende opnås:

>ti-5
c.1@@Visuel sammenligning af resultater er umiddelbart mulig, også med
de statiske op_sam_lings_ud_skrif_ter.

>ti-5
c.2@@Delresultater kan udtrækkes. Her tænkes specielt på værdier, der er
større end en vis grænse, eller de N største værdier.

>ti-5
c.3@@Relative og absolutte værdier kan udskrives direkte.
>in-6

Punktet c.1 er vigtigt, hvis den dyna_mis_ke fore_komst af programklasser undersøges.
De to sidste punkter benyttes i jagten på kandidater, hvor det er 
ønskeligt at kunne begrænse mæng_den af in_for_ma_tion for lettere at få et overblik.

>a3 TIDSMÆSSIGE PÅVIRKNINGER.

Kørsel med det ændrede mi_kroprogram bevirker følgende forsinkel_se^r pr.
in_struk_tion i forhold til det oprindelige mi_kroprogram.

- Global statistik er slået fra bevirker en forsinkelse på 0.8 mi_krosek.

- Global statistik er slået til og proces in_kar_na_tionen er ikke tilmeldt
opsamlingen bevirker en forsinkelse på 1.8 mi_krosek.

- Global statistik er slået til og proces in_kar_na_tionen er tilmeldt
opsamlingen bevirker en forsinkelse på 6.5 mi_krosek.

Det vil sige, at påvirkningen på afviklingshastigheden ligger på under
20@% ved proces in_kar_na_tioner, der ikke opsamles fra, og på under 60-70@%
ved proces in_kar_na_tioner, der opsamles fra.

>a2 STATISK OPSAMLING.

Opsamling^en af sta_tis_k^e in_struk_tionshyppighed^er er som før nævnt 
foretaget i forbindelse med over_sæt_terens passage@6.
Udgangspunktet er en simpel sta_ti_stik over de forskellige in_struk_tioners
hyp_pig_hed. Med hen_blik på af_dæk_ning af even_tuel_le pro_gram_klas_ser,
er der ud_vik_let pro_gram_mer til at akku_mulere^ for_de_lin_g^en af 
instruk_tions_hyppig_he_d^er, og samti_dig udfø_res di_ver_se statis_tisk^e
under_sø_gel_ser, og der pro_du_ce_res gra_fis_k^e over_sig_ter. Dette be_hand_les nær_me_re
i ka_pi_tel@7.
På baggrund af disse resultater specificeres, hvil_ke in_struk_tio_ner, 
der ønskes en nærmere pa_ra_me_teranalyse af. Parameter_ana_ly_sen
specificeres ved, at der kan angives værdiområder for de 
forskellige parametre, der følger efter in_struk_tionskoden. Det kan 
således blive aktuelt med flere kørsler, for at få et detal_jeret
billede af para_me_ter_værdifore_kom_ster.
Der er lige_ledes ud_vik_let pro_gram_mer, der kan akku_mulere for_delingen
af para_meter_vær_di_fore_kom_st^er, se kapi_tel@8.

>a2 ANALYSEREDE PROGRAMSYSTEMER.

Med henblik på pa_ra_me_terindkodningen er der lagt op til, at både
statiske og dynamiske op_sam_lin_ger ud_føres for en ræk_ke
ap_pli_ka_tions_syste_m^er.

Udgangspunktet har været nedenstående sy_ste_mer, der karak_teri_seres
kort i de føl_gen_de af_snit.

- RC3502 basal system.

- Alarmsystemet.

- Paxnetsystemet.

>a3 RC3502 - DET BASALE SYSTEM.

Det@basale@system^ i RC3502^ er programmeret i PASCAL80^. Det er i
nog_le for_bin_del_ser nød_ven_digt at bry_de med spro_gets stren_ge
type_kon_trol^. Dette mulig_gøres dels ved oversæt_telse med et
specielt sæt type_defi_ni_tio_ner, der i modsæt_ning til
de bru_ger_rette_de stan_dard_defi_ni_tio_ner, til_la_der at ar_bej_de med
sy_stem_va_ri_ab_le^, dels ved ad_gang til en række ruti_ner
(@kode_ruti_ne^r@), der findes
i et bib_lio_tek^; men ko_den i ru_ti_ne_krop_pen vil bli_ve kopi_eret
u_kri_tisk af over_sætter^en.

Det@basale@system^ består af en række programmer, der under ud_fø_rel_se
vare_ta_ger føl_gen_de funk_tio_ner (@se (@Bag80@) for nærmere detaljer@):

- Udvælgelse af næste proces_inkarna_tion^, der skal være aktiv^ (MONITOR). Der er
dels udvæl_gel_se forårsa_get af afbrydel_se^r, dels udvælgel_se
for_årsa_get af, at den eksekve_re^nde proces_inkar_na_tion går i en 
effek_tiv vente_til_stand^, og endelig udvælgelse for_år_sa_get af udløb
af et tids_af_snit^. Udvæl_gel_sen fore_går i 3 ind_byr_des priori_terede
klas_ser:
>tc !
>sp0
>in4
Klasse 1 : materiel^ afbrydelser
>sp0
Klasse@2@: prioriterede "coroutiner
>sp0
>tb 12 Klasse@3@:
tidsafsnitaf_bry_delig^e proces inkar_na_tio_ner i et
priorite_ret sy_stem (@garan_teret mini_mum køre_tid@)
>in-4

- Administration af lager^ og adgang til ydre enhe_der (ALLOCATOR). Det
implemente_rede sy_stem sik_rer fuld dyna_misk gen_udnyt_tel_se^ af
dis_se ressour_cer^.

- Tidsaktiviteter i form af (TIMER) :
>sp 0
>in 7
>ti-3
a.@Aktivering af procesin_kar_na_tioner, der er tilmeldt, når deres respektive
vente_tid^er er talt ned til 0.
>sp 0
>ti-3
b.@Returnering af meddelelser efter en tids_perio_de^ angi_vet i
meddelelsen.
>sp 0
>ti-3
c.@Betjening af taktsignal^s afbry_delse^r.
>in -7

- En rod^ for det dynamiske proces_inkar_nations_træ^ (ADAM).

- Et operativsystem^, der kan udføre komman_doer til procesin_kar_na_tions
kontrol^ (OPSYS).

- Et operatør_modul (OPERATOR), der sætter en operatør^ i for_bin_del_se med 
ope_ra_tiv_sy_ste_met, samt med de applikations_pro_gram^_mer, der har
sendt en inddata^ forespørgsel til operatør_mo_du_let.

- Håndtering af fejl_situa_tio_n^er - und_ta_gel_ser - der op_da_ges
un_der kør_sel (@"exception" hånd_te_ring@).

- Fastlæggelse af interne og externe a_dres_se^r ved pro_gram_ind_læs_ning^,
samt vedligehol_del_se af et bib_lio_tek^ over de indlæs_te program_mer (LINKER).

Som fundament for det basale system findes et opstarts_system^, der
brin_ges i funk_tion ved strøm_til_slut_ning, ved manuel ak_ti_ve_ring
af en opstarts tryk_knap ("autoload" knap), ved program_sty_ret op_start,
eller styret af en kon_trol mi_kro_ma_skine (@vagt_hunds_over_våg_ning@).
Opstarts_syste_met be_står af en ini_tial sekvens af instruk_tio_ner, 
der udfø_rer de nødven_di_ge for_be_re_del_ser for den øv_ri_ge del 
af op_starts_sy_stemet, der er program_me_ret i PASCAL80. Dette
opstarts_system er ikke med_taget i de fore_tagne må_lin_ger, hvil_ket
spe_cielt skyldes, at syste_met er pla_ceret i et perma_nent 
lager_om_rå_de, hvor_fra der kun kan læ_ses (@"PROM"@). Dette område af
lageret vil ikke blive anvendt til andet for_mål, og plads_bespa_relse
på opstarts_sy_stemet er der_for u_inter_essant.

Nedenstående figur viser det basale system og de enkelte 
proces_incar_na_tio_ners hierar_kis_k^e ind_pla_ce_ring.





>ne20
 MONI    TIMER     ALLO     LINKER     ADAM
 TOR               CATOR    






    I/O -    CLOCK           OPERA     OPSYS    APPL.
    TIMER    DRIVER          TOR                PROG.






                             CON-
                             SOLE






                       DE-         DE-
                      BUGIN       BUGOUT




>fg RC3502 basal system. Proces struktur.

>a3 ALARMSYSTEMET.

Det undersøgte system er en demonstrations_mo_del af Alarm_sy_ste_m^et,
der er nærmere beskrevet i (@Bra80@).

Alarmsystemet knytter alarmabonnen_ter sam_men med alarm_mod_ta_gere
(@i form af brand_sta_tio_ner, vagt_cen_tra_ler, og lig_nen_de@) via
et data_net^, PAXNET, der er opbyg_get paral_lelt med tele_fon_net_tet.
Dette il_lu_stre_res af neden_stå_ende fi_gur.


>ne 33

    FALCK
   -------
   I     I
   I O O I
   I     I
   I     I----------.
   I O O I          I               VAGTCENTRAL
   I     I .--. .--.I             -------------
   I O O I :  : :  :I            /              .
   --------'--'-'--'-           /                .
          .                     ------------------
           .                    I OO OO OO OO OO I
            .                   I OO OO OO OO OO I
             .                  I                I
              .                 I OO OOIOO OO OO I
               .              / I OO OOIOO OO OO I
                .            /  I    OOIOO       I
                                ------------------
                     PAX-
                     NET

                /
     O         /
   --O----    /
  /       .
  ---------
  I O O O I
  I   O   I   ABONNENT
  ---------

>fg Alarmsystemets funktion.

I datanettet indgår RC3502^ som Terminalstation (TS), Net_grup_pe_centre
(NC), og som en del af Distriktscentre (DC). Terminal_statio_nernes 
funk_tion er at over_vå_ge en abon_nent_stræk_ning samt at op_sam_le og
vide_re_sen_de a_lar_mer og sty_rin_ger. Net_grup_pe_cen_tre_ne funge_rer
som samle_knu_der for, og over_våg_ning af Terminal_stationer i 
data_net_vær_ket. Distrikts_cen_tre_ne inde_hol_der in_for_ma_tion om 
abon_nen_ter og vagt_cen_tra_ler og modta_ger ko_pi_er af alle data_pak_ker,
der sen_des gen_nem sy_ste_met og op_lag_rer infor_ma_tio_nen. RC3502
indgår i det fær_di_ge sy_stem som bindeled for Di_strikts_centret og
data_nettet. I den kon_kre_te demon_stra_tions_mo_del, der er an_vendt
ved den_ne under_sø_gel_se, er alarm_sy_stemet sim_pli_fi_ce_ret til
at omfatte en Terminal_sta_tion og et "Distrikts_cen_ter" (@se fi_gur@6@).
Distrikts_centrets funk_tion er simu_le_ret på en RC3502.


>ne 18


               ---------     ---------
               :       :     :       :
               :RC3502 :     :RC3502 :
    O          :       :     :       :          O
   /     O     :Termi- :     :Distr.-:     O     .
 I/---oOOI<--->:nalst. :<--->:center :<--->IOOo---.I
 I==.          :       :     :       :          .==I
 I Il          '-------'     '-------'          lI I
                ::                :::
                ::                :::
               -----             -----
               I   I             I   I
               I   II Alarmter-  I   II
               I   II minaler    I   III
               '---'I            '---'II
                 ---'              ---'I
                                    ---'


>fg Demonstrationsmodel af ALARMSYSTEM.

Jeg vil i det følgende ikke gå nær_me_re ind i en frem_stil_ling af
de enkel_te pro_gram_mers funk_tion, men nø_jes med at be_mær_ke, at
der ikke ind_går pro_gram_mel til data_net_til_slut_nin_gen i 
demon_stra_tions_mo_del_len.

>a3 PAXNET.

PAXNET er et generelt pak_ke-trans_port^ net_værk^ (@"Packet Switching
Network"@) ba_se_ret på CCITT X.25 rekommandationen. PAXNET bygger 
desuden på ISO-model_len for et åbent@net_værk^ (@PAX80@).

RC3502 indgår som knu_de^r i PAXNET, dels som til_gangs_knu_der, dels
som gennem_strøm_nings_knu_der.




>ne 21
                              Værts-
                              datamat

     Værts- 
     datamat             
                              X.25

          X.25      Til-
                   gangs-
                   knude.


              Gen-
            nemstrøm-
             nings-
              knude
                           Til-
                          gangs-
                          knude.

                                         Værts-
                                         datamat
                                  X.25

        transportnet


>fg PAXNET transportnet.
>np
De undersøgte programmer stammer fra en til_gangs_knu_de. En så_dan
knu_de vare_ta_ger en ræk_ke op_ga_ver, hvor_af kan næv_nes:

- X.25 niveau 2, hhv. niveau 3 til_slut_ning.

- Datagram "interface".

- Strømningskontrol.

- "End to end" kontrol.

- Trafikdirigering.

- Lokal kontrol

- Statistik-opsamling og rapportering.

>ne 31

  X.25-niveau 1/2/3 snitflade
   :
   :  ----------------------------------------
   :  I RC3502 tilgangsknude.                I
   :  I                                      I
   :  I -------                    -------   I
   :  I I LCP I    -------         I NCP I   I
   :  I I-----I    I LCP I         '-----'   I
   :  I IX.25 I    I-----I         -------   I
   :  I Iniv.3I    I LIC I         I LCP I   I
   :  I '-----'    I-----I         I-----I   I
   :  I            IX.25 I         I TS  I   I
   :  I -------    Iniv.3I         '-----'   I
   :  I I LCP I    '-----'         -------   I
   :  I I-----I    -------         I LCP I   I
   :  I IX.25 I    I LCP I         I-----I   I
   :  I Iniv.2I    I-----I         INCTH I   I
   :  I '-----'    I RTP I         '-----'   I
   :  I            '-----'                   I
   :  '--------------------------------------'

>fg Struktur i tilgangsknude.

      LCP: Lokal kontrol modul
      NCP: Netværks kontrol modul
      LIC: Logisk intern kanal
      RTP: Trafik dirigerings modul
      TS:  Transport station.
      NTCH:Netvætks kontrol konsol betjenings modul.

Det er ikke hele programmellet i en tilgangs_knu_de, der ind_går i
under_sø_gel_sen. Dette skyl_des prak_tis_ke for_hold ved_rø_ren_de
fær_dig_gø_rel_ses_tids_punk_ter. Der er i ste_det ud_valgt en_kel_te
mo_du_ler, der skøn_nes re_præ_sen_ta_ti_ve for en net_værks_knu_de.

Det er af ovennævnte årsager kun den sta_tis_ke un_der_sø_gel_se, der er
gen_nem_ført. En fuld_stæn_dig analy_se, sta_tisk og dy_na_misk af
pro_gram_mel_let i en net_værks_knu_de, kan vi_se sig at væ_re en
nød_ven_dig for_ud_sæt_ning for en rime_lig be_hand_ling ef em_net. Dette
gæl_der bl.a., hvis der er klasse_op_de_lin_ger i de ana_ly_se_re_de
sy_ste_mer. Som det siden skal vise sig får det ingen prak_tisk be_tydning
at an_ven_de pro_gram_ud_snit i det_te til_fæl_de.

>a1 RESULTATER FRA DE STATISKE ANALYSER.

I det følgende præsenteres resul_ta_ter_ne af de sta_tiske
ana_ly_ser. Udgangs_punk_tet er de en_kel_te sy_ste_mer un_der_søgt
hver for sig.

Inden præsentationen vil jeg dog  beskrive en statistisk model^,
der lig_ger til grund for ud_ta_lel_ser om i hvor høj grad de
en_kel_te pro_gram_mer lig_ner hin_an_den i an_ven_del_sen af
in_struk_tio_ner.

Opsamlingerne af de enkelte programmers instruk_tions_fre_kvens
kan be_trag_tes som en ræk_ke empi_ris_k^e for_de_lin_g^er, der er
grup_pe_ret på det sam_me an_tal klas_ser.

Lad m betegne antallet af fordelinger (@antallet af pro_gram_klas_ser@), 
og lad k beteg_ne an_tal klas_ser (@an_tal in_struk_tio_ner@). Med Xij 
betegnes antallet af observatio_n^er (@an_tal in_struk_tions
an_ven_del_ser@) i den j'te for_de_ling (@det j'te pro_gram@),
som fal_der i klas_se i (@an_vend_te in_struk_tions 
ope_ra_tions_ko_de = i@)

Med p   angives sandsynlighed^en for et udfald^ i den j'te for_de_ling
i klas_se i.

Vi er interesserede i at undersøge hypotese^n om ho_mo_ge_ni_tet^
dvs.:

  Ho: p  = p  ,   p  = 1;

"Maximum likelihood" estimationen under nul_hy_po_te_sen Ho er:

              Xij
>sp0
@@p@@@@---j-------@@@@@, i = 1, 2, 3, ...., k
>sp0
              Xij
          ij
Uden Ho fås:

            Xij
>sp0
@@p@@@@-----------
>sp0
            Xij
        ij
>ne 8
Cramer ( Cra46 ) har vist, at udtrykket

                                Xij  2
             Xij - (   Xij)*(-j----)
                     i          Xij
 @Z=@@@@@@-------------------ij---------
>sp0
              (   Xij)*(   Xij)
>sp0
 @@@@@ij@@@@@@--i--------j-----
>sp0
                      Xij
                   ij
under Ho er asymptotisk^ X@-fordelt med an_tal_let af
fri_heds_gra_der^@=@(@k-1@)*(@m-1@). Cramer an_gi_ver, at

   n * p =    Xij * p  > 10
           ij

sikrer en rimelig tilnærmelse til X@for_de_lin_gen. An_dre
hæv_der, at når den_ne stør_rel_se blot er stør_re end 5, vil
til_nær_mel_sen væ_re til_stræk_ke_lig i prak_sis.

I den aktuelle undersøgelse kan dette op_nås ved at slå sjæl_dent
fo_re_kom_men_de in_struk_tio_ner sam_men i en klas_se. Vi er
al_li_ge_vel kun in_ter_esse_re_de i de in_struk_tio_ner, der
fore_kom_mer hyp_pigt. De_su_den er der en græn_se for hvor små
sy_ste_mer, der kan under_søges (@små i rela_tion til an_tal 
in_struk_tio_ner@). Hvis vi f.eks. kræ_ver, at p  esti_ma_to_ren

            Xij
>sp0
@@p@@@@--j-----@@>@0.008  (@0.8%@)
>sp0
            Xij
        ij
betyder det, at det sam_lede an_tal af in_struk_tio_ner skal væ_re stør_re end
625  (@evt. 1250@).

De 0.8% viser sig senere som en nedre græn_se hvor_under enkelt_stående
kandidater ik_ke vil kun_ne blan_de sig i 'kam_pen' om ind_kod_ning^.

>a2 RESULTATER FRA DET BASALE SYSTEM.

De undersøgte moduler i det@basale@system^, iden_tifi_ceret ved 1, 2, 3, ..., a, er:

>in 6
>ti-4
(1)@ADAM  ( proces_in_kar_na_tions roden )
>ti-4
(2)@ALLOCATOR  ( lager- og ydre enhedes_ad_mi_ni_stra_tion )
>np
>ti-4
(6)@OPERATOR  ( operatør betjening )
>ti-4
(3)@CONSOLE  ( styrepanel drivprogram )
>ti-4
(5)@LINKER  ( program- og lager_sammenknytning )
>ti-4
(7)@OPSYS  ( operativsystem )
>ti-4
(8)@TIMER  ( vente-service, tidsudløbs service for driv_pro_gram_mer, be_tje_ning
af takt_sig_nals_af_bry_del_se )
>ti-4
(a)@MONITOR  ( administration af proces in_kar_na_tions afvikling )
>ti-4
(4)@PRINTEXCEPT (@undtagelses håndtering@)
>ti-4
(9)@STDROUTINES  ( fælles procedurer )
>in-6

Testet for homogenitet viser sig at give en ret kraf_tig 
sig_ni_fi_kans^, så Ho må for_kas_tes. Det_te efter_lader to mu_lig_he_der

- Der er grupperinger ( klasseop_deling ) af de pro_gram_mer,
der ind_går i det basale system.

- Homogenitetsafvigelserne er ikke sy_ste_ma_tis_ke, så 
pro_gram_mer_ne må be_trag_tes un_der et på trods af den sto_re
va_ria_tion i ma_te_ri_alet.

>a3 KLASSEOPDELING I DET BASALE SYSTEM.

For at afdække spørgsmålet om program_grup_pe_rin_g^er har jeg
be_nyt_tet føl_gen_de frem_gangs_må_de.

>a4 HISTOGRAMMER.

Først granskede jeg histogram^merne for in_struk_tions_an_ven_del_ser.
Dette af_dæk_ke_de in_gen sy_ste_ma_tik; men jeg følte mig dog ik_ke
i stand til at af_vise en klasse_op_de_ling af pro_gram_mer_ne på
det_te grund_lag.

>a4 SUMMERING AF HISTOGRAMMER.

Jeg udviklede et program, der er i stand til at samle et ak_ku_mu_le_re^t
hi_sto_gram over alle de en_kel_te hi_sto_gram_mer ( sam_me pro_gram
an_vend_tes i øv_rigt til be_reg_nin_ger af tes_to_ren for 
ho_mo_ge_ni_tets_ana_ly_sen ). Det_te pro_gram blev ud_vi_det, så
der for hver in_struk_tion over en vis fre_kvens ( 0.8 % i det 
ak_tu_el_le til_fæl_de@) bli_ver pro_du_ce_ret en graf for de en_kel_te
pro_gram_mers pro_cent_vise an_ven_del_se af den på_gæl_den_de 
in_struk_tion^ som funk_tion af an_tal_let af in_struk_tio_ner.

Der var to grunde til at inddrage antal_let af in_struk_tio_ner i
un_der_sø_gel_sen:

- Det er nemmere at få et overblik over, hvil_ke pro_gram_mer, der
er for små til at de kan til_læg_ges no_gen be_tyd_ning.

- Det kunne tænkes, at programmets størrelse har ind_fly_del_se på
an_ven_del_sen af in_struk_tio_ner, og det_te vil_le jeg ger_ne ha_ve
be_lyst ved sam_me lej_lig_hed.

Herunder er vist et udpluk af disse oversigts_fi_gu_rer
>ne 29
>sp 27
>fg Det basale systems anvendelse af RECHW.
Tallene på figuren re_fe_re_rer til de for_skel_li_ge mo_du_ler,
der ind_går i un_der_sø_gel_sen

Der er stor forskel på, hvor meget program_mer_nes
in_struk_tions_fre_kven_s^er va_rie_rer fra in_struk_tion til 
in_struk_tion. Det ser ikke u_mid_del_bart ud til, at der er ta_le
om no_gen grup_pering^ af pro_gram_mer_ne. Det ser tvært_imod ud til
at pro_gram_mer, der er ens_ar_te_de i anven_del_sen af vis_se
in_struk_tio_ner er for_skel_lige med hen_syn til an_dre
in_struk_tions_fre_kven_ser, uden at der er no_get fast møn_ster
(@ind_de_lings_kri_te_ri_um@) med hen_syn til 
in_struk_tions_fre_kven_ser.
Bortset fra små pro_gram_mer er der ik_ke no_gen sær_lig sam_men_hæng
mel_lem an_tal_let af in_struk_tio_ner i et pro_gram og de en_kel_te
in_struk_tio_ners fre_kven_ser. Det kun_ne f.eks. ven_tes, at antal_let af
pro_ce_dure_kald vil_le vok_se som en funk_tion af an_tal_let af
in_struk_tio_ner, for_di der med stør_re pro_gram_mer er et stør_re
be_hov for at be_nyt_te pro_ce_du_re_kald som "macroer", for at
be_va_re over_blik_ket over pro_gram_mets funk_tion. Der er vis_se
tegn på no_get så_dant, men ik_ke no_gen klar ten_dens.
>ne 29
>sp 27
>fg Det basale systems anvendelse af REAGD.
Tallene på figuren refererer til de forskellige mo_duler, der ind_går
i under_søgelsen.

Den her skitserede fremstillings_form gav et bed_re ind_tryk af
ma_te_ria_lets struk_tur, end det op_rin_de_li_ge hi_sto_gram,
der var ud_gangs_punk_tet; men sta_dig var jeg ik_ke
i stand til helt at af_vi_se teo_ri_en om klas_se_op_de_ling.

>a4 FORSKEL - LIGHED.

Næste trin i vurderingen blev, at jeg samlede pro_gram_lig_hed^ /
pro_gram_for_skel_lig_hed^ op i en k@x@k kryds_ta_bel, hvor
k er antallet af pro_gram_mer. Tabel(i,j) med j > i tæl_les op ved
lig_hed mel_lem pro_gram num_mer i og pro_gram num_mer j. Ved
for_skel tælles Tabel(j,i) op i ste_det. Hvis de to om_tal_te
pro_gram_mer hver_ken er ens el_ler for_skel_li_ge tælles der
ikke op i Tabel(i,j).

Kriterierne for forskel og lighed er ikke åben_ly_se. De må i
prin_cippet være ind_ret_tet lo_ga_rit_misk i for_hold til
stør_rel_sen af fre_kven_sen (@små pro_cent_vise fo_re_koms_ter
skal lig_ge tæt_te_re end sto_re fo_re_koms_ter be_hø_ver at gø_re@).
Et ud_gangs_punkt for hvor tæt fre_kvenser skal ligge for at lig_ne
hin_an_den, henholds_vis hvor stor af_stan_den skal væ_re for at de
er for_skel_li_ge, kun_ne væ_re at ud_reg_ne konfi_dens_græn_ser
for p@ i X@-@(m-1)(k-1) for_de_lin_gen, og så bru_ge dis_se af_vi_gel_ser
som må_le_stok for for_skel/lig_hed^.

Jeg har imidlertid anlagt et lidt me_re en_kelt ud_gangs_punkt.
Hvis obser_va_tio_nerne x% og y% skal vur_de_res med hen_syn til
for_skel/lig_hed, kunne føl_gen_de to udsagn være aktu_elle for x og
y stør_re end 0:
>ne 3

 I log(x/100) - log(y/100) I < K1
 I log(x/100) - log(y/100) I > K2

Nu er x og y i de kon_kre_te til_fæl_de små stør_rel_ser (nu_me_risk).
For at an_ven_de den loga_rit_mis_ke sammen_hæng rime_ligt, kan man
trans_for_me_re x og y line_ært først. Mit for_slag til
trans_for_ma_tio_ner er:

 f(x) = 100 * x + 1,  for x c R+

Rela_tionerne bliver da:

>ne 2
 I log(x+1) - log(y+1) I < K1
 I log(x+1) - log(y+1) I > K2

>ne 9
hvilket giver:

 lighed:  1/K1  1     x+1     1/K1
                -  < ----- <        2
                2     y+1      

 forskel: 1/K2  1     x+1     1/K2         x+1
                -  > -----  v       2  <  -----
                2     y+1                  y+1

Begrundelsen for dette ret simp_le ud_gangs_punkt er:

- Metoden skal afdække klasseopdelinger; men ik_ke be_vi_se dem.
En mu_lig klas_se_op_de_ling skal ik_ke kun_ne for_kas_tes un_der
Ho in_den for klas_sen af pro_gram_mer. Det be_ty_der, at Ho
ef_ter_prø_ves sta_tis_tisk i det re_du_ce_re_de ud_falds_rum.

- Bortset fra ganske få hyppige in_struktion^er lig_ger mid_del_værdierne
tæt samlet. Selv en sim_pel diffe_rence kan for_ven_tes at være anven_delig.

- Grænserne, som denne kvo_tient skal tes_tes imod, kan 
selv_føl_ge_lig va_ri_eres. De skal i_mid_ler_tid kun an_ven_des til
bil_led_ligt talt 'at skil_le få_re_ne fra buk_ke_ne'. Grænser, der
be_vir_ker, at Table(i,j)@=0 for en_ten al_le i,@j, hvor j@>@i
(@lighed@), el_ler for al_le i,@j, hvor i@>@j er u_in_ter_es_san_te.

Mit første forsøg var med grænsen for lighed sat til K1=0.25, og græn_sen
for for_skel sat til K2=0.5. Dis_se græn_ser vi_ste sig at væ_re me_get
an_ven_de_li_ge, u_den at jeg i øv_rigt vil ar_gu_men_te_re for,
at de er de bedst valg_te; men de er i alt fald til_stræk_ke_ligt
go_de til at af_kla_re ma_te_ri_a_lets struk_tur i for_bin_del_se med
klas_se_op_de_lings_un_der_sø_gel_sen. Neden_stå_en_de ta_bel vi_ser
en sådan kryds_ta_bel for det ba_sale sy_stem.
>ne 30
>sp 28
>fg Forskel/lighed^ i det basale system.

Det fremgår meget klart, at pro_gram_mer_ne ind_byr_des sam_ti_dig
er både ens for nog_le in_struk_tions_an_ven_del_ser
og for_skel_li_ge for an_dre. Teo_ri_en om klas_se_op_de_ling^ må afvi_ses
for det basale system. Det bed_ste man her_ef_ter
kan gø_re, er at be_trag_te det basale system som en en_hed,
selv om der ik_ke er ho_mo_ge_ni_tet i pro_gram_mer_nes 
in_struk_tions_fre_kven_ser.

Det skal bemærkes, at det ikke har me_ning at un_der_sø_ge 
klas_se_op_de_ling på tværs af de un_der_søg_te sy_ste_mer, med
mind_re, der i de en_kel_te sy_ste_mer af_dæk_kes klas_ser.

Nedenstående figur viser for_de_lin_gen af in_struk_tions_fre_kven_ser
for det basale system ak_ku_mu_le_re^t.
>ne 48
>sp 45
>fg Instruktionsanvendelse i det basale system.

>a2 RESULTATER FRA ALARMSYSTEMET.

Der indgår 18 moduler i Alarmsystem^_un_der_sø_gel_sen.
Der er dog kun 14 af disse, der har en stør_rel_se, så de
sta_tis_tisk set kan ind_gå i over_ve_jel_ser ved_rø_ren_de 
klas_se_op_de_ling^ af mo_du_ler_ne.

Alarmsystemet er gennemarbejdet på samme må_de som be_skre_vet
for det basale system. Som det kun_ne ven_tes, fal_der nog_le af de
helt små mo_du_ler uden_for det ge_ne_rel_le bil_le_de.

Nedenstående figurer viser nogle eks_emp_ler på mo_du_ler_nes
in_struk_tions_fre_kven_ser som funk_tion af an_tal in_struk_tio_ner.
De en_kel_te mo_du_ler er i_den_ti_fi_ce_ret ved 1,2,...,9,a,b,...
De undersøg_te mo_du_ler er:


- (1) AT-CONNECTOR
- (2) TSOPSYS
- (3) AT-HANDLER
- (4) TSSUPERVISOR
- (5) EVA (ADAM)
- (6) VC-HANDLER
- (7) VCATC
- (8) TSCONNECTOR
- (9) TIMEOUT
- (a) CHECK5
- (b) TAP
- (c) DCMODULE
- (d) VAGT
- (e) LAM
- (f) TESTOPEN
- (g) TIMERBOOK
- (h) TESTOUT
- (i) TIMERUPDATE
>np
>ne 50
>sp 49
     Fig. 13, 14.  Anvendelsen af RENHB og REVSW.
>np
Bemærk at modul c har en meget afvigende pro_cent_sats for RENHB.
Denne in_struk_tion hæn_ger meget nø_je
sam_men med pro_ce_du_re_kald, så
for_mod_nin_gen om et be_hov for pro_ce_du_rer 
for at be_va_re over_blik_ket styr_kes. I øv_rigt er
struk_tu_ren i ma_te_ria_let me_get lig struk_tu_ren i det basale
sy_stem. Ne_den_stå_en_de ta_bel vi_ser for_skel/lig_hed for
Alarm_sy_ste_met.
>ne 38
>sp 29
>fg Forskel/lighed^ i Alarmsystemet.

Bortset fra de små moduler er der ingen ten_dens til klas_se_op_de_ling;
men tvært_i_mod en ens_ar_tet_hed i for_skel/lig_heds_un_der_sø_gel_sen
der be_vir_ker, at demonstrations_model_len af Alarm_sy_ste_met og_så må  
be_trag_tes som en hel_hed i stil med det ba_sa_le sy_stem.

Nedenstående figur viser den akkumu_le_re_de in_struk_tions_fre_kvens
for Alarm_sy_stem_demon_stra_tions_mo_du_ler_ne.
>ne 50
>sp 47
>fg Total in_struk_tionsanvendelse i Alarmsystemet.

>a2 RESULTATER FOR PAXNET^ MODULERNE.

Undersøgelserne omfatter følgende moduler:

- (1) NCP
- (2) DTE-INT
- (3) COMINT
- (4) FORMATTER
- (5) NCTH

Disse moduler udgør ikke et totalt netknude_system^; men er
re_præ_sen_tan_ter for ty_pis_ke mo_du_ler i net_knu_de_sam_men_hæng.
Grunden til den_ne u_fuld_stæn_dig_hed er ude_luk_ken_de 
ka_len_der_tids_mæs_si_g, i_det sy_ste_met ik_ke er fær_dig_ud_vik_let
end_nu. I den sta_tis_ke un_der_sø_gel_se me_ner jeg dog det har god
me_ning at med_tage mo_du_ler_ne i un_der_sø_gel_sen.

Ikke overraskende viser det sig, at PAXNET modu_ler_ne ik_ke har
ho_mo_gen an_ven_del_se af in_struk_tio_n^er_ne (@Ho@af_vi_ses@).
Neden_for vi_ses et par in_struk_tions_anven_del_ser
>ne 26
>sp 25
>fg PAXNET modulernes anvendelse af REALD
>ne 25
>sp 22
>fg PAXNET modulernes anvendelse af REAGD

Det vi_ser sig des_u_den, at der ik_ke er klas_se_op_de_lin_g^er af
mo_du_ler_ne, så og_så PAXNET be_trag_tes som et sy_stem.

Nedenstående viser tabellen for for_skel/lig_hed.
>ne 18
>sp 16
>fg Forskel/lighed^ for PAXNET modulerne.

Den akkumulere^de opsamling for disse mo_du_ler frem_går af ne_den_stå_ende
>ne 50
>sp 48
>fg Instruktionsanvendelse for PAXNET moduler.

>a2 SAMMENLIGNING AF SYSTEMERNE.

De tre gennemarbejdede systemer kan naturligvis sam_men_lig_nes ef_ter
sam_me mo_del som an_vendt for de en_kel_te sy_ste_mer. På for_hånd
kan det for_ven_tes, at det basale system skil_ler sig ud. Grun_den
her_til er, at en hel ræk_ke in_struk_tio_n^er er spe_ci_elt
ma_skin_un_der_støt_ten_de (@f.eks. CSELL, der udvæl_ger et ni_veau@),
eller under_støt_ter da_ta_struk_tu_rer, der er funda_men_ta_le for det
basale system (@CULST, der afkæder sidste element i en kædestruktur,
CSCHD, der ud_væl_ger næs_te pro_ces_in_kar_na_tion på le_vel 0@. 
(Bag80)@). Disse in_struk_tio_ner bru_ges kun i det basale system og
hyp_pig_he_den af de øv_ri_ge in_struk_tio_ner for_ven_tes der_for
lidt lavere end for de øv_rige sy_ste_mers ved_kom_men_de. Det skal så
vi_se sig om det får no_gen prak_tisk be_tyd_ning.

Nedenfor vises nogle eks_emp_ler på total_sy_ste_m^ets 
in_struk_tions_an_ven_del_se^.
>ne 26
>sp 25
>fg Totalsystemets anvendelse af STVGD.
>ne 29
>sp 28
>fg Totalsystemets anvendelse af STVSB.

Der er tilsyneladende tale om en sta_bi_li_se_ring^ af fre_kven_s^er_ne,
vel på grund af de bety_de_ligt fle_re in_struk_tio_ner, der ind_går i
total_sy_ste_mer_ne end i de en_kel_te mo_du_ler (@sto_re tals lov@).
Der er ingen tegn på at det basale sy_stem skil_ler sig ud som før
an_ført.

Forskel/lighed^ undersøgelsen blev fore_taget med de sam_me græn_ser
som brug_tes i mo_dul_un_der_sø_gel_ser_ne. Ne_den_stå_en_de ta_bel
vi_ser re_sul_ta_tet. Græn_sen for for_skel/lig_hed er en_ten for
stor, el_ler og_så er der ho_mo_ge_ni_tet. Det_te ty_der tal_le_ne i
den ø_ver_ste høj_re del af ta_bel_len dog ik_ke på, og test af Ho 
gi_ver da og_så en for_kas_tel_se. Kør_sel med en mind_re græn_se er 
o_ver_flø_dig og den sam_le_de kon_klu_sion på struk_tur_under_sø_gel_se^n
bli_ver alt_så, at kan_di_da_t^er_ne kan ud_væl_ges fra det to_ta_le
ma_te_ri_a_le, u_den at der ta_ges spe_cielt hen_syn til for_skel_li_ge
sy_ste_mer.

>ne 15
>sp 13
>fg Forskel/lighed^ i Totalsystemet.

Jeg vil, som nævnt i kapitel 4.3.1.1,
gøre opmærksom på, at klas_se_struk_tur^er er under_søgt på
in_struk_tions_ni_veau_^et. Teo_re_tisk kun_ne man fo_re_stil_le sig,
at der fak_tisk er en klas_se_op_de_ling, der blot først kom_mer frem,
når man ser på næs_te lag, der er in_struk_tio_ner_nes 
pa_ra_me_ter_an_ven_del_se^r. Jeg har valgt at stop_pe ved
in_struk_tions_an_ven_del_sen, dels for_di der ikke ved en u_mid_del_bar
vur_de_ring af pa_ra_me_ter_under_sø_gel_sen er no_gen ten_dens til
dif_fu_sion^, dels arbejder de enkelte sy_ste_mer un_der de sam_me 
de_fi_ni_tio_ner for de mest ba_sa_le (@ofte an_vend_te@) 
da_ta_struk_tu_r^er og kon_ven_tio_n^er, så der er god grund til at
an_ta_ge at pa_ra_me_ter_an_ven_del_sen og_så vil væ_re sam_men_fal_den_de
for de under_søg_te mo_du_ler.

Nedenstående viser de akkumulere^de in_struk_tions_an_ven_del_se^r for
de tre sy_ste_mer.
>ne 48
>sp 46
>fg Totalsystemets in_struk_tionsanvendelse.

>a1 VALG AF KANDIDATER.

I forrige kapitel blev det fastslået, at ud_væl_gel_sen af kan_di_da_t^er
til pa_ra_me_ter_ind_kod_ning^ skal ske ud fra det to_ta_le an_tal
mo_du_ler, der er ind_gå_et i un_der_sø_gel_sen.

Som før beskre_vet er over_sæt_te_ren ud_vik_let til på grund_lag af
en bruger_defi_ne_ret in_struk_tions_lis_te med til_hø_ren_de in_ter_val_be_skri_vel_se^r,
at gi_ve en over_sigt over pa_ra_me_ter_an_ven_del_se^r
for de o_ver_sat_te ru_ti_ner.

Jeg har der_næst ud_vik_let et pro_gram, der kan akkumu_le_re^ så_dan_ne
sta_ti_stik_ker, pro_du_ce_ret ud fra sam_me spe_ci_fikation.

Metoden med intervalopdeling^ har som ven_tet vist sig at væ_re me_get
an_ven_de_lig. Det har kun væ_ret nød_ven_digt at fore_tage me_get få
'prø_ve_skud' på et mind_re ma_te_ria_le før den an_vend_te 
spe_ci_fi_ka_tion var frem_kom_met. Ud_væl_gel_sen af in_struk_tio_n^er
er dels sket ud fra den opsam_le_de sta_ti_stik over
in_struk_tions_fre_kven_ser, dels ud fra et kend_skab til kob_lin_ger
mel_lem in_struk_tio_ner i mic_ro_pro_gram_met. Kob_lin_ger_ne er
f.@eks. an_ven_del_se af sam_me a_dres_se_rings_vej el_ler til_sva_ren_de,
der kom_mer
før pa_ra_me_ter_hent_nin_gen. Det_te kom_pli_ce_rer ud_væl_gel_sen af
kan_di_da_ter en smu_le, dels for_di der er ta_le om kan_didat_fami_lie^r,
dels for_di ind_kod_nin_gen kræ_ver for_skel_li_ge an_tal trin fra
fa_mi_lie til fa_mi_lie.

Der er i princippet tale om, for de enkelte fa_mi_lier, at un_der_sø_ge,
hvor_le_des pa_ra_me_tre kan om_skri_ves på føl_gen_de form:

 PARAM = K + x , hvor K er konstant og 0 < x < max.

Indkodningen af en in_struk_tion I kan da bestå i at erstatte

 I < PARAM >  med In < x > 

eller eventuelt med:

  In1, In2, ...., Inp , afhængig af max.

Ovennævnte in_struk_tionsrække_føl_ge kan inde_hol_de 'huller'. En
ind_kod_ning, der be_ty_der, at der ind_fø_res m nye instruk_tio_ner,
er kun re_le_vant, hvis vær_di_en x kan ind_gå i sel_ve ope_ra_tions_koden
for In1, In2, ... Inp på en ens_artet må_de (@f.eks. sid_ste fi_re bit
af ope_ra_tions_ko_den@), så mi_kro_pro_gram_ud_vi_del_sen be_står
i at kun_ne gen_ken_de In1, In2, ... Inp som in_struk_tio_ner og så i
øv_rigt be_hand_le disse helt ens, dvs. bereg_ne x ud fra 
ope_ra_tions_ko_den, ad_de_re kon_stan_ten K og der_næst ud_fø_re den
op_rin_de_li_ge in_struk_tion ef_ter pa_ra_me_ter_hent_ningen.

Vælges alternativet, hvor in_struk_tionen In bibe_hol_der en pa_ra_meter, der
fyl_der mind_re, skal mi_kro_pro_gram_met lige_le_des ken_de 
in_struk_tionen In, hen_te pa_ra_me_teren x, ad_de_re K og fort_sæt_te
med in_struk_tio_nen I ef_ter pa_ra_me_ter_hent_ning.

Da operationskoden skal være indeholdt i en ok_tet (@med mind_re der
ind_fø_res en "escape" instruk_tion@), er der en be_græns_ning på
256 in_struk_tioner, og heraf er 86 le_di_ge. Det_te læg_ger
na_tur_lig_vis en be_græns_ning på hvil_ke vær_di_er af grænsen <max>, der
er in_ter_es_san_te.

Operationskoderne er ikke valgt så der er pas_sen_de fort_lø_ben_de
num_re le_di_ge; men det vil væ_re me_get en_kelt at re_de_fi_ne_re
in_struk_tio_ner_nes ope_ra_tions_ko_der, dels for_di over_sæt_te_r^en
pro_du_ce_rer kode ta_bel_sty_ret ud fra en sym_bolsk ko_de, og dels
for_di mi_kro_pro_gram^_met be_nyt_ter sig af en ta_bel_sty_ret^ 
in_struk_tions_af_vik_ling^. En om_læg_ning kræ_ver dog en ny
over_sæt_tel_se af al_le pro_gram_mer. Da der ved pro_gram_ind_læs_ning er
kon_trol af ver_sions_num_mer, er der i prak_sis in_gen pro_ble_mer
for_bun_det med en så_dan æn_dring.

Jeg har nævnt begrænsningen på 86 ledige instruk_tions_vær_di_er.
De_su_den er der en be_græns_ning stam_men_de fra le_di_ge trin i
mi_kro_program_met. Der er ca. 20 trin til_ba_ge til ind_kod_ning af
pa_ra_me_tre, så den egent_li_ge be_græns_ning lig_ger her.

Det er nu mu_ligt at op_stil_le en lis_te over kan_di_dat_fa_mi_li_er,
sor_te_ret ef_ter det sam_le_de an_tal ok_tet_ter, der kan spa_res pr.
an_vendt trin i mi_kro_pro_gram_met.

Da fastlæggelsen af K  og grænsen <max> har ind_fly_del_se på an_tal_let af
trin der skal bru_ges, vil lis_ten bli_ve ud_for_met så en fa_milie
af kan_di_da_ter op_træ_der før_ste gang på lis_ten, med en fast_læg_gelse
af kon_stan_ter og græn_ser (@<max>@), der gi_ver den størst mu_li_ge
be_spa_rel_se pr. trin. Yder_lige_re be_spa_rel_ser ved an_ven_del_se af
ek_stra trin kan så op_træ_de se_ne_re på lis_ten, og hvis en 
kan_di_dat_fa_mi_lies an_den eller senere fore_komst slip_per med blandt
de ud_valg_te kan_di_da_ter, er det na_tur_lig_vis den mest omfat_ten_de
(@sidste@) ind_kod_nings_form, der væl_ges.

Det skal, som før nævnt, bemærkes, at adresse^r, der op_træ_der som pa_ra_me_tre, ik_ke
kan gø_res til gen_stand for ind_kod_ning, da den adres_se_re_de ko_de
er flyt_bar (@fastlægges først ved pla_ce_rin_gen i la_ge_ret -
extern/intern sammen_kæd_ning@).

Tilbage er der næsten udeluk_ken_de in_struk_tio_ner af for_men
<@opcode@><@param@>, hvor <@param@> fylder 16 bit (@2 ok_tet_ter@). Det_te
simp_li_fi_ce_rer selv_føl_ge_lig ud_væl_gel_sen.

Nedenstående figurer viser pa_ra_me_ter_in_ter_val_op_de_lin_g^en for
det to_ta_le an_tal pro_gram_mer, der er un_der_søgt.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
>sp 48
>fg Total pa_ra_me_terintervalopdeling.
>np
Disse resultater bevirker, at kandidatlis_te^n ser ud som føl_ger
>ne 27
>fd 10 41 60
>ta 12 42
>nf



>fb
!       Kandidater! Sparet
>fb
!RECHW, 0/1/2 ... 15/16! 11898 oktetter
>fb
!RENHB, 16!  4440 oktetter
>fb
!REVLB/W/D/F, X!  3663 oktetter
>fb
!STVS/B/W/F, 0/2/4/6/28/30!  3226 oktetter
>fb
!REAG/LD X!  2599 oktetter
>fb
!REVSW/D/F, 0/2/4/6/12!  2274 oktetter
>fb
!PCALS <LEVEL> X <ADDRESS>!  2213 oktetter
>fb
!REVGB/W/D/F, X!  2139 oktetter
>fb
!STVLB/W/D/F, X!  1578 oktetter
>fb
!JMZ/EQ/NE/LT/GT/LE/GE X!  1311 oktetter
>fb
!RECHW Y, Y c (17..255)!  1288 oktetter
>fb
!JMPRW, X!  1208 oktetter
>fb
!STVGB/W/D/F, X!   836 oktetter
>fb
!REASD, X (+UADHW)!   690 oktetter
>fe
>fi

>fg Kandidater - første forslag.

Det skal bemærkes, at der i denne liste er anvendt konstanten K@=@0 og
grænsen <max> = 255 i alle de til_fæl_de, hvor der er an_ført en para_me_ter X. Der
er i de en_kelte tilfælde 'bed_re' valg, men på grung af øget
plads_for_brug i mi_kro_pro_gram_met gem_mes den_ne dis_ku_sion
til næs_te ske_ma, hvor mi_kro_pro_gram_plads_for_brug er ind_dra_get
i kandidat_lis_te^ns priori_tering.

Det er plads^en i mi_kro_pro_gram^_met, der sætter græn_sen for an_tal_let
af til_fø_jel_ser. Ef_fek_ten med hen_syn til plads_be_spa_rel_se, som
en funk_tion af mi_kro_pro_gram plads_for_brug ses ne_den_for.
>ne 18

   oktetter sparet

        A
        I
  50.000+
        I
        I
  45.000+
        I
        I
  40.000+
        I
        I
  35.000+
        I
        I
  30.000+
        I
        I
  25.000+
        I
        I
  20.000+
        I
        I
  15.000+
        I
        I
  10.000+
        I
        I
   5.000+
        I
        I
       0+----+----+----+----+----+----+--> trin
        0    5   10   15   20   25   30

>fg Pladsbesparelse^sudviklingen pr. trin.


Ovenstående figur svarer til indholdet af den føl_gen_de ta_bel over
kandi_dater og pladsbesparelse pr. trin.

>ne 30
>nf
>fd 9 38 44 49 61
>ta 11 39 45 50
>fb
!      Kandidater!Oktet!Trin!Oktet/trin
>ta 11 39 45 52
>fb
!RECHW, 0/ ... /16!11898! 2!5949
>fb
!RENHB, 16! 4440! 2!2220
>fb
!REAG/LD X! 2599! 2!1299.5
>fb
!REVLB/W/D/F X! 3663! 3!1221
>fb
!REVGB/W/D/F X! 2139! 2!1070
>fb
!STVSB/W/F, 0/2/4/6/28../31! 3226! 4! 807
>fb
!STVLB/W/D/F X! 1578! 2! 789
>fb
!JMZ/EQ/NE/LT/GT/LE/GE X! 1311! 2! 655.5
>fb
!RECHW Y, Y c (17..255)! 1288! 2! 644
>fb
!JMPRW X! 1208! 2! 604
>fb
!REVSW/D/F, 0/2/4/6/12! 2274! 4! 568.5
>fb
!PCALS <LEVEL> X <ADDRESS>! 2213! 4! 554.25
>fb
!STVGB/W/D/F, X!  836! 2! 818
>fb
!REASD, x (+UADHW)!  690! 3! 230
>fb
!REASD, -128 + X! +224!+1! 224
>fb
!REAGD, 64 + X!
!REALD, -16 + X! +432!+2! 216
>fe
:                                                   :
:                                                   :
>fb
!REVGB, 32 + X! +95!+1!  95
>fe
>fi

>fg Pladsbesparelse/mi_kroprogramtrin

Det kan selvfølgelig ikke over_ras_ke, at de enkel_te kan_di_dat_fa_milie^r
bi_dra_ger mind_re og mind_re, og det var og_så ven_tet at for_skel_len
mel_lem kan_di_dater me_get hur_tigt bli_ver for_svin_den_de. Man kan
med andre ord ud_væl_ge de sid_ste ind_kod_nin_ger blandt nogle
kan_di_dat_fa_mi_li_er uden at ef_fek_ten med hen_syn til 
la_ger_be_spa_rel_se æn_dres syn_der_ligt. Det vil der_for væ_re
na_tur_ligt, at la_de an_dre pri_o_ri_te_rings_kri_te_rier væ_re 
af_gøren_de for val_get af de sid_ste kan_di_da_ter.

Jeg tænker her først og frem_mest på den dyna_mis_k^e an_ven_del_se af
in_struk_tio_ner_ne. I ka_pi_tel 5.1 samt i ka_pi_tel 6.1 har jeg 
be_skre_vet den me_to_de, jeg vil an_ven_de i prak_sis. Re_sul_ta_ter_ne
af den dy_na_mis_ke op_sam_ling er be_skre_vet i det føl_gen_de ka_pi_tel.

Det skal bemærkes, at den dy_nais_ke op_sam_ling end_vi_de_re skal bru_ges
til at gi_ve et skøn over ind_kod_nin_gens virk_ning på pro_gram_mers
af_vik_lings_has_tig_hed.

Jeg vil de_su_den vur_de_re kan_di_da_ter_nes sam_men_hæng med spro_gets
kon_struk_tio_n^er ( kom_po_nen_t^er@). Som på_pe_get af bl.a. Kor_ne_rup
(@Kor76@) for BCPL og O-kode^, gæl_der det til_sva_ren_de for RC3502^ 
in_struk_tions_sæt_tet, at man_ge in_for_ma_tio_ner om spro_g^ets 
struk_tur^er er gå_et tabt un_der_vejs i o_ver_sæt_tel_sen. Vis_se 
struk_tu_rer kan dog gen_ken_des, f.@eks. pro_ce_du_re_kald.

Der er flere grun_de til den_ne un_der_sø_gel_se:

- Den væ_sent_lig_ste grund er even_tuel af_dæk_ning af in_struk_tio_ner,
der ud_fø_res i se_kvens^ el_ler er kob_le_de på an_den vis, for_di de
er pro_du_ce_ret så_le_des af o_ver_sæt_te_ren i for_bin_del_se med
sprog_li_ge kon_struk_tio_ner. Ind_ko_des se_kven_ser kan det gri_be
ind i kan_di_dat_lis_te^n.
En egentlig sekvensanalyse^ bl.a. ba_se_ret på kend_skab til spro_gets 
an_ven_del_se af de en_kel_te kon_struk_tio_ner bå_de sta_tisk og 
dy_na_misk vil væ_re en na_tur_lig for_læn_gel_se af un_der_sø_gel_ser_ne
på in_struk_tions_ni_veau_et; men vil bli_ve over_ladt til vi_de_re 
stu_dier. I ka_pi_tel 10 vil jeg nø_jes med, så vidt det er mu_ligt, at
fin_de sam_men_hæn_gen fra in_struk_tions_ni_veau_et til_ba_ge til
bru_gen af sprog_li_ge kom_po_nen_ter. Skønt langt fra fyl_dest_gø_ren_de
skal det dog vi_se sig at væ_re en sær_de_les nyt_tig un_der_sø_gel_se
med kraf_tig ind_virk_ning på pa_ra_me_ter_ind_kod_nin_gen.

- En anden grund kan være, om mu_ligt, at af_dæk_ke hvor in_te_gre_ret i
spro_get en be_stemt pa_ra_me_ter_an_ven_del_se er. Anven_del_sen kan
ud_sprin_ge af sel_ve spro_g^ets de_fi_ni_tio_ner og den der_til
knyt_te_de kode_ge_ne_re_ring^. Den kan end_vi_de_re ud_sprin_ge af
ba_sa_le da_ta_struk_tu_r^er (@f.eks. fylder en alfa 12 tegn,
og det_te gi_ver bl_a. and_led_ning til hyp_pig anven_del_se af RECHW 12. Der er man_ge 
til_sva_ren_de ek_semp_ler@). En_de_lig kan kon_ven_tio_n^er, der
knyt_ter sig til an_ven_del_sen, give an_led_ning til be_stem_te 
pa_ra_me_ter_vær_di_fo_re_koms_t^er. (@f.eks vil kon_ven_tio_ner for
da_ta_de_len af en "mes_sa_ge" be_vir_ke at en "re_cord_struk_tur", der
så_le_des er fast_lagt, vil bli_ve re_fe_re_ret en del. Dette kan f.@eks.
be_vir_ke be_stem_te pa_ra_me_ter_vær_di_er til in_struk_tio_nen 
REVSB, REVSW m. fl.@).
Hvis dis_se bag_grun_de for kan_di_da_ter_ne kan af_dæk_kes vil 
gra_den af in_te_gra_tion^ i spro_get være en priori_te_rings_grund
i kan_di_dat_ud_væl_gel_sen.
>a1 RESULTATER FRA DEN DYNAMISKE OPSAMLING.

Den dynamisk^e opsamling^ var oprindelig plan_lagt for al_le de 
un_dersøg_te pro_gram_kom_plek_ser.

Af praktiske ( kalendertidsmæssige ) grun_de, har det kun væ_ret
mu_ligt at gen_nem_fø_re un_der_sø_gel_sen for det basale system og
for Alarm_sy_ste_met. Da ud_gangs_punk_tet er, at al_le tre sy_ste_mer
be_hand_les un_der et, fin_der jeg dog det_te min_dre væ_sent_ligt.

Jeg har sam_let dy_na_misk sta_ti_stik un_der for_skel_li_ge 
be_last_nin_ger af sy_ste_met og vil i det føl_gen_de tage hen_syn til de 
in_ter_val_ler, som de en_kel_te instruk_tions_fre_kven_ser lig_ger in_den
for.

Jeg har sikret mig at input/output ikke for_styrres af op_sam_lin_gen
(@in_gen in_tro_du_ce_re_de re_trans_mis_sio_ner el_ler "time_outs"@).
Jeg har end_vi_de_re, for at få en for_nem_mel_se af de dy_na_mis_ke
fre_kven_sers va_ria_tion fo_re_ta_get må_lin_ger un_der ad_de_re_de
be_tin_gel_ser, spæn_den_de fra se_kven_ti_el_le ik_ke kom_mu_ni_ke_rende
pro_ces in_kar_na_tio_ner over kom_mu_ni_ke_ren_de
proces in_kar_na_tio_ner til "I/O" bund_ne pro_ces in_kar_na_tio_ner.

>a2 BAGGRUND FOR EFFEKTVURDERING.

De be_sluttede indkodninger bevirker, som før nævnt, fær_re
la_ger_til_gan_g^e un_der ud_fø_rel_sen af et pro_gram og med_fø_rer 
der_med hur_ti_ge_re pro_gram_af_vik_ling^.

For at kunne vur_dere effekten, vil jeg først skit_se_re hvor_dan
la_ger_til_gan_ge på_vir_kes i for_bin_del_se med ind_kod_ning.

Lad en in_struk_tion^ I* være en ind_kod_ning af in_struk_tio_nen I. Lad
læng_den af I* væ_re L* oktetter og af I væ_re L ok_tet_ter. An_tal_let af
ok_tet_ter, der spa_res bliver da (@L@-@L*@)@>@0.

Hvis (@L@-@L*@)@MOD@2@=@1, så ændres lager_bille_det ana_log med en af 
føl_gen_de fi_gu_rer, der vi_ser lagerud_snit star_ten_de på li_ge adres_se^r og med xxxxx
symbo_li_se_ren_de den plads, der anven_des af en in_struk_tion:

>ta 13 19 40 46
>ne 39
>nf
 1.
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   IxxxxxIxxxxxI              IxxxxxIxxxxxI
   -------------    =====>    -------------
   IxxxxxI     I              I     I     I
   -------------              -------------

 2.
!lige !ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   I     IxxxxxI              I     IxxxxxI
   -------------    =====>    -------------
   IxxxxxIxxxxxI              IxxxxxI     I
   -------------              -------------

 3.
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   IxxxxxIxxxxxI              IxxxxxIxxxxxI
   -------------    =====>    -------------
   IxxxxxIxxxxxI              IxxxxxI     I
   -------------              -------------

 4.
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   I     IxxxxxI              I     IxxxxxI
   -------------              -------------
   IxxxxxIxxxxxI    =====>    IxxxxxIxxxxxI
   -------------              -------------
   IxxxxxI     I              I     I     I
   -------------              -------------
>fi

>fg Ulige antal oktetter indkodet.

Hvis ( L - L* ) MOD 2 = 0 æn_dres la_ger_bil_le_det ana_log med et af føl_gen_de
til_fæl_de:

>ne 39
 5.
>nf
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   IxxxxxIxxxxxI              IxxxxxI     I
   -------------    =====>    -------------
   IxxxxxI     I              I     I     I
   -------------              -------------

 6.
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   I     IxxxxxI              I     IxxxxxI
   -------------    =====>    -------------
   IxxxxxIxxxxxI              I     I     I
   -------------              -------------

 7.
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   IxxxxxIxxxxxI              IxxxxxIxxxxxI
   -------------    =====>    -------------
   IxxxxxIxxxxxI              I     I     I
   -------------              -------------

 8.
!lige!ulige!lige  ulige
!oktet!oktet!oktet oktet
   -------------              -------------
   I     IxxxxxI              I     IxxxxxI
   -------------              -------------
   IxxxxxIxxxxxI    =====>    IxxxxxI     I
   -------------              -------------
   IxxxxxI     I              I     I     I
   -------------              -------------
>fi

>fg Lige antal oktetter indkodet.

Hentning af en in_struk_tion inklu_sive para_me_tre er ind_ret_tet, så
der læ_ses 16 bit ad gan_gen star_ten_de med en uli_ge ok_tet. Der er
in_gen form for "pre_fetch" in_vol_veret, dels på grund af at hent_ning
af ope_ra_tions_ko_den fore_går pa_ral_lelt med an_dre op_ga_ver i
mi_kro_ma_ski_nen ( f.eks ana_ly_se af af_bry_del_ses_be_tin_gel_ser@),
dels på grund af de man_ge ni_veau_er med til_høren_de regis_ter_sæt,
der hver især kan udpege næs_te in_struk_tion ved næs_te instruk_tions_hent_ning.

Det er tilfældigt om en in_struk_tion star_ter på en li_ge el_ler en
u_li_ge ok_tet, hvil_ket er 've_ri_fi_ce_ret' ved at se på stik_prø_ver
fra la_ge_ret.

Med disse bemærkninger som bag_grund ses det, at der spa_res en 
hent_ning fra la_ger i føl_gen_de si_tua_tio_ner 1,4,5,6,7,8 (@numrene 
re_fe_re_rer til de to fo_re_gå_en_de fi_gu_rer@) men ik_ke i 2 og 3.

Der er altså tale om en be_spa_rel_se på :

- ( L - 1 - L* ) DIV 2 + 1/2 lagertil_gan_ge, hvis der spa_res et u_lige
an_tal ok_tet_ter.

- ( L - L* ) DIV 2 lager til_gan_ge, hvis der spa_res et li_ge an_tal
ok_tet_ter.

Som en tommelfin_gerregel kan man benytte, at
alle de kan_didater, der kan kom_me på ta_le, med_fø_rer en_ten en-
el_ler to-ok_tet for_kor_tel_ser. Det er alt_så til_stræk_ke_ligt at
vur_de_re kan_di_da_ter i for_hold til det an_tal ok_tet_ter,
instruk_tio_nen bli_ver kor_te_re, idet for_hol_det mellem spa_rede
lager_til_gan_ge gennem_snit_ligt vil væ_re 1@:@2.
Desuden divi_deres med an_tal trin, som ind_kod_nin_gen op_ta_ger
i mi_kro_pro_grammet, da antal trin er be_græn_sen_de fak_tor.

Denne tommelfingerregel er dog ikke helt kor_rekt, da der ikke
benyt_tes de samme la_ger_hent_nings_proce_du_rer over_alt i mi_kro_program_met
og i det føl_gen_de vil jeg der_for op_stil_le kan_di_da_ter ud fra

  <forventet forekomst>*<tidsbesparelse>/trin

Tids_bespa_relserne frem_går af figur 43 og 44 i det føl_gen_de af_snit.

>a2 DYNAMISK KANDIDATUNDERSØGELSE.

Undersøgelsen af de sidste 'lige gode' statiske kan_dida_ters
dy_namis_k^e fre_kven_ser kon_cen_tre_rer sig om føl_gen_de:

>ne 21
>ta 10 36 42
>nf
>fd 9 35 40 61
>fb
!    Kandidater!Trin!Statisk besparelse
>fb
!STVSB/W/F 0/2/4/6/28../31!  4!      3226
>fb
!STVLB/W/D/F <X>!  2!      1578
>fb
!JMZEQ/NE/LT/GT/LE/GE <X>!  2!      1311
>fb
!RECHW <Y> Y c (17..255)!  2!      1288
>fb
!JMPRW <X>!  2!      1208
>fb
!REVSW/D/F,!  4!      2277
!0/2/4/6/12
>fb
!PCALS P1 <X> P3!  4!      2213
>fb
!STVGB/W/D/F <X>!  2!       836
>fe 
>fi

>fg Kandidater til dynamisk undersøgelse.

De in_struk_tion^er, som disse kan_di_da_ter ud_sprin_ger fra, fo_re_kom_mer
i de dy_na_mis_k^e må_lin_ger med føl_gen_de fre_kvens_in_ter_val^_ler.

>nf
>fd 9 37 61
>ta 10 38
>ne 21
>fb
!  In_struk_tioner!   Frekvensområde
>fb
!STVSB/W/F!      2.7 - 3.7
>fb
!STVLB/W/D/F!      1.5 - 2.9
>fb
!JMZEQ/NE/LT/GT/LE/GE!      6.6 - 8.0
>fb
!RECHW!     13.3 - 15.7
>fb
!JMPRW!      2.2 - 2.5
>fb
!REVSW/D/F!      1.8 - 2.5
>fb
!PCALS!      0.4 - 0.8
>fb
!STVGB/W/D/F!      3.0 - 3.8
>fe
>fi
>fg Dynamiske in_struk_tionsfrekvens^er.

Proportionalitetsantagelsen giver:
>ne 21
>nf
>fb
!  Kandidater! Forekomst * tid / trin
>fb
!JMZEQ/../GE X! (5.9->7.1)*0.3/2 =>
!! 0.0089 -> 0.0107
>fb
!REVSW/D/F0/2/4/6/12! (1.5->2.1)*1.5/4 =>
!! 0.0056 -> 0.0079
>fb
!STVSB/W/F0/2/4/6/28/..31! (2.3->3.2)*0.8/4 =>
!! 0.0046 -> 0.0064
>fb
!RECHW Y, Y c (17..255)! (2.2->2.6)*0.3/2 =>
!! 0.0033 -> 0.0039
>fb
!JMPRW X! (1.8->2.1)*0.3/2 =>
!! 0.0027 -> 0.0032
>fb
!STVGB/W/D/F X! (1.5->1.7)*0.3/2 =>
!! 0.0023 -> 0.0026
>fb
!STVLB/W/D/F X! (1.2->2.4)*0.3/2 =>
!! 0.0018 -> 0.0036
>fb
!PCALS P1 X P2! (0.4->0.8)*0.3/4 =>
!! 0.0003 -> 0.0006
>fe
>fi
>fg Kandidaters forventede frekvens.

Hermed er kandidaternes rækkefølge un_der hen_syn_ta_gen til den
dy_na_mis_ke in_struk_tions_fre_kvens, tids_be_spa_rel_se og an_tal trin gi_vet. Men lis_ten er end_nu
kun  fore_lø_big.

>a2 FORVENTET EFFEKTFORBEDRING.

Det kan være en meget van_ske_lig sag at efter_kon_trol^_le_re en
ef_fekt_for_bed_ring^ af pro_gram_af_vik_lings_has_tig_he_d^en. Man
kan ven_te at for_bed_rin_gen kan svin_ge fra pro_gram til pro_gram.
De un_der_søg_te pro_gram_mer har ingen ind_byg_ge_de tids_må_lin_ger
og eg_ner sig ik_ke til ma_nu_el stop_urs_kon_trol. I/O bund_ne 
pro_gram_mer vil i øv_rigt spo_le_re et_hvert så_dant for_søg.

Jeg vil i stedet vælge en anden an_grebs_vin_kel til pro_ble_met.
Me_to_den vil bl.a. in_de_bæ_re den for_del, at det er mu_ligt at 
vur_de_re den nu_værende effekt - den for_ven_te_de ef_fekt_for_bedring,
samt under efter_kon_trol (@se kapi_tel 11@) at sam_men_hol_de den_ne
med den op_nå_e_de for_bed_ring.

Jeg vil i vur_de_rin_gen af ef_fek_ten sim_pelt_hen be_reg_ne den 
gen_nem_snit_li_ge in_struk_tions_tid^ for det nu_væ_ren_de 
in_struk_tions_sæt ud fra de dy_na_mis_k^e in_struk_tions_op_sam_linger.
Me_to_den er ana_log til P. Brink Hansens meto_de (@Han78@) til 
sam_men_lig_ning af mi_kro_pro_ces_so_rer. Me_to_den er brug_bar for_di
de to invol_ve_re_de in_struk_tions_sæt er funk_tio_nelt i_den_tis_ke.
Ud fra an_ta_gel_sen om pro_por_tio_na_li_tet i 
pa_ra_me_ter_vær_di_fo_re_koms_ter fra det sta_tis_ke til det dy_namis_ke
til_fæl_de, og ud fra vi_den om in_struk_tions_ti_der for de ind_ko_dede
in_struk_tio_ner, kan den for_ven_te_de gennem_snit_li_ge 
in_struk_tions_tid be_reg_nes. Ved ef_fekt_for_bed_ring^ vil jeg da for_stå
den for_ven_te_de re_duk_tion i den gen_nem_snit_li_ge in_struk_tions_tid.
Den for_vente_de re_duk_tion, der er be_reg_net her, gæl_der for den
fo_re_lø_bi_ge kan_di_dat_lis_te, der li_ge er præ_sen_te_ret.
>ne 50

>ta 11 25 35 50
>fd 9 23 33 48 61
>nf
>fb
!Instruktion!     %!Instr. tid!Tidsbidrag
>fb
>ta 15 27 38 52
!RECHW!13.25! 6.0!0.795
!REAGD! 8.09! 7.9!0.639
!JMZEQ! 5.75! 6.2!0.357
!REWGW! 5.51! 7.7!0.424
!RECHD! 5.21! 9.9!0.516
!REVGD! 4.17!11.2!0.467
!REVLW! 3.70! 7.7!0.284
!INDEX! 3.25!20.8!0.676
!REVLD! 2.74!11.2!0.307
!STVGW! 2.66! 7.6!0.202
!STWSB! 2.65! 7.6!0.201
!JMPRW! 2.41! 4.2!0.244
!GT   ! 1.94! 7.7!0.149
!REVPW! 1.85! 5.4!0.100
!STVLD! 1.81!10.6!0.192
!REVSW! 1.81!11.0!0.199
!REVSB! 1.65!11.0!0.182
!LT   ! 1.54! 7.7!0.119
!RENHB! 1.54! 4.9!0.075
!ADD  ! 1.48! 7.3!0.108
!REVLB! 1.45! 7.7!0.112
!JMZGT! 1.38! 6.2!0.086
!REALD! 1.36! 7.9!0.146
!REVGB! 1.35! 7.7!0.104
!REASD! 1.34!11.2!0.150
!INTRS! 1.16!11.5!0.133
!REVSM! 1.11!16.2!0.200
!EQ   ! 0.88! 7.5!0.066
!CWTAC! 0.87!11.8!0.139
!CWAIT! 0.87!50.0!0.435
!STVLW! 0.86! 7.6!0.065
!DIV  ! 0.81!32.7!0.265
!PEXIT! 0.77!24.0!0.185
!PCALS! 0.77! 9.1!0.070
>fb
!I alt!87.99!!8.392
>fb
>fd 9 61
>ta 11
!                         8.392*100
!Middel instruktionstid^: ---------- us = 9.54 us
!                           87.99
>fe
>fi

>fg DC-simulator. Dynamisk^ måling.
To sekunder mellem forespørgsler ("poll").

>ne 50
>ta 11 25 35 50
>fd 9 23 33 48 61
>nf
>fb
!Instruktion!     %!Instr. tid!Tidsbidrag
>fb
>ta 15 27 38 52
!RECHW!13.82! 6.0!0.829
!REAGD! 9.03! 7.9!0.713
!REVGW! 6.99! 7.7!0.538
!JMZEQ! 6.32! 6.2!0.538
!RECHD! 5.29! 9.9!0.524
!REVLW! 4.42! 7.7!0.340
!REVGD! 4.25!11.2!0.476
!INDEX! 4.09!20.8!0.851
!STVGW! 3.41! 7.6!0.259
!GT   ! 2.51! 7.7!0.193
!STVSB! 2.34! 7.6!0.178
!JMPRW! 2,24! 4.2!0.094
!REVPW! 2.10! 5.4!0.113
!REWSW! 1.99!11.0!0.219
!LT   ! 1.92! 7.7!0.148
!REVGB! 1.90! 7.7!0.146
!ADD  ! 1.74! 7.3!0.127
!JMZGT! 1.65! 6.5!0.100
!REASD! 1.46!11.2!0.164
!STVLD! 1.34!10.6!0.142
!REVSM! 1.07!16.2!0.173
!REVSB! 1.02!11.0!0.112
!TOPEN! 0.94!10.5!0.099
!CWTAC! 0.91!11.8!0.107
!CWAIT! 0.91!50.0!0.455
!SUB  ! 0.88! 7.3!0.064
!EQ   ! 0.86! 7.5!0.065
!DIV  ! 0.82!32.7!0.268
!REALD! 0.81! 7.9!0.064
!INTRS! 0.78!11.5!0.090
!STVLW! 0.78! 7.6!0.059
!RENHB! 0.74! 4.9!0.036
!REVLD! 0.70!11.2!0.055
!REVLB! 0.64! 7.7!0.049
!PEXIT! 0.37! 9.1!0.034
!PCALS! 0.37!21.6!0.080
>fb
!I alt!89.49!!8.359
>fb
>fd 9 61
>ta 11
!                         8.359*100
!Middel instruktionstid^: ----------- us = 9.34 us
!                           89.49
>fe
>fi

>fg TS-alarmmoduler. Dynamisk^ måling.
To sekunder mellem forespørgsler.

>ne 50
>ta 11 25 35 50
>fd 9 23 33 48 61
>nf
>fb
!Instruktion!     %!Instr. tid!Tidbidrag
>fb
>ta 15 27 38 52
!RECHW!14.97! 6.0!0.898
!REAGD! 9.76! 7.9!0.771
!REVGD! 6.60!11.2!0.739
!JMZEQ! 6.42! 6.2!0.398
!REVGW! 5.79! 7.7!0.446
!RECHD! 5.03! 9.9!0.500
!REVLW! 3.47! 7.7!0.267
!STVGW! 3.33! 7.6!0.253
!INDEX! 2.85!20.8!0.593
!STVSB! 2.73! 7.6!0.207
!JMPRW! 2.38! 4.2!0.100
!REVSB! 1.89!11.0!0.208
!REVSW! 1,78!11.0!0.196
!ADD  ! 1.77! 7.3!0.129
!EQ   ! 1.75! 7.5!0.131
!CWTAC! 1.41!11.8!0.166
!CWAIT! 1.41!50.0!0.705
!INTRS! 1.41!11.5!0.162
!RENHB! 1.34! 4.9!0.066
!REVSM! 1.21!16.2!0.196
!REVLB! 1.15! 7.7!0.086
!GT   ! 1.05! 7.7!0.081
!REVGB! 1.03! 7.7!0.079
!TOPEN! 0.93!10.5!0.098
!SETTM! 0.81!15.1!0.122
!REALD! 0.79! 7.9!0.062
!SUB  ! 0.77! 7.3!0.056
!STVLD! 0.76!10.6!0.081
!STVLW! 0.71! 7.6!0.054
!PEXIT! 0.67! 9.1!0.061
!PCALS! 0.67!21.6!0.145
!REVLD! 0.63!11.2!0.071
!REVPW! 0.57! 5.4!0.031
!DIV  ! 0.54!32.7!0.177
!LT   ! 0.45! 7.7!0.035
>fb
!I alt!88.83!!8.370
>fb
>fd 9 61
>ta 11
!                         8.370*100
!Middel instruktionstid^: ----------- us = 9.42 us
!                           88.83
>fe
>fi

>fg Det basale system. Dynamisk^ måling.
Belastning med sekventielle og kommunikerende pro_ces inkarna_tio_ner.

Følgende oversigt over kandidater, op_rin_de_li_ge og re_du_ce_rede
instruk_tions_ti_der samt sta_tisk para_meter_værdi_for_deling, dan_ner
bag_grund for ud_reg_nin_gen af den for_ven_te_de gennem_snit_li_ge
in_struk_tions_tid. Der er anvendt selvforklarende navne for kan_di_da_ter_ne.

>ne 42
>nf
>fd 12 35 42 55
>ta 14 36 44
>fb
!Instruktion!  Tid!Statisk
!!!fordeling
>fb
>ta 14 37 45
!RECHW! 6.0!  6.80%
!REC0/1/2..16! 4.3! 76.61%
!RECHWS! 5.7! 16.59%
>fb
!REVLB! 7.7!  0.00%
!REVLBS! 7.4!100.00%
!REVLW! 7.7!  5.26%
!REVLWS! 7.4! 94.74%
!REVLD!11.2!  0.00%
!REVLDS!10.9!100.00%
>fb
!REAGD! 7.9! 46.91%
!REAGDS! 7.6! 53.09%
!REALD! 7.9! 10.64%
!REALDS! 7.6! 89.36%
>fb
!STVLB! 7.6!  9.26%
!STVLBS! 7.3! 90.74%
!STVLW! 7.6! 21.26%
!STVLWS! 7.3! 78.74%
!STVLD!10.6! 19.28%
!STVLDS!10.3! 80.72%
!STVLF!21.8!  0.00%
!STVLFS!21.5!100.00%
>fb
!STVSB!11.0! 11.12%
!SVSB0/2/4/6/28../31!10.2! 88.88%
!STVSW!11.0! 25.35%
!SVSW0/2/4/6/28../31!10.2! 74.65%
!STVSF!25.2! 18.33%
!SVSF0/2/4/6/28/../31!24.4! 81.67%
>fb
!JMZEQ/NE../GE! 6.2! 10.65%
!JMZEQS/NES../GES! 5.9! 89.35%
>fe

>fg Instruktionstid^er og statisk fordeling.
Skemaet fortsætter næste side.
>ne 44
>fb
!Instruktion! Tid!Statisk
!!!fordeling
>fb
!JMPRW! 4.2! 17.18%
!JMPRWS! 3.9! 82.83%
>fb
!REVSW!11.0! 23.50%
!RVSW0/2/4/6/12! 9.5! 76.50%
!REVSD!14.4!  1.73%
!RVSD0/2/4/6/12!12.9! 98.27%
!REVSF!19.1! 51.69%
!RVSF0/2/4/6/12!17.6! 48.31%
>fb
!STVGB! 7.6! 49.23%
!STVGBS! 7.3! 50.77%
!STVGW! 7.6! 61.39%
!STVGWS! 7.3! 38.61%
!STVGD!10.6!  4.78%
!STVGDS!10.3! 95.22%
!STVGF!21.8! 58.33%
!STVGFS!21.5! 41.67%
>fb
!REASD!11.2! 26.44%
!REASDS!11.0! 73.56%
>fb
!REVGB! 7.7! 63.01%
!REVGBS! 7.4! 36.99%
!REVGW! 7.7! 48.52%
!REVGWS! 7.4! 51.48%
!REVGD!11.2! 38.41%
!REVGDS!10.9! 61.59%
!REVGF!15.8!  0.00%
!REVGFS!15.5!100.00%
!RENHB! 4.9! 14.09%
!RNHB16! 3.4! 85.91%
!PCALS!23.4!  0.00%
!PCALSS!23.1!100.00%
>fe
>fi

>fg Instruktionstid^er og statisk fordeling.

Den forventede forbedring beregnet på TS-alarm modulernes dynamiske
instruk_tions_for_de_ling, som den er frem_stillet her_over.
 
>ne 46
>fd 9 22 32 39 50 61
>ta 11 23 33 40 51
>nf
>fb
!Instruktion!Målt fo-!  Tid!Forventet!Tidsbidrag
!!rekomst!!forekomst
>fb
!RECHW!13.82!  6.0!  0.94!  0.056
!REC0..16!!  4.3! 10.59!  0.455
!RECHWS!!  5.7!  2.29!  0.131
!REAGD! 9.03!  7.9!  4.24!  0.335
!REAGDS!!  7.6!  4.79!  0.364
!REVGW! 6.99!  7.7!  3.39!  0.261
!REVGWS!!  7.4!  3.60!  0.266
!JMZEQ! 6.32!  6.2!  0.67!  0.042
!JMZEQS!!  5.9!  5.65!  0.333
!RECHD! 5.29!  9.9!!  0.524
!REVLW! 4.42!  7.7!  0.23!  0.018
!REVLWS!!  7.4!  4.19!  0.310
!REVGD! 4.25! 11.2!  1.63!  0.183
!REVGDS!! 10.9!  2.62!  0.285
!INDEX! 4.09! 20.8!!  0.851
!STVGW! 3.41!  7.6!  2.09!  0.159
!STVGWS!!  7.3!  1.32!  0.096
!GT! 2.51!  7.7!!  0.193
!STVSB! 2.34! 11.0!  0.26!  0.029
!SVSB0..31!! 10.2!  2.08!  0.212
!JMPRW! 2.24!  4.2!!  0.094
!REVPW! 2.10!  5.4!!  0.113
!REVSW! 1.99! 11.0!!  0.219
!LT! 1.92!  7.7!!  0.148
!REVGB! 1.90!  7.7!  1.20!  0.092
!REVGBS!!  7.4!  0.70!  0.052
!ADD! 1.74!  7.3!!  0.127
!JMZGT! 1.65!  6.2!  0.81!  0.050
!JMZGTS!!  5.9!  0.84!  0.049
!REASD! 1.46! 11.2!  0.39!  0.043
!REASDS!! 11.0!  1.07!  0.118
!STVLD! 1.34! 10.6!  0.26!  0.026
!STVLDS!! 10.3!  1.08!  0.111
!REVSM! 1.07! 16.2!!  0.173
!REVSB! 1.02! 11.0!!  0.112
!TOPEN! 0.94! 10.5!!  0.099
!CWTAC! 0.91! 11.8!!  0.107
!CWAIT! 0.91! 50.0!!  0.455
!SUB! 0.88!  7.3!!  0.064
!EQ! 0.86!  7.5!!  0.065
!DIV! 0.82! 32.7!!  0.268
!REALD! 0.81!  7.9!  0.09!  0.007
!REALDS!!  7.6!  0.72!  0.055
>fe
Skemaet fortsættes
>ne 26
>fb
!Instruktion!Målt fo-! Tid!Forventet!Tidsbidrag
!!rekomst!!forekomst
>fb
!INTRS! 0.78! 11.5!!  0.090
!STVLW! 0.78!  7.6!!  0.059
!RENHB! 0.74!  4.9!  0.10!  0.005
!RNHB16!!  3.4!  0.64!  0.022
!REVLD! 0.70! 11.2!  0.00!  0.000
!REVLDS!! 10.9!  0.64!  0.047
!PEXIT! 0.37!  9.1!!  0.034
!PCALS! 0.37! 23.4!!  0.087
>fb
!I alt! 89.49%!!!  8.036
>fb
>fd 9 61
!                        8.036*100
!Middel instruktionstid^: --------- us = 8.98 us
!                          89.49
>fb
!              (9.44-8.98)*100
!Forbedring:  ----------------- % = 4.9%
!                    9.44
>fe
>fi

>fg Forventet effektforbedring^.
>a1 KANDIDATERS SAMMENHÆNG MED SPROGKONSTRUKTIONER.

Stevenson og Tanenbaum ( STE79 ) kræver at sekvens^er er fundet
og indført ved en 'i_te_ra_tiv pro_ces' før kan_di_dat_un_der_sø_gel_se
med hen_blik på pa_ra_me_ter_ind_kod_ning kan på_be_gyn_des. Det er 
selv_føl_ge_lig og_så det let_tes_te at hånd_te_re; men da pa_ra_me_ter-
og se_kvens_ind_kod_ning kan have gen_si_dig ind_fly_del_se på
hin_an_den, er sa_gen ik_ke helt så en_kel. Egent_lig bør bå_de
se_kvens_ana_ly_ser og para_me_ter_ana_ly_ser fo_re_ta_ges og de en_kel_te
kan_di_da_ter fra beg_ge grup_per kon_trol_le_res for ind_fly_del_se
på den an_den gruppes kan_di_da_ter. Det er så_dan_ne o_ver_ve_jel_ser,
der lig_ger til grund for det_te ka_pi_tel. En fuld_stændig 
se_kvens_ana_ly_se vil_le der_for væ_re at fo_re_træk_ke; men jeg vil
o_ver_la_de det_te til vi_de_re stu_di_er. I ste_det vil jeg med 
ud_gangs_punkt i de ud_før_te op_sam_linger, sta_tisk og dyna_misk, 
be_hand_le kandi_da_ter_ne (@kan_di_dat_fa_mi_li_er_ne@) til
pa_ra_me_ter_ind_kod_ning en for en og for_sø_ge at knyt_te 
for_bin_del_sen til_ba_ge til sprog_kon_struk_tio_n^er, hvor/hvis
det_te er mu_ligt.

I de til_fæl_de hvor en sammen_hæng han på_vi_ses, vil jeg se på
over_sæt_te_r^ens ko_de_ge_ne_re_ring^ med hen_blik på at af_dæk_ke
mu_li_ge in_struk_tions_kob_lin_g^er (@f.eks. in_struk_tions_se_kven_s^er@),
der kun_ne væ_re at_trak_ti_ve at ind_ko_de. Eksemp_let i ka_pi_tel
4.3.5 vi_ser at sam_spil_let mel_lem pa_ra_me_ter_ind_kod_nin_ger og
se_kvens_ind_kod_nin_ger kan væ_re me_get 'spe_get'; men og_så, at det
er vig_tigt at få af_kla_ret det_te.

Formålet med dette ka_pi_tel er med an_dre ord, at kon_sta_te_re 
se_kvens_ind_kod_nin_ger ( eller afvi_se dem@) på bag_grund af det
ind_sam_le_de ma_te_ria_le om in_struk_tions_an_ven_del_ser, og
vur_de_re om pa_ra_me_ter_ind_kod_nings_kan_di_da_ter evt. for_svin_der
i den for_bin_del_se. Der vil i ka_pit_let rej_se sig nog_le åb_ne
spørgs_mål, som hæn_ger sammen med en e_gent_lig se_kvens_ana_ly_se og
som nævnt vil bli_ve o_ver_ladt til vi_de_re stu_di_er. Der vil i
ka_pit_let bli_ve an_vendt navne på in_struk_tio_ner og forud_sat
kend_skab til dis_ses funk_tion. Yder_ligere for_kla_rin_ger kan fin_des
i re_fe_ren_cen (@Møl81@).


>a2 GENNEMGANG AF KANDIDATER.

I de følgende afsnit gennemgås kandidaterne en for en for om mu_ligt
at afdække se_kven_s^er og i givet fald kor_ri_ge_re her_for.

>a3 "RETRIEVE" KONSTANT.

Instruktionen RECHW <PARAM> -> REC1, REC2, ..., REC16, RECHW <x>, x c (17..255), kan stam_me
man_ge ste_der fra. Den vil først og frem_mest fo_re_kom_me i 
arit_metis_ke ud_tryk, hvor der ind_går kon_stan_ter. De_su_den bru_ges den
i for_bin_del_se med SET-in_struk_tio_ner (@"size"-felt@) og i 
for_bin_del_se med brug af ty_pen BOOLEAN (@RECHW <0>, RECHW@<1>@).

Det kan forventes, at RECHW <PARAM> of_te op_træ_der med for_skel_li_ge
ope_ra_to_rer, f.eks. ADD. Det er ikke mu_ligt at vur_de_re, hvor
hyp_pigt så_dan_ne se_kven_ser fo_re_kom_mer ud fra det op_sam_le_de
ma_te_ria_le; men det er mu_ligt at fast_slå nog_le øv_re be_græns_ninger.
Hvad angår ADD vil den mest op_ti_ma_le si_tua_tion væ_re, at en 
be_stemt af kan_di_da_ter_ne, RECI og ADD altid op_træ_der i se_kvens.
Der kan da statisk spa_res højst minimum( antal RECI, antal ADD@)@*@3
ok_tet_ter = 431@*@3 oktetter ved at ind_fø_re en ADDCI in_struk_tion. Der er
dog ved ind_fø_rel_sen af RECI alle_re_de spa_ret 431@*@2 ok_tet_ter, så
se_kven_sen på det_te ni_veau vil ik_ke væ_re til_lok_ken_de, hvad
an_går plads_be_spa_rel_se. Til_sva_ren_de argu_men_ter hol_der for
de øv_ri_ge ope_ra_to_rer.

Med hensyn til afviklings_has_tig_heden, vil der i bed_ste fald 
kun_ne vin_des ca. 5 us ved se_kvens_ind_kod_nin_gen i højst 1.8@% af
de ud_før_te in_struk_tio_ner. Med en gen_nem_snit_lig in_struk_tions_tid
på ca. 10@us bli_ver for_bed_rin_gen max_i_malt:

 1.8@*@5@*@100
 -------------- % = 0.9 %
    10 * 100

Dette er en grov øvre grænse, der i betragtning af sin be_sked_ne
stør_rel_se gør se_kven_sen u_in_ter_es_sant.

Hvis vi imid_ler_tid for_la_der in_struk_tions_ni_veau_et til for_del
for et ni_veau, hvor in_for_ma_tio_ner om den sprog_li_ge sam_men_hæng
sta_dig er til ste_de, så er der mu_lig_vis stør_re be_spa_rel_ser at
hen_te. Føl_gen_de ek_sem_pel kan be_ly_se det_te.

>ne 38
>nf
>ex Sekvenser ved "assignments".

Betragt følgende funktionelt ækvivalen_te "as_sign_ments"
VAR
a : integer;
 :
 :
BEGIN
 :
a := a + 1;
 :
a := 1 + a;
 :
END; (* simple assignment *)

Oversætteren kan produce_re føl_gen_de sym_bol_ske ko_de:
 :
 :
REVLW "a"
RECHW  1
ADD
STVLW "a"
 :
RECHW  1
REVLW "a"
ADD
STVLW "a"
 :
 :
>fi
Indføres ADD1, som før omtalt, vil dette kunne ud_nyt_tes i den
før_ste pro_duk_tion; men ik_ke i den an_den med_min_dre
o_ver_sæt_te_ren på et tid_li_ge_re tids_punkt er i stand til at
'fan_ge' så_dan_ne ud_tryk og ven_de dem me_re op_ti_malt for
ind_kod_ning. Det ses at additionen kan fore_ta_ges di_rek_te til
la_ger i ste_det for at være tvun_get til at e_va_lu_e_re på
stak_top_pen. Ind_fø_res ADD1L@<PARAM> , (@L be_ty_der rela_tivt til
LOCAL FRAME@) bli_ver den pro_du_ce_re_de ko_de til

 ADD1L "a"

Her spa_res der he_le 7 oktetter pr. fo_re_komst og ca. 20us i udførel_sestid.

Vide_re undersøgelser må til for at af_kla_re om en så_dan se_kvens bør
ind_fø_res som in_struk_tion, og om den vil fjer_ne be_grun_del_sen
for REC1 ind_kod_ningen.
Se (@Aga79@) for en mere gene_rel dis_ku_sion og an_ven_del_se af
den_ne type se_kven_ser.

Oven_stående er et godt eksempel på, at en sla_visk sekvens_ana_ly_se^,
f.@eks. be_ståen_de i opsamling af to_følger^ - tre_føl_ger^ o.s.v., vil
væ_re man_gel_fuld. Det er i man_ge sam_men_hæn_ge nød_ven_digt at vi_de
hvad man 'går' efter. Som en bekræftelse herpå kan jeg i for_læn_gel_se
af oven_stå_en_de ek_sem_pel næv_ne, at der i for_bin_del_se med 
op_tæl_ling i en FOR@-@sæt_ning ik_ke pro_du_ce_res
no_gen ADD; men op_tæl_lin_gen fo_re_går ved at ud_nyt_te in_struk_tio_nen
REASD 1 (@UADHW@) i ste_det. Ind_fø_rel_sen af ADD1L@<PARAM@> vil og_så
med for_del kun_ne an_ven_des her, men in_gen au_to_ma_tis_ke me_to_der
vil_le fan_ge no_get så_dant.

I stil med disku_sionen af ADDI er det og_så her mu_ligt at fin_de en
grov øvre be_græns_ning for, hvad der kan op_nås sta_tisk og dy_na_misk.
Begrænsningen findes ud fra summen af

- minimum( antal ADD, antal RECHW 1 ) og
>sp0
- minimum( antal REASD, antal LT, antal JMZGT )

Statisk vil indkodningen ikke være at_trak_tiv i for_hold til 
pladskrav i mic_ro_pro_gram_met. Dyna_misk^ vil grænser_ne for
fore_komst være ca. 1.85 + 0.16 % = 2.01@%, og der_med en øvre græn_se på

 20 * 2.0 * 100
 -------------- % = 4.0 %
   10 * 100

Da grænsen er grov kan en ind_kod_ning næp_pe be_ta_le sig; men
kun me_re de_tal_je_re_de se_kvens_under_sø_gel_ser kan af_gø_re
det_te. Da ho_ved_for_må_let med ind_kod_nin_ger_ne er plads_be_spa_relse,
er der ikke no_get for_gjort i at ind_kode REC1, ..., REC16, pro_ble_met
duk_ker først frem, hvis no_gen si_den vil ind_kode f.eks ADD1L.
Selv da vil REC1 stadig væ_re kan_di_dat, da antallet af RECHW 1 -
an_tal_let af ADD er til_stræk_ke_ligt stort. ( på grund af 
sam_men_hæn_gen mellem RECH1,..., REC16 indkodningen  er det fak_tisk
det samlede antal REC1+REC2+...+REC16 - antal ADD, der skal vur_de_res, så
det bli_ver kan_di_da_tu_ren blot bed_re af ).

>a3 "RETRIEVE" NONSENS.

Kandidaten er her RENHB 16. Denne in_struk_tion^ kan stam_me fra fle_re
sprog_li_ge sam_men_hæn_ge. Den bru_ges bl.a. i for_bin_del_se med
pro_ce_du_re_kald^ til at af_sæt_te plads på stak_ken til en "activa_tion
re_cord", der in_de_hol_der re_tur_hops_in_for_ma_tion, samt in_for_mation
til brug for en eventuel "excep_tion". Antal_let af pro_ce_du_re_kald kan
di_rek_te ses på an_tal_let af an_ven_del_ser af in_struk_tio_nen PCALS
(@PCALD i for_bin_del_se med pro_ce_durer som pa_ra_me_tre an_ven_des
ik_ke@). PCALS fore_kom_mer 2193 gan_ge i den sta_tiske ko_de. Da RENHB@16
kal_des 2200 gan_ge, hæn_ger kan_di_da_tu_ren alt_så helt sam_men med
pro_ce_du_re_kald.

RENHB og PCALS forekommer ikke i se_kvens, idet da_ta_struk_tu_ren
( "RUN TIME environment") for et pro_ce_du_re_kald er de_fi_ne_ret, så
der først af_sæt_tes plads til "ac_ti_va_tion re_cord", der_ef_ter
hen_tes de ak_tuel_le pa_ra_me_tre på stak_ken, og en_de_lig ud_fø_res
PCALS instruk_tio_nen. Ne_den_stå_en_de fi_gur vi_ser det_te.

>ne 17
        Stak før               Stak efter

     +-------------+         +-------------+
 LF->I             I         I             I
     I             I         I             I
     +-------------+         +-------------+
 LP--------------'      LF-> I"activation  I
                             I record"     I
                             +-------------+
                             I"actual para-I
                             I meters"     I
                             ---------------
                             I"local vari- I
                             I ables"      I
                             +-------------+
                       LP----------------'

>fg Stakudvikling ved procedurekald.

Nedenfor er den pro_ducerede kode vist
>ne 12

>fd 9 61
>fb
  :
  RENHB 16
  REVGW <PARAM>  (* evt. tilsvarende in_struk_tion *)
  REVGD <PARAM>             - " -
  :
  PCALS <DISTANCE><LEVEL><ADDRESS>
  :
>fe

>fg Produceret kode ved procedurekald.

Det er selvfølgelig nærliggende at o_ver_ve_je om en kob_ling^ mel_lem
to in_struk_tioner kan trans_for_me_res til en e_gent_lig se_kvens, der
så kan ind_ko_des. Dette er fak_tisk mu_ligt i det_te til_fæl_de ved
en sim_pel om_de_fi_ne_ring af da_ta_struk_tu_ren ved pro_ce_du_re_kald.
Den_ne ænd_ring går ud på, at hen_te de ak_tu_elle pa_ra_me_tre på
stak_top_pen før der af_sæt_tes plads til "ac_ti_va_tion re_cord", og
så be_nyt_te ne_ga_tiv afstand til "LOCAL FRAME" pointeren ved
re_fe_ren_cer til de ak_tuel_le pa_ra_me_tre i ko_den der ud_gør 
pro_ce_du_ren. Ne_den_stå_en_de fi_gur vi_ser det_te.

>ne 20
          Stak før             Stak efter

     +-------------+         +--------------+
 LF->I             I         I              I
     I             I         I              I
     +-------------+         +--------------+
 LP--------------'           I"actual para- I
                             I meters"      I
                             I              I
                             +--------------+
                        LF-> I"activation   I
                             I record"      I
                             +--------------+
                             I"local para-  I
                             I meters"      I
                             I              I
                             +--------------+
                        LP----------------'

>fg Ændret datarepræsentation ved procedurekald.

Den producerede kode vil hermed æn_dres på føl_gen_de må_de:

>fd 10 56
>ne 12
>fb
    REVGW <PARAM>   (* 1. actual pa_ra_me_ter *)
    REVGD <param>   (* 2.     - " -        *)
     :
    RENHB 16
    PCALS <DISTANCE><LEVEL><ADDRESS>
     :
>fe
>fi

>fg Kodegenerering ved ændret procedurekald.

Sekvensen

>ne 6
 RENHB 16
 PCALS <DISTANCE><LEVEL><ADDRESS>

kan herefter indkodes til

 PCALS*<LEVEL><ADDRESS>

Til gengæld skal in_struk_tionen PEXIT have en ek_stra pa_ra_me_ter,
sva_ren_de til <DISTANCE> fra PCALS, så der kan af_stak_kes til
og med de aktu_elle parame_ter ved pro_ce_du_re_afslut_ning (@funk_tions_afslut_ning@).

Med til hele historien hører, at der i en proce_du_re nu ind_le_des
med

>ne 3
 REAAD "LINETAB"
 STVLD "RLINETAB"

idet linieinformation til brug ved "exception" skal læg_ges et
vel_de_fi_ne_ret sted i for_hold til "LOCAL FRAME" ( her i slut_nin_gen
af "ac_ti_va_tion record" ). Når der ved indgangen til pro_ce_du_ren,
efter æn_drin_gen, al_tid er en vel_de_fi_ne_ret kon_stant af_stand til
"LOCAL FRAME", er det til_stræk_ke_ligt at hen_te a_dres_sen på "LINETAB"
på stakken, som det før_ste i pro_ce_du_ren. Der spares alt_så en
STVLD "RLINETAB" in_struk_tion. ( Det skal li_ge be_mær_kes, at en fejl
i designet her_med er løst ved sam_me lej_lig_hed, idet en "exception"
i forbindelse med REAAD "LINETAB" nu - i modsæt_ning til før - er
vel_de_fi_ne_ret@).

Det samlede resultat af dis_se æn_drin_ger bli_ver da:

>ne 10
>nf
>ta 12 45
>fd 10 43 61
>fb
!    
!     Ændring! Besparelse
!   
>fb
!RENHB 16
!PCALS<P1><P2><P3>
!     :!11065 oktetter
!     v
!PCALS*<P2><P3>
>fb
!Ingen STVLD "RLINETAB"! 1008 oktetter
!Reduktion!12073 oktetter
>fb
!<P2> tilføjes i PEXIT!  672 oktetter
>fb
!Samlet resultat!11401 oktetter
>fe
>fi

>fg Besparelse ved ændret procedurekald

Dette udgør en pladsbesparelse på 7.76 % af netto_ko_den, alt_så
langt me_re end RENHB 16 vil_le kun_ne gi_ve.

Dynamisk^ vil effekten i forbindelse med pro_ce_du_re_kald og ud_fø_relsen
af en pro_ce_dure væ_re en ge_vinst på ca. 17.2 us. Da den dy_na_mis_ke
fo_re_komst af PCALS er ca. 0.65@% af de ud_før_te in_struk_tio_ner vil
ef_fek_ten væ_re:

 17.2 * 0.7 * 100
 ---------------- % = 1.2 %
    10 * 100

De her an_førte ændringer vil ud over ind_fly_del_sen på RENHB 16 og
på STVLD "RLINETAB", have indfly_del_se på al_le in_struk_tio_ner,
der an_ven_der "LOCAL FRAME" som udgangs_punkt, i_det de ak_tu_elle
pa_ra_me_tre nu vil op_træ_de i in_struk_tio_ner_ne med ne_ga_ti_ve
vær_di_er. Prin_ci_pielt kan ind_kod_ningen, der be_rø_rer dis_se
in_struk_tio_ner ik_ke fast_læg_ges præ_cist, før der fore_lig_ger
re_vi_de_re_de op_sam_lin_ger fra den æn_dre_de over_sæt_ter. Jeg vil
dog til_la_de mig den fri_hed at sky_de på en nu_me_risk lil_le vær_di,
(@under 16@), hvor_un_der næs_ten al_le ak_tu_el_le pa_ra_me_tre hol_der
sig. Jeg vil retfær_dig_gø_re det_te med fle_re grun_de. An_dre
un_der_sø_gel_se (@Tan78@), (@Der74@), har be_skæf_ti_get sig med an_tal pa_ra_me_tre
i pro_ce_du_re_kald for pro_ce_du_re_orien_te_re_de høj_ni_veau sprog.
Dis_se un_der_sø_gel_ser pe_ger på me_get få pa_ra_me_tre i
pro_ce_du_re_kald. Nu kan selv få pa_ra_me_tre jo godt i prin_cip_pet
fyl_de me_get som VALUE pa_ra_me_tre; men det for_ven_tes, at der, hvis
mu_ligt, vil bli_ve be_nyt_tet VAR pa_ra_me_tre ved me_re
plads_kræ_ven_de ty_per. Para_me_tre vil da fyl_de et eller to ord, og
en an_ta_gel_se om et ne_ga_tivt offset nu_me_risk mind_re end 16
vir_ker der_for ri_me_lig. An_ta_gel_sen vil kun_ne ef_ter_kon_trol_leres,
ef_ter ind_fø_rel_sen af den æn_drede stak_re_præ_sen_ta_tion i
for_bin_del_se med pro_ce_du_re_kald.

Det koster et ek_stra trin i mi_kroprogrammet at in_tro_du_ce_re en
kon_stant, så for at det kan be_ta_le sig i for_bin_del_se med den_ne
æn_dring, kræ_ver det en kraf_tig æn_dring af de ek_si_ste_ren_de
pa_ra_me_ter_vær_di_er for instruk_tio_ner_ne, der ar_bej_der re_la_tivt
til LOCAL FRAME. I de ek_si_ste_ren_de op_sam_lin_ger skal der f.eks.
for in_struk_tio_ner_ne REVLB, REVLW, REVLD og REVLF i alt mindst flyt_tes
af stør_rel_ses_or_de_nen X = 1221 oktetter, hvor X er be_stemt ved

 3663 - X
 --------- * 3 = 3663
    2

Under antagelsen om en intervalforskydning på 16 ok_tet_ter, er der ikke
ba_sis for at ind_fø_re en kon_stant, -16, i mic_ro_pro_gram_met, men
det_te bør dog ef_ter_kon_trol_le_res.

For REALD in_struk_tionen gæl_der det, at den ind_ko_des i 'fa_mi_lie' med
REAGD. Ind_fø_res en kon_stant < 0 vil der må_ske nok vin_des på REALD;
men til gen_gæld ta_bes på REAGD. Det kan umid_del_bart fast_slås, at
en ind_kod_ning med en fæl_les ne_ga_tiv kon_stant ik_ke kan kom_me
på ta_le. Om_vendt vil det sta_dig væ_re op_lagt at ind_ko_de de to
in_struk_tio_ner a_le_ne på grund af REAGD. Med to forskel_li_ge
kon_stan_ter K1 <> K2 <> 0 koster det 4 trin i mi_kro_pro_gram_met, mod
2 trin ved K1 = K2 = 0. Det er u_sand_syn_ligt; men kan dog ik_ke
af_vi_ses, at det kan be_ta_le sig at an_ven_de to trin på det_te frem
for an_dre kan_di_dat_ind_kod_nin_ger.

>a3 "RETRIEVE" LOKAL VÆRDI.

Instruktionerne REVLB, REVLW, REVLD og REVLF ind_ko_des un_der et. De
kan pro_du_ce_res i for_bin_del_se med al_le an_ven_del_ser af lo_ka_le va_riab_le i
pro_ce_du_rer og funk_tio_ner, samt ved funk_tions_re_sul_ta_ter.
Undersøgel_sen her gi_ver ik_ke no_gen fyl_dest_gø_ren_de in_for_ma_tion,
der pe_ger på en se_kvens_ind_kod_nings_kan_di_dat. Det enes_te spor
der er værd at føl_ge her, er den kob_ling, der of_te vil væ_re
mel_lem re_pe_te_ren_de kon_struk_tio_ner og REVL* ( * står for B/W/D/F@).
Den_ne kob_ling gæl_der og_så i no_gen grad for STVL* in_struk_tio_ner_ne.
Re_pe_te_ren_de in_struk_tio_ner tes_ter of_te mod en græn_se_vær_di
(@el_ler til_sva_ren_de@), der er er_klæ_ret som lo_kal va_ria_bel. Det
be_ty_der, at REVL* in_struk_tio_ner sam_men med hop_in_struk_tio_ner
og mo_na_dis_ke boolske ope_ra_to_rer, kan dan_ne se_kven_ser af
in_ter_es_se. Den vi_de_re dis_ku_sion her_af ta_ges op i for_bin_del_se
med hop_in_struk_tio_ner og med in_struk_tio_nen "UADHW" (@=REASD@).

>a3 "RETRIEVE" GLOBAL OG LOKAL ADRESSE.

Instruktionerne REAGD OG REALD er diskut_te_ret i for_bin_del_se med
RENHB og deraf afledede kon_se_kven_ser.

>a3 "STORE" LOKAL VÆRDI.

Der gælder for STVLB, STVLW, STVLD og STVLF stort set det sam_me som
for de til_sva_ren_de "re_trieve" in_struk_tio_ner. Dog vil de i
for_bin_del_se med re_pe_te_ren_de in_struk_tio_ner ik_ke væ_re så
hyp_pigt fo_re_kom_men_de som "re_trie_ve" in_struk_tio_ner_ne. Den vi_de_re
dis_ku_sion her_af hen_læg_ges li_ge_le_des til dis_ku_sion af
hop- og boolske in_struk_tio_ner samt af UADHW (@REASD@).

>a3 "RETRIEVE" GLOBAL VÆRDI.

Instruktionerne REVGB, REVGW, REVGD og REVGF indkodes un_der et. De
kan produ_ce_res i for_bin_del_se med alle an_ven_del_ser af glo_ba_le vari_ab_le. Der
gæl_der i øv_rigt de sam_me be_mærk_nin_ger som for "retrieve" lokal
vær_di in_struk_tio_ner_ne.

>a3 PROCEDUREKALD.

Instruktionen PCALS er behandlet under RENHB og giver ikke anledning
til flere sekvensindkodninger.

>a3 "STORE" VÆRDI RELATIVT TIL STAKTOPADRESSE.

Instruktionerne STVSB, STVSW og STVSF ind_ko_des sam_men, og de_res
funk_tion er at af_le_ve_re en vær_di (@hen_tet fra stak_ken@) i 
a_dres_sen (@hen_tet fra stak_ken@) med et off_set an_gi_vet i
in_struktions_pa_ra_me_te_ren. Instruk_tio_nen an_ven_des ty_pisk i
for_bin_del_se med re_cord_struk_tu_rer.
Det er værd at be_mær_ke, at para_me_ter_vær_di_er_ne 28, 29, 30 og 31
stam_mer fra defi_ni_tio_nen af (kon_ven_tio_nen for) en "message header"
(@Møl81@), idet der her er fire ok_tetter, der kan læses og skrives fra
program_met. Hvis kon_ven_tio_nen for en "message header" æn_dres, fal_der
de afle_de_de kan_di_da_ter bort.
STVSB/W/F instruk_tio_nerne an_ven_des ty_pisk
som en slags in_di_rek_te "sto_re value". Hvis den adres_se, der benyt_tes
er fær_dig_be_reg_net og f.eks. lig_ger som en lokal va_ri_a_bel, vil
ind_fø_rel_sen af in_di_rek_te "store value" væ_re at_trak_tiv; men når
a_dres_sen først skal for_be_re_des f.eks. ved græn_se_test (@"array indexing"@), kan
in_di_rek_te a_dres_se_ring ik_ke an_ven_des. Som ved RENHB dis_ku_sionen,
er der her et ek_sem_pel på, at en se_kvens_ana_ly_se, der kun ser på
in_struk_tions_ræk_ke_føl_ger ik_ke er til_stræk_ke_lig. Be_reg_nin_gen
af a_dres_sen og STVS* instruk_tio_nen står nem_lig med et va_ri_a_belt
an_tal in_struk_tio_ner i_mel_lem sig. En se_kvens_ana_ly_se kræ_ver 
alt_så, at man ved, hvad man sø_ger ef_ter, f.eks ud fra sprog_li_ge
kon_struk_tio_ner. For_må_let med dis_kus_sio_nen i det_te ka_pi_tel er
da og_så at for_sø_ge at fin_de til_ba_ge fra in_struk_tio_ner til 
kon_struk_tio_ner(@kode_pro_duk_tio_ner@), for med dem som ud_gangs_punkt
at af_dæk_ke se_kven_ser/kob_lin_ger mel_lem in_struk_tio_ner.

Følgende eksempel kan be_ly_se, hvad ind_fø_rel_sen af en in_di_rek_te^
"store value" vil be_ty_de.
>np
>ex Indirekte "store" af værdi.

Betragt følgende programudsnit.

>ne 9
>nf
TYPE
descriptor = RECORD
             sh : shadow;
             state : integer;
             name1 : alfa;
             name2 : alfa;
             size : integer;
             END;
procesrec = RECORD ..... END;
>ne 24
VAR
childtable : ARRAY(0..max) OF descriptor;
 :
 :
PROCEDURE initproces(childindex : integer;
          name : alfa;p : procesrec;
          psize,prio : integer);
VAR
i : integer;
BEGIN
  WITH childtable(childindex) DO
    BEGIN
     :
     :
      state := created;
      name1 := name;
      size := psize;
       :
    END
    :
END;  (* initproces *)

Den symbolske ko_de vil se så_le_des ud:
>ne 26
; procedure entry
  
    :
; WITH childtable(childindex) DO
REAGD "CHILDTABLE"
REALW "CHILDINDEX"
REAAD "ADDRESS OF DOPE"
INDEX
STVLD "ELEMENT ADDRESS AS LOCAL"
    :
; state := created;
REVLD "ELEMENT ADDRESS AS LOCAL"
REXHW 2       (* 2 is the constant: created *)
STVSW 12      (* 12 is offset of state in RECORD *)
    :
; name1 := name;
REVLD "ELEMENT ADDRESS AS LOCAL"
REASD 14      (* name1 has offset 14 in RECORD *)
REALD "NAME"
RECHW 12      (* size of alfa type *)
MOVEG
    :
; size := psize;
REALD "ELEMENT ADDRESS AS LOCAL "
REVLW "PSIZE"
STVSW 38       (* 38 is offset of size in RECORD *)

>fi
Ved ind_fø_rel_sen af en in_di_rek_te^ "store" in_struk_tion:
STVILW<PARAM1><PARAM2> (@"store value indirect local word"@), vil sæt_ningen

 state := created;

udvik_le sig til

 RECHW 2
 STVILW "ELEMENT ADDRESS AS LOCAL" 12

Der er altså spa_ret en en_kelt ok_tet og sam_ti_dig er der stil_let
krav til o_ver_sæt_te_r^en, der skal kun_ne hus_ke "element address" i
for_bin_del_se med vær_di_til_de_lin_ger. Pladsbe_spa_rel_sen i sig selv er
ik_ke grund_lag nok for den_ne ind_fø_rel_se, når det ta_ges i
be_tragt_ning, at det kos_ter en hel del trin i mic_ro_pro_gram_met, at
ind_fø_re de nye indi_rek_te in_struk_tio_ner (@det drejer sig bå_de om
STVIG* og STVIL* in_struk_tio_ner for fuld_stæn_dig_he_dens skyld@).
De_su_den kan STVS* instruk_tio_ner_ne ik_ke und_væ_res ved
a_dres_se_be_reg_ning ef_ter in_di_ce_ring.

For afviklingshastigheden vil ind_kod_nin_gen be_ty_de en be_spa_rel_se
på ca. 10 us. Da den sam_le_de dy_na_mis_k^e fo_re_komst af STVS*
in_struk_tionerne er 2.7->3.7@%, vil ge_vin_sten højst væ_re

>ne 3
 10 * 3.7 * 100
 -------------- % = 3.7 %
    10 * 100

og sik_kert no_get mind_re.

Den dynamiske forekomst kan, med lidt besvær gan_ske vist, be_stem_mes
i alle til_fæl_de, hvor over_sæt_te_ren kan detekte_re en se_kvens, som her,
og i for_bin_del_se med se_kven_sen pro_du_ce_re in_struk_tio_nen NOOP,
der er en tom instruk_tion. Denne in_struk_tion pro_du_ce_res ellers
nor_malt ikke og kan der_for ved dy_na_misk op_sam_ling si_ge præ_cist,
hvor of_te se_kven_sen ud_fø_res.

I betragtning af den knebne mi_kro_pro_gram_plads er der ikke grund til
at gå vi_de_re med dis_kus_sio_nen; men set me_re ge_ne_relt for
lig_nen_de in_struk_tions_sæt kan en vi_de_re un_der_sø_gel_se her_af
have in_ter_es_se.

Jeg vil i den for_bin_del_se (@no_get i ud_kanten af em_net gan_ske vist@)
be_mær_ke, at det gen_nem_gåe_de ek_sem_pel gan_ske godt il_lu_stre_rer
en stor svag_hed ved en ren stak_ma_ski_ne^, set i rela_tion til 
plads_be_spa_relse og af_vik_lings_has_tig_hed. Til trods for, at der i den
sprog_li_ge kon_struk_tion WITH ekspli_cit gø_res op_mærk_som på, at
et ele_ment vil bli_ve re_fe_re_ret fle_re gan_ge, kan det_te ik_ke 
ud_nyt_tes fuldt ud af over_sæt_teren, der bundet af stak_dis_ci_pli_n^en
må ud_fø_re REVLD "ELEMENT ADDRESS AS LOCAL" of_te. Hvis man bry_der
med stak_dis_ci_pli_nen og ind_fø_rer ar_bejds_re_gis_tre^ med der_til
hø_ren_de "load/store" instruk_tio_ner, vil man åb_ne op for
ko_de_op_tima_li_se_rin_g^er sty_ret af o_ver_sæt_te_r^en på et ni_veau,
hvor in_for_ma_tio_ner om den sprog_li_ge sam_men_hæng end_nu er til
ste_de ( hvilket ikke er til_fæl_det på RC3502-instruk_tions_ni_veau i
al_min_de_lig_hed@). Et så_dant skridt vil be_vir_ke, at de om_tal_te
in_di_rek_te a_dres_se_rin_ger ik_ke er at_trak_ti_ve al_li_ge_vel, så
med i en vi_de_re un_der_sø_gel_se hø_rer af_kla_ring af e_gen_ska_ber
ved en blan_det stak/re_gis_ter_ma_ski_ne.

>a3 BETINGEDE HOPINSTRUKTIONER.

Af de be_tin_ge_de hop_instruk_tio_ner ind_går JMZEQ, JMZLT og JMZGT i
re_pe_tions_de_len af løk_ke_struk_tu_rer. (@JMZGT i FOR .... TO 
og JMZLT i FOR ... DOWNTO samt JMZEQ i REPEAT ... UNTIL@..@). Hele bun_den af en FOR-konstruktion kun_ne væ_re
gen_stand for en se_kvens_ind_kod_ning. Un_der_sø_gel_sen kan gi_ve
en grov øv_re græn_se for de sta_tis_ke og dy_na_mis_ke ge_vin_ster,
der kan op_nås her_ved.

En grov øvre grænse for den statiske be_spa_rel_se kan op_nås ved at
se på mi_nimum af fo_re_koms_ter_ne for (UADHW, JMZGT og (LT og GT)@).
Dette mi_ni_mum bli_ver 0.63@% svaren_de til 307 fo_rekoms_ter.
Be_spa_rel_sen ved ind_kod_ning vil væ_re 5 ok_tet_ter. Der kan alt_så
mak_si_malt spa_res 1535 ok_tet_ter. Ind_kod_nin_gen vil fyl_de så man_ge
trin (@> 10@), at be_spa_rel_sen ik_ke kan kon_kur_re_re. Dyna_misk^ vil
mi_ni_mum af fo_re_koms_ter_ne for (REASD, JMZGT og (LT og GT)@) =
0.16 % væ_re en øv_re græn_se. Der vin_des skøns_mæs_sigt 20@us
pr. ud_fø_rel_se så en øv_re græn_se vil væ_re

>ne 3
 20 * 0.16 * 100
 --------------- % = 0.3 %
    10 * 100

alt_så ikke interessant at ind_ko_de og der_med ik_ke for_styr_ren_de
for kan_di_dat_lis_ten.

JMZEQ optræder for_u_den i REPEAT ... UNTIL .. også i for_bin_del_se
med IF ... THEN ... ELSE konstruk_tio_ner, der ofte optræ_der i krop_pen
af løk_ke_struk_tu_rer. Det er muligt, at der i for_bin_del_se med
f.@eks. "retrieve" instruk_tio_ner kan være basis for se_kven_ser.
Nærme_re se_kvens_un_der_sø_gel_ser må til for at af_kla_re det_te.

>a3 HOP RELATIVT INSTRUKTIONEN.

Instruktionen produce_res i for_bin_del_se med man_ge for_skel_li_ge 
sprog_kom_po_nen_ter. Den ind_går f.eks i IF .. THEN .. ELSE - 
konstruk_tio_ner, i WHILE løk_ker og i CASE - kon_struk_tio_ner. Både
IF .. THEN .. ELSE og CASE konstruktio_ner kan for_ven_tes of_te at
fo_re_kom_me i løk_ke_struk_tu_rer. JMPRW vil her of_te føl_ge ef_ter
en STV** in_struk_tion. Så_dan_ne se_kven_ser er de enes_te mu_li_ge
kan_di_da_ter i for_bin_del_se med JMPRW. Ved at un_der_sø_ge 
mi_ni_mum for fore_koms_ten af in_struk_tio_ner_ne (@JMPRW, STV**@),
hvor der blandt STV** instruktio_ner_ne væl_ges den hyp_pigst 
fore_kom_men_de fås:

Den statiske besparelse bli_ver maksimalt 1.96% sva_rende til 955 fo_re_koms_ter
af STVLW. Der kan spa_res en ok_tet og ind_kod_nin_gen kos_ter 2 trin.
Alt_så no_get i un_der_kan_ten af kan_di_dat_lis_ten i bed_ste fald.

Dynamisk^ kan der spa_res ca. 4 us . Med STVGW fås:

 4 * 3.3 * 100
 ------------- % = 1.3 %
    10 * 100

hvil_ket ik_ke er attraktivt, så JMPRW som kan_di_dat til 
pa_ra_me_ter_ind_kod_ning for_styr_res ik_ke.

>a3 "RETRIEVE" VÆRDI RELATIVT TIL STAKTOPADRESSE.

Instruktionerne REVSW, REVSD og REVSF indkodes under et. De kan stam_me
fra man_ge for_skel_li_ge sprog_li_ge sam_men_hæn_ge. De kræ_ver en
a_dres_se på top_pen af stak_ken, så der vil væ_re kob_lin_ger til
in_struk_tio_ner som INDEX, REAGD, REALD, REVLD og REVGD. De vil ty_pisk
bli_ve brugt i for_bin_del_se med in_di_ce_ring og strukture_re_de
va_riab_le (@RECORD m.m. @). En grov øv_re græn_se for mu_li_ge
se_kvensers ind_kod_nings_ef_fekt kan let ud_reg_nes. Statisk er der
ingen grund til ind_kod_ning og den dy_na_mis_ke ef_fekt vil væ_re
1.1 %, hvil_ket hel_ler ik_ke gi_ver anled_ning til ind_kod_ning, så
end_nu en gang kan kan_di_da_ten til pa_ra_me_ter_ind_kod_ning væ_re i
fred.

>a3 "STORE" VÆRDI RELATIVT TIL GLOBAL.

Instruktionerne STVGB, STVGW, STVGD og STVGF indkodes sam_men. Der
gæl_der stort set de sam_me be_mærk_nin_ger om dis_se in_struk_tio_ner,
som der er frem_sat for STVL* instruk_tio_ner_ne. Under_sø_gel_serne her
af_dæk_ker in_gen se_kven_ser.

>a2 REVIDERET KANDIDATLISTE EFTER SEKVENSINDKODNING.

Sekvensindkodning^er påvirker kandidatliste^n, som her_ef_ter ser
så_le_des ud:
>ta 12 38 48
>fd 10 36 46 59
>nf
>ne 32

>fb
!Kandidat!Trin!Besparelse
!!!i oktetter
>fb
!RECHW, 0/ .. /16! 2! 11898
>fb
!REAG/LD X! 2!  2599
>fb
!REVLB/W/D/F X! 3!  3663
>fb
!REVGB/W/D/F X! 2!  2139
>fb
!JMZEQ/../GE X! 2!  1311
>fb
!REVSW/D/F0/2/4/6/12! 4!  2274
>fb
!STVSB/W/F0/2/4/6/28/..31! 4!  3226
>fb
!RECHW Y, Y c (17..255)! 2!  1288
>fb
>fd 10 59
!Trinforbrug i mi_kroprogram = 21
>fd 10 36 46 59
>fb
!JMPRW X! 2!  1208
>fb
!STVGB/W/D/F X! 2!   836
>fb
!STVLB/W/D/F X! 2!  1578
>fb
!PCALS 0, <P3>! 2!  2181
>fe

>fi
>fg Revideret kandidatliste^.

>a2 REVIDERET FORVENTET EFFEKT EFTER SEKVENSINDKODNING.

Den forventede dynamiske effekt ændres i for_bin_del_se med
se_kvens_ind_kod_nin_g^en så_le_des:
RENHB <16> indkodes ikke. I stedet indkodes RECHW <Y>, Y@c@(17..255).
PCALS og PEXIT får nye tider (@ der flyttes tid fra PCALS til PEXIT@).

Den akkumulerede tid fra TS-alarm_system_eksemp_let ændres her_ef_ter
så_le_des:

- akkumuleret tid = 8.036 + 0.009 - 0.007 + (NEWPEXIT - PEXIT) - 
(PCALS - NEWPCALS)
>sp0
= 8.038 + z - z us = 8.033 us

                         8.038*100
Middelinstruktionstid:  ----------- us = 8.98 us
                           89.49

Den forventede effektforbedring for_bli_ver heref_ter uæn_dret

                   (9.44-8.98)*100
Effektforbedring^= -----------------% = 4.9 %
                        9.44
>a1 EFTERKONTROL I PRAKSIS.

Ud over efterkontrol^ af STVL* og REVL* in_struk_tionernes para_meter_værdier
er ef_ter_kon_trol_len kun re_le_vant for den dy_na_mis_k^e 
pro_gram_af_vik_ling.

I kapitel 5.3 har jeg be_skrevet den ge_ne_rel_le frem_gangs_må_de
for at ve_ri_fi_ce_re, at de kan_di_da_ter, der er med_ta_get på
grund_lag af den dy_na_mis_ke in_struk_tions_op_sam_ling, er anven_de_lige,
eller om der er grund til at re_vur_de_re. Når det_te er af_kla_ret,
re_ste_rer der en efter_kon_trol af ind_kod_nin_gens ef_fekt på
pro_gram_af_vik_lings_has_tig_he_den.

>a2 KANDIDAT EFTERKONTROL I PRAKSIS.

Metoden be_skrevet i kapitel 5.3 er for så vidt udmær_ket; men hvis den
kræver for man_ge 'skud' kan den bli_ve en be_kos_te_lig af_fæ_re.
(@ca. 1.500 kr pr. skud i materiale_udgifter@). Det der skal af_dæk_kes
er ikke funk_tio_nelt nye in_struk_tio_n^er, og da det kun er et
spørgs_mål om de nye in_struk_tio_ner bli_ver ud_ført til_stræk_ke_ligt
of_te i for_hold til for_vent_ninger_ne, kan man an_ven_de en
mellem_løs_ning til at afkla_re det_te. Man kan udnyt_te, at
mi_kro_pro_gram^_met ud_fø_rer in_struk_tio_ner ta_bel_sty_ret^. Ta_bel_len
er nem_lig lo_ka_li_se_ret i spe_ciel_le "map-prom_mer". Dis_se skal
nu for_sy_nes med ind_gan_ge sva_ren_de til kan_di_da_ter_ne; men det
er den op_rin_de_li_ge in_struk_tion i fuldt om_fang, de nye ind_gan_ge
pe_ger hen på. Over_sæt_te_rens "assemb_ler" (@PASS@6@) skal de_su_den
re_di_fi_ne_re ope_ra_tions_ko_der_ne i over_ens_stem_mel_se her_med;
men ikke æn_dre ved in_struk_tions_læng_den og hel_ler ik_ke ved
pa_ra_me_tre_ne. Denne mel_lem_løs_ning kan gen_nem_fø_res for en
be_ske_den ud_gift (@ca. 100 kr i materiale_ud_gif_ter@), og end_vide_re
er det må_ske end_nu væ_sent_li_ge_re, at fle_re kan_di_dat_mu_lig_heder
kan prø_ves sam_ti_digt (@for så vidt, at kan_di_da_ter_ne er
dis_junk_te@), da der er ledige instruk_tions_ope_ra_tions_vær_di_er.
Anta_gel_sen om pro_por_tio_na_li_tet i pa_ra_me_ter_an_ven_del_sen fra
det sta_tis_ke til det dy_na_mis_ke til_fæl_de er her_med ik_ke læn_gere
en væ_sent_lig u_sik_ker_heds_fak_tor.

Tabellen nedenfor viser, hvorledes disse målin_ger faldt ud sam_men_holdt
med de es_ti_me_re_de vær_di_er.

>fd 9 36 48 60
>ta 11 37 49
>ne 22
>nf
>fb
!Kandidater!Estimeret!Observeret
!!forekomst!forekomst
>fb
!JMZEQ/../GE X!  89.35%!  87.80%
!REVSW/D/F0/2/4/6/12!  83.19%! 100.00%
!STVSB/W/F0/2/4/6/28/..31!  83.58%! 100.00%
!RECHW X!  16.59%!  11.34%
!JMPRW X!  82.83%!  13.58%
!STVGB/W/D/F X!  60.01%!  43.73%
!STVLB/W/D/F X!  80.84%!  96.32%
!PCALS 0/1 P3!  98.55%! 100.00%
>fe
>fi

>fg Estimeret og observeret dynamisk^ fordeling.

Disse resultater benyttes i neden_stående tabel over dynamisk
fore_komst * tidsgevinst / trinforbrug.

>fd 9 36 61
>ta 11 38
>nf
>ne 20
>fb
!Kandidater!Fordeling * tid / trin
>fb
!JMZEQ/../GE X!(5.8->7.0)*0.3/2 =>
!!0.0087 -> 0.0105
>fb
!REVSW/D/F0/2/4/6/12!(1.8->2.5)*1.5/4 =>
!!0.0068 -> 0.0094
>fb
!STVSB/W/F0/2/4/6/28/..31!(2.7->3.7)*0.8/4 =>
!!0.0054 -> 0.0074
>fb
!STVLB/W/D/F X!(1.4->2.8)*0.3/2 =>
!!0.0021 -> 0.0042
>fb
!RECHW Y, Y c (17..255)!(1.5->1.8)*0.3/2 =>
!!0.0023 -> 0.0027
>fb
!STVGB/W/D/F X!(1.3->1.7)*0.3/2 =>
!!0.0019 -> 0.0026
>fb
!JMPRW X!(0.3- 0.3)*0.3/2 =>
!!0.0005 -> 0.0005
>fb
!PCALS 0/1 P3!(0.4->0.8)*0.3/2 =>
!!0.0006 -> 0.0012
>fe
>fi

>fg Kontrol af dynamisk betingede kandidater.
>ne 10
Kandidaternes dynamisk^e forekomst sammenholdt med de instruk_tioner, de
er ind_kod_nin_ger af, vi_ser, at propor_tionali_tets_an_ta_gel_se^n
ikke hol_der for alle de be_rør_te kan_di_da_ter, der med_ta_ges på
grund af hastigheds_gevinst^. Da det kun er de fire første kan_di_dat_fami_lier,
der er plads til, er der kun tvivl om, hvorvidt RECHW Y, Y c (17..255)
eller STVLB/W/D/F X skal medtages. Da inter_vallet for RECHW Y er inde_holdt
i inter_vallet for STVLB/W/D/F X, kan der med god grund argumen_teres
for beg_ge kan_di_da_ter. Jeg væl_ger at med_tage STVLB/W/D/F X, for_di
der i visse situa_tio_ner er størst effekt på af_vik_lings_has_tig_he_d^en,
og der spares flest oktet_ter.

JMPRW var estimeret alt for højt. Andre para_me_ter_vær_di_om_rå_der må
til gen_gæld ud_fø_res oftere (@det bli_ver i fa_mi_lien, jvf. kapitel 5.3@).
Selv om de re_ste_ren_de 86.42% af instruk_tio_nen JMPRW kun_ne pla_ceres
på en enkelt kandi_dat, vil_le den_ne højst kun_ne kon_kur_re_re med
STVLB/W/D/F X og RECHW Y om den sid_ste plads til ind_kod_ning, så jeg
vil se bort fra det_te uden at må_le igen med an_dre para_meter_værdi_er
for JMPRW.

Den samlede pladsbesparelse ved ind_kod_ning bli_ver da 28688 oktetter,
svarende til 19.5% af nettokoden og 15.4% af brut_to_ko_den.
Dertil kommer en bespa_relse på 11401 oktet_ter ved æn_dret proce_du_re-
og funktions_kald med der_af føl_gen_de indkodning, svarende til 7.8%
af netto_ko_den hhv. 6.1% af brut_to_koden.
Den samlede be_spa_rel_se bli_ver da på 27.3% af netto_ko_den hhv. 
21.5% af brutto_koden.

>a2 EFTERKONTROL AF EFFEKT.

I kapitel 9.3 er den for_ventede for_bed_ring af program_mers
af_vik_lings_has_tig_hed^ be_reg_net ved at sam_men_hol_de den
gen_nem_snit_li_ge in_struk_tions_tid med den forvente_de gennem_snitlige
in_struk_tions_tid. I ka_pi_tel 10.3 er der korri_ge_ret for se_kven_sers
ind_kod_ning. Ef_ter_kon_trol^_len be_står sim_pelt_hen i at ind_sam_le
den dynamiske instruk_tions_an_ven_del_se ef_ter at ind_kod_nin_gen er
fo_re_ta_get, og der_næst be_reg_ne den gen_nem_snit_li_ge
in_struk_tions_tid for det nye, udvi_de_de in_struk_tions_sæt 
sammenholdt med den gennemsnitlige instruk_tions_tid for samme kør_sel,
hvor ind_kod_nin_ger_ne til_ba_ge_fø_res til de_res læn_ge_re form.
Herefter er der kun til_ba_ge at
kon_sta_te_re, om for_vent_nin_ger_ne holdt stik.

Jeg vil i det følgende skema benytte mig af nye navne for de ind_kode_de
kandi_dater. Et efter_stil_let S ("Short") betyder, at paramete_ren ef_ter
instruk_tion^en fyl_der en ok_tet. Navne_ne er i øvrigt selv_for_kla_rende
ud fra de op_rin_deli_ge nav_ne (@Møl81@).

>ne 40
>nf
>fd 9 23 32 37 48 61
>ta 10 24 33 38 49
>fb
!Instruktioner!Målt fo-!Tid !Tidsbidrag!Tilbagereg-
!!rekomst!!!net bidrag
>fb
!RECHW!  0.94%! 6.0! 0.056us! 0.900us
!REC0..16! 12.43%! 4.3! 0.535us! 
!RECHWS!  1.63%! 5.7! 0.093us
!REAGD!  2.54%! 7.9! 0.201us! 0.797us
!REAGDS!  7.55%! 7.6! 0.574us! 
!REVGW!  2.35%! 7.7! 0.181us! 0.413us
!REVGWS!  3.01%! 7.4! 0.223us!
!JMZEQ!  0.84%! 6.2! 0.052us! 0.392us
!JMZEQS!  5.49%! 5.9! 0.324us! 
!RECHD!  4.82%! 9.9! 0.477us! 0.477us
!REVLW!  0.09%! 7.7! 0.007us! 0.330us
!REVLWS!  4.19%! 7.4! 0.310us! 
!REVGD!  0.09%!11.2! 0.010us! 0.578us
!REVGDS!  5.07%!10.9! 0.553us!
!INDEX!  3.17%!20.8! 0.659us! 0.659us
!STVGW!  1.31%! 7.6! 0.100us! 0.216us
!STVGWS!  1.53%! 7.3! 0.112us!
!GT!  1.17%! 7.7! 0.090us! 0.090us
!STVSB!  0.02%!11.0! 0.002us! 0.319us
!SVSB0/2..31!  2.88%!10.2! 0.294us! 
!JMPRW!  2.00%! 4.2! 0.084us! 0.084us
!REVPW!  0.63%! 5.4! 0.034us! 0.034us
!REVSW!  0.01%!11.0! 0.001us! 0.151us
!RVSW0/2..12!  1.36%! 9.5! 0.129us!
!LT!  0.54%! 7.7! 0.042us! 0.042us
!REVGB!  0.32%! 7.7! 0.025us! 0.075us
!REVGBS!  0.65%! 7.4! 0.048us!
!ADD!  1.82%! 7.3! 0.133us! 0.133us
!JMZGT!  0.11%! 6.2! 0.007us! 0.010us
!JMZGTS!  0.05%! 5.9! 0.003us! 
!REASD!  0.00%!11.2! 0.000us! 0.017us
!REASDS!  0.15%!11.0! 0.017us!
!STVLD!  0.01%!10.6! 0.001us! 0.074us
!STVLDS!  0.69%!10.3! 0.071us! 
>fe
Skema fortsættes
>ne 50
>fb
!Instruktioner!Målt fo-!Tid !Tidsbidrag!Tilbagereg-
!!rekomst!!!net bidrag
>fb
!REVSM!  1.50%!16.2! 0.243us! 0.243us
!REVSB!  1.39%!11.0! 0.153us! 0.153us
!TOPEN!  1.11%!10.5! 0.117us! 0.117us
!CWTAC!  1.28%!11.8! 0.151us! 0.151us
!CWAIT!  1.28%!50.0! 0.640us! 0.640us
!SUB!  0.90%! 7.3! 0.066us! 0.066us
!EQ!  1.31%! 7.5! 0.098us! 0.098us
!DIV!  0.58%!32.7! 0.190us! 0.190us
!REALD!  0.00%! 7.9! 0.000us! 0.113us
!REALDS!  1.43%! 7.6! 0.109us!
!INTRS!  0.87%!11.5! 0.100us! 0.100us
!STVLW!  0.04%! 7.6! 0.003us! 0.061us
!STVLWS!  0.77%! 7.3! 0.056us!
!RENHB!  1.15%! 4.9! 0.056us! 0.056us
!REVLD!  0.00%!11.2! 0.000us! 0.133us
!REVLDS!  0.57%!10.9! 0.130us!
!PEXIT!  0.57%! 9.1! 0.052us! 0.052us
!PCALS!  0.57%!23.4! 0.133us! 0.133us
>fb
!I alt ! 85.40%!! 7.745us! 8.097us
>fd 9 61
>fb
!                        7.745*100
!Middelinstruktionstid: ----------- us = 9.07 us.
!                          85.40
>fb
!Tilbageregnet           8.097*100
!middelinstruktionstid: ----------- us = 9.48 us.
!                          85.40
>fb
!                             (9.48-9.07)*100
!Faktisk effektforbedring^ ---------------- % = 4.4%
!                                  9.48
>fe

>fi
>fg Efterkontrol^ af effekt^.

>a1 KONKLUSIONER OG PERSPEKTIVER.

Det udførte arbejde har givet følgende hoved_re_sul_ta_ter.

- Program^mer er forskellige med hensyn til deres statiske instruk_tions_an_ven_del_se^.

- Der er ingen klasseopdeling^ af programmer med hensyn til
instruk_tions_an_ven_del_se^r.

- Grundlaget for indkodning^ er den totale mæng_de program_mer.

- Huffmanindkodning i radix 256 er ikke relevant i RC3502 på
grund af den be_sked_ne mi_kro_pro_gram_plads^.

- Pladsbesparelse^n ved indkodning blev på 40089 oktetter, sva_ren_de
til en be_spa_rel_se på net_to_kode^n på 27.3 hhv. 21.5 % på brutto_kode^n.

- Programafviklingshastighed^en blev øget så be_ske_dent som 4.4@%

Problematikken omkring indkodning har ikke været helt så en_kel som
frem_stil_let i teo_ri_en (@Ste79@). Praktis_ke for_hold i form af
mi_kro_maskine- og mi_kro_pro_gram_struk_tur spil_ler af_gø_ren_de ind.
Ved maskin_design^ er det nød_ven_digt, at tage hen_syn til
ind_kod_nings_prin_cip^_per for at fast_læg_ge mic_ro_pro_gram_mets
plads_for_brug. Det er en for_del at få para_me_ter_hent_nin_g^en 
pas_sen_de i_so_le_ret, f.@eks. i star_ten af en in_struk_tion^. Det
vil for_enk_le ind_kod_nings_me_to_den og ik_ke med_fø_re
'føl_ge_in_struk_tio_ner', der er med til at kom_pli_ce_re ud_væl_gel_sen.
I prin_cip_pet er det øn_ske_ligt, at hver in_struk_tion har sine
se_pe_ra_te mi_kro_pro_gram_trin. Dette vil_le re_sul_te_re i krav om
man_ge trin; men øko_no_mis_ke for_hold vil p.@t. dik_te_re, at der
ind_fø_res en art pro_ce_du_re_be_greb i mi_kro_pro_gram_met.

I RC3502^ blev stør_rel_sen af mi_kro_pro_gram^_met fast_lagt før
in_struk_tions_sæt^_tet var ende_ligt desig_net. Dette valg af
mic_ro_pro_gram_stør_rel_se (@2048 60-bits-ord@), re_præ_sen_te_rer en
be_græns_ning, der blandt andet har to al_vor_lige kon_se_kven_ser
i rela_tion til ind_kod_ning.

- Instruktionerne er meget integrerede i hin_an_den (@fælles kode@). Det
medfø_rer tab af effek_ti_vi_tet, idet der bru_ges tid på at hop_pe
frem og til_ba_ge ved brug af fæl_les ko_de. Dette er end_vi_de_re
årsa_gen til, at kan_di_da_ter til ind_kod_ning blev kan_di_dat_fa_milier,
og at det kan kos_te vidt for_skel_ligt an_tal trin at ind_ko_de.

- Der efterlades for lidt plads til at ind_fø_re ind_ko_de_de 
in_struk_tio_ner. Det er ikke mu_ligt at få det ful_de ud_byt_te af
ind_kod_nin_gen på grund af plads_be_græns_nin_gen i mi_kro_pro_gram_met.

De foretagne analyser vil kunne an_ven_des i for_bin_del_se med
be_stem_mel_se af mi_kro_pro_gram_stør_rel_se ved til_sva_ren_de
ma_skin_de_sign. 

Den trange plads gør, at in_struk_tionssættets de_sign bør ta_ges op til
re_vi_sion. Enkel_te in_struk_tio_ner er må_ske 'over_flø_di_ge' i den
for_stand, at de kan sub_sti_tu_e_res af en se_kvens af in_struk_tio_ner.
Så_dan_ne se_kvens_ind_kod_nin_ger er for RC3502 ma_ski_nens ved_kommen_de
fore_ta_get pr. er_fa_ring/for_nem_mel_se og ik_ke på em_pi_ris_ke
må_lin_ger. De fore_tag_ne ana_ly_ser af instruk_tions_an_ven_del_sen
sta_tisk og dy_na_misk kan bru_ges til at ud_pege u_brug_te eller
sjæl_dent brug_te in_struk_tio_ner. For så vidt så_dan_ne in_struk_tioner
re_præ_sen_te_rer en se_kvens, kan en instruk_tions_af_kod_ning^ kom_me
på ta_le for at skaf_fe plads til an_dre ind_kod_nin_ger. Og_så her skal
man dog tæn_ke sig grun_digt om. Hvis sprog^et sta_dig er un_der udvik_ling,
kan in_struk_tions_an_ven_del_ses_møn_stret og_så ud_vik_le sig, så en
af_kod_ning^ af en instruk_tions_se_kvens vil få u_hel_di_ge føl_ger. Et
eksem_pel her_på, er ind_fø_rel_sen af dynamis_ke ty_per i PASCAL80^.
Det vil be_vir_ke et ø_get for_brug af in_struk_tio_ner, der adres_serer
re_la_tivt til et mellem_lig_gen_de stak_af_snit (@"intermediate frame"@)
(@Møl81@). Disse kan_didater fremtræ_der ellers i den_ne under_sø_gelse
som op_lag_te kan_di_da_ter til af_kod_ning.

Instruktionsindkodning og afkodning har beg_ge ind_fly_del_se på et
om_rå_de, som ikke er dis_kut_te_ret her i øv_rigt. Beg_ge de_le vil
be_vir_ke, at den gen_nem_snit_li_ge in_struk_tions_tid^ bli_ver kor_te_re,
og da af_brydelses_sy_ste_m^ets til_stand normalt kun under_sø_ges i
lø_bet af hent_ning af næs_te in_struk_tion, vil det_te be_ty_de 
hur_ti_ge_re be_tje_ning af af_bry_del_ser og der_med en for_bed_ret
ind_data/uddata^ - kapa_ci_tet for den ty_pe yd_re@en_he_d^er, der kan tå_le
mid_ler_tidi_ge op_hob_nin_ger ( el_ler for_sin_kel_ser@) af af_brydelser.
For yd_re en_he_der, der ik_ke er så_le_des ind_ret_tet, vil den læng_ste 
in_struk_tion, der ikke kan af_bry_des, sæt_te en græn_se for
kapa_ci_te_ten. Sekvensind_kod_ning^ har så_le_des og_så u_hel_di_ge
kon_se_kven_ser, der bør ta_ges med ind i o_ver_ve_jel_ser_ne. Det gæl_der
om at finde en ba_lan_ce mel_lem kra_ve_ne til af_bry_del_ses_sy_stem^et
og kra_ve_ne til af_vik_lings_effek_tivi_tet^ af maskin_bund_ne opgaver.
En egent_lig se_kvens_ana_ly_se^ er der_for rele_vant som tid_ligere 
an_ført. Dette be_styrkes yder_li_ge_re af de ten_den_ser, der er i
ret_ning af stadig mere in_tel_li_gen_te yd_re en_he_der (@"device controllers"@),
idet kra_ve_ne til af_bry_del_ses_sy_ste_met her_med slæk_kes
(@afbry_delser_ne sker ty_pisk pr. blok i stedet for pr. tegn@).

Indkodningen er ikke noget mål i sig selv. Målet er især plads_besparelse.
Dette mål kan være udgangs_punkt for en række design_over_ve_jel_ser
ved_rø_ren_de instruk_tions_sæt. De foretag_ne må_lin_ger vi_ser en
stor over_vægt både sta_tisk og dy_namisk af "load" in_struk_tioner
(@"retrieve"@). Dette kan ikke bare for_kla_res med lan_ge ud_tryk
(@"expressions"@); men bun_der for_mo_dent_lig i den på_tvung_ne
stren_ge stak_dis_ci_plin^. Instruk_tions_sæt^, der er en kom_bi_na_tion
af sædvanlige in_struk_tions_sæt, som de ken_des fra regis_ter_ma_ski_ne^r,
og af stak_ma_ski_ne^rs in_struk_tions_sæt, vil være et op_lagt em_ne
for vi_de_re ana_ly_ser. Man skal her væ_re op_mærk_som på, at der med
i be_gre_bet 'effek_ti_ve pro_gram_mer' hø_rer et krav om sik_re (@rigtige@)
pro_gram_mer. Dette til_gode_ses bl.a. af et stak_orien_te_ret 
in_struk_tions_sæt, der gør kode_gene_re_rin_g^en simp_le_re. Ved at 
blan_de de to ty_per in_struk_tions_sæt kan kra_vet til sik_ker_hed^ 
til_gode_ses i før_ste om_gang ved at an_ven_de den stak_orin_te_rede
del af in_struk_tions_sæt_tet til kode_gene_re_rin_gen i over_sætte_ren;
men kode_optimali_se_rin_ger i større om_fang vil væ_re mu_lige ved bl.a.
an_ven_del_se af register_maskin_instruk_tio_ner.

Som før nævnt kan in_struk_tioner, der inde_hol_der a_dres_ser som
pa_ra_me_tre ikke gøres til gen_stand for ind_kod_ning i forbin_del_se
med oversættelsen af et program. Man kunne overveje at ind_byg_ge den_ne
ind_kod_ning i for_bin_del_se med indlæsning/sammenkædning (@"load/link"@)
specielt i for_bindel_se med kryds_sammenkæd_ning, hvor en mere
plads_kræ_ven_de sammen_kæd_ningsfilo_so_fi ikke be_rø_rer plads_forbruget
i RC3502 sammenkædnings_mo_du_let. Da der kan fore_kom_me kon_stant_er
i ko_den er det_te dog ikke mu_ligt for RC3502 implemen_ta_tio_nen af
PASCAL80; men ideen kan overvejes ved til_sva_ren_de de_sign.
>ap
>a1 REFERENCER.

Referencerne er sorteret kronologisk.

>tb 14 (Cra46)
Cramer
>sp0
Mathematical Methods of Statistics.
Ch. 30. (1946)

>tb 14 (Huf52)
D. Huffman
>sp0
A Method for Minimum Redundancy Codes.
>sp0
Proc. IRE, vol. 40 pp. 1098-1101, sept. 1952.

>tb 14 (Dij60)
E. W. Dijkstra
>sp0
Recursive Programming
>sp0
Numer. Math. 2, pp. 312-318, 1960.

>tb 14 (Dij69a)
E. W. Dijkstra
>sp0
Notes on Structured Programming
>sp0
Tech. Rep.
>sp0
Technische Hogeschool, Eindhoven, 1969.

>tb 14 (Dij69b)
E. W. Dijkstra
>sp0
Structured Programming
>sp0
Conf. tech. software eng.
>sp0
Rome, NATO sci. Comm. okt. 1969.

>tb 14 (Knu71)
D. K. Knuth
>sp0
An Empirical Study of FORTRAN Programs
>sp0
Software Practice and Experience 1, pp. 261-301, 1971.

>tb 14 (Joh71)
J. B. Johnston
>sp0
The Contour Model of Block Structured Processes.
>sp0
SIGPLAN Proceedings of a Symposium on Data Structures in Programming
Language. pp. 55-82, feb. 1971.

>tb 14 (Den74)
P. J. Denning
>sp0
Is It not Time to Define Structured Programming?
>sp0
Operating Sys. Rev., vol 8, pp 6-7 jan. 1974.

>tb 14 (Der74)
N. Derret
>sp0
Design of Computing Mechanisms
>sp0
Ph.D. dissertation from University of Oxford, may 1974.

>tb 14 (DSt75)
Dansk Standardiseringsråd
>sp0
Dansk standard DS 2049-1970, EDB-ordbog
>sp0
Data serien, Gjellerup, 1975.

>tb 14 (Sal75)
A. Salvadori, J. Gordon and C. Capstick
>sp0
Static Profile of COBOL Programs.
>sp0
Sigplan Notices (ACM) 10, pp. 20-33, 1975.

>tb 14 (Ale75)
W. G. Alexander, D. B. Wortman
>sp0
Static and Dynamic Characteristics of XPL Programs
>sp0
Computer 8, 11, pp. 41-46, nov. 1975.

>tb 14 (Han78)
P. B. Hansen and C. Hayden
>sp0
Mi_krocomputer Evaluation
>sp0
Computer Science Department, University of Southern Cali_fornia,
Los Angeles, Cali_fornia, jan. 1978.

>tb 14 (Fer78)
D. Ferrari
>sp0
Computer Systems Performance Evaluation.
>sp0
PRENTICE-HALL, INC., Engelwood Cliffs, New Jersey, 1978.

>tb 14 (Tan78)
A. S. Tanenbaum
>sp0
Implications of Structured Programming for Mashine Architecture
>sp0
CACM, vol. 21, pp. 237-246, march 1978.

>tb 14 (Kor78)
P. Kornerup, B. B. Kristensen and O. L. Madsen
>sp0
Interpretation and Code Generation Based on Intermediate Languages.
>sp0
Software - Practice and Experience, vol. 10, pp. 635-658 june 1980.

>tb 14 (Aga79)
R. K. Agarwal and S. T. Chanson
>sp0
A Space Efficient Code Generation Sheme for BCPL.
>sp0
Software - Practice and Experience, vol. 10, pp. 77-95, 1980, from feb. 1979.

>tb 14 (Cra79)
H. G. Cragon
>sp0
An Evaluation of Code Space Requirements and Performance of Various
Architectures.
>sp0
ACM Computer Architecture News 7, 5, 1979.

>tb 14 (Ste79)
J. W. Stevenson and A. S. Tanenbaum
>sp0
Efficient Encoding of Mashine Instructions.
>sp0
Computer Architecture News 7, 8, june 1979.

>tb 14 (DSt80)
Dansk Standardiseringsråd
>sp0
Forslag til dansk standard
>sp0
DS F 80/240-245, 1980.

>tb 14 (Wil80)
I. R. Wilson
>sp0
Pascal for School and Hobby Use.
>sp0
Software - Practice and Experience, vol. 10, pp. 659-671, jan. 1980

>tb 14 (Sta80)
J. Staunstrup
>sp0
Pascal80, Report
>sp0
RC-Computer, RCSL 52-AA964, jan. 1980.

>tb 14 (PAX80)
JTAS, KTAS, RECAU, RC-COMPUTER.
>sp0
General Information of PAXNET
>sp0
PAXNET Report no. 1, may 1980.

>tb 14 (Wilc80)
C. R. Wilcox
>sp0
A Language@-@oriented Approach to Computer Architecture.
>sp0
Ph. D. - dissertation from Stanford University, Stanford Ca., june 1980.

>tb 14 (Bra80)
W. Brandt, S. Biering-Sørensen
>sp0
Brugs- og funktionsbeskrivelse for alarmsystem.
>sp0
De danske teleadm., doks. nr. SP.SYS.3/2, 1980

>tb 14 (Lau80)
B. B. Lauersen
>sp0
Pascal80, RC3502, Reference Manual
>sp0
RC-Computer, RCSL 42-i-1542, nov. 1980.

>tb 14 (Møl81)
P. Mølgaard
>sp0
RC3502 Reference Manual
>sp0
RC-Computer, RCSL 52-AA679, to appear in june - july 1981.
▶EOF◀
DataMuseum.dk

RC4000/8000/9000

⟦97db78252⟧ TextFile

Derivation

TextFile
