Trabalho Realizado por:

Fábio Daniel Andrade Batista nº 501011228 Tiago Fraga Tinoco Frade de Macedo nº 501011288

Introdução

Desde 1995, a Transmeta, uma pequena empresa fundada por nomes importantes do design de processadores e arquitecturas saídos de empresas como Motorola ou Sun, têm vindo a desenvolver um processador que quebra com alguns conceitos básicos em arquitecturas tradicionais e que, no início do ano 2000 foi oficialmente apresentado, surgindo então os primeiros produtos comerciais com processador Crusoe. Apesar da ideia inicial ser criar um processador para todos os segmentos de mercado, as características que este acabou por apresentar depois de 5 anos de desenvolvimento tornaramo especialmente indicado para computação portátil. Estas características são essencialmente a pouca energia que consome (devido à simplificação do hardware), a ausência da necessidade de refrigeração externa, a facilidade de evolução causada pela arquitectura que mistura hardware e software e as suas dimensões reduzidas.

A compatibilidade com binários para a arquitectura x86 é conseguida através de uma camada de software que isola totalmente o hardware de todo e qualquer código x86, incluíndo rotinas de BIOS e sistema operativo. É a esta camada que a empresa chamou e patenteou como Code Morphing Software. Este é um dos pontos de maior inovação no processador da Transmeta a par do LongRun Advanced Power Management.

A Arquitectura do Crusoe

Como já foi referido, o Crusoe inova o conceito de arquitectura de microprocessadores criando uma estrutura de hardware isolada do sistema por uma camada de software invisível ao sistema operativo. Quanto ao hardware propriamente dito, simplicidade é a palavra de ordem. Uma arquitectura simplificada requer menos transístores que as “tradicionais” e isto conduz a necessidades energéticas muito inferiores ao habitual. A utilização de software nesta arquitectura permite reduzir para cerca de um terço o número de transístores em relação ao que seria necessário para realizar uma arquitectura de desempenho semelhante recorrendo apenas a hardware.

Hardware

O TM5400, produzido num processo de .22 micron, está equipado com 64KB de cache L1 de instruções e 64KB de dados (ambas ‘8-way set associative’), possui também 256KB de cache L2 (‘write-back’, ‘4-way set associative’) e ainda uma TLB unificada de 256 entradas (‘4-way set associative’). O seu controlador de memória suporta SDRAM a 66MHz e 133MHz e DDR SDRAM a 100MHz e 166MHz. Também incluído no processador está o controlador do bus PCI a 33MHz (3.3V).

Existem diversas versões do TM5400 (474 pins) sendo que a diferença entre elas é apenas no ‘clock speed’ que varia entre 500MHz e 700MHz. O pipeline do TM5400 é também bastante simples tendo apenas 7 etapas para inteiros e 10 etapas para floating-point.

Para além disto o Crusoe possui um serial flash ROM de 1mb onde está armazenado o Code Morphing Software.

A nível de unidades funcionais está equipado com: - Duas unidades aritméticas de inteiros - Uma unidade aritmética de vírgula flutuante - Uma unidade de memória (load/store) - Uma unidade de saltos (branches) Não existe nenhuma lógica de hardware para controlar o fluxo e ordem das instruções, esta função está a cargo do software. Existe um conjunto de 64 registos ( de %r0 até %r63) com finalidades diversas. Sendo todos modelados directamente para o Crusoe, alguns deles são utilizados como os registos mais importantes da arquitectura x86, mantendo o seu estado. Esta é mais uma característica essencial para manter a compatíbilidade com o x86, permitindo ao sistema manipular registos transparentemente como se de uma arquitectura deste tipo se tratasse.

As palavras de instruções têm comprimento de 128 bits e contêm até quatro instruções do tipo RISC. Como tal, todas estas quatro instruções têm o mesmo tamanho, neste caso 32 bits. Cada uma destas instruções de 32 bits designa-se átomo e ao seu conjunto (de 64 ou 128 bits) a Transmeta deu o nome de molécula. Os átomos de cada molécula são executados em paralelo e o formato da molécula determina como os átomos são redireccionados para as unidades funcionais. É o software que cria e optimiza estes conjuntos de instruções. Assim, estas são executadas pela ordem definida pelo software evitando-se assim lógica de reordenação de instruções de extrema complexidade, são ainda cuidadas pelo software as dependências de dados entre instruções e a estrutura dos átomos dentro de cada molécula. Mais uma vez, é conseguida a simplificação da lógica de despacho e descodificação a custa de algum trabalho extra no software.

Code Morphing Software

