Waarom assembler?

Het gebruik van assembler als programmeertaal is niet populair meer. Over het algemeen geeft men de voorkeur aan derde of vierde generatie talen.

Meestal - voor "gewone" applicaties - is dit volkomen terecht. Er zijn echter wel degelijk situaties, waarin het wijs is om de argumenten voor en tegen eens goed op een rij te zetten.

Niet alleen berusten de argumenten tegen het gebruik van assembler grotendeels op vooroordelen, ook zijn de argumenten voor het gebruik van assembler relatief onbekend. Wie de vooroordelen tegen assembler wel kent, maar de voordelen ervan niet, kan moeilijk een objectieve beslissing nemen ten aanzien van de taalkeuze.

Wel blijft natuurlijk altijd gelden wat voor elke programmeertaal geldt: zonder goed opgeleide mensen kom je nergens. Zonder documentatie blijf je nergens.

Hieronder volgt eerst een overzicht van de belangrijkste voordelen van assembler. Vervolgens een poging om de vooroordelen te nuanceren. We eindigen met een korte samenvatting.

De voordelen van assembler.

Het werken met assembler biedt u een aantal mogelijkheden, die 3GL- en 4GL-programmeurs niet (altijd) tot hun beschikking hebben.

• Fouten ondervangen.
  Hoe vaak gebeurt het dat een applicatie struikelt over een onnozel probleempje? Een S0C7-abend doordat er spaties stonden waar nullen verwacht werden? Een hulpdataset die net iets te klein gealloceerd is? Met behulp van een relatief eenvoudige assembler-routine zijn dit soort problemen af te vangen en op te lossen. Uw applicatie struikelt niet, maar loopt gewoon door. Het geconstateerde probleem wordt gemeld in de joblog of in een aparte error log, zodat de verantwoordelijke beheerder de benodigde acties kan ondernemen.
• Gebruik van geheugen boven de 16MB-lijn.
  Er zijn nog steeds bedrijven die hun compiler (moeten) instellen op Amode=24. Door het toevoegen van kleine assembler-modules kunt u uw programma's wel boven de 16MB-lijn laten draaien, waardoor op cruciale punten de druk op het geheugen onder de 16MB-lijn wordt verlicht.
• Dynamisch geheugenbeheer.
  Programma's die gegevens bijhouden in tabellen, lijsten, of bomen weten vaak van te voren niet hoe groot die tabellen etc. zullen moeten worden. In assembler kan geheugen dynamisch worden aangevraagd en weer vrijgegeven, waardoor tabellen etc. gemakkelijk zijn uit te breiden en/of in te krimpen tot het benodigde formaat.
• Optimalisatie.
  De moderne compilers maken zeker efficiënte code aan. Zij kunnen echter niet bepalen welk optimalisatie-criterium voor u in een bepaald programma van cruciaal belang is. Door de kennis die de programmeur heeft van de structuur van de applicatie kan hij dit wel. Hierdoor kan bijvoorbeeld geanticipeerd worden op page-steal, waardoor het aantal page faults gereduceerd kan worden. Resultaat: uw programma loopt sneller, en het systeem krijgt meer lucht.
• Het gebruik van faciliteiten die het operating system biedt. Veel van dit soort services zijn niet beschikbaar in 'hogere' programmeertalen, en wanneer ze dat wel zijn, dan is vaak de overhead van het aanroepen vauit die taal zo groot, dat het het performance voordeel al gauw te niet doet.
  U kunt hierbij onder meer denken aan:
  • Data spaces.
    Programma's die behoefte hebben aan grote hoeveelheden werk-geheugen kunnen hiervan gebruik maken. U hoeft hierdoor minder gauw hulpdatasets te alloceren (scheelt I/O), en u bespaart virtual storage in uw eigen address space, waardoor u minder gauw een out-of-storage-abend zult krijgen.
  • Virtual lookaside facility.
    VLF biedt u de gelegenheid om benoemde gegevens in virtual storage te bewaren, buiten uw eigen address space. Voor benoembare gegevens die veelvuldig worden geraadpleegd (bv PDS-members uit bepaalde datasets) kan dit behoorlijk wat I/O-vertraging besparen.
  • Gelijktijdig benaderen van meerdere datasets.
    Wanneer een applicatie records uit twee of meer datasets nodig heeft, kunnen deze gelijktijdig worden gelezen en/of geschreven. Het is zelfs mogelijk meerdere records uit een enkele dataset gelijktijdig te benaderen. Deze gelijktijdigheid kan heel wat I/O-wachttijd schelen, vooral als de betreffende datasets niet op hetzelfde volume staan.
  • Subtaken.
    Door van een taak een of meer subtaken af te splitsen kan de verwerkingstijd enorm bekort worden. B.v. door het schrijven en lezen van tussenbestanden overbodig te maken. Of door het aanmaken van de journaalpost aan een subtaak over te laten, waardoor de verkoop-transactie zelf sneller afgehandeld kan worden.
  • Reenterability.
    Door veel-gebruikte programma-segmenten reenterable te maken kunnen ze in common storage geplaatst worden (liefst boven de 16MB-lijn natuurlijk). Hierdoor kan het betreffende programma efficiënter worden uitgevoerd: de kans op een page-fault in zo'n code-segment is relatief klein.

