Perché usare l'Assembler?

L'utilizzo dell'Assembler come linguaggio di programmazione non è più così diffuso. Di norma i programmatori preferiscono usare linguaggi di terza o di quarta generazione (di seguito: 3GLs o 4GLs).

Normalmente - per applicazioni ordinarie - questo è assolutamente vero. Tuttavia ci sono casi in cui sarebbe consigliabile valutare bene sia gli argomenti a favore sia gli argomenti contro l'utilizzo di questo linguaggio.

Se da un lato gli argomenti contro l'uso dell'Assembler sono in larga parte frutto di pregiudizi, dall'altro i motivi a favore di questo linguaggio sono relativamente poco conosciuti. Quando si conoscono i pregiudizi contro l'Assembler senza conoscerne i vantaggi, diventa difficile scegliere obiettivamente il linguaggio di programmazione adatto.

Una regola importante - così come per qualsiasi linguaggio di programmazione - è la seguente: senza personale qualificato non si raggiungerà alcun obiettivo, senza un'adeguata documentazione si rischierà di non sapere più a che punto si è arrivati.

Di seguito troverai una panoramica dei più importanti vantaggi dell'Assembler. Proseguendo, proveremo a smontarne i pregiudizi. Alla fine cercheremo di trarre le conclusioni.

I vantaggi dell'Assembler.

Lavorare con l'Assembler offre una gamma di possibilità, non (tutte) disponibili nei 3GLs o 4GLs.

• Errori evitabili.
  Quante volte capita che l'applicazione si "inceppi" su una cosa così banale? Un Abend-0C7 a causa di una serie di spazi (blank), anzichè di zero? Oppure un dataset temporaneo allocato un po' troppo piccolo? Con l'aiuto di una semplice routine Assembler questo tipo di problemi possono essere risolti. La tua applicazione non si interrompe più, continuando a funzionare. Tutti i problemi riscontrati verranno documentati nel joblog o in un error log separato, consentendo al controllore dei comandi a prendere le dovute contromisure.
• Utilizzo della memoria sopra la linea dei 16 MB.
  Ancora oggi ci sono aziende che compilano i loro applicativi in Amode=24. Con l'aggiunta di piccoli moduli in Assembler si potranno far girare programmi applicativi sopra la linea dei 16 MB, liberando così spazio per quei programmi che girano sotto la 16MB-line.
• Gestione dinamica della memoria.
  I programmi che mantengono dati in tabelle, liste o strutture ad albero non conoscono in anticipo di quanto cresceranno le dimensioni di questi oggetti. In Assembler la memoria può essere allocata o deallocata dinamicamente, consentendo di allargare o diminuire la grandezza di tali oggetti nella dimensione richiesta.
• Ottimizzazione.
  I compilatori di ultima generazione creano certamente dei programmi efficienti. Tuttavia, essi non sono in grado di decidere quale criterio di ottimizzazione si adatta meglio ad un programma specifico. Dal momento che il programmatore conosce la struttura della sua applicazione, solo lui è in grado di prendere una tale decisione. Per esempio potrebbe decidere di ridurre il rischio di page-steal, facendo in modo che il suo programma giri più velocemente e diminuendo quindi il carico del sottosistema di paginazione.
• Uso dei servizi del sistema operativo. Molti di questi servizi non sono disponibili per i linguaggi ad alto livello, e quando lo sono le linee di codice in più richieste da questo linguaggio per servirsi di questa o quella facility mette molto spesso in secondo piano i vantaggi che ne sarebbero derivati in termini di prestazione.
  Tra i diversi servizi, ricordiamo:
  • Data space.
    Quei programmi che utilizzano grandi quantità di memoria potrebbero giovarsi dell'uso dei data space. Questo riduce il bisogno di allocare dei work dataset (che a sua volta riduce l'I/O) e al tempo stesso riduce l'uso di memoria virtuale all'interno del tuo address space, diminuendo il rischio di abend per out-of-storage.
  • Virtual look-aside facility.
    Il VLF permette di mantenere dati in memoria virtuale, fuori dal proprio address space. Per quei dati usati frequentemente (ad esempio membri di alcuni dataset partitioned) questa servizio può ridurre i tempi di I/O della tua applicazione.
  • Accesso contemporaneo a più dataset.
    Quando un'applicazione necessita di accedere ai record di due o più dataset, questi record possono essere scritti e/o letti contemporaneamente. È perfino possibile accedere a diversi record di un singolo dataset nello stesso momento. Questa contemporaneità può diminuire considerevolmente il tempo di attesa dell'I/O, specialmente quando i dataset interessati risiedono su volumi diversi.
  • Subtasks.
    Separando uno o più subtask da un task principale, quest'ultimo può aumentare considerevolemente la sua velocità d'esecuzione. Per esempio eliminando il bisogno di scrivere dati su un work-dataset. Oppure lasciando il compito di scrivere i necessari record cronologici ad un subtask, facendo così in modo che la transazione vendite possa essere gestita più velocemente.
  • Reenterability.
    Rendendo rientrabili quei segmenti di programmi molto spesso utilizzati, questi stessi possono essere piazzati in common storage (preferibilmente sopra la linea dei 16MB). Questo significa che tutti quei programmi che usano quel codice possono essere eseguiti più efficientemente, perché l'eventualità di una condizione di page fault in questo tipo di codice è minima.

