Suporte em software para o conjunto de instruções SPARC16

(1)

Suporte em software para o conjunto de instruções SPARC16

Bruno Cardoso Lopes

bruno.cardoso@gmail.com

Laboratório de Sistemas de Computação Instituto de Computação

UNICAMP

Suporte em software para

o conjunto de instruções

SPARC16

(2)

Agenda

• Introdução

• Trabalhos Relacionados

–Métodos de compressão de código –Conjuntos de instruções de 16-bits

• Descrição da proposta

– Objetivos – Etapas

– Desafios

(3)

Introdução

• SOCs estão se tornando complexos

• Techos de código maiores

• RISC = baixa densidade de código

• Alta necessidade de memória

• Memória recurso raro

(4)

Trabalhos relacionados

• Duas soluções para memória:

–Compressão de código.

–Criação de conjuntos de instruções de 16 bits a partir dos modelos RISC de 32 bits (MIPS16 e Thumb)

(5)

Conjunto de instruções de 16-bits

• DLX

–Criada por Hennessy e Patterson

–Primeira a ter uma extensão 16-bits –Razão de compressão: 62%

–5% de perda de desempenho

(6)

Conjunto de instruções de 16-bits

• Thumb

–Extensão 16-bits do ARM –Troca de modo (BX)

–8 registradores, 1 stack pointer e 1 link register –Thumb 2, presença de instruções privilegiadas. –Razão de compressão: 70% –Ganho de 30% em desempenho (barramento de 16 bits), 10% de perda

(7)

Conjunto de instruções de 16-bits

• Thumb:

(8)

Conjunto de instruções de 16-bits

• Mips16

–Versão 16 bits do MIPS –Troca de modo (JALX)

–Redução do tamanho de imediatos (16 para 5) –8 Registradores visíveis e instruções especiais

para outros registradores (MOVR32)

–Deslocamento de offsets em Loads/Stores –Endereçamento relativo a SP e PC

–Instrução EXTEND.

(9)

Conjunto de instruções de 16-bits

• Mips16

(10)

Compressão de Código

• Diversos métodos:

–Técnicas em software –Técnicas em hardware

• Software

–Fraser e Proebsting: Representação compacta do código original e interpretador gerado.

–Liao: Baseado em dicionário, bloco de instruções mais executados transformados em

procedimentos, substituidos por chamadas ao dicionário.

(11)

Compressão de Código

• Hardware

–Compressão em software e descompressão no hardware.

–PDC (Processor-Descompressor-Cache) –CDM (Cache-Descompressor-Memory)

(12)

Compressão de Código

• Hardware

–PDC possui melhores resultados em desempenho e consumo de memória

–Wolfe e Chanin: Huffman e CDM –Lekatsas: Dois métodos

• Instruções classificadas em 4 classes, cada

uma recebe um método de compressão. PDC com um pipeline para cada classe.

(13)

Compressão de Código

• Hardware

–Lekatsas:

• PDC com método de dicionário: contagem estática do número de instruções. 25% de

aumento de desempenho, 35% na redução do código.

–Benini: Método de dicionário, perfil dinâmico de execução das instruções. Razão de compressão de 72% e 28% no ganho de desempenho.

(14)

Compressão de Código

• Hardware

–IC-UNICAMP: Método baseado em dicionário

• Mistura entre elementros estáticos e dinâmicos • PDC

• I-Cache com presença de bursting

• Descompressão simultânea aos bursts • Razão de descompressão: 72% a 88% • Ganho de desempenho: até 45%

(15)

Compressor

• Hardware

–IC-UNICAMP: 15

(16)

Descrição da Proposta

• Objetivos:

–Criar uma representação de 16 bits para as instruções do processador SPARCv8.

–Implementação do suporte em software para emissão de código.

• Alterações na etapa de geração de código de um compilador com suporte a arquitetura SPARC.

(17)

Escolha do SPARCv8

• Processador com especificação aberta.

• Casos de sucesso com outros dois

processadores RISC (Mips e ARM).

• Mercado (Leon 3, Agência Espacial

Europeia).

• Grande potencial de compressão.

(18)

(19)

Escolha do SPARCv8

• Mesmo em arquiteturas RISC, nem todas

instruções são utilizadas pelos compiladores.

• Análise das instruções do MIPS para o

SPEC2006.

• Como nem todas são utilizadas, é mais fácil realizar o corte na

instruções.

(20)

(21)

Etapas

• Escolha do subconjunto SPARCv8.

• Análise de instruções privilegiadas

–Impacto da sua utilizaçao em rotinas que geram gargalo em um sistemas operacional.

• Codificação do SPARC16

–Facilitando o processo de decodificação em

hardware.

• Modelo que permita coexistência e troca

entre os modos SPARC16 e SPARCv8

–Inclusive entre procedimentos diferentes.

(22)

Etapas

• Escolha de um compilador

• Implementação do suporte básico a 16 bits

neste compilador.

• Implementação de otimizações específicas

para o SPARC16.

(23)

Subconjunto SPARC16

• Análise estatística da ocorrência de

instruções em benchmarks consagrados:

MediaBench, MiBench e SPEC2006.

• Benchmarks compilados com pelo menos 2

compiladores diferentes.

• Contagem estática e dinâmica.

(24)

Instruções privilegiadas

• Análise diferenciada de instruções

privilegiadas.

–Mapeamento de I/O em memória.

–Campos especias para ASI (Address Space

Identifier)

(25)

Codificação do conjunto

• Dados provenientes da análise

–Tamanho médio de imediatos –Registradores por bloco básico

• Determinar:

–Quantidade de registradores visíveis –Tamanho da janela de registradores –Quantidade de operandos

(26)

Compilador

• Ponto crítico do projeto.

• Escolha do compilador adequado

–Suporte a SPARC

–Código Aberto (LLVM, GCC).

• Modificação da etapa de geração de código

(27)

Compilador

• Teste da geração de código:

–SAV (Sparc Application Verifier) benchmark, fornecido pela SPARC International

• Implementação de algumas otimizações:

–Preenchimento de delay slots –Otimização de load/store

–Utilização de small sections

(28)

Compilador

• LLVM (Low Level Virtual Machine)

–Código aberto

–Otimizações agressivas (LTO) –Back-end SPARC

–Projeto moderno, baixa curva de aprendizado

–Facil integração de novos recursos e otimizações –Back-ends pouco estáveis

(29)

Compilador

• GCC (Gnu Compiler Collection)

–Código aberto

–Possui cerca de 50 back-ends estáveis –Otimizações conservativas

–Alta curva de aprendizado (presença de código legado)

–A implementação e teste de novos recursos são demorados.

(30)

Compilador

• Entendimento dos seguintes componentes:

–Estruturas de dados da representação intermediária

–Algoritmos de geração de código independente de arquitetura.

–Estruturas de dados e callbacks genéricos customizados em cada arquitetura.

(31)

Desafios

• SPARCv8 possui janela de registradores

–Redução do tamanho da janela

• Densidade de código do SPARCv8 é maior

que o das outras arquiteturas

–Dificuldade na decisão das instruções.

(32)

(33)