De vooroordelen tegen assembler.

Over het werken met assembler bestaan een aantal vooroordelen. De belangrijkste daarvan zijn wel:

1. Gestructureerd programmeren kan niet in assembler.
   Onjuist, in feite biedt assembler op dit terrein zelfs meer faciliteiten dan de meeste 3GLs.
2. Onderhoud aan assembler-programmatuur kost veel meer tijd dan bij een 3GL.
   In de tijd dat 3GLs werden geïntroduceerd, was dit wellicht waar. Nu nog maar zeer ten dele.
3. Assembler is een omslachtige taal en moeilijk te leren.
   Assembler is inderdaad iets minder doorzichtig voor de leek dan een taal als Cobol. Een taal als C of C++ daarentegen is weer veel moeilijker te leren.

Ad 1.

Gestructureerd programmeren kan niet in assembler.
Het aanbrengen van structuur in programma's is in de eerste plaats een kwestie van stijl en vakmanschap. Als de gebruikte taal goede faciliteiten biedt is dat mooi meegenomen.

• Op het gebied van segmentatie biedt assembler meer mogelijkheden dan 3GLs: niet alleen kun je in assembler subroutines en functies maken, ook is het mogelijk om programma's op te delen in CSECTS, die natuurlijk weer in subroutines en/of functies kunnen worden opgedeeld.
  Bovendien kan voor het calling mechanisme gekozen worden tussen een aantal alternatieven, waaronder standaard MVS-linkage via register 14, de linkage stack, of een ander calling mechanisme, al dan niet via een jump-table.
  Voor het doorgeven van argumenten ten slotte kan gekozen worden tussen pass-by-value en pass-by-reference, of een mengsel van die twee.
• Op het gebied van loop-control biedt assembler met 3GLs vergelijkbare mogelijkheden: naast de branch-on-count zij er de branch-on-index instructies. Met behulp van macro's kunnen deze mogelijkheden nog worden uitgebreid met krachtiger instructies.
• Net als in de meeste 3GLs biedt assembler de mogelijkheid om standaard-code vanuit een copy-member in uw programma's op te nemen.
• De macro-faciliteit ten slotte biedt diverse mogelijkheden voor het aanbrengen van structuur en het standaardiseren van regelmatig weerkerende programma-structuren. Door het gebruik van conditional assembly kan altijd optimale code worden aangemaakt. De meeste 3GLs beschikken niet over vergelijkbare functionaliteit.
   

Ad 2.

Onderhoud aan assembler-programmatuur kost veel meer tijd dan bij een 3GL.
Toen 3GLs geïntroduceerd werden, was er een grote basis van assembler-programma's. Doordat gestructureerd programmeren toen nog een nieuwe ontwikkeling was lieten deze programma's vaak te wensen over aan structuur. In assembler kunt u - net als in andere talen - zo veel of zo weinig structuur aanbrengen als u zelf wilt. Met alle consequenties voor de onderhoudbaarheid.
In assembler heeft u wel meer mogelijkheden dan in de meeste 3GLs om er een rommeltje van te maken. Maar dank zij de macro-taal heeft u in assembler ook weer aanzienlijk meer mogelijkheden voor het aanbrengen van structuur dan in enige andere taal.
 
Verder geldt natuurlijk de kwestie van vakmanschap. De 3GL-programmeur die assembler "er bij doet" kan zich niet meten met de vakman. Dat vertaalt zich niet alleen in de benodigde tijd, maar ook in de kwaliteit van de geproduceerde code. Probleem is dan natuurlijk wel, hoe u aan ervaren vakmensen komt. Maar dat geldt - zeker op dit moment - voor elke taal.
 