Esta camada de software é a característica mais distintiva deste processador e uma das suas maiores inovações. É através dela que se consegue compatibilidade total com a arquitectura de instruções x86. A Transmeta designa o CMS como um sistema dinâmico de tradução, ou seja, uma sistema que transforma instruções nativas de uma arquitectura em instruções de outra.

Este software é residente numa memória ROM sendo assim possível actualizar o CMS sem recurso a qualquer mudança no hardware. É até virtualmente possível implementar a já citada compatíbilidade com outros conjuntos de instruções (não x86) através de actualizações dessa memória. Novas versões do CMS podem também ser responsáveis por incrementos de desempenho geral do sistema por optimização das estratégias de tradução de instruções.

Quando o sistema é ligado o CMS é carregado da ROM e copiado para uma zona de memória primária protegida e que partilha com uma zona de cache de código traduzido, como veremos adiante. Este gasto de memória e o número de acessos à mesma que este mecanismo provoca são dois dos maiores handicaps deste tipo de arquitectura.

Torna-se óbvio que o CMS teve ser escrito em instruções nativas VLIW. Não tão evidente, mas igualmente inevitável, é o facto de este ser o único programa escrito na ISA (Instruction Set Architecture) original deste processador. Este facto permito isolar todos os restantes programas, incluindo as rotinas de BIOS e o sistema operativo e device drivers, das características reais do hardware.

Desta forma a flexibilidade que este processador nos permite, leva a que ciclos de relógio que nas arquitecturas “tradicionais” seriam utilizados para a execução do código da aplicação, aqui são utilizados para a tradução das mesmas para a linguagem Crusoe. Perante esta situação, optimização é a palavra de ordem no Crusoe sendo este ponto o que tem requerido maior atenção por parte das equipas que estão envolvidas no desenvolvimento, de forma a não tornar a execução um processo lento. Esta penalidade que se tem na tradução do código terá então de ser compensada para que, apesar das inovações, o processador da Transmeta seja capaz de atingir performances tão boas ou melhores que a concorrência.

Esta tarefa, aparentemente impossível, é conseguida através de

diversas estratégias de optimização de que falaremos adiante. No entanto, é importante não deixar de referir que, apesar da importância que tem no mercado actual, a performance não é o maior objectivo do Crusoe pois destina-se maioritariamente ao mercado dos computadores portáteis.

Tradução de código Nas arquitecturas tradicionais com escalonamento de instruções,

estas são lidas da memória e descodificadas individualmente em micro-instruções sendo depois reordenadas da forma mais conveniente através de lógica de hardware bastante complexa. Este processo acontece para todas as instruções sem excepções. Isto implica um gasto de tempo e energia constante que se repete mesmo para um troço de código pertencente a um ciclo onde o código gerado e as decisões de escalonamento serão repetidas várias vezes sem que o processador e a sua lógica de controlo de fluxo de instruções sequer se apercebam. O processador da Transmeta notou esta quebra de desempenho e aproveitou o seu CMS para a minorar o mais possível. Isto é conseguido recorrendo a uma estratégia que traduz um conjunto de instruções x86 de cada vez em vez de o efectuar individualmente. O software pode então aperceber-se quando as instruções pertencem a ciclos, quando existe a hipótese de serem executadas muitas vezes ou mesmo que nunca chegarão a ser executadas. Desta forma a tradução pode ser optimizada tendo em conta este e outros factores importantes que indicam o peso de cada troço de código no tempo de execução total de um determinado programa ou processo.

Um conjunto de instruções x86 gera uma tradução. Estas traduções podem ser, caso o software entenda que isto é vantajoso, armazenadas numa cache de traduções criada em memória no arranque do sistema.

Cache de Traduções

O tamanho da zona de memória atribuída a cache de traduções pode ser definido no arranque do sistema. Esta cache contém blocos de 128 bits. Este sistema de cache funciona como uma cache de dados ou instruções habitualmente. Assim, o CMS tenta perceber quais os troços mais chamados e reutilizados para fazer uma gestão mais eficiente da cache.

Em situações de execução reais a frequência de repetição de código é muito elevada pelo que esta é mais uma forma de efectuar optimizações no processo de conversão de código em micro-instruções. A partir do momento em que um troço de código é traduzido e colocado na cache, em cada nova execução do mesmo é utilizado o código já traduzido. A importância desta característica é proporcional ao número de chamadas a execução de cada troço uma vez que cada reutilização de código dispensa ciclos de relógio gastos em tradução amortizando assim o tempo gasto na tradução inicial. Assim, teoricamente, esse tempo “perdido” acaba por ser completamente amortizado e até compensado podendo, em situações ideais, surgir melhorias de desempenho.

