/ 0
La programmazione in assembler 360
L'arrivo del 360 fu una grossa rivoluzione; come ho già detto si trattava del capostipite dei nuovi mainframe IBM, cioè della prima di una serie di macchine che anche se continuamente aggiornata nell'hardware, avrebbe sempre consentito il funzionamento dei programmi già scritti.
Questo richiese non solo di definire un set di istruzioni che non sarebbe più cambiato se non per l'aggiunta di nuove istruzioni, ma anche di definire delle funzioni di sistema che sarebbero sempre state disponibili.
Per raggiungere questo obiettivo ambizioso ed importante l'IBM dovette però chiedere a coloro che erano già suoi clienti per avere in uso macchine della seconda generazione, di compiere il grosso sforzo di riscrivere tutti i programmi: ed è quello che accadde anche a noi !
Eravamo nel 1965 e poichè i linguaggi avanzati, o "problem oriented" come venivano chiamati allora, non erano ancora sufficientemente affidabili, la nostra Direzione decise di continuare ad usare il linguaggio "machine oriented" e quindi tutti noi programmatori partecipammo ai necessari corsi di istruzione per imparare l'assembler del 360.
La cosa che ci preoccupava moltissimo era il fatto che mentre il 7070 disponeva di 100 registri indici, nel 360 esistevano soltanto 15 "general register" e ad essi erano anche affidati compiti diversi; infatti alcuni di essi avevano un compito fisso, ed un altro buon numero doveva essere usato come registri base, cioè registri da impostarsi all'inizio del programma per consentire il corretto indirizzamento; noi che con il 7070 ci eravamo abituati a fare largo uso dei registri indice, utilizzandone uno dedicato per ogni tabella da gestire, ci trovammo abbastanza a disagio nel dovere usare solo i pochi registri che rimanevano liberi; si capì subito però, che nessuno vietava di usare anche soltanto uno o pochi registri, in quanto in qualunque momento era possibile salvare il loro contenuto in un'apposita area di memoria e ripristinarli quando necessario (a tale scopo erano disponibili due istruzioni STM -Store Multiple- e LM -Load Multiple- che consentivano appunto di salvare e ripristinare un gruppo contiguo di registri).
L'altro problema che ci tormentava, anch'esso legato ai pochi registri disponibili, era il fatto che il set di istruzioni del 360 prevedeva di "fabbricare" gli indirizzi degli operandi, sommando un offset che poteva andare da 0 a 4095 al contenuto di un registro base che poteva contenere un valore su 24 bits (da 0 a 16.777.215); dunque per rendere possibile l'indirizzamento di programmi e dati era necessario impostare all'inizio di ogni programma una serie di general registrer ad uso di registri base; il primo registro base doveva contenere l'indirizzo di caricamento del programma, il secondo quel valore aumentato di 4096, il terzo quel valore aumentato di 8192 e così via fino a "coprire" l'intera lunghezza del programma; di conseguenza più grande era il programma, più registri base erano necessari; la soluzione a questo problema era naturalmente la modularizzazione dei programmi, cosa a cui non eravamo ancora abituati.
Ma tutte queste complicazioni derivavano dal fatto che la nuova serie di macchine prometteva di avere memoria centrale sempre più grande e sarebbe stata dotata di sistemi operativi che avrebbero consentito la multiprogrammazione di più programmi ospitati contemporaneamente in memoria centrale; la conseguenza era che ogni programma doveva poter essere caricato in una zona qualunque della memoria senza accusare problemi di funzionamento, mentre se l'assemblatore avesse generato le istruzioni del codice oggetto assegnando a ciascun operando un indirizzo assoluto, sarebbe accaduto che il programma avrebbe funzionato soltanto se fosse stato caricato in una zona ben precisa della memoria.
Il set di istruzioni del 360, oltre a consentire di utilizzare un basso numero di bits per individuare un operando, utilizzava la tecnica dell'indirizzamento relativo per cui ogni programma poteva accedere a tutti i propri indirizzi a partire dal suo indirizzo di caricamento.
Un ultimo problema era quello degli "address constant", cioè di quegli indirizzi di una qualche tabella o area di memoria che erano stati generati dall'assemblatore e impostati in una variabile per richiesta del programmatore; in questo caso l'indirizzo veniva generato facendo riferimento ad un ipotetico indirizzo di caricamento del programma, che non necessariamente poi sarebbe stato rispettato; ed allora durante il caricamento esisteva un meccanismo che stabiliva la differenza tra l'indirizzo di caricamento del programma e quello che era stato assunto durante l'assemblaggio determinando un valore algebrico chiamato "fattore di rilocazione"; questo valore veniva sommato algebricamente durante il caricamento a ciascun address constant, risolvendo quindi anche questo problema.