Análise Semântica - Fase de Análise - Uma máquina virtual para uma linguagem concorrente int

5.3 Fase de An´alise

5.3.2 An´alise Semˆantica

A análise semântica tem como objetivo a verificação de tipos. É nesta fase que são de- tetados, por exemplo, os conflitos entre tipos, a ausência de declarações de registos e etiquetas. A implementação da análise semântica é apoiada no sistema de tipos apresentado na secção 3.3 e consiste em efetuar várias passagens sobre a árvore, visitando os nós relevantes da AST. Cada passagem na AST é feita com um visitante espec´ıfico obtido a

<<interface>> Type

isSubtype(type : Type) : boolean clone() : Type

replaceTypeVariable(tv : TypeVariable , type : Type)

unify(type : Type) : Type CodeType .... .... IntType .... .... TypeVariable .... .... LockType .... .... TupleType .... .... UninitializedType .... .... ExistsType .... .... StringType .... .... UniversalType .... ....

Figura 5.2: Diagrama de classes

partir da extens˜ao dos visitantes gerados pelo SableCC (pacoteanalysis).

Diagrama de Classes

A figura 5.2 mostra a hierarquia de classes que representa os tipos da linguagem e apoia a an´alise semˆantica.

O método isSubtype verifica se o tipo que chama o método é subtipo do tipo que é passado como parâmetro (type). Por exemplo, quando se atribui um valor (v) a uma posição (n) de um tuplo, o tipo do valor v tem ser subtipo do tipo da posição (n) do tuplo. Esta verificação é feita com o métodoisSubtype(para mais detalhe ver as regras de subtipos do apêndice B). O método clone cria uma réplica do tipo atual. Este método é necessário, para duplicar os tipos polimórficos a fim de serem instanciados. Tome- mos o seguinte exemplo: o tipo do bloco levantarGarfoDireito, do exemplo da figura 4.1, é ∀ e1::Lock({},{}).∀ d1::Lock({e1},{}).{r1:lock e1,r2:lock d1} requires {e1}. Ao efetuar a aplicação de valores da linha 6 (r6 := levantarGarfoDireito [g1]) o trinco polimórficoe1será substitu´ıdo porg1, e esta substituição é efetuada sobre uma réplica do tipo da etiqueta

levantarGarfoDireito. Após a aplicação levantarGarfoDireito [g1], o tipo do registo r6 fica

∀ d1::Lock({g1},{}).{r1:lock g1,r2:lock d1} requires {g1}. O replaceTypeVariable substitui, no tipo corrente, a variável de tipotvpelo tipotype. Este método utiliza-se quando é feita uma aplicação de tipos, pois neste caso é necessário efetuar a substituição das variáveis. Por fim, o método unify determina se dois tipos são equivalentes. Unify foi implemen- tado com base no algoritmo de unificação apresentado em [1]. A unificação de dois tipos

determina a substituição que torna os tipos idênticos.

A classe TypeVariable representa as variáveis de tipo. Para além dos métodos que implementa do interface Type, contém os métodos getName, getLessSet e getGreaterSet. O métodogetNamedevolve uma representação textual da variável. O métodogetLessSet

devolve o conjunto de trincos menores que a variável e o métodogetGreaterSetdevolve o conjunto de trincos maiores que a variável.

A classe UninitializedTyperepresenta o tipo não inicializado. Foi acrescentado o méto- do getType que devolve o tipo inicializado. A classe IntType representa o tipo inteiro e classe StringType representa o tipo string. A classe LockType representa o tipo lock. O métodogetLockdevolve o trinco correspondente ao tipo.

A classeTupleTyperepresenta o tuplo de tipos e cont´em os m´etodosgetLock, initialize

e uninitialized. Esta classe é iterável nos tipos do tuplo. O métodogetLockdevolve o trinco que protege o tuplo; o método initialize inicializa o tipo que está no ´ındice, passado por parâmetro, do tuplo e o método uninitialized torna o tipo que está no ´ındice, passado por parâmetro, do tuplo, num tipo não inicializado.

A classeCodeTyperepresenta o tipo bloco de código. Esta contém os métodosgetPermi ssions, getRegisters, isContainedAll e removeAll. O método getPermissions devolve o conjunto de permissões, e ogetRegistersdevolve a tabela de registos. O métodoisContainedAll

