Generazione di un bytecode JVM per un'espressione non unaria

Question

Diciamo che stai scrivendo un compilatore Java (o sottoinsieme di Java) e vuoi generare bytecode per un'espressione non unaria, !E. Hai passato il controllo di tipo in modo da sapere che è boolean, ad esempio, se si preme un 1 o uno 0 nella pila degli operandi.

Un modo per farlo è qualcosa di simile (nella sintassi Jasmin):

E 
ifeq truelabel 
iconst_0 
goto stoplabel 
truelabel: 
iconst_1 
stoplabel: 

cioè se c'è uno 0 sulla spinta pila 1, altrimenti spinta 0. Un altro modo per farlo, approfittando del fatto che un boolean è solo un int con un valore 1 o 0, vale a dire !E = (E + 1) % 2 e generare

E 
iconst_1 
iadd 
iconst_2 
irem 

c'è un vantaggio di utilizzare uno sopra l'altro? O qualcos'altro interamente?

Answer 1

Non conterei sulla seguente definizione per mantenere true a livello di byte.

true == 1 

A livello binario (e la sua quasi indipendente dalla lingua), un valore booleano viene solitamente definita come

false == 0 
true != 0 

Il compilatore javac apparentemente segue anche questa definizione (tutti i controlli in javac bytecode che ho visto solo controlla sempre nuovamente ZERO, mai contro ONE).

Ed senso usare questa definizione per booleana invece solo trattamento 1 come vero, C definisce anche in questo modo (vero è proprio! = 0, non semplicemente 1), in codice assembly questa convenzione è anche comunemente usato. Quindi java, anche utilizzando questa definizione, consente di passare/passare i booleani java ad altri codici senza alcuna conversione speciale.

Sospetto che il tuo primo esempio di codice (con ifeq) sia l'unico modo per implementare correttamente il non operatore per i booleani. Il metodo^1 (xor con 1) fallirà se il valore booleano non è rappresentato in modo strisciante come 0/1. Qualsiasi altro valore int causerebbe un'espressione non corretta.

Answer 2

Una volta ho provato a scrivere un decompilatore Java, quindi ero solito sapere quale codice javac ha generato. Come ricordo, javac 1.0.x utilizzava !E = E ? false : true mentre javac 1.1 utilizzava !E = E^1 (bit XOR bit a bit).

Answer 3

Ho sentito che le operazioni del modulo possono essere molto lente. Non ho una fonte per questo, ma ciò ha senso dato quanto è più semplice aggiungere che dividere. Inoltre, può darsi il caso che saltare il contatore del programma troppo spesso possa essere in discussione, nel qual caso l'approccio if/else non funzionerebbe troppo bene.

Con ciò detto, sospetterei che Neil's E^1 sia il più veloce, ma è solo una sensazione. Tutto quello che devi fare è passare il numero attraverso un circuito logico, e il gioco è fatto! Solo una operazione piuttosto che una manciata.