Giovanny Lucero giovanny@ufs.br Departamento de Estatística e Informática Universidade Federal de Sergipe Compiladores Registros de Ativação Giovanny Lucero giovanny@ufs.br

Introdução Funções podem ter variáveis locais Criadas dinamicamente na “entrada” da função Várias instâncias da mesma função podem existir ao mesmo tempo (quando?) Cada instância tem suas próprias vars. locais int f (int x) { int y; y = x+x; if (y<10) y = f(y); else y = y-1; return y }

Pilha e funções de alta ordem Em muitas linguagens imperativas temos: Variáveis locais são destruídas na saída Alocação e destruição de variáveis locais tem um comportamento LIFO (pilha) Com aninhamento de funções e funções de alta ordem (juntos), não é assim. Ex. def f(x) : def g(y) return x + y; return g; a = f(4); b = a(5); -- uma função onde “x” não foi destruído

Registros de Ativação Também conhecidos como stack frames Representa o formato dos dados manipulados na execução de um subprograma Uma instância de um registro de ativação é criada dinamicamente na chamada a um subprograma Pilha de chamadas é uma pilha de frames Implementada como um “array” com um ponteiro indicando o topo da pilha

O projeto dos frames deve levar em conta O conjunto de instruções da arquitetura Fabricantes prescrevem um frame padrão Permite inter-operação entre diferentes linguagens A linguagem sendo compilada Deve existir uma infra-estrutura em tempo de execução Infra-estrutura é definida em tempo de compilação

Modelo de um stack frame Argumentos de entrada Vars. locais de sub-blocos Argumentos Registradores salvos Variáveis Locais ponteiro para o topo do registro de ativação do chamador Temporais Registradores ponteiro para a base do registro de ativação do pai estático Vínculo dinâmico Para que o Vínculo Estático? ... para localizar as variáveis não locais (seguindo o caminho dos ancestrais estáticos) Ponteiro do frame não é necessário: para isto temos o vínculo dinâmico Nem sequer o vínculo dinâmico é preciso quando os tamanhos dos frames são conhecidos em tempo de compilação Vínculo Estático Endereço de retorno ponteiro para o código Argumentos Argumentos de saída

Modelo de um stack frame Endereços mais altos Argumentos Variáveis Locais Temporais Registradores crescimento da pilha Vínculo dinâmico Para que o Vínculo Estático? ... para localizar as variáveis não locais (seguindo o caminho dos ancestrais estáticos) Ponteiro do frame não é necessário: para isto temos o vínculo dinâmico Nem sequer o vínculo dinâmico é preciso quando os tamanhos dos frames são conhecidos em tempo de compilação Vínculo Estático Endereço de retorno Endereços mais baixos Argumentos

Modelo de um stack frame ponteiro do frame (FP) Possui dois ponteiros para . FP que aponta para o início do Frame atual e SP que aponta para o final da pilha. Argumentos Variáveis Locais Temporais Registradores Vínculo dinâmico Para que o Vínculo Estático? ... para localizar as variáveis não locais (seguindo o caminho dos ancestrais estáticos) Ponteiro do frame não é necessário: para isto temos o vínculo dinâmico Nem sequer o vínculo dinâmico é preciso quando os tamanhos dos frames são conhecidos em tempo de compilação Vínculo Estático ponteiro da pilha (SP) Endereço de retorno Argumentos

Funcionamento ponteiro do frame (FP) 1. O subprograma atual faz chamada a um outro subprograma. Argumentos Variáveis Locais Temporais Registradores Vínculo dinâmico Vínculo Estático Endereço de retorno ponteiro da pilha (SP) Argumentos

Funcionamento 2. Um novo frame é alocado. Os ponteiros FP e SP devem ser atualizados. O novo FP = FrameSize - SP. O antigo FP é guardado em memória SP sempre aponta para o início da pilha. Argumentos Variáveis Locais Temporais Registradores ponteiro do frame Vínculo dinâmico Vínculo Estático Endereço de retorno Argumentos Variáveis Locais Temporais Registradores Vínculo dinâmico Vínculo Estático Endereço de retorno ponteiro da pilha Argumentos

Funcionamento 3. Ao desalocar o frame. FP e SP são restaurados ponteiro do frame Argumentos Variáveis Locais Temporais Registradores Vínculo dinâmico Vínculo Estático ponteiro da pilha Endereço de retorno Argumentos