verifica se um conjunto de permissões (otherPermissions) contém todos os trincos fechados (permissions) do tipo atual. O método removeAllremove, de um conjunto de permissões (otherPermissions), todos os trincos fechados (permissions) do tipo atual.

A classe ExistsType representa o tipo existencial. Para além dos métodos que implementa do interfaceType, a classe ExistsType contém os métodosgetType, getVariablee

isLock. O m´etodogetTypedevolve o tipo abstra´ıdo contido no tipo existencial. O m´etodo

getVariable devolve a variável de tipo. O métodoisLock indica se a variável de tipo abstra´ıda é um trinco. A classeUniversalTyperepresenta o tipo universal. Esta classe contém exatamente os mesmos métodos que a classeExistsTypee com o mesmo significado.

Contextos

Contextos são estruturas de dados que guardam informação relevante para apoiar a análise semântica. A implementação dos vários contextos foi realizada através de conjuntos e mapas da linguagem Java. Usamos os conjuntos porque estes não permitem que haja elementos duplicados e têm as operações que precisamos: adicionar, remover e procurar elementos. Relativamente aos mapas, utilizámo-los porque precisamos de estabelecer uma relação entre identificadores e os seus tipos.

Os contextos de tipificação existentes no interpretador são: o conjunto de permissões, conjunto de trincos definidos, tabela Ψ que mapeia etiquetas com tipos e, por fim, a tabela Γ, que mapeia registos com os seus tipos.

trincos definidos (K) são Set<TypeVariable>, em que TypeVariable representa os trincos, Ψ éMap<Symbol, Type>, em queSymbolrepresenta uma etiqueta eTyperepresenta o tipo da etiqueta, e o Γ éMap<Register, Type>, em que Registerrepresenta um registo e Type

representa o tipo do registo.

Por fim, devido à definição de tipos, associamos o tipo ao nome da definição através da tabelaMap<Symbol, Type>, em queSymbolrepresenta o nome do tipo eTyperepresenta o tipo da definição.

Visitantes

A fase de análise semântica assenta em vários visitantes para efetuar as verificações ne- cessárias, de forma a averiguar se um programa é semanticamente correto. Os visitantes constru´ıdos foram os seguintes:DeclarationTypesVisitor, DeclarationVisitor,ExistsMainVisitor,

GlobalLockVisitor, InferRegistersVisitor, HeapValues, WellFormedTypes, TypeCheckValues e

TypeCheckerVisitor.

O visitante DeclarationTypesVisitor recolhe os tipos que são definidos globalmente e guarda-os na tabela de tipos globais. Para além disso, verifica se os tipos estão bem formados, passando o visitanteWellFormedTypessobre o tipo da definição.

O DeclarationVisitor preenche o mapa Ψ (Map<Symbol, Type>). Antes de adicionar uma nova etiqueta na tabela, verifica se esta já existe na mesma. Se a etiqueta não existir na tabela, é adicionada com o respetivo tipo. No caso da etiqueta já existir, é lançado um erro, pois não é permitido a existência de duas etiquetas com o mesmo nome.

O visitanteExistsMainVisitorverifica se existe a etiquetamain e se n˜ao requer registos nem permiss˜oes.

OGlobalLockVisitoré um visitante que recolhe as declarações de trincos globais de programas MIL. O visitante InferRegistersVisitor infere o número de registo dos programas. O visitanteHeapValuespercorre todas as etiquetas do programa e preenche os contextos. As etiquetas de um programa MIL podem ser compostas de 3 formas:

1. o tipo é um bloco de código e o valor um bloco de instruções;

2. o tipo ´e um tuplo de tipos e o valor um tuplo de valores;

3. o tipo ´e lock e o valor um valor de trincos.

Sobre cada tipo das etiquetas, é executado o visitante WellFormedTypes para analisar se o tipo está bem formado. No caso de uma etiqueta estar associada ao tipo lock e, no amontoado o valor do trinco ser 0, é adicionado o trinco ao conjunto de permissões. Por fim, no caso de o tipo ser um tuplo de tipos e o amontoado um tuplo de valores, é verificado se os tipos de cada um dos valores do tuplo de valores correspondem aos tipos do tuplo de tipos. Este visitante implementa as regras da figura B.1.