I pregiudizi contro l'Assembler.

Esistono diversi pregiudizi contro l'utilizzo dell'Assembler. Tra questi ricordiamo i più ricorrenti:

1. In Assembler la programmazione strutturata è impossibile.
   Questo non è vero. Al contrario, l'Assembler offre in proposito molte più possibilità rispetto alla maggior parte dei 3GLs.
2. La manutenzione dei programmi in Assembler è di gran lunga più costosa rispetto a quella dei 3GLs.
   Al tempo in cui i 3GLs furono introdotti, quest'affermazione poteva essere vera. Al presente questa posizione è certamente opinabile.
3. L'Assembler è un linguaggio scomodo e difficile da imparare.
   L'Assembler è, certamente agli occhi di un profano, meno leggibile rispetto al Cobol. D'altra parte è molto più difficile avere la completa padronanza di linguaggi come il C e il C++.

Punto 1.

In Assembler la programmazione strutturata è impossibile.
Scrivere programmi in modo strutturato è essenzialmente una questione di stile e di abilità. Se il linguaggio di programmazione offre diverse possibilità in questo senso, questo rappresenta certamente un aiuto, ma niente di più.

• Quando parliamo di segmentazione dei programmi teniamo presente che l'Assembler offre più possibilità rispetto ai 3GLs: oltre al normale uso di subroutine o funzioni, in Assembler è anche possibile dividere i programmi in Control Section (CSECTs), che a loro volta potranno essere sottodivisi ulteriormente in subroutines e/o funzioni.
  Inoltre è possibile scegliere diversi meccanismi di chiamata. Tra gli altri ricordiamo lo standard MVS-linkage tramite il registro 14, il linkage stack, od altri meccanismi di chiamata con o senza l'uso della jump-table.
  Il passaggio dei parametri può alla fine essere scelto in base al valore, al riferimento, o a un insieme di questi due.
• Per ciò che riguarda il controllo dei loop, l'Assembler offre possibilità comparabili con i 3GLs: sono le cosiddette istruzioni branch on index e branch on instructions. Con l'ausilio di macro queste facility possono essere estese con istruzioni più complesse.
• Così come la maggior parte dei 3GLs, l'Assembler è in grado di copiare codice standard da un membro di una libreria direttamente nel tuo programma.
• Le macro consentono quindi un'ampia scelta per strutturare i propri programmi, e per standardizzare la creazione di programmi ricorrenti. Mediante l'uso di conditional assembly è sempre possibile ottimizzare il codice da generare. La maggior parte dei 3GLs non offre funzionalità comparabili.
   
  

Punto 2.

La manutenzione dei programmi Assembler è più costosa rispetto ai 3GLs.
Quando i 3GLs furono introdotti, esisteva già una vasta base di programmi Assembler. Siccome la programmazione strutturata era un principio relativamente nuovo per quei tempi, questi programmi lasciavano sotto questo aspetto molto a desiderare. In Assembler - così come per altri linguaggi - si può strutturare i propri programmi tanto quanto se ne desideri. Con conseguenze per la loro successiva manutenzione.
In Assembler, più che con i 3GLs, si hanno più possibilità di fare molta confusione. Tuttavia, grazie alle macro, si ha un considerevole numero di opzioni supplementari per strutturare i propri programmi rispetto agli altri linguaggi.
 
La questione dell'abilità è di primaria importanza. Un programmatore Cobol che "se la cava un po' con l'Assembler" non può certamente misurarsi con un programmatore Assembler senior. Gli effetti sono verificabili non solo per ciò che rigurda il tempo necessario per finire un determinato lavoro, ma anche per quello che riguarda la qualità del codice prodotto. Il principale problema quindi è come riuscire a trovare personale qualificato per il proprio team. Un problema che si pone comunque, a prescindere dal linguaggio scelto.
 