Modos de execução

É importante, no desenvolvimento de micro-processadores, reunir esforços tentando optimizar partes do processo de execução que ocupem partes relevantes dos tempos consumidos. Isto é um facto a ter em conta seja em que optimização for e não pode ser esquecido pelo CMS.

Estatisticamente, é frequente apenas 10% do código tomar mais de 95% do tempo de execução total. Por isso, é muitíssimo importante que este software seleccione cuidadosamente o tempo (leia-se ciclos de relógio) a atribuir à optimização de cada troço. É suposto gastar-se um número mínimo de ciclos com partes de código executadas apenas uma vez e perder-se mais tempo nos troços que sejam executados mais vezes.

Para melhorar este processo foram implementados vários modos de execução que permitem dosear os recursos gastos em cada optimização. Estes modos variam entre a simples interpretação, em que o código x86 não sofre qualquer tipo de optimização reduzindo os gastos de tradução mas que piora o tempo de execução do código; passando por modos com estratégias de tradução simples até outros, com estratégias mais complexas e consumidoras de ciclo de relógio, que produzem código com elevado grau de optimização. Este último, apesar de ter um tempo de tradução e optimização superior, produz código mais “eficiente” que será, em situações ideais, executado mais rapidamente que o código x86 original.

Algumas informações recolhidas durante a execução do código permitem melhorar o conhecimento do CMS sobre um programa melhoram a capacidade de seleccionar o modo de execução mais indicado para cada situação.

Previsão/selecção de saltos

É importante, para o CMS poder melhorar as suas estratégias, ir

recolhendo algumas informações sobre a execução do código. Será interessante e útil para o CMS poder, por exemplo, ter noção se existe algum padrão em valores atribuídos a uma qualquer variável, manter um histórico de saltos ou frequência de execução de troços de código. Baseado nesta informação o Crusoe tenta fazer uma previsão e selecção de saltos inteligente baseada em dados estatísticas resultantes dos recolhidos durante a execução do código. Esta recolha é realizado por código extra, colocado no código traduzido pertencente à aplicação. Este mecanismo permite realizar estratégias de optimização que beneficiem os caminhos mais executados em prejuízo daqueles que são executados com muito menos frequência.

Caso o CMS encontre caminhos que são escolhidos equilibradamente, é possível especular sobre o resultado da execução deste código sendo assim possível escolher o caminho que, com maior probabilidade, será executado realmente.

Suporte de hardware ao CMS Este conceito que integra software no processo de execução de instruções no micro-processador e permite criar o conceito de tradução dinâmica de código é algo pesado e seria impraticável se implementado nas arquitecturas até aqui existentes. Só faz sentido, por se conseguirem desempenhos de qualidade, se juntarmos ao software uma estrutura de hardware construída paralelamente e que tenha em linha de conta todas as especificidades e necessidades de uma interface de software entre o processador e as aplicações.

Os engenheiros da Transmeta basearam-se neste facto e implementaram diversas características no hardware que visam fornecer um suporte de qualidade a este tipo de arquitectura mista. Note se que estas características não se destinam a uma versão específica do CMS, mas ao conceito de morfismo de código no processador Crusoe de forma genérica.

Interrupções

É suposto este processador deter compatibilidade total com a

arquitectura x86. Para isto ser conseguido, existem alguns aspectos de hardware importantes que foi necessário desenhar desde o início com este objectivo em mente.

Uma das características que mais condicionantes provocam no escalonamento de instruções em x86 é o funcionamento das interrupções, estas são exactas. Isto é, uma vez desencadeada uma interrupção todas as intruções iniciadas antes da que gerou a interrupção devem terminar e as que se iniciaram depois devem ser interrompidas. Conseguir manter esta característica é imprescindível para manter a compatibilidade mas é também uma das maiores dificuldades no desenho do Crusoe. Este problema existe em todas as arquitecturas que realizam escalonamento de instruções. Segundo a Transmeta, os desenhos de micro-processadores existentes resolvem este problema com recurso a lógica complicada para refazer os efeitos de instruções executadas. A técnica utilizada pelo Crusoe não é muito diferente: todos os registos que guardem o estado do x86 (working registers) têm uma cópia a que se chama shadow register. Todas as alterações durante a execução são gravadas nos registos working. O processo que se segue é um commit-rollback simples. Chegando ao fim de uma tradução (lembre-se que o CMS cria troços de código traduzidos a que chama traduções) sem que nenhuma instrução tenha gerado interrupções é efectuada uma operação que valida as alterações efectuadas durante a execução da tradução, um commit. Esta operação efectua a cópia para os registos shadow dos registos working que haviam sido alterados.

