⟦97db78252⟧

TextFileVerbose

>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

RC3500

⟦97db78252⟧ TextFileVerbose

Derivation

TextFileVerbose
