[quote=entanglement]Hum… você está usando “fst” que usa o coprocessador aritmético, que por si só é muito lento (mesmo a JVM evita usar o coprocessador e usa, em seu lugar, as instruções SSE2 / SSE3 se for fazer contas com double.
Se for adequar seu código para um processador mais moderno (64 bits), use rep stosq.[/quote]
Se a jvm usa sse2, então vê-se que é necessário fazer assembly inline em partes críticas. Esse código postado acima tem uns 10 anos, e funciona bem até hoje.
Só para esclarecer: já programei muito em assembler. E vários assemblers diferentes desde o IBM 1130, IBM /360, /370, mod. 30, mod. 50, 4341 e PCs. Ah, já programei também direto em linguagem de máquina em várias computadores diferentes.
Continuo com a mesma opinião que escrevi e alguns não leram: assembler só para micro controladores.
Já otimizei sistemas usando assembler inclusive para aproveitar as instruções de 80 bits do coprocessador aritmético. Hoje em dia isto não tem mais nenhum sentido.
Troco tudo que sei de Assembler por qualquer 10 mil réis.
para casos em uso de microcontroladores, utilizar assembly me pareceu mais eficaz, mas na maioria das vezes utilizava pelo editor a conversão de código escrito em c para assembly, posteriormente checando como foi a lanbança de conversão.
é preciso ter muito saco para ver todas aquelas intruções em assembly. não podíamos fazer tudo em c, por questões do tamanho da memória do microcontrolador.
postei um tópico tempão atrás aqui no guj, onde estava implementando c com assembly para microcontrolador 8051. utilizei o proteus neste projeto para antecipar algumas simulações, ambiente de comunicação e testes, antes da efetuar fabricação da placa. me ajudou a economizar e antecipar compra de peças não planejadas!
havia também, um outro conversor bem melhor, mas se lembrar, posto aqui!
o assembly inline realmente é muito útil e simples de usar. É muito difícil, haver situações onde se precisa fazer isso, mas as vezes é a única carta que possuimos.
Um exemplo, é que a maioria dos compiladores não suportam instruções mmx. Salvo o freepascal, e alguns c++. Como boa parte dos nossos softwares são delphi, nos deparamos com esse problema. A solução foi utilizar mmx diretamente em assembly, e pudemos somar duas matrizes(imagens digitais) assim: