INMOS Transputer: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
m r2.6.4) (Bot: Aggiungo: kk:Транспьютер
FrescoBot (discussione | contributi)
m Bot: sintassi e spaziatura dei link e modifiche minori
Riga 9:
Un effetto collaterale di molte architetture ''multitasking'' è che spesso permette di eseguire i processi su CPU fisicamente differenti, nel qual caso il processo è noto come ''[[multiprocessing]]''. Una CPU a basso costo, pensata in quest'ottica, avrebbe permesso di aumentare la velocità di calcolo di una macchina aggiungendo altri processori simili, scelta potenzialmente molto più economica di una basata su un singolo e più potente processore.
 
== Design==
Il Transputer ('''Trans'''istor Com'''puter''') fu il primo microprocessore ad uso generico progettato specificatamente per essere usato in sistemi di calcolo parallelo. L'obiettivo era di produrre una famiglia di chip, limitati in costo e potenza, che avrebbero potuto poi essere connessi tra loro per formare un computer completo. Il nome era stato scelto per indicare il ruolo che il singolo Transputer avrebbe avuto: molti di loro sarebbero stati usati come "mattoni di base", proprio come i transistor lo erano stati precedentemente.
 
Riga 30:
 
=== Programmazione ad alto livello ===
Per la programmazione dei transputer, la INMOS aveva progettato un linguaggio apposito, ispirato al paradigma di comunicazione a passaggio di messaggi [[Communicating Sequential Processes|CSP]] (Communicating Sequential Processes) ideato dal britannico [[C. A. R. Hoare]] e chiamato [[linguaggio di programmazione Occam|Occam]]. In effetti è più corretto dire che il Transputer fu progettato specificatamente per eseguire codice Occam, mentre la maggior parte dei processori CISC dell'epoca, e successivi, non erano (con l'eccezione di progetti come l' [[Intel iAPX 432|iAPX 432]] dell' [[Intel]]) progettati per eseguire direttamente codice in [[Pascal (linguaggio)|Pascal]], [[C (linguaggio)|C]] o [[Ada(linguaggio)|Ada]]. L'Occam supportava lo sviluppo di applicazioni divise in più processi e spesso la semplice scrittura di un programma in Occam risultava un'applicazione di questo tipo. Con il supporto per i task e le comunicazioni integrati nel chip e il linguaggio di programmazione che vi interagiva direttamente, scrivere il codice per cose come controllare un device controller divenne una banalità: anche il codice più semplice poteva controllare le porte seriali per l'I/O, e si sarebbe automaticamente messo in pausa in assenza di dati.
 
== Implementazioni ==