Newsgroup: it.comp.java
Titolo: Di bytecode, Java ed altri linguaggi

Innanzitutto, ciao a tutto il NG.
E' dai tempi del mio esame di programmazione che non lurko il NG;
scusate quindi se piombo qui dal nulla ponendo domande tra l'altro di
ordine puramente accademico (o quasi).
Tutto prende il via da questo post di Punto Informatico
(
http://punto-informatico.it/pol.asp?mid=207450&fid=40548
) e dal thread
conseguente.
Venendo al sodo, la mia domanda e':
Essendo il Bytecode di java, in pratica, un assembler (tant'e' che
esistono processori in grado di far girare nativamente bytecode, se non
erro sempre progettate da Sun), sarebbe possibile, teoricamente, creare
un compilatore, ad esempio, C che generi invece che codice X86 bytecode
java? o la struttura del bytecode e' troppo ottimizzata per java per
ottenere prestazioni decenti con altri linguaggi? oppure vi sono
problemi di altro tipo?
Un grosso grazie anticipato a chiunque sapra' rispondere a questo mio
dubbio.
Saluti
Un Corrado che a volte la fantasia...
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

Proprio ieri ho buttato via un raccoglitore di Byte (una rivista 
americana che ha chiuso parecchio tempo fa) fra cui uno dedicato ai 
processori Java, macchine con il bytecode come formato binario nativo.
Sono stati popolari nel '97-'98 poi sono spariti completamente.
Il fatto che il byte code non sia arrivato al silicio mi fa sospettare 
che ci sia qualche buco nella procettazione della VM, cioč che non sia 
affato general purpose, ma mirato specificamente a Java.
Mi piacerebbe sentire qualche compilatorista esperto sull'argomento.

 che ci sia qualche buco nella procettazione della VM, cioè che non sia


 > Sono stati popolari nel '97-'98 poi sono spariti completamente.
Penso che il motivo sia piu' economico che tecnico. Lo sviluppo di un
microprocessore non e' una attivita' banale. Si parla del '98 come
fosse un secolo fa, e forse cosi' e' per gli strumenti software, ma
per il silicio cosa volete che siano 3 o 4 anni di sviluppo ?
Praticamente il tempo necessario per dire "si puo' fare" o "non si
puo' fare".
saluti
Luca

 puo' fare".
A maggior ragione per un processore che deve interpretare il bytecode
Java, imho, proprio per questione tecniche.
Andrea

Michele Costabile <ple...@no.spam> wrote in news:3D0DF659...@no.spam:

Non e' una questione tecnologica, ma di costi e massa critica della 
produzione di chip, per macchine con target consumer. Semplicemente, costa 
meno ed e' piu' sicuro usare VM su macchine intel che non cercare di 
vendere nuovo hardware incompatibile ai consumatori.


vendere nuovo hardware incompatibile ai consumatori.
infatti ... buttare fuori un nuovo processore e pretendere che
l'utente medio lo vada a comprare preferendolo ad un Intel o AMD che
sia č un suicidio .....
giusto una domanda ..... ma il bytecode cos'č?
Max

 Max
O_o! Il cuore di Java. Cioè se io compilo in codice
nativo il compilatore mi darà un eseguibile con una
struttura interna, leggi instruzioni macchina, tali che
solo quella piattaforma riesce ad eseguirlo. Mentre
la forza di Java è nella JVM (Java Virtual Machine)
che legge il ByteCode. Il ByteCode sono una sequenza
di istruzioni non legati ha una piattaforma, Linux, Windows..,
ma bensì ha un computer virtuale, la JVM appunto, che funge
da intermediario tra il tuo programma e l'OS sottostante,
infatti se a un programma Java gli togli la JVM il file non
ti girerà su nessuna piattaforma perchè, diciamo, che gli
manca la sua. Un po' come tentare di far girare Microsoft
Office sotto Linux :-). Traducendo la JVM su varie piattaforme
hai il codice portabile e indipendente dalla piattaforma.
Ciò è la croce e delizia di Java. Croce perchè rallenata di
molto i programmi complessi, delizia perche' non devi preccuparti
molto del tuo codice, perchè esso funzionerà bene su molte
piattaforme. Bhè spero di essere stato chiaro, se non lo sono
stato, chiedi pure. Se ho detto delle castronerie accetto le critiche ;-).
Salutoni
Giacomo Succi