O visitanteWellFormedTypesverifica se um determinado tipo est´a bem formado. Este visitante ´e aplicado apenas sobre tipos e implementa as regras das figuras 3.4 e B.2.

O visitanteTypeCheckValuestem como finalidade obter o tipo dos valores, verificar se estes já foram declarados, ou seja, verifica se valores como etiquetas e registos já estão declarados. No caso de não estarem, é lançado um erro. É verificado ainda se os valores ?τ elock l estão bem formados. Este visitante implementa as regras da figura B.4. Por exemplo, na regra T-LABEL, ao receber a etiqueta l, devolve o seu tipo no caso de l existir em Ψ; caso contrário, é lançado um erro. No caso da regra T-REG, verifica-se se o registo

que esta recebe existe em Γ. Se existir, devolve o tipo do registo; caso contr´ario, lanc¸a um erro.

OTypeCheckerVisitor é o visitante principal da análise semântica e implementa as regras da figura 3.5.

Para além destes visitantes, foram constru´ıdos outros para proceder à inferência de anotações, de acordo com o algoritmo descrito no cap´ıtulo anterior. Os visitantes são:

LockDefinitionRestrictionsVisitor, SignatureRes trictionsVisitor, CodeBlockRestrictionsVisitore

RestrictionsEmitter.

O visitante LockDefinitionRestrictionsVisitor recolhe, através das anotações que se en- contram em programas MIL, as restrições decorrentes dessas anotações. Este visitante recolhe apenas as restrições no caso de existirem anotações nos programas. O visitante

SignatureRestrictionsVisitor percorre todas as assinaturas de blocos de código e gera novas anotações (variáveis de conjuntos) e novas restrições. É poss´ıvel gerar estas anotações e restrições de três modos diferentes: quando o tipo da assinatura é∀ l :: Lock, quando a declaração de um trinco no corpo do bloco é (λ :: Lock.τ ) ou quando é uma instrução

unpack. Neste visitante, s˜ao geradas duas vari´aveis de conjuntos (Ln e Ln+1, em que n

é um número gerado cada vez que é criada uma variável de conjuntos) e três restrições (Ln ≺ l, l ≺ Ln+1 e Ln ≺ Ln+1). Estas restrições são geradas de acordo com a fi-

gura 3.8. Este visitante recolhe apenas as restrições das variáveis de tipos que não contêm anotações, uma vez que, no caso de conter anotações, as restrições são recolhidas pelo visitante LockDefinitionRestrictionsVisitor.

O visitante CodeBlockRestrictionsVisitorrecolhe as restrições que possam ser geradas dentro dos blocos de código. Essas restrições são obtidas de acordo com o algoritmo apresentado no cap´ıtulo 4.

O visitante RestrictionsEmitter é o responsável por emitir as restrições para o Z3 recolhidas pelos visitantes anteriores.

Por fim, apresentamos os métodos que concretizam a análise semântica, ilustramos alguns métodos das regras de tipos de instruções. Em relação à regra T-FORK, esta será aplicada quando na árvore existir um nó que represente a instruçãofork. Para implementar a regra, o método a redefinir épublic void caseAForkInstruction (AForkInstruction node). Em primeiro lugar, é verificado se o tipo do registo r é do tipo bloco de código; no caso

de não ser, é lançado um erro. De seguida, verifica-se se as permissões requeridas pelo registo r estão no conjunto de permissões atual. Se não estiverem, é lançado um erro, caso contrário as permissões que são requeridas pelo registo r são retiradas do conjunto de permissões atual. Por fim, verifica-se se o bloco de código do registo r é subtipo do bloco de código atual.

No que diz respeito à instruçãonew, é necessário redefinir o métodopublic void case ANewInstruction(ANewInstruction node). A figura 5.3 ilustra o modo como esta regra foi implementada.

Se o tipo que a instrução recebe é um tuplo

1. Verifica se o tuplo est´a bem formado e no caso de n˜ao estar ´

e adicionado um erro `a lista de erros.

2. Transforma os tipos do tuplo em tipos n˜ao inicializados.

3. Adiciona a Γ o par (registo, tuplo com tipos não inicializados). Se o tipo que a instrução recebe é um trinco

1. Verifica se o tipo est´a bem formado e no caso de n˜ao estar, ´

e adicionado um erro `a lista de erros.

