A sensação que tenho é que nestas últimas 2 semanas o projeto evoluiu muito. Espero que gostem :-)

Tenho várias novidades, mas aqui vou comentar apenas sobre os novos operadores implementados (multiplicação, divisão, relacionais e booleanos) e a sentença if.

Após resolver a pegadinha da precedência de operadores existente na gramática original (mais informações aqui) foi relativamente fácil implementar os novos operadores. Além do que escrevi vários exemplos em Java para analisar os opcodes gerados pelo JavaC.

Abaixo detalharei mais sobre o JASM (Java Assembly) gerado pelo POJ.

Operadores de multiplicação e divisão

Após o aprendizado gerando o JASM para soma e subtração, foi relativamente fácil gerar o assembly para multiplicação e divisão.

A partir do programa Pascal abaixo:

program MulDivIntegers;
begin
  writeln (8*4/2);
end.

O POJ gera o seguinte JASM:

// Code generated by POJ 0.1
public class mul_div_integers {
    public static main([java/lang/String)V {
        getstatic java/lang/System.out java/io/PrintStream
        ;; multiplica 8 * 4
        sipush 8
        sipush 4
        imul
        ;; divide o resultado por 2
        sipush 2
        idiv
        ;; desempilha e imprime um inteiro
        invokevirtual java/io/PrintStream.println(I)V
        return
    }
}

Vale aqui relembrar que a JVM é uma stack based machine, ou seja, é uma máquina baseada em pilha. Isso quer dizer que suas instruções utilizam uma pilha para realizar as suas operações.

No assembly acima getstatic, sipush, imul, idiv, invokevirtual e return são mnemônicos do Java Assembly. Possuem a seguinte finalidade:

• getstatic: obtém uma referência de um método estático de uma classe
• sipush <N>: empilha o inteiro N
• imul: desempilha dois inteiros e empilha a multiplicação destes valores
• idiv: desempilha dois inteiros e empilha a divisão destes valores
• invokevirtual: desempilha dois valores (método a ser invocado e parâmetro) e executa
• return: finaliza a execução do método

Na prática o par getstatic/invokevirtual serve para invocar o println, responsável por enviar dados para a saída padrão. O "I" em println(I) indica que será exibido um inteiro. E para saber qual método println invocar, o POJ precisa fazer o tracking dos tipos de dados que estão sendo empilhados/desempilhados na JVM.

Na tabela abaixo é possível ver as instruções geradas a partir da expressão "8*4/2" bem como o estado da pilha da JVM após a execução de cada instrução:

No final da execução a pilha contém o resultado esperado de 8*4/2: 16.

Operadores relacionais e a sentença if

Para corretamente implementarmos os operadores relacionais (>, <, >=, <=, = e <>) foi necessário introduzir as instruções da JVM relacionadas à condicionais (ifs) e saltos (goto e labels). Sim, o famigerado goto existe na JVM, e faz todo sentido existir :-)

Vamos a um exemplo com if/then/else. A partir do programa Pascal abaixo:

program IfWithIntegers;
begin
  if ( 111 < 222 ) then
    write('true')
  else
    write('false');
end.

O POJ gera o seguinte JASM:

