Um conjunto reutilizável de deĄnições básicas foi desenvolvido para mode- lar conceitos e tipos de dados de hardware. Os modelos contêm deĄnições para representar: registradores, interrupções, portas de entrada e saída, memória e ins- truções. Esses conceitos estão agrupados em projetos de desenvolvimento e estão disponíveis como bibliotecas. Assim, o espaço de trabalho é composto da seguinte forma:
Power: contém a deĄnição padrão de exponenciação inteira, bem como alguns lemas básicos. Por exemplo, valores de diferentes potências de dois. Esse módulo é essencial para estabelecer a relação entre os vetores de bit e arit- mética de números inteiros. Além disso, o ambiente de veriĄcação necessita
2 Atelier B é uma ferramenta de suporte que provê vários recursos para o gerenciamento dos
projetos B. As diferenças entre as gramáticas do ProB e Atelier B estão em:<http://www.
Capítulo 3. Tradução B para linguagem de máquina especíĄca 42 deste componente para oferecer suporte à avaliação de expressões com o operador de potência, pois, apesar do operador de exponenciação compor a notação B, as regras do provador automático de teoremas do Atelier B são insuĄcientes para este propósito.
Biblioteca de hardware: deĄne vetores de bit, as funções básicas para ma- nipular vetores de bit e importantes lemas relacionados. Os vetores de bits têm tamanhos deĄnidos (8 ou 16 bits) e, embora seja possível generalizar a deĄnição para tamanhos quaisquer, esta generalização utiliza recursos que impedem a animação.
Biblioteca de tipos: deĄne subconjuntos de naturais e inteiros representados com 8 bits e 16 bits, funções básicas de conversão entre os tipos e vetores de bit e lemas importantes.
Plataforma: deĄne as funções da unidade lógica e aritmética, a unidade de memória, os registradores e as instruções de montagem.
O diagrama da Ągura 8oferece uma visão geral mostrando a hierarquia de dependência relacionando os componentes e as bibliotecas. O componente principal (Z80) inclui uma instância do componente de memória, visualiza as deĄnições das bibliotecas e do componente ALU. No projeto das bibliotecas, as dependências dos componentes BIT_VECTOR_ARITHMETICS e BIT_VECTOR_DEFINITION foram removidas a Ąm de possibilitar a animação, mas tais componentes foram mantidos, pois podem ser reusados em outros projetos com propósitos diferentes.
Capítulo 3. Tradução B para linguagem de máquina especíĄca 43
Figura 8 Ű Diagrama estrutural dos componentes do microcontrolador.
As duas bibliotecas foram desenvolvidas com o objetivo de serem reusá- veis, pois também foram utilizadas na modelagem de outros microcontroladores (PIC16C432 e M8051 ). As bibliotecas e a plataforma serão apresentados nas pró- ximas seções.
3.1.1
Bibliotecas de tipos de dados e hardware
A especiĄcação do conjunto de instruções depende da deĄnição de vários tipos, ilustrados na tabela 2. Para cada tipo, várias funções são deĄnidas, assim como funções de conversão entre diferentes tipos.
Nome do tipo Intervalo Tamanho Biblioteca
BIT 0..1 1 bit Hardware
BYTE 00000000..11111111 1 byte Hardware
BV16 0000000000000000..1111111111111111 2 bytes Hardware
UCHAR 0..255 1 byte Tipos
SCHAR -128..127 1 byte Tipos
USHORT 0..65535 2 bytes Tipos
SSHORT -32768..32767 2 bytes Tipos
Tabela 2 Ű Detalhes dos tipos de dados básicos.
A seguir, temos as deĄnições de duas funções de conversão entre os tipos BYTE e UCHAR. As funções ����_��ℎ�� e ��ℎ��_���� utilizam as constantes
Capítulo 3. Tradução B para linguagem de máquina especíĄca 44 contidas em Power, para representar a potência, com o objetivo de facilitar a avaliação da expressão pelo provador. Veja a deĄnição na Ągura9.
1 byte_uchar =
2 %(v0).( v0 : BYTE | pow2_7*v0(8) + pow2_6*v0(7) + pow2_5*v0(6)
3 + pow2_4*v0(5) + pow2_3*v0(4) + pow2_2*v0(3) + pow2_1*v0(2) + pow2_0*v0(1))
4
5 uchar_byte =
6 %(v0).( v0 : UCHAR | [(v0 mod pow2_1)/pow2_0, (v0 mod pow2_2)/pow2_1,
7 (v0 mod pow2_3)/pow2_2, (v0 mod pow2_4)/pow2_3,
8 (v0 mod pow2_5)/pow2_4, (v0 mod pow2_6)/pow2_5,
9 (v0 mod pow2_7)/pow2_6, (v0 mod pow2_8)/pow2_7])
Figura 9 Ű Funções de conversão entre byte e inteiro sem sinal.
Essas funções são deĄnidas através do formalismo do cálculo lambda. A conversão do byte [01010101] pode ser representada através da aplicação da função ����_��ℎ��([01010101]) que resulta em: 27
*0 + 26 *1 + 25 *0 + 24 *1 + 23 *0 + 22 *1 + 21 *0 + 20 *1 = 85.
A primeira modelagem proposta (MEDEIROS JR.; DÉHARBE, 2009) de- pendia de um componente (BIT_VECTOR_DEFINITION) para representar um tipo geral de vetor, tendo como parâmetro o tamanho, e as funções para manipu- lação desses vetores. Um elemento do tipo BIT_VECTOR poderia ter tamanho arbitrário, o que não pode ser representado no animador. As funções para os ve- tores de bits com tamanho deĄnido (BYTE e BV16) reusavam as deĄnições de BIT_VECTOR. Consequentemente, a adição do suporte à animação com o ProB também exigiu a remoção da dependência de funções não tratadas. Essas duas funções (����_��ℎ�� e ��ℎ��_����) foram redeĄnidas sem utilizar diretamente as deĄnições de funções de BIT_VECTOR. Similarmente, várias outras funções e lemas foram redeĄnidos para outros tipos de dados.
Um aspecto ignorado nesta primeira modelagem foi a utilização de funções deĄnidas através de propriedades, onde o tipo de cada função é veriĄcado somente no nível de implementação B. Como esta modelagem contém somente máquinas B, não há garantia formal de que o valor dado à função pertence ao tipo declarado. Isto acontece especiĄcamente no Atelier B, pois nele não é gerada a obrigação de prova que veriĄca o tipo de cada função. Contudo, essa obrigação de prova existe de acordo comSchneider(2001). Diante desse contexto, a modelagem passou por uma
Capítulo 3. Tradução B para linguagem de máquina especíĄca 45 reformulação para veriĄcar o tipo da função deĄnida na cláusula de propriedades. A solução no Atelier B foi adicionar uma asserção forçando a veriĄcação do tipo de cada função.
O exemplo a seguir esclarece o aspecto ignorado no Atelier B. Por padrão, o Atelier B não gera obrigações de prova para veriĄcar o tipo de funções deĄnidas na cláusula PROPERTIES de uma máquina. Por exemplo, a deĄnição da função abaixo (3.1) não gera uma obrigação de prova para veriĄcar a consistência da deĄnição.
��� ∈ ¶0, 1♢ ⊃ ¶0, 1♢ ∧ ��� = Ú(�).(� ∈ ¶0, 1♢♣� + 1) (3.1)
No entanto, essa deĄnição é inconsistente quando ���(1) = 2, porque não satisfaz a deĄnição do tipo da função (2 ̸∈ ¶0, 1♢).
As propriedades dessas funções são veriĄcadas somente quando a especiĄca- ção está no nível de implementação B. Por outro lado, a modelagem dos componen- tes relacionados ao microcontrolador era representada somente através de máquinas B. Para evitar tais inconsistências, as deĄnições de tipo das funções (no caso do exemplo: ��� ∈ ¶0, 1♢ ⊃ ¶0, 1♢) foram declaradas na cláusula ASSERTIONS, obrigando a prévia veriĄcação de tipos. Isso provocou a geração de várias novas obrigações de prova correspondentes e um novo processo de veriĄcação.
A seção seguinte (3.2) apresenta a modelagem reformulada de um micro- controlador.