2. Adiciona o trinco ao conjunto de permiss˜oes Λ. 3. Adiciona a Γ o par (registo, trinco).

Sen˜ao

Adiciona o erro "´E esperado um tuplo de tipos ou um trinco" `

a lista de erros.

Figura 5.3: Algoritmo para a instruc¸˜aonew

Em relação à regra T-STORE, que corresponde ao nó AStoreInstruction, o método a redefinir é opublic void caseAStoreInstruction(AStoreInstruction node). A figura 5.4 ilustra o modo como esta regra foi implementada.

Em relação à regra T-GSL, esta corresponde ao nóAGetsetlockInstructionda AST. Para implementar esta regra, é necessário redefinir o métodopublic void caseAGetsetlockInstruc tion (AGetsetlockInstruction node). Em primeiro lugar, verifica-se se o registo é um trinco. No caso de ser falso, é adicionado um erro à lista de erros; caso contrário, é verificado se o trinco já se encontra no conjunto de permissões. No caso de se encontrar no conjunto, é adicionado o erro ”O trinco já se encontra fechado” à lista de erros. Por fim, é adicionado a Γ o par (registo, variável de tipo do trinco).

Para a regra T-DONE, é necessário redefinir o métodopublic void caseADoneInstruction (ADoneInstruction node), no qual o nó visitado representa a instrução done. Nesta regra, é apenas necessário garantir que não existe nenhum trinco fechado, ou seja, que o conjunto de permissões esteja vazio. No caso de este não estar vazio, então é adicionado o erro ”Os trincos devem ser abertos”.

Por fim, apresentamos como foram implementadas as regras de valores T-REG e T-

VALAPP. Para a regra T-REG, é necessário redefinir o métodopublic void caseARegisterVa lue(ARegisterValue node), no qual o nó visitado representa um registo. Inicialmente, é

Se o registo r n˜ao existe em Γ

Adiciona o erro "Registo não inicializado" à lista de erros Se o registo r’ não existe em Γ

Adiciona o erro "Registo não inicializado" à lista de erros Se o tipo do registo r não for um tuplo

Adiciona o erro "Espera um valor do tipo tuplo" à lista de erros Se o ´ındice n não é válido

Adiciona o erro "O ´ındice n está fora dos limites" à lista de erros Se Λ não contém o trinco λ

Adiciona o erro "O trinco não pertence às permissões" `

a lista de erros TUPLO <- tipo do registo r

TIPO <- tipo que est´a no ´ındice n do tuplo TIPO DESTINO <- tipo do registo r’

Se TIPO DESTINO não é subtipo de TIPO Adiciona um erro à lista de erros Senão

Inicializar TIPO

Adiciona a Γ o par (r, TUPLO)

Figura 5.4: Algoritmo para a regra T-STORE

obtido o tipo do registo através da tabela Γ, se o tipo for null, indica que o registo não foi inicializado antes, ou seja, é adicionado o erro ”Registo não inicializado”. Por fim, é devolvido o tipo do registo.

No que diz respeito à regra T-VALAPP, é necessário redefinir o método public void ca seAValApp(AValApp node), no qual o nó visitado representa a aplicação de valores. A figura 5.5 ilustra o modo como esta regra foi implementada.

Se o tipo τ n˜ao estiver bem formado

Adiciona o erro "O tipo τ não está bem formado" à lista de erros Se o tipo do valor v não é um tipo universal

Adiciona o erro "Espera um valor do tipo universal" `a lista de erros Se o λ do tipo universal ´e um trinco, ou seja: λ :: Lock

e o tipo τ n˜ao ´e um trinco

Adiciona o erro "Espera um trinco" `a lista de erros

No tipo τ ’ o τ ´e substitu´ıdo por λ, usando o m´etodo replaceTypeVariable. ´

E devolvido o tipo τ ’ com as substituic¸˜oes anteriores.

Trinco Vari´aveis Constante g1 L0 e L1 #b0000000100 g2 L2 e L3 #b0000000010 g3 L4 e L5 #b0000000001 e L6 e L7 #b0000001000 d L8 e L9 #b0001000000 l L10 e L11 #b1000000000 e1 L12 e L13 #b0000100000 d1 L14 e L15 #b0100000000 e2 L16 e L17 #b0000010000 d2 L18 e L19 #b0010000000