Caso suceda alguma interrupção, os registos working são actualizados com os registos shadow validados no fim da execução do trecho de código anterior, sendo assim reposto o estado dos registos no início da execução corrente. Após isto, o CMS entra em acção e repete a execução da tradução anulada mas de forma conservativa, isto é, mantendo a ordem original das instruções de forma a poder determinar a posição real da interrupção.

Fazer algo semelhante em relação à memória é também necessário. A solução utilizada consiste num buffer colocado “à entrada” da memória onde são armazenadas as alterações efectuadas pelas operações de Store. A persistência destas alterações é efectuada pela operação de commit. A operação inversa, designada rollback, não implica qualquer gasto de ciclos pois basta apenas “esquecer” o conteúdo do buffer.

Gestão de dependências

As dependências de dados são, no estado actual de desenvolvimento do desenho de micro-processadores, um dos factores mais limitativos e estranguladores. Este problema seria um handicap muito sério

para a arquitectura Crusoe que baseia grande parte dos seus créditos na “inteligência” e capacidade do CMS de escalonar instruções. Gerir dependências eficazmente e fazer trocas muito elaboradas de instruções de Load e Store (únicos acessos à memória de dados) são dois aspectos que dificilmente podem coexistir. Assim, a Transmeta optou por encontrar uma estratégia que resolvesse o problema das dependências.

Uma vez mais o software é a chave da solução mas não dispensa uma pequena “ajuda” do hardware. O que se passa é que ao reordenar uma intrução Load antes de um Store, mudando a posição relativa dos dois, transforma a primeira num Load-andprotect e a segunda num Store-underalias-mask.

Naturalmente, estas duas instruções são realizadas exclusivamente em hardware, portanto a sua execução não é demasiadamente atrasada pelas verificações que têm de fazer para além de ler e escrever na memória, respectivamente.

Estas duas instruções funcionam da seguinte forma:

- Load-and-protect - Lê os dados da memória, mas regista ainda a posição da memória lida e o tamanho dos dados;

- Store-under-alias-mask - Verifica, antes de gravar os dados, se irá escrever numa zona de memória protegida por um load-and-protect.

Caso isto aconteça é gerada um interrupção. Caso contrário pode

escrever e o processamento continua normalmente. Quando ocorre uma excepção na execução do store-under-alias-mask (situação pouco provável para a maior parte das reordenações de instruções) o software encarrega-se de resolver a situação tomando as medidas correctivas devidas. Isto pode passar, em algumas situações, por reiniciar a execução de uma tradução, mas nem sempre uma medida tão drástica será necessária. Este processo permite ainda eliminar redundância de acessos à memória. Numa situação em que são detectados duas leituras na mesma posição de memória mas onde surge uma instrução de escrita na memória pelo meio é muito provável que exista redundância nas leituras. Isto só não acontece no caso em que a escrita é efectuada na mesma posição de memória das leituras. Com este mecanismo de protecção de posições lidas, é possível eliminar o segundo load transformando o primeiro num load protegido (loadand-protect) e o store num que verifica as protecções pendentes (store-under-alias-mask). Assim, no caso em que a escrita é feita para a zona protegida, o processamento recomeça, por acção da interrupção, antes do primeiro load e a coerência mantém-se.

Modificações ao código original

As instruções x86 em memória modificam-se muitas vezes. Isto

acontece quando algum novo programa é carregado pelo sistema. Como nas secções anteriores é necessário cuidados especiais para manter a compatibilidade com o x86 sem perder coerência ou desempenho.

Nesta situação, o desempenho sofrerá sempre alguma penalização pois, como é lógico, não existe forma de evitar a tradução do novo código. A questão centra-se então em perceber quando sucede alguma alteração ao código. A arquitectura Crusoe recorre a um mecanismo que marca cada página de código x86 já traduzido através de um bit ‘protected’ na entrada dessa página na unidade de gestão de memória (MMU). Desta forma, quando o código é sobreposto a solução é efectuar a tradução do novo código.

A Transmeta garante que o CMS consegue utilizar estratégias mais inteligentes (que evitam a tradução de toda a página) ao analisar o comportamento dos programas em execução. No entanto, esse tipo de informação não está disponível.

LongRun Advanced Power Management

O processador Crusoe foi projectado para baixo consumo de energia, e mesmo em uso extremo é bastante económico mas, para esse feito, foi desenvolvida uma tecnologia designada de LongRun. Graças a esta tecnologia o Crusoe consegue ser muito mais eficaz neste campo que a concorrência directa.