Vínculo estático serve para acessar variáveis não locais O formato do registro de ativação é estático mas seu tamanho pode ser dinâmico. Por que? Vínculo estático serve para acessar variáveis não locais Vínculo dinâmico para destruir (desempilhar) o corrente registro de ativação, no fim da chamada variáveis stack dinâmicas (arrays por exemplo) .. Para que o Vínculo Dinâmico? ... para destruir o registro corrente. Note que o reg. de ativação do pai dinâmico é sempre o imediatamente “acima” na pilha. (lembre que a pilha é desenhada ao revés) Por que é necessário? Por que o tamanho do reg. de ativ. nem sempre é conhecida em compilação (ex. arrays dinâmicos) nem em execução pois as vezes o reg. mantém também descritores de outros recursos que o subprograma tá usando (ex. arquivos, sockets, ....)

Vínculos estático e dinâmico Main var x .. A C x C() B A() B() frames ... Main x B A C estático dinâmico

Registradores Muito mais velozes que memória vars. locais, valores intermediários, etc. Precisam ser salvos para reuso por outra função Quem salva, quem restaura? Caller-save Quando a “função que chama” é responsável por salvar/restaurar callee-save Quando a “função chamada” é responsável por salvar/restaurar Salvar pode ser desnecessário Var. local que não vai ser usada após uma chamada È preciso um alocador de registradores Alocador de registradores: aloca em tempo de compilação

Passagem de parâmetros Alguns parâmetros (até 4, por ex.) são passados em registradores Salva-se (do chamador) só quando necessário Procedimentos folhas Alocação interprocedural O parâmetro é uma variável morta no momento da chamada a outra função Janelas de registradores (oferecidos por algumas arquiteturas) Resultado de função é devolvido em registrador Para evitar tráfico de memória Obs. Para procedimentos nas folhas é interessante que quem salve seja o “chamado” .... Isto é, salva-se só quando se chega a saber (que quem chama) não é folha ... Resultado em registrador ( pois o chamador pode usar depois no cálculo de alguma expressão, por ex.)

Endereço de retorno Quando g chama f, eventualmente f termina Aonde volta o fluxo de controle? Onde passar o endereço de retorno? Na pilha (máquinas dos anos 70) Em registrador Tráfico evitado em procedimentos folha

Variáveis residentes no frame Em resumo, registradores contém Parâmetros, endereço de retorno, retorno da função, variáveis locais e valores intermediários Usa-se obrigatoriamente memória quando: A variável é passada por referência Variável de um procedimento mais externo é acessada por procedimento aninhado. O valor é grande A variável é um array – aritmética para acesso O registrador é necessário para outro propósito Não há suficientes registradores Variável passada por referência => precisa obrigatoriamente de um endereço!. Variável “global” ou mais externa => acesso num procedimento interno precisa da sua referência (pois não iria saber qual é o registrador em que ela está). O operador & de C permite pegar os endereços de variáveis. Na declaração de uma variável não sabemos se ela escapa. Um compilador industrial atribui uma locação provisória para depois decidir onde realmente irá a variável.

Variáveis residentes no frame Usamos sempre memória para variáveis que escapam Variáveis escapadas são aquelas passada por referência, seu endereço é pego (& C/C++), ou é acessada por uma função aninhada Cálculo de escapes pode requerer duas passadas Quando é decidido se uma variável vai num registrador? Na elaboração da declaração? Variável passada por referência => precisa obrigatoriamente de um endereço!. Variável “global” ou mais externa => acesso num procedimento interno precisa da sua referência (pois não iria saber qual é o registrador em que ela está). O operador & de C permite pegar os endereços de variáveis. Na decl. de uma var. não se sabe se ela escapa ou não. Na declaração de uma variável não sabemos se ela escapa. Um compilador industrial atribui uma locação provisória para depois decidir onde realmente irá a variável.

Implementação dos Frames Frames dependem da máquina, mas queremos deixar a análise semântica independente da máquina usada package Frame; public abstract class Access {...} public abstract class Frame { abstract public Frame newFrame(Label name, List /*of bool*/ formals); public Label name; public List /*of Access*/ formals; abstract public Access allocLocal(boolean escape); .... } Frame segue o padrão factory method. Não se sabe qual é a implementação ... portanto não sabemos que construtor usar Obs. Access é um TAD Frame usa Factory method

Modularização dos Frames Camadas de abstração Frame, Acess, Temp e Label provêem visões independentes de máquina Translate permite separar análise semântica da tradução lps.semantica Translate lps.traducao Frame Access Temp Label frame temp

Implementação dos Frames Encapsula A locação dos parâmetros formais O número de variáveis locais alocadas O “endereço” do código da função