Tabela 5.1: Constantes e vari´aveis de trincos

No Z3 representamos os trincos e os conjuntos de trincos usando a teoria vetores de bits. O tamanho do vetor de bits coincide com o número de trincos declarado no programa. A cada trinco é atribu´ıdo um bit diferente, uma potência de 2. Um conjunto de trincos é representado por um vetor. Neste vetor, os bits correspondentes aos trincos que pertencem ao conjunto têm valor 1 e os restantes 0.

As funções e predicados que definimos são gerados para cada programa, uma vez que o seu tipo depende do número de trincos do programa e o Z3, como a generalidade dos SMT, não aceita definições polimórficas em funções.

De forma a ilustrar as funções e os predicados gerados para cada programa, apresentamos um exemplo, que usa o programa da figura 4.1. O exemplo contém dez trincos:

g1, g2, g3, e, d, l, e1, d1, e2 e d2. Os trincos são representados por constantes. Por exemplo, em Z3, atribu´ımos ao trincog1do bloco main a constante#b0000000100, enquanto ao trinco d do bloco levantarGarfoEsquerdo atribu´ımos #b0001000000, tal como podemos ver na tabela 5.1. Esta tabela apresenta as constantes e as variáveis de conjuntos a que cada trinco corresponde. Outra qualquer escolha de constantes para os trincos seria válida, desde que fossem usados valores distintos para cada trinco. Para representar o conjuntoL0, usamos a definição(declare−const L0 ( BitVec 10)), que declara uma constante com o nome da variável (L0) e o seu tipo (um vetor de bits de tamanho coinci- dente com o número de trincos do programa).

Para representar as restrições há que implementar predicados e funções que nos permitam escrever, por exemplo, que um trinco é menor do que um conjunto de trincos ou efetuar uma substituição de um trinco por outro num dado conjunto, de acordo com a representação que escolhemos para os trincos e para os conjuntos de trincos. O excerto seguinte define o predicadosubset e as funçõesremove e add, que são utilizados para definir a função de substituiçãosubs.

(define−fun subset ((S ( BitVec 10)) (S1 ( BitVec 10))) Bool

(= (bvand S S1) S))

(define−fun remove ((l ( BitVec 10)) (S ( BitVec 10))) ( BitVec 10) (bvand (bvxor All l ) S))

(define−fun add ((l ( BitVec 10)) (S ( BitVec 10))) ( BitVec 10) (bvadd l S))

(define−fun subs ((l( BitVec 10)) (m( BitVec 10)) (S( BitVec 10))) ( BitVec 10) (if (subset m S) (add l (remove m S)) S))

Para cada predicado e função, a primeira linha define a sua assinatura e a linha seguinte o seu corpo, escrito numa notação prefixa. As expressõesbvand, bvxore bvadd fazem parte da teoria do Z3 para vetores de bits. Foram definidas duas constantes que são utili- zadas na definição de funções e predicados. A constanteEmptyrepresenta um conjunto vazio ((define−const Empty ( BitVec 10) #b0000000000)) e a constante Allrepresenta um conjunto com todos os trincos de um programa ((define−const All ( BitVec 10) #b1111

111111)). O predicadosubset verifica se o conjunto S está contido no conjuntoS1. A assinatura indica que o predicado tem dois parâmetrosS eS1, ambos do tipo BitVec 10, enquanto o resultado da função, definido a seguir aos dois parâmetros, é um booleano. O corpo do predicado aplica, sobre ambos os conjuntos, a expressão bvand, de forma a devolver um conjunto que contenha elementos que ambos os conjuntos contêm. De seguida, é verificado se este conjunto é igual ao conjuntoS, pois caso seja, o conjunto S

est´a contido emS1.

A assinatura da funçãoremoveindica que a função tem dois parâmetros l eS, todos do tipo BitVec 10, tal como o retorno da função. O objetivo desta função é remover o elemento l do conjuntoS. Esta devolve um novo vetor de bits sem o elemento removido. A assinatura da função add é idêntica à assinatura da função remove. O objetivo desta função é adicionar o elementol ao conjuntoS. Esta devolve um novo vetor de bits com o elemento adicionado. A funçãosubsimplementa a substituição dempor l emS(S[m/l]). A assinatura indica que a função tem três parâmetros l,meS, todos do tipoBitVec 10, tal como o retorno da função. O corpo da função removeme adiciona l aS, casompertença aS. Caso contrário, comporta-se como a função identidade.