O que o LongRun faz é variar rapidamente a velocidade do processador para se ajustar à necessidade actual. Sendo assim, se estivermos a usar aplicações que não requeiram o uso dos 700MHz ele baixa sucessivamente a sua velocidade em intervalos de 33MHz até chegar à velocidade necessária. O LongRun ajusta também a voltagem do processador, até 200 vezes por segundo, reduzindo assim em muito o consumo.

Outro factor que contribui para o baixo consumo dum sistema equipado com um Cruose é o facto de a Northbridge e o controlador de memória estarem integrados no processador, o que apesar de aumentar o número de transístores acaba por consumir menos energia pois são necessários menos chips.

Por consequência deste baixo consumo o Crusoe não precisa de qualquer tipo de ventoinha pois corre sempre a temperaturas significativamente mais baixas que a concorrência directa ( Pentium III ).

Comparação de temperaturas entre um Intel Pentium III e um TM5400 durante a reprodução de um DVD

Benchmarking

Testar a performance de um Crusoe não é tão linear como testar outro processador. Muitos aspectos da arquitectura do Crusoe previligiam o baixo consumo de energia e não alta performance o que faz com que o Crusoe não tenha performances comparáveis com os processadores topo de gama desenhados para terem alta performance.

Os gráficos seguintes ilustram a performance e o consumo energético de portáteis equipados com um TM5400 e Pentium III:

• NEC Versa DayLite w/ 600 MHz Transmeta Crusoe • NEC Versa UltraLite w/ 600 MHz Transmeta Crusoe • IBM i Series ThinkPad 1124 w/ 500 MHz Intel Pentium III • IBM x Series ThinkPad X20 w/ 600 MHz Intel Pentium III • Dell L400 w/ 700 MHz Intel Pentium III

Conclusão

A Transmeta com o seu processador Crusoe lançou algo de inovador, especialmente ao nível do seu Code Morphing Software. No entanto não tornaram público o código da componente de software que traduz as instruções. Assim, não é possível ter a certeza sobre que tradução é gerada para um dado código de entrada. De qualquer forma, mesmo que este código fosse divulgado e partindo do princípio que este código tem de facto algoritmos que analisam os padrões de execução dos programas, seria muito dificil prever uma tradução pois estas dependem não só do algoritmo do CMS mas também das características e histórico de execução de cada programa. Apesar das optimizações introduzidas no Crusoe nota-se que este tipo de arquitectura perde muitos ciclos de relógio em verificações, reexecuçóes de código e, principalmente, em tradução.

No entanto, a Transmeta não tem conseguido acompanhar a concorrência em termos de performance. Actualmente o Crusoe é significativamente mais lento que os processadores da Intel ou da AMD, e para além disso os processadores da concorrência destinados ao mercado dos portáteis têm melhorado muito ao nível de consumo energético, o que levou várias empresas a deixarem de produzir sistemas equipados com processadores Crusoe.

Questões Dado que toda a tradução das instruções de x86 para VLIW é feita pelo Code Morphing Software que é executado pelas mesmas unidades que têm de executar o código depois de traduzido, como é que o Crusoe consegue ter um desempenho ao nível das arquitecturas x86 que não têm de fazer este tipo de traduções? Este “speedup” é conseguido através de optimizações ao código. Durante a tradução o CMS vai optimizar o código e de seguida é guardado na translation cache de modo a não ter de ser traduzido novamente. O CMS guarda também um histórico de execução de modo a saber como vão ser tomados os branches e que partes do código serão reexecutadas, pois assim sabe quais são as partes do código cuja optimização mais beneficiará o tempo de execução.

Em que é que o LongRun do Crusoe é diferente do SpeedStep da Intel (Mobile Pentium III)? A tecnologia SpeedStep funciona alternanado a velocidade do processador apenas com base na fonte de energia (baterias ou tomada eléctrica), no caso de estar em modo de bateria reduz a velocidade (e voltagem) do processador de modo a economizar energia. O LongRun faz isto dinamicamente variando consoante o uso do processador, ou seja, sem precisar de qualquer intervenção por parte do utilizador e de modo a maximizar a “vida” das baterias sem perder desempenho devido a isso.

Fontes The Technology Behind Crusoe Processors , Alexander Klaiber LongRun Power Management, Marc Fleischmann Data Sheet for Crusoe Processor Model TM5400, Transmeta Corporation Transmeta Crusoe Explored, Jon Stokes http://www.arstechnica.com/cpu/1q00/crusoe/crusoe-1.html Transmeta Crusoe Preview At Platform 2000, Jon Simon http://www.sharkyextreme.com/hardware/articles/transmeta_crusoe/