MokaByte Numero 15 - Gennaio 1998
		JavaChip
	di Ivan  Bazzi	Dopo l'introduzione del mese scorso vediamo alcune implementazioni di Chip Java.

JEM1: il javachip.
Il primo di cui si tratta è l'approccio puro cioè l'uso di un vero javachip che realizzi la specifica picoJava: il JEM1 della Rockwell Avionics & Comunication. Inizialmente rivolto a sistemi di navigazione aerea si valuterà la possibilità di commercializzarlo come componente per sistemi di telecomunicazioni. La scelta del javaChip è giustificato dalla possibilità di fornire aggiornamenti del sistema mentre è in funzione. Ad esempio, con le possibilità di connessione offerte da java è pensabile che un aeroplano, quando ancora in volo, ottenga un aggiornamento, di dati o di funzioni, tramite collegamento satellitare.
Ora qualche dato tecnico. Alla frequenza di clock di 50 MHz, realizzato con una tecnologia CMOS a 0,5 micron, il core è limitato in una regione di 6 millimetri quadrati. Oltre al core il chip integra un controllore degli interrupt, due timer programmabili, supporto per bus esterni da 32, 16 e 8 bit, e l'interfaccia per la tecnologia di test JTAG.
Oltre al set di istruzioni standard Java, JEM1 realizza funzionalità estese (extended byte code) per permettere di accedere a parti specifiche del processore consentendo il controllo a basso livello sui registri, le cache e le operazioni di caricamento e memorizzazione. I portavoce Rockwell assicurano che questo codice esteso rimane trasparente ai programmatori di applicazioni java. Le così dette java Subroutine dovrebbero tradurre direttamente chiamate java standard in codice esteso del JEM1. insomma, il codice esteso può limitarsi alla programmazione del kernel o dei device driver.

Quindi, concludendo, in questo caso l'uso di un javachip è giustificato dalle caratteristiche del linguaggio (facile sviluppo, aggiornamento "on the fly") unito alle necessità di performance, mirate più ad una possibile commercializzazione del JEM1. Per Rockwell le specifiche di progetto miravano soprattutto ad un basso consumo: il processore consuma in media 60 mW e mai più di 100 mW.
 

PCS1000: l'architettura a stack.
Il processore JEM1 è il risultato della convergenza dell'architettura AAMP (Advanced Architecture MicroProcessor) di Rockwell verso le specifiche picoJava. Convergenza resa possibile da licenze incrociate tra le due case. E' interessante notare che l'architettura AAMP era basata su componenti da assemblare (off the shelf, come dicono gli americani). I ricercatori di Rokwell, durante lo sviluppo di AAMP si sono accorti della enorme somiglianza con le specifiche picoJava di Sun rese pubbliche all'epoca. Le macchine a stack sono state realizzate sin dagli anni 60. Un'altra architettura a stack a zero operandi, come il forth, ha riscosso simpatie come jave.  Queste simpatie si sono rivelate nel news group dedicato ai sistemi embedded (comp.arch.embedded) dove ci si è chiesto come mai processori a stack come quelli basati sul forth non abbiano avuto altrettanta popolarità di java. Questo riferimento alle macchine forth sarà chiaro immediatamente.
Sun, nei suoi documenti, propone il modello di scelta del progettista biforcato: 1. la JVM (Java Virtual Machine) su una CPU general purpose con supporto di un JIT (Just In Time compiler) o 2. esecuzione diretta del bytecode tramite un javaChip. In effetti c'è una proposta alternativa da Patriotic Scientific. Benché il PCS1000 sia una macchina RISC a 32 bit non mi sembra trascurabile il fatto che sia basato su una architettura a stack a zero operandi, fortemente influenzato dai processori forth. Molte funzioni del PCS1000 hanno una diretta esecuzione  delle istruzioni JVM. Così il PCS1000 può eseguire molte istruzioni java in un solo ciclo di clock.
Un esempio tipico è l'istruzione IADD della JVM che per il PCS1000 è semplicemente l'istruzione add, mentre ad esempio CPU come SPARC, MIPS o PowerPC hanno bisogno di sei istruzioni; 80x86 e Pentium sette istruzioni e quattro istruzioni per il 680x0. Naturalmente questo ha un significato relativo. Per il calcolo delle prestazioni di un a CPU vanno tenute in considerazione diverse variabili: la pipeline, il flusso del codice e numero di pagine perdute nella cache. Però in linea di principio, la cosa ha un senso.
Il PCS1000 è stato progettato principalmente con l'idea del basso costo. Per soddisfare tale specifica non integra cache dati, preferendo usare registri appositi per la stessa funzionalità. Non ha pipeline né è superscalare. A fronte di questo aumenta la cura che si dovrà porre per la progettazione del sistema.  Unico vantaggio possibile è il rapporto prezzo/prestazioni, di cui però non si può dire ancora nulla mancando notizie per i javachip.