Os predicados setLessThanLock (apresentado na figura 5.6), lockLessThanSet (figura 5.7) esetLessThanSet(figura 5.8) representam a relação entre trincos e conjuntos. Os pre- dicadossetLessThanLock, lockLessThanSet e setLessThanSet definem, de forma expl´ıcita (com recurso a expressões condicionais), a associação entre trincos e variáveis sobre conjuntos, pois o Z3 não tem modo de especificar relações de dependência funcional entre diferentes valores que permitam estabelecer esta associação, de forma compacta e efici- ente.

O predicadosetLessThanLockverifica se um conjunto é menor que um trinco, ou seja, se o vetor de bitsSé menor que l. O predicado recebe três vetores de bits: o primeiro,S, é o conjunto que se pretende que seja menor que o trinco; o segundo, l, é o trinco em

(define−fun setLessThanLock

2 (( S ( BitVec 10)) ( l ( BitVec 10)) (Less l ( BitVec 10))) Bool

(if (= S Empty)

4 true

(∀ (( x ( BitVec 10))) 6 (if (subSet x S)

(if (= #b0000000100 x) ;corresponde a g1

8 (or (subSet #b0000000100 Less l) (subSet l L1))

(if (= #b0000000010 x) ;corresponde a g2

10 (or (subSet #b0000000010 Less l) (subSet l L3))

(if (= #b0000000001 x) ;corresponde a g3

12 (or (subSet #b0000000001 Less l) (subSet l L5))

(if (= #b0000001000 x) ;corresponde a e

14 (or (subSet #b0000001000 Less l) (subSet l L7))

(if (= #b0001000000 x) ;corresponde a d

16 (or (subSet #b0001000000 Less l) (subSet l L9))

(if (= #b1000000000 x) ;corresponde a l

18 (or (subSet #b1000000000 Less l) (subSet l L11))

(if (= #b0000100000 x) ;corresponde a e1

20 (or (subSet #b0000100000 Less l) (subSet l L13))

(if (= #b0100000000 x) ;corresponde a d1

22 (or (subSet #b0100000000 Less l) (subSet l L15))

(if (= #b0000010000 x) ;corresponde a e2

24 (or (subSet #b0000010000 Less l) (subSet l L17))

(if (= #b0010000000 x) ;corresponde a d2

26 (or (subSet #b0010000000 Less l) (subSet l L19)) true )))))))))) ;no caso de ser vazio

28 true) ;para continuar o ciclo

) 30 ))

Figura 5.6: Representa o predicadosetLessThanLock

questão; e o terceiro vetor é o conjunto de trincos menores de l. Para verificar se o conjuntoS é menor que o trinco l, temos de verificar se todos os elementos do conjunto são menores que o trinco. Se, por exemplo, o trincog1, (#b0000000100), é menor que l, temos de verificar se g1 pertence ao conjunto de trincos menores (Less l) de l ou se l

pertence ao conjunto de trincos maiores (L1) de l1.

O predicadolockLessThanSetverifica se um trinco é menor que um conjunto, ou seja, se l é menor que o vetor de bits S. Tal como o predicadosetLessThanLock, que recebe três vetores de bits: o primeiro, l, é o trinco em questão; o segundo, S, é o conjunto que se pretende que seja maior que o trinco l; e o terceiro vetor é o conjunto de trincos maiores de l. Para que o trinco l seja menor que o conjuntoS, temos de verificar se o trinco é menor que todos os elementos do conjunto. O que se confirma, se, por exemplo, o trincol é menor queg1, (#b0000000100) e se l pertence ao conjunto de trincos maiores

(define−fun lockLessThanSet

2 (( l ( BitVec 10))(S ( BitVec 10)) ( Greater l ( BitVec 10)))Bool

(if (= S Empty)

4 true

(∀ (( x ( BitVec 10))) 6 (if (subSet x S)

(if (= #b0000000100 x) ;corresponde a g1

No documento Uma máquina virtual para uma linguagem concorrente intermédia (páginas 45-58)