Newsgroup: it.comp.java
Titolo: Endianity, puntatore a documentazione

Ieri ho  provato a cercare sia  su 
java.sun.com
 che su  altri siti, ma
non ho trovato  un qualcosa che mi garantisca  che le variabili intere
(da short a long) siano memorizzate in modo big endian.
Ho  trovato  solo  l'indicazione  che  i parametri  degli  opcode  del
bytecode vengono caricati sullo stack in modo big endian. Ora questo a
naso dovrebbe garantirmi  che se leggo 4 byte in un  int (che so 0xDE,
0xAD,  0xBE,  0xEF)  in  modo  big  endian  allora  il  confronto  per
uguaglianza con la costante 0xDEADBEEF dovrebbe valere true.
O mi sbaglio ?
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

Ieri ho  provato a cercare sia  su 
java.sun.com
 che su  altri siti, ma
non ho trovato  un qualcosa che mi garantisca  che le variabili intere
(da short a long) siano memorizzate in modo big endian.
Ho  trovato  solo  l'indicazione  che  i parametri  degli  opcode  del
bytecode vengono caricati sullo stack in modo big endian. Ora questo a
naso dovrebbe garantirmi  che se leggo 4 byte in un  int (che so 0xDE,
0xAD,  0xBE,  0xEF)  in  modo  big  endian  allora  il  confronto  per
uguaglianza con la costante 0xDEADBEEF dovrebbe valere true.
O mi sbaglio ?
Qualcuno ha un puntatore a della documentazione che dica in modo certo
"si,  puoi  affidarti  all'endianity  della JVM"  oppure  "meglio  non
affidarsi alla endianity della JVM" ?


 affidarsi alla endianity della JVM" ?
Ciao,
immagino tu cerchi una risposta meno banale di questa,
ma un dettaglio del genere non dovrebbe essere trasparente allo 
sviluppatore?
-- 
Emanuele Torrenti
Registered Linux User #409659

 sviluppatore?
Cercando ho trovato unapossibile risposta: passaggio di dati da e verso 
C/C++
prova con questa ricerca, sembrerebbe esserci qualcosa:
http://www.google.com/search?q=jvm+endianess+site%3Ajava.sun.com&btnG=Cerca&lr=


> non affidarsi alla endianity della JVM" ?
MT> Ciao,
MT> immagino tu cerchi una risposta meno banale di questa, ma un
MT> dettaglio del genere non dovrebbe essere trasparente allo
MT> sviluppatore?
Ni.
Uno sviluppatore  può aver voglia di  confrontare 4 byte  con una sola
istruzione  Java invece  che con  4  :) per  questioni di  efficienza,
sapendo che  dovrà verificare sequenze  di soli 4 byte  (garantisce lo
standard PNG :) ).
Vero che c'è  la possibilità di definire le  costanti per il confronto
non come un numero esadecimale esplicito ma come una espressione, e la
cosa è essere endianity-invariante,  ma per gusto personale preferirei
evitare  (alla  fin  fine non  mi  costa  tanto  di più  far  generare
all'editor l'uno o l'altro codice, ma al cuor non si comanda :)) .
Comunque  quello che mi  serviva era  il puntatore  al luogo  dove Sun
definisce  esplicitamente   la  JVM  come  Big  Endian   (e  non  solo
"implicitamente" come  quando definisce come gli  operandi vanno sullo
stack del "processore").
Grazie in ogni caso, sono comunque  tutte voci che dicono che la JVM è
big endian  (o anche "scrive i  numeri come Dio  comanda" [M. "athena"
Frigo]).


 Frigo]).
Eppure non mi spiego... Ma una jvm big endian su una macchina little 
endian non perde in prestazioni?


> [M. "athena" Frigo]).
MT> Eppure non mi spiego... Ma una jvm big endian su una macchina
MT> little endian non perde in prestazioni?
Ni.
Il  processore è  virtuale salvo  nei casi  in cui  intervenga  il JIT
compiler, nel qual caso (e solo in quello) c'è qualche ciclo perso per
sistemare le variabili di tipo intero prima e dopo la parte portata in
linguaggio nativo  (immagino).
In compenso  non avere  una endianity unica  porterebbe a  problemi di
portabilità del codice e con  le invocazioni di metodi remoti, pensati
cosa  accadrebbe a  richiedere  una  somma via  RMI  tra macchine  con
endianity diversa...


 stack del "processore").
Questa definizione "formale" non mi pare di averla vista... :-)
Spero che ti basti quello che ti ho fornito.
Ciao,
        Claudio

>>>>> "CV" == Claudio Vesco <no...@chiedere.it.nospan> writes:
CV> per j2sdk1.4+ guarda java.nio.ByteOrder in particolare
CV> ByteOrder.nativeOrder()
Non devo essermi spiegato bene.  Quello che voglio č essere sicuro che
l'endianity nativa  non vada ad influire sul  comportamento del codice
Java e sopratutto che la JVM sia big endian.
CV> Un'applicazione un po' piů pratica :-) si ha se un
CV> java.nio.ByteBuffer, per efficienza, č mappato direttamente con un
CV> determinato ordine che corrisponde a quello nativo
CV> (ByteBuffer.order() e MappedByteBuffer+). In particolare se il
CV> ByteBuffer (evviva nio) permette una piů efficiente
CV> intercomunicazione tra JVM e codice nativo.
Ripeto,  e mi  scuso  per essermi  spiegato  male. Non  ho bisogno  di
comunicare con codice nativo, sono  in una situazione di puro java, ho
un file  che per  definizione (vedi 
http://www.w3.org/TR/PNG/
)  usa il
network order, ovvero  ha i numeri rappresentati in  modo big endian e
voglio vedere se per dei  confronti, che penso dovranno essere fatti N
volte, posso contare che ANCHE la JVM lavori in modo big endian.
Questo tra l'altro  permette di gestire il confronto  multiplo con uno
switch() {} invece che con una catena if()  {} - else if () {} - ... -
else {} .
CV> Questa definizione "formale" non mi pare di averla vista... :-)
Sono riuscito a risalire all'url.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html
        "The number  and size of  the operands are
         determined by  the opcode. If  an operand
         is more than one byte in size, then it is
         stored   in  big-endian  order-high-order
         byte first."