// Code generated by POJ 0.1
public class if_with_integers {
    public static main([java/lang/String)V {
        ;; se 111 >= 222 salta para L1
        sipush 111
        sipush 222
        if_icmpge L1
        ;; imprime true
        getstatic java/lang/System.out java/io/PrintStream
        ldc "true"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
        goto L2
    L1: ;; imprime false
        getstatic java/lang/System.out java/io/PrintStream        
        ldc "false"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
    L2: return
    }
}

Em relação ao exemplo anterior agora estamos utilizando novas instruções:

• if_icmpge <label>: desempilha dois inteiros e salta para o label indicado se o primeiro valor for maior ou igual ao segundo
• labels: no exemplo acima "L1:" e "L2:"
• goto <label>: salta para o label indicado

A instrução if_icmpge faz parte de um conjunto amplo de instruções de teste e salto. O "ge" (de if_icmpge) é a abreviatura de "greater or equal". Outras variações são gt (greater than), eq (equal), ne (not equal), lt (less than) e le (less or equal).

Na tabela abaixo é possível ver as instruções geradas a partir do assembly acima bem como o estado da pilha da JVM após a execução de cada instrução:

As instruções marcadas desta forma não são executadas durante o fluxo de execução deste programa.

No final da execução o programa exibe a saída esperada: "true".

Vale ressaltar que a condição utilizada na geração do assembly (ge) é a inversa do programa em pascal (<). Esta técnica facilita a geração do assembly para os casos onde a sentença if somente tem o então (then), sem o senão (else).

Vamos a um exemplo com if/then (sem o else). A partir do programa Pascal abaixo:

program IfWithIntegers;
begin
  if ( 111 < 222 ) then
    write('true');
end.

O POJ gera o seguinte JASM:

// Code generated by POJ 0.1
public class if_with_integers {
    public static main([java/lang/String)V {
        ;; se 111 >= 222 salta para L1
        sipush 111
        sipush 222
        if_icmpge L1
        ;; imprime true
        getstatic java/lang/System.out java/io/PrintStream
        ldc "true"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
        goto L2
  L1:L2:return
    }
}

Os mais atentos podem ter notado que o último goto (goto L2) é desnecessário. O código gerado está funcionalmente correto, apesar de não otimizado. Não só esta otimização bem como várias outras podem ser implementadas futuramente no POJ.

Operadores booleanos and e or

Para implementarmos os operadores booleanos (and e or) foi necessário introduzir as seguintes instruções:

• iand: desempilha dois inteiros, executa o and e empilha o resultado
• ior: desempilha dois inteiros, executa o or e empilha o resultado
• ifeq <label>: desempilha o último valor, e caso igual a 0 salta para o label indicado
• iconst <N>: empilha o inteiro N

Vamos a um exemplo. A partir do programa Pascal abaixo:

program IfWithAnd;
begin
  if ( 111 < 222) and ( 222 < 333 ) then
    write('true')
  else
    write('false');
end.

O POJ gera o seguinte JASM:

// Code generated by POJ 0.1
public class if_with_and {
    public static main([java/lang/String)V {
        sipush 111    ;; se 111 >= 222 salta para L1
        sipush 222
        if_icmpge L1
        iconst 1      ;; carrega true (1) na pilha
        goto L2
    L1: iconst 0      ;; carrega false (0) na pilha
    L2: sipush 222    ;; se 222 >= 333 salta para L3
        sipush 333
        if_icmpge L3
        iconst 1      ;; carrega true (1) na pilha
        goto L4
    L3: iconst 0      ;; carrega false (0) na pilha
    L4: iand          ;; se algum teste falhou salta para L5
        ifeq L5
        ;; imprime true
        getstatic java/lang/System.out java/io/PrintStream
        ldc "true"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
        goto L6
    L5: ;; imprime false
        getstatic java/lang/System.out java/io/PrintStream
        ldc "false"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
    L6: return
    }
}

Vale aqui ressaltar que a JVM não possui os tipos booleanos true e false. Estes tipos são emulados através dos inteiros 1 e 0, respectivamente. Para tal utilizamos as instruções "iconst 1" e "iconst 0".

Na tabela abaixo é possível ver as instruções geradas a partir do assembly acima bem como o estado da pilha da JVM após a execução de cada instrução:

No final da execução o programa exibe a saída esperada: "true".

Operador booleano not

Até aqui falamos sobre os operadores and e or. E o operador not? Vamos a um exemplo.

A partir do programa Pascal abaixo:

program IfWithAndNot;
begin
  if not(( 111 < 222) and ( 222 < 333 )) then
    write('true')
  else
    write('false');
end.

O POJ gera o seguinte JASM:

// Code generated by POJ 0.1
public class if_with_and_not {
    public static main([java/lang/String)V {
        sipush 111   ;; se 111 >= 222 salta para L1
        sipush 222
        if_icmpge L1
        iconst 1     ;; carrega true (1) na pilha
        goto L2
    L1: iconst 0     ;; carrega false (0) na pilha
    L2: sipush 222   ;; se 222 >= 333 salta para L3
        sipush 333
        if_icmpge L3
        iconst 1     ;; carrega true (1) na pilha
        goto L4
    L3: iconst 0     ;; carrega false (0) na pilha
    L4: iand         ;; se testes foram ok salta para L5
        ifne L5
        iconst 1     ;; carrega true (1) na pilha
        goto L6
    L5: iconst 0     ;; carrega false (0) na pilha
    L6: ifeq L7
        ;; imprime true
        getstatic java/lang/System.out java/io/PrintStream
        ldc "true"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
        goto L8
    L7: ;; imprime false
        getstatic java/lang/System.out java/io/PrintStream
        ldc "false"
        invokevirtual java/io/PrintStream.print(java/lang/String)V
    L8: return
    }
}

Vale aqui ressaltar que apesar da JVM ter as instruções iand e ior, ela não possui uma instrução como inot. Esta "negação" da operação deve ser implementada com ifne e labels. O ifne (if not equal) salta para o label indicado caso o último valor da pilha não seja zero.

Na tabela abaixo é possível ver as instruções geradas a partir do assembly acima bem como o estado da pilha da JVM após a execução de cada instrução:

No final da execução o programa exibe a saída esperada: "false".

"Perrengue" com JASM e uma grata surpresa

No início do projeto tive que decidir entre gerar o arquivo class diretamente ou utilizar um assemblador de Java Assembly. Optei por utilizar o JASM, um assemblador Java em que rapidamente consegui rodar alguns exemplos.

Eis que em pleno feriado (29/3, sexta-feira santa), após gerar o assembly para o operador not, ao executar o JASM ele simplesmente gerava um "NullPointerException". Fiz alguns testes mas não identifiquei nada estranho no assembly gerado pelo POJ.

Como é o usual entrei no github do JASM e tentei identificar algum bug relacionado, mas não havia nada. Como o projeto é pouco movimentado eu já estava esperando por alguma mudança drástica no POJ: ter que escolher outro assemblador ou gerar o arquivo class diretamente.

Antes que alguém diga "o JASM é open source, contribui lá". Até pensei nisso, mas eu não sei programar em Java, e sendo bem sincero, não é uma das linguagens que eu tenha interesse em aprender :-)

Bom, abri uma issue no JASM, e para minha surpresa, em menos de 1 hora o mantenedor respondeu e identificou o problema. Inicialmente eu estava utilizando a instrução "iconst_1" (ao invés de "iconst 1"). A JVM tem a instrução "iconst_1", mas como é uma otimização da instrução "iconst 1", o JASM não a implementa. Enfim, ajustei para "iconst 1" e tudo funcionou.

Maiores informações

O repositório com o código completo do projeto e a sua documentação está aqui.