M32R/D: il sistema sul chip.
Un approccio completamente diverso ma molto interessante all'uso della tecnologia java all'interno dei sistemi embedded e particolarmente rivolta a quelli che saranno i nuovi elettrodomestici chiamati in inglese Information Appliances, che tradurrei elettrodomestici informativi (o dell'informazione), è quello della Mitsubishi che suggerisce l'uso del processore M32RD. Si tratta, in effetti, di un sistema integrato in un chip. Sposta la complessità di un progetto embedded nella semplicità di un sistema costituito da uno o due componenti: l'M32R/D, un ASIC per I/O e una ROM. Non si tratta di un processore java, esso è un microprocessore con integrata una DRAM grazie alla tecnologia eRAM Mitsuibishi. La serie di M32RD contengono 2 MB di DRAM. Il core è una macchina RISC a 32 bit con cache da 2 Kbyte, un controllore di memoria e circuiti periferici. Il sistema permette due tipi di caching: uno sfrutta la DRAM integrata, l'altro sfrutta una ROM esterna. Il primo tipo viene utilizzato per quei sistemi che usano la DRAM come memoria principale. Il caching esterno sulla ROM è usato per la memorizzazione di istruzioni, in questo modo il sistema legge il programma e usa la DRAM come memoria per i dati (in soma la soluzione tradizionale per sistemi embedded).
In un sistema embedded, solitamente il software viene memorizzato in una EPROM. Gli aggiornamenti vengono fatti sostituendola EPROM, inserita in una scheda apposita. Con l'M32R/D la parte invariante può essere memorizzata nella ROM il resto dell'applicazione potrebbe venire scaricato dalla rete e contenuto nella DRAM dove potrebbe venire sostituito giornalmente se necessario.
L'abbinamento di questo chip con la tecnologia java, in particolare le Embedded Java API e le Personal Java API, consente una buona flessibilità per la progettazione di sistemi quali telefoni con possibilità di navigazione internet, sistemi di navigazione automobilistica e sistemi per l'automazione domestica.
Ricordo che Embedded Java è progettata per sistemi a 32 e 64 bit, comprende la JVM e un insieme di classi che richiedono approssimativamente 512 Kbyte di spazio di memoria. Comprende  moduli opzionali per venire incontro alle necessità specifiche dell'applicazione finale.
Personal Java è un API per applicazioni con capacità di connessine alla rete che escludono le classi java più complesse come JDBC, RMI che hanno senso in ambito aziendale. Includendo però classi per la gestione di dispositivi I/O come telecomandi all'infrarosso, display a cristalli liquidi e simili.
I 2 Megabyte di memoria integrata consentono a quei sistemi che incorporino l'M32R/D una risposta quasi in tempo reale a differenza di sistemi tradizionali che, per contenere il costo, sono progettati in modo da avere poca memoria. Una tale scarsità di memoria significherebbe scarse prestazioni per un'applicazione java.
Ed infine, prima di concludere, qualche dato tecnico.
Il chip ha una frequenza di lavoro di 100 MHz, è dotato di un bus interno a 128 bit che connette la CPU alla DRAM e la memoria cache, consentendo una comunicazione dei dati molto veloce all'interno del M32RD. La CPU ed il bus operano a 66.6 MHz. Tutte le funzioni necessarie per ottenere un sistema ad alte prestazioni sono state implementate all'interno dell'M32RD. Essendo un sistema su chip queste alte prestazioni conducono ad un costo totale di sistema più basso.
Un altro vantaggio dell'integrazione della DRAM è il contenimento della dissipazione di energia.
 

CONCLUSIONI
Un modo tradizionale di affrontare il mercato delle applicazioni embedded è quello di dividerlo in due categorie di prodotto. Un prodotto piccolo, semplice, possibilmente da tenere in mano (handheld) oppure con un certo grado di complessità. Nel primo caso un RISC sarà sempre più conveniente sia dal punto di vista del costo che dall'energia impiegata. Nel secondo caso sono necessari processori di capacità paragonabili a quelle impiegate nei personal computer. In nessuno dei due casi c'è la necessita di dover utilizzare un java processor. Cionondimeno va considerato che vi è sempre più una richiesta di controllori a 32 bit ed inoltre stanno producendosi i già citati Information Appliances che hanno caratteristiche particolari e la cui complessità può richiedere un processore a mezzo tra i due estremi tradizionali, oltre a particolari capacità di connessione e di interfaccia.
Il successo dei javaChips può essere legato anche all'ubiquità del linguaggio. Se questo è sufficientemente distribuito tra i produttori di apparecchiature embedded, il cliente per aggiornamenti o altro potrebbe non sentirsi particolarmente vincolato al sistema. Cambia solo il software.
Inoltre, come suggerisce lo stesso M32RD non è detto che si debbano produrre soluzioni pure java, ad esempio si hanno particolari esigenze di interfaccia con l'utente (ad esempio un chiosco) java è sicuramente più flessibile delle soluzioni tradizionali.
 
 
 

	MokaByte Web  1998 - www.mokabyte.it MokaByte ricerca nuovi collaboratori.  Chi volesse mettersi in contatto con noi può farlo scrivendo a mokainfo@mokabyte.it