Così, se vogliamo fare un giusto paragone per il personale richiesto tra Assembler e 3GLs, dovremo paragonare professionisti con professionisti, prendendo anche in considerazione l'età dei programmi (leggi: grado di strutturazione), così come la documentazione disponibile.
 
La nostra esperienza ci dice che quando si lavora con l'Assembler per sviluppare nuovi programmi, si necessita un 10, 20 percento in più di personale. Per la manutenzione di programmi già esistenti la documentazione disponibile o il grado di strutturazione dei programmi stessi possono differire di molto da caso a caso, per cui diventa difficile fornire stime attendibili.
 
Un esempio: uno dei nostri clienti possiede un modulo in Assembler, creato da noi, e uno in Cobol. Entrambi i moduli fanno esattamente la stessa cosa. Per implementare alcune modifiche il programmatore Assembler ha avuto bisogno di una giornata, mentre il programmatore Cobol ha lavorato tre giorni. Anche se questo può sembrare un'eccezione, l'esempio ci mostra come l'aggiornamento di programmi Assembler non è necessariamente più oneroso rispetto ai 3GLs.
 

Punto 3.

L'Assembler è un linguaggio scomodo e difficile da imparare.
Se siete in mano a dei dilettanti sarebbe meglio evitare di scegliere l'Assembler. Così come per altri linguaggi, riuscireste solo a mettervi in difficoltà da soli.
Certamente esistono anche professionisti qualificati in giro. Non solo hanno la padronanza del linguaggio, ma posseggono una vasta conoscenza delle macro che questo linguaggio è in grado di offrire. Questo ci permette di scrivere programmi più rapidamente, efficienti e chiari.

Conclusioni.

Gli argomenti a favore e contro l'uso dell'Assembler possono essere riassunti come segue:

• Lavorare con l'Assembler necessita di più tempo, anche se non così tanto quanto si possa pensare.
• L'Assembler offre più possibilità per strutturare i programmi, anche se la mancanza di abilità potrebbe far emergere problemi in fase di aggiornamento.
• Con l'Assembler si hanno più possibilità di risolvere o prevenire problemi di prestazione.
• Ci vogliono più tempo e risorse per trovare o formare dei professionisti.

Concludendo, il nostro consiglio è il seguente: non usate l'Assembler quando non è necessario. D'altra parte, in presenza di buone ragioni, non scartatelo a priori; l'Assembler non deve spaventare. E in caso si è scelto di farne uso, utilizzatelo per quei moduli che ne trarranno vantaggio. La fetta più grande del vostro applicativo sarà probabilmente scritta in un 3GLs o 4GLs.

Un ultima considerazione: per alcuni applicativi è semplicente impossibile non usare l'Assembler. Questo vale soprattutto per la maggior parte delle exit. Non solo il sistema operativo, ma anche molti prodotti se ne servono per adattarne le funzionalità alle proprie esigenze. Per molte di queste exit la codifica in Assembler è inevitabile. E con gli argomenti discussi fin qui, quest'ultima non dovrebbe (più) rappresentare un problema insormontabile.

Questo sito è membro del WebRing. Clicca qui per accedere una lista dei siti sui mainframe.		I dinosauri non sono morti. Sono vivi e vegeti e vivono nei centri elaborazione dati intorno a te. Parlano una loro lingua e fanno strane magie con i computer. Stai in guardia! E in caso tu stia aspettando la loro prossima estinzione, ricorda che i dinosauri hanno dominato il mondo per 155 milioni di anni!
Dinosauri ed altri anacronismi [ Iscriviti | Ring Hub | Casuale | << Prec | Succ >> ]

Vai a I vantaggi dell'Assembler.
Vai a I pregiudizi contro l'Assembler.
Vai alle Conclusioni.

Alla Home Page italiana.
Alla Home Page generale.

Il testo di questa pagina è a cura di A.F. Kornelis, tradotto da Walter Marguccio.
© Copyright: A.F. Kornelis, 1997-2004. Tutti i diritti riservati.
La traduzione: © Copyright: Walter Marguccio, 2004. Tutti i diritti riservati.
Scrivi all'autore oppure al traduttore.

Di seguito troverai il logo del nostro sponsor e altri logo standard ai quali le nostre pagine web aderiscono.