Gera sim.
veja esse link
[quote=lordcarlos][quote=juliocbq]
Mas a minha dúvida ainda é a seguinte. Imagine um compilador de pascal para bytecode jvm. Eu conseguiria criar um tipo primitivo inteiro de 16 bits por exemplo?[/quote]
Bom, não conheço muito sobre o funcionamento da jvm, mas acredito que seu compilador só precisara abrir um arquivo e escrever as instruções do seu programa em bytecode, a alocação de memória propriamente dita sera feita pela máquina virtual desde que você escreva no arquivo o tipo correto (colocando o equivalente a long ou integer no arquivo de bytecodes)
Por exemplo, numa pesquisa rápida encontrei a instrução em bytecode “dload”, que carrega um valor double para uma variável. Não importa muito como você represente esse valor double no seu computador (pode ser até como uma string por exemplo), desde que você escreva no arquivo .class a instrução corretamente a máquina virtual vai executa-la[/quote]
sim, mas dload sempre carrega 64 bits? O que eu queria mesmo saber é se existe uma maneira de criar tipos primitivos. Por exemplo eu fazer um set de inteiros (jint8, jint16, jint32, …) e po aí vai. Porque até onde eu entendo todas as linguagens da jvm geram o mesmo bytecode, ou seja, tanto faz programar em java groovy ou scala para jvm. O desempenho desses programas sempre serão muito semelhantes no final. Agora do contrário, em c ou c++ eu consigo alocar a quantidade de recursos para o tipo que eu bem entender. Poderia ter um inteiro com 4 bits por exemplo. Eu digo isso porque a capacidade dos tipos influencia drasticamente no desempenho de um programa. Se você contar até 1000 por exemplo incrementando um inteiro de 16 bits vs um inteiro de 32 vai ver a difrença que isso gera no resultado final. Sei que o hotspot faz essas otimizações quando o jit entra em ação. Mas a nível de bytecode acredito que não há como eu fugir de um inteiro de 32 bits.
[quote=GilsonNunes]Gera sim.
veja esse link
http://wiki.freepascal.org/FPC_JVM[/quote]
Rapaz, muito interessante isso, Eu não sabia que ele compilava bytecode também.
[quote=juliocbq]
sim, mas dload sempre carrega 64 bits? O que eu queria mesmo saber é se existe uma maneira de criar tipos primitivos. Por exemplo eu fazer um set de inteiros (jint8, jint16, jint32, …) e po aí vai. Porque até onde eu entendo todas as linguagens da jvm geram o mesmo bytecode, ou seja, tanto faz programar em java groovy ou scala para jvm. O desempenho desses programas sempre serão muito semelhantes no final. Agora do contrário, em c ou c++ eu consigo alocar a quantidade de recursos para o tipo que eu bem entender. Poderia ter um inteiro com 4 bits por exemplo. Eu digo isso porque a capacidade dos tipos influencia drasticamente no desempenho de um programa. Se você contar até 1000 por exemplo incrementando um inteiro de 8 bits vs um inteiro de 16 vai ver a difrença que isso gera no resultado final. Sei que o hotspot faz essas otimizações quando o jit entra em ação. Mas a nível de bytecode acredito que não há como eu fugir de um inteiro de 32 bits.[/quote]
Acredito que não, pelo que li a instrução dload sempre carrega 64 bits. A máquina virtual do java possui instruções específicas para cada tipo primitivo, então sem mudar o bytecode acho que não da para criar novos tipos primitivos como um inteiro de 128 bits por exemplo. Mas essa é uma limitação da máquina virtual, não do compilador. Uma vez disponibilizado essas instruções você pode alterar seu compilador para escrever elas e usar em sua linguagem que esta criando
dload carrega um double (tipo de ponto flutuante, de 64 bits). Tem certeza que vocês estavam falando de doubles?
De fato, na verdade é melhor você trabalhar com int em vez de char ou short (ambos tipos de 16 bits), mas isso também reflete as máquinas de 32 e de 64 bits, onde é muito mais rápido trabalhar com um int que trabalhar com um char ou short individualmente - normalmente uma instrução adicional de máquina é necessária para converter um short (16 bits) para um int de 32 bits ou um long de 64 bits. Em máquinas Intel, a instrução se chama MOVSX ou MOVSXD, ou então CBW ou CWDE.
Um algoritmo como o strlen (determina o comprimento de uma string em C procurando a posição do primeiro byte \0 ) normalmente nunca é implementado da forma estúpida:
int strlen (char *s) {
int n = 0;
while (*s++)
n++;
return n;
}Em vez disso, normalmente esse código é implementado em assembly carregando 4 ou 8 bytes de cada vez (em vez de um de cada vez) e determinando, através de uns truques, qual é a posição do primeiro byte 0 nos 4 bytes carregados.
É por isso que os Java bytecodes não têm instruções (exceto por bastore, castore, sastore, baload, caload, saload) que lidam diretamente com esses tipos de dados mais “estreitos” que os de 32 bits.
[quote=lordcarlos][quote=juliocbq]
sim, mas dload sempre carrega 64 bits? O que eu queria mesmo saber é se existe uma maneira de criar tipos primitivos. Por exemplo eu fazer um set de inteiros (jint8, jint16, jint32, …) e po aí vai. Porque até onde eu entendo todas as linguagens da jvm geram o mesmo bytecode, ou seja, tanto faz programar em java groovy ou scala para jvm. O desempenho desses programas sempre serão muito semelhantes no final. Agora do contrário, em c ou c++ eu consigo alocar a quantidade de recursos para o tipo que eu bem entender. Poderia ter um inteiro com 4 bits por exemplo. Eu digo isso porque a capacidade dos tipos influencia drasticamente no desempenho de um programa. Se você contar até 1000 por exemplo incrementando um inteiro de 8 bits vs um inteiro de 16 vai ver a difrença que isso gera no resultado final. Sei que o hotspot faz essas otimizações quando o jit entra em ação. Mas a nível de bytecode acredito que não há como eu fugir de um inteiro de 32 bits.[/quote]
Acredito que não, pelo que li a instrução dload sempre carrega 64 bits. A máquina virtual do java possui instruções específicas para cada tipo primitivo, então sem mudar o bytecode acho que não da para criar novos tipos primitivos como um inteiro de 128 bits por exemplo. Mas essa é uma limitação da máquina virtual, não do compilador. Uma vez disponibilizado essas instruções você pode alterar seu compilador para escrever elas e usar em sua linguagem que esta criando[/quote]
era isso que eu estava tentando explicar mais acima. Lidar com inteiros de 32 bits é muito custoso a não ser que haja um esquema debaixo do hotspot que ajusta tanto para 8, 16, 32, ou 64 de acordo com o algoritmo(algumas estruturas de laços) e plataforma alvo.