In questo nuovo appuntamento settimanale col retrocomputing, andremo a “disseppellire” l’emblema di un’epoca del PC direi felicemente conclusasi: le limitazioni imposte dalla memoria convenzionale e i sistemi usati per aggirarla, per poi inquadrare le origini del moderno concetto di multitasking.
640KB (qui approfondito tecnicamente da Cesare) è il quantitativo di memoria che i progettisti IBM ritennero all’inizio degli anni ’80 soddisfacente per ogni eventuale uso del computer.
Sempre a livello progettuale, la parte oltre i 640KB del primo megabyte di RAM (1MB era il massimo indirizzabile da una CPU 8086/8088) fu riservata in blocco, alle periferiche e al BIOS. Si tratta di ben 384KB, che non rappresentano una quantificazione esatta delle esigenze menzionate ma piuttosto un’approssimazione, questa sì per eccesso, dei bisogni creati da futuribili scenari d’uso.
Risultato: in ogni PC/XT, del primo MB di RAM, solo 640KB (la cd. memoria convenzionale) sono direttamente fruibili, mentre 384 rimangono inaccessibili ai programmi e, in certa parte, inutilizzati.
Già pochissimi anni dopo il PC/XT (1981) questo limite si rivelò stringente e poco lungimirante, mano a mano che sempre più programmi TSR e driver di periferica, in abbinamento ai programmi d’uso comune, rivendicavano spazio nella memoria convenzionale.
Prima 286 (1982) con la novità della modalità protetta per l’accesso a tutta la memoria indirizzabile, poi il lancio del PC/AT basato su 286 e infine il debutto del 386 (1985), con l’introduzione di innovazioni sulla gestione della memoria e la possibilità di indirizzare 4GB di RAM, accelerarono drasticamente l’obsolescenza del real mode e dei problemi legati alla memoria convenzionale.
La protezione della memoria introdotta del 286 (qui un approfondimento di Cesare) rappresentò un passo fondamentale per abilitare il multitasking sul PC. L’implementazione della memoria protetta su 286 risultò però difficilmente fruibile a causa dell’incompatibilità del DOS – sviluppato attorno alle specifiche di 8086 – e dell’impossibilità di commutare fra modalità reale e protetta senza un reset.
Il 386 introdusse lo switching dinamico alla memoria protetta e il Virtual 8086 mode, che consente ai programmi obsoleti di girare credendosi “padroni assoluti” del sistema.
Questa modalità presentava tuttavia problemi di compatibilità, che finirono col rendere spesso indispensabile anche sul 386 il ricorso alla modalità reale – che di fatto faceva girare il computer come un XT superveloce.
A questo punto è chiaro che non affrontare il problema della memoria convenzionale avrebbe potuto implicare un ritardo nell’adozione di 286 e 386, dunque un ritardo nello “svecchiamento” del parco software.
In conseguenza di ciò si sarebbe osservato uno stallo della piattaforma DOS-Intel, incapace di gestire elevati quantitativi di memoria ed eseguire più applicazioni contemporaneamente – al contrario piattaforme come Mac, Amiga e Atari ST.
In attesa di un’innovazione nel mondo OS che traghettasse tutto l’ecosistema PC verso l’uso della memoria protetta, si lavorò sull’accessibilità della memoria UMA e della memoria sopra il primo MB in modalità reale.
La soluzione di questo enigma era però tutt’altro che semplice: i 640KB di memoria convenzionale sono infatti situati al di sotto dei 384 riservati a BIOS e periferiche (Upper Memory Area). La memoria convenzionale è dunque “intrappolata” e non direttamente espandibile, come lo sarebbe stata se si fosse trovata al di sopra dei 384KB della UMA.
Per accedere in modalità reale al resto della memoria indirizzabile da un 286 (16MB) o un 386 (4GB), servono quindi degli escamotage, utili anche per recuperare quella parte della UMA che resta vuota.
Molte soluzioni al limite del gioco di prestigio, sia hardware che software, furono trovate all’epoca, per rendere tanto la UMA quanto la memoria estesa accessibile anche in modalità reale.
Il DOS Extender più emblematico e noto all’alba del multitasking su PC, fu probabilmente il memory manager QEMM della Quarterdeck. Grazie ad un uso intelligente dello switch real mode/protected mode del 386 QEMM, in accoppiata con il “task manager” DesqView, mise per la prima volta i possessori di 386 equipaggiati con MS-DOS 3.3 o 4, davanti alle reali potenzialità della loro macchina.
Uso di più applicazioni Windows in assieme a più applicazioni DOS, lo switching fra i singoli task, l’esecuzione di processi in background, mentre driver network, mouse e quant’altro erano caricati contemporaneamente in memoria: tutto questo era improvvisamente possibile per quanti avevano sborsato la considerevole somma necessaria per l’acquisto di un 386 senza averne ancora mai “assaggiato” le reali prestazioni.
Si trattava di vantaggi enormi rispetto al real mode a cui applicazioni vetuste confinavano le macchine più potenti, ma anche rispetto al precedente Topview (di cui abbiamo parlato qui), sviluppato dalla IBM nella speranza di dare nuova linfa al PC/AT, e presto finito nel dimenticatoio.
QEMM+DesqView, come altri DOS Extender, non era tuttavia esente da problemi di compatibilità con specifiche applicazioni. Per questo motivo vennero sviluppate frequenti soluzioni software personalizzate, incorporate in specifiche applicazioni: il DOS Extender di Autocad ne è un esempio, così come quello incorporato in Lotus 1-2-3 3.0.
E per chi era ancora fresco di mega-assegno per un 286, magari un costoso IBM PC/AT? QEMM-DesqView erano disponibili anche per questa piattaforma abilitando, pur a velocità ridotta, molti dei vantaggi citati su macchine di classe AT.
Ad un prezzo non troppo dissimile dalle soluzioni software come QEMM, erano per disponibili anche add-on hardware per 286, capaci di estenderne le capacità di gestione della memoria e velocizzare il multitasking.
Ricordiamo in proposito la soluzione All Chargecard (1988), una scheda che andava ad inserirsi fra 286 e scheda madre e metteva a disposizione – tramite il software di gestione incluso – un’esperienza multitasking molto veloce anche a chi non avesse intenzione di acquistare un computer 386.
Non a caso IBM, interessata a prolungare la vita dei PC/AT nella speranza di tenere il business dei mainframe al riparo dalla potenza del 386, fece tutto il possibile per rendere la Chargecard compatibile con i propri PC.
È interessante notare come tutti i vantaggi citati sia per le soluzioni software che hardware, fossero possibili tramite un complessissimo lavoro di sottofondo da parte dell’extender, che in estrema sintesi consisteva in:
- trasferire il massimo numero di driver e TSR nell’UMA, in modo da lasciare la maggior quantità di memoria convenzionale libera per l’esecuzione di programmi;
- abilitare l’accesso dell’OS alla memoria estesa (oltre il 1° MB) replicandola un pezzo alla volta in un preciso segmento dell’UMA;
- gestire molteplici applicazioni, ciascuna in un suo spazio di memoria “virtuale”, “illudendo” le applicazioni richiedenti il real mode, di essere padrone di tutte le risorse.
A conclusione di questa veloce panoramica sui guasti di un ecosistema PC rimasto troppo a lungo ancorato all’8086, è interessante ricordare che, già nei primi anni ’90, OS/2 (di cui abbiamo parlato qui) era pronto a fare piazza pulita di cotanti equilibrismi e rattoppamenti e delle relative penalità prestazionali.
Come? Con un uso “illimitato” della memoria indirizzabile dal processore, col supporto nativo a tutte le potenzialità delle nuove CPU Intel fra cui multitasking e 32bit “puliti” (su 386) e, dulcis in fundo, con un buon supporto alle vecchie applicazioni DOS.
Malgrado tutto ciò, con Windows 3.0 e le lotte IBM-Microsoft che lo precedettero, la storia prese tutt’altra direzione.
E tutto sto casino perchè qualche genio ha invertito di posizione due blocchi di memoria…
Ma la ragione di una simile deleteria scelta è mai stata spiegata ?
Cioè, tra un bios, che si sapeva anche allora sarebbe stato limitato nello spazio quindi anche a livello di programmazione non avrebbe potuto permettersi sprechi del tipo “in qualche indirizzo scrivo questo” ed un programma perchè ingabbiare quest’ultimo ?
640KB sarebbero stati sufficienti per tutti, ma dico io, i precedenti sistemi che avevano sviluppato operavano da sempre con 640KB tanto da non poter supporre un’evoluzione delle necessità generali ?
I precedenti sistemi non nascevano con molta meno ram e negli anni si finiva per espanderla (certo non per la gioia di spendere denaro a vuoto visto il costo dei relativi moduli) ?
O stiamo parlando della madre delle limitazioni artificiose imposte di fabbrica nella speranza di pilotare all’estremo nascita, vita e morte della piattaforma pc ?
ERRATA:
“in qualche indirizzo scrivo questo” –> “In quale indirizzo scrivo questo”
@D: ci sono due problemi. Il primo è il fatto che sia stata scelta la memoria alta (com’è capitato con altre architetture, ad esempio l’Amiga; purtroppo) per infilarci BIOS, memoria video e ROM per le espansioni.
Sarebbe stato meglio posizionarli nella memoria bassa per facilitare l’estensione lineare dello spazio d’indirizzamento delle applicazioni.
Il secondo è che hanno riservato TROPPA memoria (ben 384KB, appunto; a cui possiamo aggiungere altri 64KB – 16 byte della HMA, la memoria subito a ridosso del limite degli 1MB, che dai 286+ è indirizzabile anche in modalità reale; quindi siamo a poco meno di 448KB totali) per questa roba. Con una suddivisione più oculata sarebbe stata disponibile molta più memoria convenzionale.
Ma non credere che si tratti di errori dovuti alla progettazione del primo PC. Ad esempio il limite dei 640KB è dovuto all’introduzione dei PC dotati di schede video EGA e VGA, che hanno utilizzato il segmento A0000 (64KB) per la loro memoria video, anziché condividere il B0000 utilizzato da MDA (32KB) e il B8000 dalla CGA (altri 32KB).
Questa scelta pare sia stata dettata per non sovrapporre le aree di memoria di queste schede grafiche con quelle di MDA e CGA. Ma avrebbe avuto senso soltanto se fosse stato possibile utilizzare più schede video (di diverso tipo, ovviamente) nello stesso sistema.
Il risultato è che con PC dotati di CGA era possibile arrivare a indirizzare fino a 736KB (cioè tutta la memoria dall’indirizzo 0, circa, fino a B7FFF), mentre con le MDA (ed Hercules) era possibile arrivare fino a 704KB (indirizzi fino ad AFFFF).
Si tratta di scelte effettuate dagli ingegneri che sono decisamente discutibili. E questo senza voler tirare in ballo il famoso “senno di poi”, perché un minimo di riflessione su tali scelte e le eventuali conseguenze potevano benissimo farla.
Comunque il limite più grosso rimane ovviamente quello dell’architettura 8086, che rimane vincolata a 1MB di spazio d’indirizzamento totale. Qui c’è poco da fare: è stata Intel a mettere un cappio al collo alla sua architettura, ma stiamo parlando di una CPU nata nella seconda metà degli anni ’70…
Aggiungo anche che l’8086/88 dopo un reset legge la sua prima istruzione all’indirizzo FFFF0, e ha bisogno di 1 KB di ram a partire dall’indirizzo 0 per la tabella dei vettori di interrupt, quindi la disposizione è stata un po’ obbligata, perchè se avessero voluto mettere la ram dopop il bios, avrebbero dovuto mettere 1KB di ram, poi rom, poi ram, poi 16 Byte di rom per le istruzioni di reset.
@ Cesare:
“Qui c’è poco da fare: è stata Intel a mettere un cappio al collo alla sua architettura, ma stiamo parlando di una CPU nata nella seconda metà degli anni ‘70…”
L’8086 è stato terminato e commercializzato nel 1978, il 68000 nel 1979 (fonte Wikipedia). Forse gli ingegneri Motorola sapevano qualcosa sul futuro prossimo che gli ingegneri Intel non sapevano? Pure lo Z8001 poteva indirizzare 8MB! ;)
Intel s’è voluta portare dietro la compatibilità con gli 8085 (anche se a livello di sorgente), con tutte le conseguenze del caso. Come al solito (sì, ci mettono proprio i mezzi per farsi del male :D).
Comunque, come ho scritto nell’articolo sull’8086, l’errore più grosso è stato quello di fissare la granularità dei segmenti a 16 byte anziché a qualcosa di più (con 256 byte si sarebbero potuti indirizzare agevolmente 16MB).
Per quanto riguarda il boot, non c’è bisogno di avere per forza RAM a FFFF0.
L’Amiga ha un problema diametralmente opposto, perché i 68000 al reset leggono dall’indirizzo 000000, ma la ROM del sistema parte da FC0000 (e da F80000 nei sistemi con 512KB di ROM). :D
La soluzione che hanno adottato gli ingegneri della Commodore è stata quella di mappare la ROM all’indirizzo 000000 al reset, in modo da poter effettuare il boot, per poi farla sparire subito dopo settando il bit di un registro di uno dei due CIA (se non ricordo male).
Il tutto per avere l’indirizzo 000000 libero da usare per la (chip) RAM, ma così facendo hanno appioppato agli Amiga gli stessi problemi dei PC, con una memory map abbastanza castrante (visto che nella memoria alta c’hanno infilato, appunto, la ROM e l’I/O).
Comunque sia continuiamo a non arrivare a capo della faccenda.
Perchè scambiare di posizione i due blocchi che al di fuori dei limiti del 8086 avrebbe portato problemi anche nelle evoluzioni successive ?
Continuo ad essere dell’idea che la scelta è stata decisa a tavolino con l’intento di evitare che i pc xt potessero in qualche modo fare concorrenza alla linea dei mainframe o anche solo degli AS* S/*
Pensiamoci un momento bene: siamo alla fine degli anni 70 all’interno dei lab IBM, sti qua vogliono costruire il primo Personal Computer però non hanno un’idea precisa di cosa voglia dire quel personal. A quei tempi nessuno si sarebbe immaginato che la gente avrebbe speso milioni per andare su facebook, youtube, scrivere il blog e cazzeggiare.
L’idea di “personal” era quindi di staccare su ogni scrivania un pezzo della potenza del mainframe centrale per fargli elaborare le cose che prima passavano dal sistemone e qui nasce il problema, la paura che tanti XT collegati insieme potessero sostituire il bestione (come del resto è stato nel corso degli anni, al giorno d’oggi nessuno affitterebbe un mainframe per archiviare la contabilità e fare i bilanci). Adesso non so se ai tempi c’era già l’idea di cluster attraverso la rete come potremmo fare oggi con cose come i Beowulf ma forse si temeva una possibilità di quel tipo.
In un ipotetico futuro saremmo quindi giunti che invece di affittare/comprare un macchinone da centinaia di milioni di lire dei tempi avremmo tenuto un xt su ogni scrivania, un cavo ed avremmo fatto lo stesso lavoro.
Da qui nascono allora tutta una serie di limitazioni.
La ram “a tappo” avrebbe impedito al sistemino di elaborare quantitativi troppo elevati di dati anche se questa fosse stata espansa.
Il sistema operativo, perchè ibm non ne ha scritto uno in casa ed ha scelto il dos ?
Aveva paura che parte della sua esperienza nella realizzazione di os per mainframe sarebbe finita nei piccoli pc creando dei potenziali concorrenti ? Strano che non abbia puntato neanche al cp/m: solo questione di soldi come si favoleggia o forse dal momento che il cp/m era visto come “professionalizzante” ed era utilizzato su molti minicomputer poteva sembrare una minaccia sul lungo periodo ?
Se i cloni non avessero preso il largo avremo visto ibm comportarsi come apple, costantemente impegnata a chiudere le porte ai sviluppatori che non sono interessati a piegarsi a creare iFart e quindi niente dos extender ?
Immagina un S/36: sarebbe stato tanto difficile adattare un XT per fare lo stesso lavoro ?
Bus di espansione non mancavano, velocità di elaborazione simile, insomma l’idea di piazzarci un po’ di terminali seriali ci poteva stare ma così si finiva per deprezzare ed uccidere il mercato degli AS/400.
Certe scelte sono state probabilmente meno ragionate, in termini di sviluppi futuri, di quanto si possa immaginare.
E’ anzitutto certo che ben pochi potessero immaginare allora tutto quello che ne sarebbe seguito, come qualcuno che un giorno si fosse messo a gestire GiB di dati su macchine d’uso “personale”.
Anche in tempi più recenti si è spesso continuato a /sottovalutare/ il fattore di crescita dei dati elaborati, come nei limiti di allocazione software di certi sistemi operativi (finanche in Windows 3.1), oppure nel ritardo a sviluppare nuovi chip (vedi la necessità d’inventare il PAE su processori a 32 bit, prima di passare ai 48/64 bit d’indirizzamento fisico).
Tornando alla /casualità/ della progettazione, ovvero al modo selvaggio e poco organico in cui sono stati sviluppati certi sistemi, faccio un altro esempio, molto significativo.
Prendete ad esempio le tastiere di PC XT e PC AT, che ad un certo punto hanno subito un cambiamento radicale: perché è avvenuto?
In fondo la codifica poteva rimanere la stessa, aggiungendo solo i nuovi tasti. Non solo è stata stravolta, senza un’apparente chiarezza di ragionamento, ma ad alcuni tasti sono assegnati codici da 1 byte, ad altri di 2 byte, e a due tasti persino una sequenza di 4 e 8 byte! Ma se perfino la codifica Unicode riesce a tenere in 2 byte le codifiche di tutti i caratteri di tutti gli alfabeti del mondo, com’è possibile che una tastiera (solitamente sotto i 256 tasti, indipendenti dalla lingua, ma identificati per posizione) debba necessitare di sequenze così tanto complesse?
Evidentemente non c’è alcuna soluzione razionale, e allo stesso modo si può vedere la struttura di memoria di certi sistemi, guarda caso sviluppati dalla stessa azienda.
@ D
La teoria che esprimi su una volontà consapevole di limitare il PC in effetti è del tutto coerente con l’approccio di IBM al PC (basti pensare ai wait state introdotti nella memoria del PC/AT per rallentarlo, poi tolti nel PC/XT 286 che quindi andava quasi allo stesso modo, ma anche pensare al ruolo di controllore che doveva assumere Topview).
Per quanto abbia senso, gli elementi in evidenza non sono sufficienti a formulare nulla più di un sospetto, ma sarebbe di certo interessante scavare più a fondo, nel caso molto difficile in cui si potessero trovare “gole profonde” disposte a un riscontro nella Intel dell’epoca – che avrebbe dovuto partecipare attivamente alla “castrazione”, contro il suo stesso interesse.
Un tentativo lo potremmo fare, perlomeno per avere un parere: credo che con un po’ di fortuna potremmo scrivere a Tom Rolander della fu DRi, che credo abbia esperienza diretta di molti passaggi cruciali della vicenda. Che ne dici Cesare, proviamo? :-)
@D: dell’evoluzione successiva per ovvi motivi all’epoca non se ne sapeva proprio nulla.
Comunque il caso dell’Amiga è eclatante: se si fossero invertiti i blocchi, non ci sarebbe stato alcun problema a far espandere linearmente lo spazio per la memoria.
Non credo, comunque, a una progettazione a tavolino “interessata”. A me sembra proprio una cosa fatta coi piedi, senza pensarci sù.
“senza pensarci sù.”
Si ma da IBM ? Non stiamo parlando degli ultimi arrivati, di inesperti che fino al giorno prima investivano in campi di cotone o pelletteria ed un giorno hanno scoperto l’informatica come le varie coleco, mattel, commodore…
Secondo me volevano riempire un nuovo segmento di mercato (dato da quelle piccole aziende ed uffici non interessati ad un CED personale) e dati i tempi, non potendo prevedere certe evoluzioni (tempi in cui il concetto di gui e mouse erano limitati ai confini del parc) hanno temuto di sovrapporre le fascie. Col senno di poi la cosa può apparire strana del resto nessuno si sognerebbe di usare un iSeries per andare su youtube o di far fare il lavoro di quella macchina ad un macinino con linux + mysql o windows + odbc.
“D”, non ti seccare, ma tu hai visto in che modo è stata mappata la memoria? Ma, soprattutto, in che modo sono strutturati i registri delle schede video che hanno progettato gli ingegneri di IBM? E come si programmavano?
A me vien voglia di imitare Vlad Tepes quando ci penso…
Non è che un ingegnere, soltanto perché lavora alla IBM, debba sempre progettare le cose “per bene”.
In genere l’obiettivo è di far funzionare il tutto il prima possibile, perché i soldi degli investimenti in ricerca & sviluppo devono rientrare.
Spiegami quale insana logica porta a dire “dal momento che il bios deve caricarsi prima dell’os e dei programmi, allora lo posiziono per ultimo nella mappatura della memoria”.
E’ una cosa perfettamente banale per chiunque, perfino per fior di “programmatori” scadenti moderni, figuriamoci per quella gente là.
Qual’è l’utilità funzionale di una simile scelta se non quella commerciale di creare un sistema volutamente castrato.
Trovo veramente difficile credere che il progetto xt sia stato lasciato in mano a dei dilettanti di cotanto infimo livello.
Forse per capire meglio come stanno le cose sarebbe buona cosa cercare notizie sui predecessori del AS/400 (S/36 S/38) e valutare se effettivamente erano su un altro pianeta rispetto l’XT o se c’erano buone possibilità di sostituirli con una spesa nettamente più contenuta.
Posso solo dirti che l’informatica è piena di cose stupide, che ritrovi anche in prodotti realizzati da gente blasonata. :D
Cercando adesso informazioni sugli AS e guardando solo al S/36 (il più piccolo se 300kg si possono definire pochi) devo dire che tra questa macchina e l’xt ci passa un abisso (la ram ad esempio è espandibile fino a 7MB) però la wiki non spiega se il sistema ha subito evoluzioni o se le prime versioni dovevano accontentarsi di un’espandibilità minore tale tale da poter portare a pensare che gli xt potessero scavalcarle.
Infatti non c’è proprio paragone: erano due mondi completamente diversi, e non era pensabile che si potessero sovrapporre (com’è, invece, oggi, dove l’architettura x86 stradomina anche nel mercato dei server). ;)
Non è pensabile però qualcosa ha portato a farlo.
L’XT possiede 8 slot isa: dato per scontato che sarebbe stato possibile montare delle porte seriali in quantità per collegarci dei terminali, sarebbe stato possibile anche espanderci la ram come si faceva con le zorro su amiga ?
La ram di base era da 128KB esattamente come nel S/36, potenza e velocità se la giocavano (da 2 a 8MHZ per il S/36, 4,77MHz per XT), hard disk 10MB l’XT (non facilmente espandibile per limitazioni del dos) contro tagli che partivano da 30 a salire.
A prima vista non ci sarebbe stata storia. Ma se fosse stato possibile espandere l’XT ai limiti previsti dal hardware, senza quelli artificiosi quali wait state e memoria a tappo, se qualcuno gli avesse scritto sopra un os tipo AS, avrebbe potuto esserci un confronto tale da segare la fascia entry degli AS stessi ?
Perchè un conto è prendere un S/36 pompato al limite, un altro è prendere il sistema di base ed espanderlo nel tempo.
Al di là di possibili teorie del complotto, che rimangono comunque da dimostrare, io una spiegazione me la do. Alla fine degli anni ’70, quando è stato sviluppato l’8086, ogni CPU era più o meno una storia a sé.
I processori allora in fase di studio o già rilasciati (Z80, 6800, 6502, 8085, 8086, 68000) erano sviluppati più o meno in direzione indipendente.
Certo, 8086 porta in eredità scelte fatte con l’8085 (che a sua volta discende dall’8080), ma è dopo l’8086 che la retrocompatibilità assume quel potere “ricattatorio” rispetto a un ecosistema software di massiccia diffusione ma piuttosto lento nell’adeguarsi allo sviluppo di nuove CPU.
Credo che nelle scelte conservative fatte al passaggio da 8086 e 80286 e 80386, abbia inciso significamente il fatto che, nel periodo 1978(8086) – 1982(286), sia avvenuto il boom del PC, che in qualche modo ha “congelato” le specifiche su cui poggiava la mole di software nel frattempo sviluppatasi.
Interrompere la catena della retrocompatibilità con il 286 (portando la UMA all’inizio della memoria per esempio) avrebbe significato destabilizzare la piattaforma e lasciare spazio ai concorrenti.
Queste congiunture ovviamente hanno fatto gioco di IBM, per la quale l’evoluzione del PC era bene che avvenisse lentamente. Dopotutto però hanno fatto il gioco anche di MS, la quale, se x86 avesse perso terreno interrompendo la retrocompatibilità, avrebbe dovuto muoversi in un mercato più frammentato.
Concordo pienamente con la tua analisi.
@D: non è l’hardware più o meno simile che potrebbe accomunare le due macchine. Anche perché le similitudini riguardano soltanto pochi aspetti, e non altri critici per il settore dei server.
Le CPU che montavano le serie S36 erano decisamente diverse. L’8086 era limitato dal canonico 1MB di ram, e per andare oltre bisogna ricorrere agli accrocchi di cui parlava l’articolo.
Inoltre era una CPU molto lenta e non supportava in hardware virtualizzazione et similia, che in quell’ambiente erano, invece, fondamentali.
Insomma, non c’era proprio paragone né da impensierire IBM e i suoi server.
Poi l’XT venne dopo il (primo) PC, mentre quest’ultimo non aveva nemmeno il supporto per gli hard disk…
Dimentichi una cosa: ieri come oggi si trovano gli imbecilli convinti di sostituire sistemi studiati appositamente per un lavoro con altri più generalisti e di fronte alla possibilità di risparmiare denaro gli “imprenditori” non si preoccupano di altro. SDSM insegna…
Il limite del mega di ram sarebbe stato aggirabile con un sistema di bankswitching se non ci fosse stato il tappo a complicare le cose e comunque alla fine un S/36 non avrebbe potuto sostituirlo ma lo avrebbe insediato nelle fascie basse.
Se il cliente medio di quel sistema, lo comperava in versione base e poi lo espandeva, ci sarebbero state buone possibilità di fare del danno
“In genere l’obiettivo è di far funzionare il tutto il prima possibile, perché i soldi degli investimenti in ricerca & sviluppo devono rientrare.”
La prima cosa in effetti è stato il time-constraint (time to market di circa 1 anno), per il resto Paul Ceruzzi in “A History of Modern Computing” afferma che (più che plausibile) la scelta di Intel e Microsoft (così come l’impiego di altro hardware off the shelf) è stata dovuta anche al fatto che al tempo IBM operava sotto la lente di ingrandimento dell’antitrust, per cui un sistema proprietario e chiuso avrebbe anche potuto creare dei grossi problemi legali.
@ Marco
L’opzione più accreditata fra le mie fonti riguardo al rilascio del PC IBM sotto specifiche aperte e HW da scaffale, riguarda il fatto che IBM – azienda tradizionalmente elefantiaca nelle sue decisioni – sia stata travolta dalla rivoluzione PC, che è iniziata fuori da Armonk e in un certo senso (come sarebbe divenuto chiaro a breve) è avvenuta al contro i suoi interessi.
Per contenere il time to market la costruzione di un sistema con componenti disponibili e il ricorso ad OS di terze parti, rappresentò praticamente un imperativo per Big Blue.
Di certo l’antitrust avrebbe avuto ragione di indagare IBM riguardo al suo business mainframe, ma non mi spiego come avrebbe potuto accusarla di posizione dominante in un mercato dal quale, fino a fine anni ’70 (ossia mentre l’Apple II imperava e IBM correva ai ripari), era totalmente assente.
“Per contenere il time to market la costruzione di un sistema con componenti disponibili e il ricorso ad OS di terze parti, rappresentò praticamente un imperativo per Big Blue.”
Beh ma mi pare che avesse già parecchia roba sviluppata in casa, fra cui la serie 5100.
OS ne sviluppava già da decenni, non vedo perché non avrebbero potuto adottare un port di DOS/360: del resto QDOS è stato sviluppato in poco tempo da una sola persona (Tim Paterson) e contava circa 4K linee di codice, lo stesso dicasi per CP/M.
“Di certo l’antitrust avrebbe avuto ragione di indagare IBM riguardo al suo business mainframe”
E’ un’ipotesi infatti. Probabilmente un giudice avrebbe visto un PC chiuso e tutto IBM come un’ennesimo computer + SO completamente controllato da una recidiva Big Blue, che per la cronaca era già stata obbligata all’unbundling di vari software per mainframes.
“ossia mentre l’Apple II imperava”
Apple II non ha mai imperato nelle vendite, al limite è riuscita a ritagliarsi una buona fetta del mercato “small office” con Visicalc:
http://arstechnica.com/old/content/2005/12/total-share.ars/4
“azienda tradizionalmente elefantiaca nelle sue decisioni”
Vero, ma bisogna considerare che la storia era già stata vissuta con i mini qualche anno prima. E se pensiamo al grosso della crescita del mercato PC, IBM è entrata in gioco relativamente presto.
@ Marco
5100 era sviluppato attorno a una CPU proprietaria di IBM mi pare, di 4 anni precedente all’8088 che è poi finito nel 5150, e nasceva con una vocazione da “mainframe in miniatura”, a partire dall’APL. Non so quanto sarebbe stato facile per IBM adattare 5100 ad un progetto PC.
Anche qui non sono certo che la trasportabilità degli OS che IBM sviluppava da decenni fosse semplice o rapida verso una macchina “general purpose”. Le fonti che ho consultato parlano di una necessità di ricorrere a fornitori esterni per evitare che il progetto passasse per le lungaggini che contraddistinguevano i processi decisionali di Big Blue.
Non sono molto convinto da questa ipotesi, particolarmente pensando al fatto che tutte le piattaforme alternative all’epoca circolanti, a parte il denominatore abbastanza comune del 6502, erano un mondo a sé stante. Chiedere ad IBM, in nome di problemi che riguardavano tutt’altra fascia di prodotti, di andare in controtendenza su un mercato peraltro ancora embrionale, non so quanto senso avrebbe avuto. Per carità, sempre di ipotesi parliamo.
Mi riferivo a fine anni ’70, un periodo non coperto da quel grafico ma da uno precedente (http://arstechnica.com/old/content/2005/12/total-share.ars/3), dal quale si desume che, al netto di Atari e TRS (macchine posizionate diversamente rispetto al II e al PET) e della pletora di sistemi componenti la fascia “other”, Apple deteneva una quota di mercato significativa (pari al PET) prima di Visicalc, che ovviamente rappresentò un eccezionale moltiplicatore per le vendite di Apple II e di computer in generale.
http://www.jeremyreimer.com/postman/node/329
[…] In 1980, Apple Computer Inc.?s sales totaled about $200 million, compared with Tandy Corp.?s approximately $175 million and Commodore Business Machines Inc.?s approximately $40 million. (Source: Robert Metz, I.B.M. Threat to Apple, The New York Times, Sept. 2, 1981)
Worldwide, some 500,000 computers priced less than $5,000 were sold in 1980 at a total value of $730 million, according to Dataquest Inc. […]
Non è quindi corretto dire che imperasse, ma che fosse uno dei modelli singoli più venduti prima del lancio del PC, è un’affermazione abbastanza corretta.
Sempre da Ars:
In 1981 the company sold 210,000 units, leaving the PET in the dust and nearly equaling the TRS-80’s numbers.
D> paragonare l’xt e l’s36 con la velocita’ di clock e’ sbagliato.
nei sistemi s* e as400 la cosa fondamentale non e’ la velocita’ della cpu, ma quella dei bus.
esempio classico dei sistemi midrange as400: compilazione fatture.
accedo al db, leggo le righe del tal cliente e le porto in memoria.
leggo i codici e vado di nuovo sul db a leggere il prezzo dell’articolo in questione e lo metto in ram. moltiplico l’importo con la quantita’, ed eseguo la stessa cosa per tutte le righe, scrivendo poi su db la riga di fattura.
come vedi tanti accessi su disco e ram, e pochi calcoli.
oggi si producono pc di fascia bassissima che hanno una potenza in mips che e’ molto maggiore di un sistema Iseries di fascia alta, ma se facessi girare gli stessi programmi su un pc, con centinaia di terminali connessi contemporaneamente, otterresti prestazioni ridicole.
comunque anche io dico che hanno volutamente incasinato la cosa per evitare sovrapposizioni.
inoltre in quegli anni le architetture nascevano e morivano in 4-6 anni (ben poche le eccezioni, ad esempio c64) e forse credevano di poter testare il mercato, passando poi a un’architettura piu’ robusta ed efficiente quando sarebbe uscito un 32 bit. cosi’ non e’ stato.
@ Cesare di Mauro
Caro Cesare, ti sbagli nel dire che non si usavano più di una scheda grafica su un PC.
http://it.wikipedia.org/wiki/Video_Graphics_Array
“A causa dell’uso di mappature differenti per modalità differenti, è possibile avere una scheda video monocromatica, e una a colori come la VGA, EGA, o CGA contemporaneamente installate su una macchina. All’inizio degli anni ’80, questa era una pratica diffusa, per visualizzare ad esempio un foglio di calcolo di Lotus 1-2-3 in testo ad alta risoluzione su un display monocromatico e i grafici associati su una schermata CGA a bassa risoluzione. Più tardi molti programmatori, utilizzarono tale configurazione con le schede monocromatiche per visualizzare informazioni di debug, mentre sull’altra scheda era in esecuzione un programma grafico, In particolare il debugger CodeView di Microsoft poteva lavorare in una configurazione dual-monitor per eseguire il debug di windows.”
Come puoi vedere a pagina 86 del manuale della VGA ( http://www.mcamafia.de/pdf/ibm_vgaxga_trm2.pdf ), è possibile selezionare quale segmento utilizzare e la sua ampiezza tramite i bit 3 e 2.
Selezionando la prima o la terza configurazione c’è un evidente conflitto con le schede monocromatiche, che utilizzano il segmento B0000.
Pertanto l’utilizzo di una VGA (ma lo stesso registro è presente nell’EGA, per cui vale lo stesso) non è possibile, se non limitandosi a utilizzare il BIOS o comunque a non toccare questo registro.
E’ possibile, invece, utilizzare una scheda monocromatica e una CGA assieme senza alcun problema, ma non ricordavo che fosse stato fatto.