In dit verslag hebben we het gehad over de techniek van het tijdens de executie veranderen van instructies. Bekeken zijn het gebruik, de enkele toepassingen en de problemen die deze techniek met zich meebrengt. Ook eventuele toepassingen in de toekomst zijn aan de orde gekomen.

Het gebruik van self modifying code, bijvoorbeeld in een lus, is over het algemeen gunstig als de uitsparing (van vaak testinstructies) opweegt tegen de tijd die nodig is om de code te wijzigen. Deze tijd bestaat vaak uit het flushen van de cache (direct) en de kosten van cache-misses die volgen (indirect).

De versnelling die verkregen kan worden door self modifying code te gebruiken is geen orde versnelling in de zin van complexiteit, maar (op zijn best) een constante versnelling. In real-time of multimedia toepassingen kan dit echter wel een aanzienlijke tijdwinst zijn, omdat hier veel lussen in voorkomen.

Het is moeilijk om een exacte afschatting te geven van hoeveel sneller self modifying code kan zijn dan gewone, statische code. Dit komt onder andere door het ontbreken van goede metrieken. Ook is de eventuele versnelling sterk afhankelijk van het op te lossen probleem.

Toepassingen van self modifying code zijn vooral te vinden in gebieden die het lezen en herkennen van code moeilijker proberen te maken zoals virussen. Toepassingen van runtime compilers zijn wel 'serieuze' toepassingen waarin het tijdens runtime de functionaliteit wordt vastgesteld.

Ook zijn er enkele specifieke toepassingen waarin self modifying code gebruikt zou kunnen worden. Voorbeelden hiervan is het gebruik bij systemen met een lage geëiste failure-rate of bij een eenvoudige oplossing voor mutual exclusion.

Het ontwikkelen van programma's die tijdens runtime hun code veranderen vereist een andere aanpak dan bij statische programma's. Een dergelijke verschil zou kunnen lijken op het verschil tussen sequentiële en parallelle programma's. Een dynamische aanpak heeft wellicht meer verband met de 'werkelijkheid' dan een statische aanpak.

Self modifying code biedt echter geen extra functionaliteit. Self modifying code is altijd wel om te schrijven in een statische variant, welke eventueel trager is. Ook bij self modifying code wordt statisch de functionaliteit vastgelegd en zal voor echt dynamisch probleemoplossen naar methoden als neurale netwerken en dergelijke gekeken moeten worden.

Met self modifying code kan soms bespaard worden op het gebruik van ruimte en tijd. Op het moment zijn zowel de hoeveelheid beschikbare ruimte en de hoeveelheid beschikbare processortijd in nieuwe systemen nog steeds aan het groeien, wat natuurlijk geen excuus is om daar slordig mee om te gaan. Dit maakt het echter wellicht voorlopig voor velen een minder zwaar wegende factor in het ontwikkelen van software.

Het is niet waarschijnlijk dat self modifying code in de huidige ontwikkelingen in de hardware en besturingssystemen ondersteund gaat worden. Het gebruik van pipelines en caches neemt alleen maar toe en de kosten van cache-misses en chache-fulshen in vergelijking met cache-hits worden alleen maar groter.

Als de techniek niet veel toevoegt aan bestaande technieken, zou de toename in onoverzichtelijkheid doorslaggevend zijn. Het ontwikkelen van grote programmatuur is een complexe aangelegenheid die door het dynamisch veranderen van code niet eenvoudiger wordt. In het algemeen is self modifying code niet aan te raden in general-purpose systemen. Toepassingen op beperkte schaal voor specifieke doeleinden zijn echter wel denkbaar.

Verder onderzoek is in het gebruik van self modifying code in real-time en multimedia toepassingen, runtime compilers en genetische algoritmen is aan te bevelen. Ook het ontwikkelen van standaard-metrieken voor executie-tijden op complexe architecturen zou hierbij van pas komen.