Software retargeting
Luigi & Flavio CMP502 2002/II
Binary translation
zArquitetura é uma camada de
software
zé uma tecnologia disruptiva?
zSuporte a novo paradigma: virtual IT
shop
PARA MAIS INFORMAÇÕES...
Altman et alli. Advances and Future Challenges in Binary Translation and Optimization. Proc. IEEE, nov 2001
Descrição
z Tradução JIT de um código binário a outro
z possibilita otimizações dinâmicas – achar paralelismo, como em superescalar – pelo tamanho do código analisado, custo
energético muito menor
– similaridade com trace memory!
z Otimizações feitas por SW em run-time, e salvas para reuso, para amortizar seu custo
Traduz e otimiza Arquitetura real
Exemplos
z Daisy (IBM)
– mercado de servidores, substitui PowerPC z Crusoe (Transmeta)
– mercado dos ultra-portáteis z Dynamo (HP)
– máquina Java
zLaTTe
Porque BT é interessante
z Aumento de desempenho
– feita no run-time, pode fazer profiling e
otimizar
z arquitetura = camada de software – máquina substrato complexa e alterável,
máquina de cima fixa e padrão
– novas arquiteturas incompatíveis com
compatibilidade de SW são possíveis
– redução da complexidade do HW
• paralelismo descoberto por profiling ou outros
algoritmos simples
• otimizações feitas somente uma vez por execução de
trecho
Será disruptiva?
zSe BT funcionar, o processador
núcleo será realmente uma commoditie
zaumento de desempenho ou
potência facilitados (HW mais simples!)
zÓtimo global, não atingível em HW
Virtual IT shop: write once, run
everywhere
zRecursos computacionais
disponíveis via web
zdownload de SW para diferentes
plataformas-> muita armazenagem
zarmazena um único executável
– cada um baixa o seu Sparc, X86,
Power-PC, 8051 ...
zCrash da aplicação não é crash do
sistema
Convergence Virtual Machine
zFigura do quadro
zCVM similar à JVM, mas uma camada
acima
– pode executar SO e C/C++
– roda sobre um RISC não tão seguro
zcomputação independete de
arquitetura não é uma idéia nova...
Alguns detalhes
zSource architecture- target
architecture
zVirtual Machine Monitor (tradutor)
zTranslation cache
– não necessariamente uma cache
zinterpretação X tradução/otimização
zindependente ou dependente de SO
ztraduzindo para uma mesma
arquitetura ou não
Problemas não banais I:
zCódigo auto-modificável
– programas sendo carregados pelo SO!
zInterrupções precisas
ztradução de endereços
– I/O mapeada em memória – condições de page-fault
zcódigo com check
– checksum ou auto-avaliação de
Problemas não banais II:
zGerência das traduções
– o que fazer quando Tcache cheia – garbage collector
znecessidades de tempo-real
– garantir previsibilidade da execução – garantir deadlines
zBoot & BIOS
zconfiabilidade: bugs implicam na
troca a camada de SW apenas
Problemas não banais III:
zReuso é mister: 4000 operações para
uma única tradução (Daisy-PowerPC)
zpode fazer otimizações caras,
extraindo ILP
zotimizações especificamente
dinâmicas
zTcaches maiores: mais reuso, mais
(ou menos) potência, menos adaptabilidade a troca de fonte
Problemas não banais IV:
zCusto em ciclos, memória e potência
retirados da arquitetura alvo
zalta latência (maior quanto mais
otimizações)
zdebug muito difícil, não
determinístico!
Algumas outras vantagens
zExecuta heranças binárias sem fonte
(cobol)
zotimizações sem fronteiras (rotinas,
bibliotecas, chamadas dinâmicas de sistema, etc.)
zcompatibiliade entre VLIWs de
diferentes tamanhos
zmelhoria de arquitetura: troca a
camada de software. Inteligência no SW!
Daisy (IBM) I:
zMercado de servidores
zfiguras no quadro
zindependete de boas predições de
salto
zILP scheduling com Data e Controle
especulativo
zloop unrolling, alias analisys, load-store telescoping, deadcode
elimination
Daisy (IBM) II:
zExecuta 3-4 instruções
Power-PC/ciclo (benchmark)
z8-16 inst/ciclo VLIW
zgigabytes de memória, 100MB só
Crusoe (Transmeta)
zFigura do quadro
zEmula x86
z667 MHz crusoe = 500MHz Pentium III
z2-4 instr/ciclo
z64-128MB memória, mas 16 para si
Dynamo (HP)
zSoftware que executa sobre a
própria arquitetura!
zCamada de otimização
– basicamente gerência de memória – strength reduction, loop invariant code
motion, constant propagation, loop unrolling
zaumenta desempenho de 22%
(alguns specs), 10% na média
LaTTe
zJIT para java
zRoda em SUN (comparação direta)
z2.2 x mais rápida, 3 x mais lenta
zgerência de registradores
Retargetable binary utilities
zDAC 2002, Univ. Toronto
zobjetivo: gerador de ferramentas
pós-compiler
– baseado no gnu – binutils: 250k linhas!
zLinkers modernos
– dynamic binding, bibliotecas
compartilhadas, otimizações intra-procedural...
– Figura no quadro
Experiência local I:
zassemblador do Risco, 1994!
– Múltiplos bits
– diferentes modos de instrução em fç do
número de bits
– inclusão automática de instruções – manipulação de número variável de
Experiência local II:
zCompilador do Risco (94-96)
– otimizações do GNU
– otimizações do próprio processador
zMBSG
– classificação do tipo de rotina
• data intensive, control, memory • otimização baseada na classificação
– HW-dedicado, RISCO-WCS, Duplo DP – válido para DLX também
BT e sistemas embarcados I:
zCompatibilidade entre plataformas
zEvolução de plataformas
– no início mono processador,
multi-processador, múltiplas arquiteturas ...
zPor que Dynamo tem tão pouca
eficiência?
zQuão simples devem ser as
arquiteturas? Qual o compromisso entre projeto e reuso?
BT e sistemas embarcados II:
zQual o overhead aceitável
– memória, potência, área, – latência
zOportunidades para
– uso de lógica reconfigurável
– otimizações de SW-HW para um certo
domínio
zo assembler é o lugar certo para
capturar o modelo de computação?