Als we voor de benodigde mankracht een eerlijke vergelijking willen maken tussen assembler en 3GLs dan moeten we dus niet alleen vakman naast vakman zetten, maar ook de ouderdom van de programmatuur (lees: mate van structuur) in ogenschouw nemen, alsmede de kwaliteit van de beschikbare documentatie.
 
Onze ervaring is dat u in de nieuwbouw dan zo'n 10 tot 20 procent extra mankracht moet rekenen voor assembler. Bij onderhoud is het verschil te zeer afhankelijk van de mate waarin de programmatuur gedocumenteerd en gestructureerd is om enig cijfer te kunnen geven.
 
Een voorbeeld: een van onze klanten draait naast een door ons ontwikkeld assembler-module een Cobol-variant met dezelfde functionaliteit. Bij de laatste paar modificaties was de assembler-programmeur in één dag klaar; de Cobol-programmeur had er drie dagen voor nodig. Hoewel dit een bijzonder voorval zou kunnen zijn, toont het wel aan dat onderhoud aan assembler programmatuur niet per definitie meer tijd vergt dan onderhoud aan 3GL-programmatuur.
 

Ad 3.

Assembler is een omslachtige taal en moeilijk te leren.
Als u van "leken" afhankelijk bent, dan moet u zeker niet voor assembler kiezen. Zoals met elke andere taal creëert u dan uw eigen moeilijkheden.
Maar er zijn natuurlijk ook vakmensen beschikbaar. Die beheersen niet alleen de kunst van het assembleren, die hebben ook grondige kennis van de macro-faciliteiten van de assembler, waarmee snel, efficiënt en netjes coderen binnen handbereik komt.

Samenvatting.

De argumenten voor en tegen kunnen als volgt worden samengevat:

• Werken met assembler kost iets meer tijd, maar niet zo veel als men pleegt te denken.
• Assembler biedt meer mogelijkheden tot structureren, maar bij gebrek aan vakmanschap zullen er ook sneller onderhoudsproblemen kunnen ontstaan.
• In assembler heeft u meer mogelijkheden voor het oplossen of voorkomen van performance-problemen.
• Het kost iets meer moeite om aan vakmensen te komen of ze op te leiden.

Alles bij elkaar luidt ons standaard-advies: gebruik geen assembler als het niet nodig is. Maar als er wel aanleiding toe is, loop er dan niet voor weg; assembler is niet eng. En als u dan voor assembler kiest, bouw dan alleen die modules in assembler, die daar baat bij hebben. Het grootste deel van uw project kunt u prima in uw vertrouwde 3GL of 4GL bouwen.

Ten slotte is het voor sommige zaken domweg niet mogelijk een andere taal te gebruiken dan assembler. Dit geldt met name voor veel exits.
Niet alleen het operating system, maar ook een groot aantal standaard produkten zijn voorzien van de mogelijkheid om exits te installeren, teneinde e.e.a. op uw eigen behoeften/specificaties af te stemmen. Voor de meeste exits geldt, dat coderen in assembler domweg onvermijdelijk is. Met de hierboven gegeven argumenten hoeft dat dus geen onoverkomelijk probleem (meer) te zijn.

Deze site is aangesloten bij WebRing. Bekijkt u gerust de lijst van mainframe-gerelateerde sites.		Dino's zijn niet dood. Ze zijn gezond en wel en leven in computer-centra overal om ons heen. Zij spreken in tongen en doen wonderbare magie met computers. Pas op voor de dino! En voor het geval u zit te wachten op het definitieve einde van deze dino's: onthoud dat dino's de wereld 155 miljoen jaren hebben geregeerd!
Dino's en andere anachronismen [ Aanmelden | Ring Overzicht | Willekeurig | << Vorige | Volgende >> ]

Naar de voordelen van assembler.
Naar de vooroordelen tegen assembler.
Naar de samenvatting.

Naar de nederlandse homepage.
Naar de algemene homepage.

Deze tekst is geschreven door A.F. Kornelis, vertaald door A.F. Kornelis.
Tekst en vertaling: © Copyright A.F. Kornelis, 1997-2003. Alle rechten voorbehouden.
e-mail de auteur.

Hieronder vindt u het logo van onze sponsor en logos van web-standaarden waaraan deze web-pagina voldoet.