Già...
faccio giusto un'osservazione:
non ho particolari competenze della piattaforma .NET, ma per quanto ho visto
ci sono varie similitudini con Java. Uno degli aspetti simili è l'
intermediate language (IL) un parallelo al bytecode di Java. Io penso che se
Microsoft comincerà a rendere i prossimi OS .NET enabled, non passerà molto
tempo prima di vedere processori che includono componenti per l'esecuzione
nativa di codice IL. Ora molte cose dipendono da quanto questo IL è ben
fatto o meno, in più penso che se non è così legato alla piattaforma win32
l' IL prima o poi verrà supportato in qualche modo anche da Linux e altri
OS, salvo limiti tecnologici o "posizioni politiche". Il fatto è che in una
certa misura MSFT è in grado di controllare anche la diffusione di una
tecnologia (vedi Internet Explorer), e limitarne un'altra (es. non c'è più
supporto per Java 2 in IE)...
Bisognerebbe vedere anche l'appoggio che .NET sta ottenendo. non conosco
molta gente che sviluppa già in .NET ma sto vedendo una quantità di libri
pubblicati che mi fanno pensare che stia prendendo piede.
Stiamo a vedere...
Luigi

 bytecode cos'č?
Il nome dell'assembly della JVM. Che in generale e' interpretato (o 
convertito al volo in assembly della piattaforma su cui una JVM sta 
girando), tranne appunto che nel caso di chip appositi, dove e' 
implementato direttametne in hardware o microcodice.


 Office sotto Linux :-).
Pare che ora ci si riesca.
http://www.codeweavers.com/products/office/supported_applications.php

 
http://www.codeweavers.com/products/office/supported_applications.php
O_O non ci posso credere! Bello ;-P.
Salutoni
Giacomo Succi

nativa di codice IL.
[CUT]
Non serve un processore che esegua nativamente MSIL (il nome 
ufficiale): semplicemente (allo stato attuale e AFAIK) non viene mai 
eseguito MSIL.
Cerco di sintetizzare.
In Java il JIT è un optional; importantissimo ma sempre un optional. 
Tanto che si può disabilitare, no?
Nell'attuale implementazione di .NET non esiste esecuzione senza previa 
traduzione in codice nativo (del processore).
Anzi PUOI pre-compilare tutto il tuo codice (ma non sei obbligato).
Forse con un esempio mi spiego meglio.
Scrivi il tuo sorgente nel linguaggio che preferisci (o quasi).
Compili il tuo sorgente con il corrispondente compilatore .NET e 
ottieni MSIL (ipotesi un exe).
Questo exe, oltre a IL, contiene un header "vecchio stile" che serve 
per caricare l'ambiente di runtime e che potrebbe sparire se/quando 
Windows riconoscerà direttamente .NET
Ora puoi eseguire il tuo programma: OGNI metodo, alla prima chiamata, 
viene JITtato (:-)) in codice nativo e inserito in una cache per... le 
prossime volte.
Oppure puoi fare una precompilazione di tutto il tuo exe (e ottieni di 
inserire in un repository un'immagine "nativa" del tuo exe) e allora 
anche la prima esecuzione sarà più rapida.
Se vuoi posso essere più preciso, ma non vorrei essere preso per un 
eretico :-D
HTH
-- 
Ciao
	Fabrizio C.

 eretico :-D
Nessuna eresia, nel nostro mestiere dobbiamo conoscere un po' di tutto.
Se non fosse per il modo di fare di alcuni tecnici MSFT, di cui ho visto
fare ironia su Java prima che esordisse .NET, e che continuano ancora a
farla dopo che la loro piattaforma è palesemente copiata... .NET mi starebbe
perfino simpatica.
.NET, io credo che prenderà piede, quindi meglio farci i conti, e non farne
una questione di religione. :-)
Luigi