Wiki**3 - User contributions [en]

Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega "zero"

2026-05-22T16:07:07Z

Root:

{{PRJCompiladoreAvisosEN20252026}}
{{PRJCOMandatory20252026}}
{{TOCright}}

== Pauta ==
Aqui: https://bit.ly/co26-pautas (ver Fénix)

== Prazo de Revisão ==
'''PAUTA FECHADA'''


Os resultados da entrega inicial podem ser revistos, nos horários de dúvidas, até à data da entrega intermédia.

== Critérios de Avaliação ==
'''A entrega inicial é obrigatória.'''

'''LER COM ATENÇÃO'''

'''A avaliação é realizada sobre a versão existente no repositório no final do prazo para a entrega inicial. Projectos que não apresentem alterações relativamente ao conteúdo inicial do repositório não serão considerados.'''

'''Considerando que é um passo crucial na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo actual.'''

Ver também: [[Compiladores/Projecto de Compiladores/Avaliação do Projecto (Época Normal)]].

Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina.

Estas condições são aplicáveis à data da entrega inicial.

'''Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.'''

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #BDDD8D;" | '''VALORAÇÕES'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Existem '''2 valores''' (dos 20 disponíveis para o projecto) associados a esta entrega:

* '''gestão do projecto: 0.5 valores'''
** projecto com a estrutura correcta no repositório GIT: 0.25 valores (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório GIT)
** projecto compila e produz compilador "p6" ("p6", com letras minúsculas: variações correspondem a "não compilação"): 0.25 valores

'''Se o projecto compilar''', poderão ser atribuídos mais '''1.5 valores''' (desenvolvimento do compilador), distribuídos como se segue:

* '''Classes dos nós do compilador (completo): 1.0 valores'''
** Reutilização dos nós da CDK (simples ajuste do Simple)
** Definição ou extensão de elementos existentes (simples ajuste do Simple)
** Definição de novas declarações/definições (variáveis/funções) (completo)
** Definição de novas instruções (completo)
** Definição de novas expressões (completo)
** Definição de outros elementos (completo)
** Sugere-se (por simplicidade de gestão do código) a separação das várias classes de nós em namespaces coerentes (à la Simple)
** Não é necessário criar as regras na especificação Bison para criar os nós (se for feito, é conveniente para o progresso do projecto, mas não é avaliado nesta entrega)

* '''Métodos dos "visitors" (completo): 0.5 valores'''
** Reutilização de métodos já definidos (simples ajuste do Simple)
** Definição de todos os métodos do_X (correspondentes ao nó da class X) em todos os visitors (simples extensão do Simple)
** Métodos novos podem estar vazios, mas devem existir
** Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (mesmo que não modificados numa primeira instância)
** A presença de implementações de semântica no postfix_writer (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega
|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #FFCC99;" | '''PENALIZAÇÕES'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Existem penalizações relativas à (deficiente) execução do projecto.

São considerados os seguintes aspectos preliminares:

# A linguagem do projecto contém a linguagem Simple, pelo que não há razão para não utilizar completamente o compilador Simple, eventualmente com pequenas alterações (incluindo a passagem de binário para ternário).
# A semântica da linguagem do projecto contém a da linguagem Simple, pelo que a implementação de alguns aspectos da linguagem do projecto não requer qualquer reimplementação relativamente ao Simple.
# O compilador Simple foi fornecido completamente funcional, assim como a versão inicial do compilador do projecto no respositório GIT (igual ao Simple e apenas alterado, para ter um nome apropriado).
# A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples).
# Os métodos (na sua maioria, vazios) dos "visitors" são simples paralelos com as classes dos nós e os que não estão vazios são quase 100% reutilizáveis na nova linguagem.
# O compilador é obrigatoriamente desenvolvido em C++, fazendo-se uso do material de apoio.

Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:

* Destruição de funcionalidade do compilador Simple sem substituição por funcionalidade equivalente do compilador do projecto: '''2 valores'''
* Utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras): '''penalização máxima de 1 valor'''
* Não utilização de qualquer material obrigatório ou não satisfação dos critérios mínimos: '''2 valores e considera-se entrega não realizada (implica exclusão da avaliação)'''
|}

== Legenda ==



'''Os alunos são encorajados a compreender/verificar/corrigir os problemas reportados, especialmente nos casos em que exista anotação explícita na pauta.'''

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Anotações da tabela'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |
* dups: cópia de código que já está disponível na CDK (não devem existir estas cópias: devem ser usadas as classes da CDK)
* pointer: este nó não deve existir
* loop/while: problemas vários com o nó de iteração
* lvals: más utilizações de left-values (um left-value é a designação de um endereço de escrita)
* index: problemas com os nós de indexação (e.g. não são lvalues, faltam expressões)
* decls: faltam nós correspondentes a declarações ou têm problemas (e.g. confundidas com expressões, problemas com tipos, etc.)
* func decls: problemas com declarações de funções
* function/func defs: faltam nós correspondentes a definições de funções ou têm problemas: e.g. faltam tipos, têm relações com lvalues (não devem existir)
* vars: faltam nós correspondentes a declarações/definições de variáveis ou têm problemas: e.g. faltam tipos, têm relações com lvalues (não devem existir)
* exprs: faltam expressões (tipicamente, faltam operadores, chamadas a funções)
* file/public/use/qualifier: nós que não devem existir
* print/write: problemas com o nó de escrita
* read/input: o nó de leitura deve ser uma expressão e não uma instrução; ao contário do que acontece no Simple, não tem um left-value associado
* call: este nó tem de ser uma expressão que tem como atributos um nome de função e uma sequência de argumentos
* alloc/objects: este nó tem de ser uma expressão
* address: este nó é uma expressão aplicável a um left-value
* types: não foram os usados os tipos da CDK (basic_type e subclasses) para representar os tipos de dados da linguagem
* [outras anotações específicas]: contactar o professor responsável

|}

[[category:Compiladores 2025-2026]]
[[category:Compiladores]]
[[category: Ensino]]

Compiladores/Pautas 2025-2026

2026-05-22T16:06:53Z

Root: /* Pautas do Projecto (época normal) */

{{TOCright}}
Além dos resultados de avaliação, as páginas das pautas contêm também os critérios de avaliação e aprovação.
* {{PautaAberta}} indica avaliação em curso
* {{PautaFechada}} indica avaliação terminada (classificações definitivas)
* {{ProvaPorRealizar}} indica avaliação prevista

== Pautas da Disciplina ==

* [[Compiladores/Pautas 2025-2026/Pauta Global da Disciplina|Pauta Global da Disciplina]] -- próxima avaliação: (ver Fénix)
* {{PautaAberta}} [[Compiladores/Pautas 2025-2026/Pauta das Aulas Práticas|Pauta das Aulas Práticas]] (época nornal)

== Pautas do Projecto (época normal) ==

* {{PautaFechada}} [[Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega "zero"|Pauta do Projecto: Entrega "zero"]]
* {{PautaAberta}} [[Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega Intermédia|Pauta do Projecto: Entrega Intermédia]]
* {{ProvaPorRealizar}} [[Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega Final|Pauta do Projecto: Entrega Final]]
* [[Compiladores/Pautas 2025-2026/Pauta Global do Projecto|Pauta Global do Projecto]]

[[category:Compiladores 2025-2026]]
[[category:Compiladores]]
[[category: Ensino]]

Compiladores/Projecto de Compiladores/Projecto 2025-2026/Manual de Referência da Linguagem P6

2026-05-21T07:54:45Z

Root: /* Gramática */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}


'''ÉPOCA NORMAL'''

'''P6''' é uma linguagem imperativa. Este manual apresenta de forma intuitiva as características da linguagem: [[#Tipos de Dados|tipos de dados]]; [[#Manipulação de Nomes|manipulação de nomes]]; [[#Convenções Lexicais|convenções lexicais]]; [[#Gramática|estrutura/sintaxe]]; [[#Funções|especificação das funções]]; [[#Instruções|semântica das instruções]]; [[#Expressões|semântica das expressões]]; e, finalmente, [[#Exemplos|alguns exemplos]].

= Tipos de Dados =

A linguagem é fracamente tipificada (são efectuadas algumas conversões implícitas). Existem 4 tipos de dados básicos, apenas alguns dos quais são compatíveis com a [https://en.wikipedia.org/wiki/C_(programming_language) linguagem C]. O alinhamento em memória binária é sempre a 32 bits. Note-se que alguns dos tipos de dados são ternários e devem ser manipulados com as funções das ALUs disponibilizadas.

* Tipos numéricos: os inteiros são [https://en.wikipedia.org/wiki/Balanced_ternary ternários equilibrados], ocupam 40 trits (empacotados em 64 bits); os reais são ternários e estão representados no formato [https://arxiv.org/abs/2404.18603 Takum] (note-se que a definição neste artigo é para uma representação binária e não é exactamente a que é implementada pelas ALUs ternárias em uso no projecto), ocupam 80 trits (empacotados em 128 bits).
* As cadeias de caracteres são vectores de caracteres binários terminados por [https://en.wikipedia.org/wiki/ASCII ASCII] NUL (carácter com o valor zero). Variáveis e literais deste tipo só podem ser utilizados em atribuições, impressões, ou como argumentos/retornos de funções. Os caracteres são valores de 8 bits não directamente manipuláveis.
* Os ponteiros representam endereços de objectos (de qualquer tipo) e ocupam 32 bits. Podem ser objecto de operações aritméticas (deslocamentos) e permitem aceder ao valor apontado. Note-se que não é possível usar inteiros ternários directamente em aritmética de ponteiros (têm de ser convertidos para isso).

Os tipos suportados por cada operador e a operação a realizar são indicados na [[#Expressões|definição das expressões]].

Existem ainda tipos associado a valores funcionais, i.e., tipos que descrevem a interface de funções (ver abaixo). Os valores em memória associados a estes tipos são efectivamente ponteiros, mas para funções e não para dados, podendo ser usados para invocar as funções correspondentes. Estes identificadores não podem ser usados como variáveis (e.g., passados como argumentos de outras funções, etc.).

= Manipulação de Nomes =

Os nomes (identificadores) correspondem a variáveis e funções. Nos pontos que se seguem, usa-se o termo entidade para as designar indiscriminadamente, explicitando-se quando a descrição for válida apenas para um dos casos. Existem ainda nomes para funções externas à linguagem P6. Tanto em P6, como em C, os nomes das funções referem directamente a posição do código dessas funções (à la C; ver '''extern''' abaixo).

== Espaço de nomes e visibilidade dos identificadores ==

O espaço de nomes global é único, pelo que um nome utilizado para designar uma entidade num dado contexto não pode ser utilizado para designar outras (ainda que de natureza diferente).

Os identificadores são visíveis desde a declaração até ao fim do alcance: ficheiro (globais) ou bloco (locais). A reutilização de identificadores em contextos inferiores encobre declarações em contextos superiores: redeclarações locais podem encobrir as globais até ao fim de um bloco. É possível utilizar símbolos globais nos contextos dos blocos das funções, mas não é possível declará-los (ver [[#Símbolos globais|símbolos globais]]).

== Validade das variáveis ==

As entidades globais (declaradas fora de qualquer função), existem durante toda a execução do programa. As variáveis locais a uma função existem apenas durante a sua execução. Os argumentos formais são válidos enquanto a função está activa.

= Convenções Lexicais =

Para cada grupo de elementos lexicais (tokens), considera-se a maior sequência de caracteres constituindo um elemento válido. Assim, por exemplo, a designação '''>=''' é sempre um único elemento lexical (por oposição à situação ilegal de se terem dois símbolos: '''>''' seguido de '''=''').

== Caracteres brancos ==

São considerados separadores e não representam nenhum elemento lexical: '''mudança de linha''' ASCII LF ('''0x0A''', '''\n'''), '''recuo do carreto''' ASCII CR ('''0x0D''', '''\r'''), '''espaço''' ASCII SP ('''0x20''', ⌴) e '''tabulação horizontal''' ASCII HT ('''0x09''', '''\t''').

== Comentários ==

Existem dois tipos de comentários, que também funcionam como elementos separadores:

* '''explicativos''' -- começam com '''//''' e acabam no fim da linha; e
* '''operacionais''' -- começam com '''/*''' e terminam com '''*/''', podendo estar aninhados.

Se as sequências de início fizerem parte de uma cadeia de caracteres, não iniciam um comentário (ver [[#Cadeias de caracteres|definição das cadeias de caracteres]]).

== Palavras-chave ==

As seguintes palavras-chave são reservadas, não constituindo identificadores (devem ser escritas exactamente como indicado):

* tipos: '''int real string void'''
* declarações: '''extern forward public auto'''
* instruções: '''if elif else while stop next return'''
* expressões: '''input null sizeof'''
* outras: '''begin end'''

== Tipos ==

Os seguintes elementos lexicais designam tipos em declarações (ver gramática): '''int''' (inteiro), '''real''' (real), '''string''' (cadeia de caracteres).

Os tipos correspondentes a ponteiros são outros tipos delimitados por '''[''' e ''']''', designando uma indirecção e não o objecto directo (ver gramática).

Note-se que, quando se tem uma declaração '''extern''', os tipos correspondem aos compatíveis com a linguagem C na mesma arquitectura ix86 de 32 bits, i.e., '''int''' corresponde a um número binário inteiro em [https://en.wikipedia.org/wiki/Two%27s_complement complemento para 2] (32 bits), '''real''' coresponde a uma representação segundo a norma [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] de dupla precisão (64 bits), devendo ser convertidos de e para os tipos nativos da linguage P6 sempre que necessário (ver RTS).

== Operadores de expressões ==

São considerados operadores os elementos lexicais apresentados na definição das expressões.

== Delimitadores e terminadores ==

Os seguintes elementos lexicais são delimitadores/terminadores:
* ''',''' (vírgula)
* ''';''' (ponto e vírgula)
* '''!''' e '''!!''' (operações de impressão)
* '''(''' e ''')''' (delimitadores de expressões)
* '''{''' e '''}''' (delimitadores de blocos)

== Identificadores (nomes) ==

São iniciados por uma letra, seguindo-se 0 (zero) ou mais letras ou dígitos. O comprimento do nome é ilimitado e dois nomes são distintos se houver alteração de maiúscula para minúscula, ou vice-versa, de pelo menos um carácter.

== Literais ==

São notações para valores constantes de alguns tipos da linguagem (não confundir com constantes, i.e., identificadores que, em algumas linguagens, designam elementos cujo valor não pode ser alterado durante a execução do programa).

=== Inteiros ===

Um literal inteiro é um número não negativo (mas ver a seguir). Números negativos podem ser construídos pela aplicação do operador de negação unária ('''-''') a um literal (sempre positivo).

Literais inteiros decimais são constituídos por sequências de 1 (um) ou mais dígitos de '''0''' a '''9''', em que o primeiro digito não é 0 (zero), excepto no caso do número 0 (zero). Neste caso, é composto apenas pelo dígito 0 (zero) (em qualquer base).

Literais inteiros em base 9 começam sempre pelo dígito 0 (zero), sendo seguidos de um ou mais dígitos de '''0''' a '''8''' (note-se que '''09''' é um literal inválido em base 9). Exemplo: '''086 = 78'''.

Literais inteiros em base 3 (equilibrada) começam sempre com a sequência '''0t''', seguida de um ou mais símbolos dessa base: '''-''' (valor '''-1'''), '''0''' (valor '''0''') e '''+''' (valor '''1'''). Estes literais podem ser intrinsecamente negativos. Exemplos: '''0t+0-0 = 24'''; '''0t-0+0 = -24'''

Se não for possível representar um literal na máquina, devido a overflow, deverá ser gerado um erro lexical.

=== Reais em formato Takum3 ===

Os literais reais (sempre positivos) são expressos tal como em C (exclusivamente em base 10).

Não existem literais negativos (números negativos resultam da operação unária '''-''').

Note-se que um literal sem '''.''' (ponto decimal) nem parte exponencial é do tipo inteiro.

Note-se que, apesar de C normalmente usar uma representação interna em binário no formato IEEE 754, a linguagem P6 usa um formato, representado em ternário, completamente diferente (embora a forma de escrita dos literais seja a mesma).

Exemplos: '''3.14''', '''1E3''' = 1000 (número inteiro representado como real). '''12.34e-24''' = 12.34 x 10-24 (notação cientifica).


=== Cadeias de caracteres ===

As cadeias de caracteres são delimitadas por aspas ('''"''') e podem conter quaisquer caracteres, excepto ASCII NUL (0x00) e ASCII LF (0x0A). Nas cadeias, os delimitadores de comentários não têm significado especial. Se for escrito um literal que contenha '''\0''', então a cadeia termina nessa posição. Exemplo: '''ab\0xy''' tem o mesmo significado que '''ab'''.

É possível designar caracteres por sequências especiais (iniciadas por '''\'''), especialmente úteis quando não existe representação gráfica directa. As sequências especiais correspondem aos caracteres ASCII HT, LF e CR ('''\t''', '''\n''' e '''\r''', respectivamente), aspa ('''\"'''). ''backslash'' ('''\\'''), ou a quaisquer outros especificados através de 1 a 3 dígitos em base 8, designando valores de 8 bits (e.g., '''\012''' ou apenas '''\12''' se o carácter seguinte não representar um dígito em base 8). Exemplo: '''xy\012z''' tem o mesmo significado que '''xy\12z''' e que '''xy\nz'''.

Elementos lexicais distintos que representem duas ou mais cadeias consecutivas são representadas na linguagem como uma única cadeia que resulta da concatenação. Exemplo: '''"ab"''' '''"cd"''' é o mesmo que '''"abcd"'''.

=== Ponteiros ===

O único literal admissível para ponteiros corresponde ao ponteiro nulo e é indicado pela palavra-chave '''null'''. Este literal é compatível com todos os tipos de ponteiro. Os inteiros não são convertíveis em ponteiros, pelo que o valor '''0''' (zero) não é um valor inicial admissível para ponteiros.

Note-se que a aritmética de ponteiros é possível apenas com inteiros binários, mas não com inteiros ternários (estes devem ser convertidos para binário, caso seja necessário).

= Gramática =

A gramática da linguagem está resumida abaixo. Considerou-se que os elementos em tipo fixo são literais, que os parênteses curvos agrupam elementos, que elementos alternativos são separados por uma barra vertical, que elementos opcionais estão entre parênteses rectos, que os elementos que se repetem zero ou mais vezes estão entre <math>\langle</math> e <math>\rangle</math>. Alguns elementos usados na gramática também são elementos da linguagem descrita se representados em tipo fixo (e.g., parênteses).

{|
! style="width: 140px; font-weight: normal;" | ''ficheiro''
! style="width: 50px; font-weight: normal;" | <math>\rightarrow</math>
| <math>\langle</math> ''declaração'' <math>\rangle</math> [ ''programa-principal'' ]
|-
! style="width: 150px; font-weight: normal;" | ''declaração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''tipo'' ''identificador'' [ '''=''' ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] [ '''auto''' ] ''identificador'' '''=''' ''expressão'' ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''função''
|-
! style="width: 150px; font-weight: normal;" | ''programa-principal''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''begin''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''end'''
|-
! style="width: 50px; font-weight: normal;" | ''função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''variáveis'' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''variáveis''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''variável'' <math>\langle</math> ''',''' ''variável'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''tipo''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''int''' <math>|</math> '''real''' <math>|</math> '''string''' <math>|</math> '''void''' <math>|</math> '''[''' ''tipo'' ''']''' <math>|</math> ''tipo-de-função''
|-
! style="width: 50px; font-weight: normal;" | ''tipo-de-função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' '''>'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' ''tipos'' '''>'''
|-
! style="width: 50px; font-weight: normal;" | ''tipos''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' <math>\langle</math> ''',''' ''tipo'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''bloco''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''{''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''}'''
|-
! style="width: 50px; font-weight: normal;" | ''instrução''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' ''';''' <math>|</math> ''expressões'' '''!''' <math>|</math> ''expressões'' '''!!'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''stop''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''next''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''return''' [ ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''instrução-condicional'' <math>|</math> ''instrução-de-iteração'' <math>|</math> ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''instrução-condicional''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''if''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\langle</math> '''elif''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\rangle</math> [ '''else''' ''instrução'' ]
|-
! style="width: 50px; font-weight: normal;" | ''instrução-de-iteração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''while''' '''(''' ''expressão'' ''')''' ''instrução''
|-
! style="width: 50px; font-weight: normal;" | ''expressões''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' <math>\langle</math> ''',''' ''expressão'' <math>\rangle</math>
|}

== Tipos, identificadores, literais e definição de expressões ==

Algumas definições foram omitidas da gramática: tipos de dados. qualificadores e variável (ver [[#Declarações de variáveis|declarações de variáveis]]), identificador (ver [[#Identificadores (nomes)|identificadores]]), literal (ver [[#Literais|literais]]); expressão (ver [[#Expressões|expressões]]). 

Quanto a tipos de dados, '''int''' designa valores inteiros, '''real''' designa valores reais, '''string''' designa cadeias de caracteres. Os ponteiros são tipos compostos por um tipo entre parênteses rectos, e.g., '''[int]'''.

Os tipos funcionais são definidos a partir dos tipos de dados anteriormente descritos e do tipo especial '''void''' (ver a seguir). O tipo é indicado com o formato indicado na gramática, i.e., tipo de retorno seguido dos tipos dos argumentos (zero ou mais separados por vírgulas). Estes tipos servem para declarar símbolos de função sem as definir.


O tipo '''void''' apenas pode ser usado para indicar a ausência de retorno ou para declarar um ponteiro genérico. Neste caso, o aninhamento é irrelevante, i.e., '''[void]''' e '''<nowiki>[[[void]]]</nowiki>''' são equivalentes. Um ponteiro deste tipo é compatível com todos os outros tipos de ponteiros. A aritmética de ponteiros decrementa/incrementa em uma unidade o valor de um ponteiro do tipo '''[void]'''.

== Left-values ==

Os ''left-values'' são posições de memória que podem ser modificadas (excepto onde proibido pelo tipo de dados). Os elementos de uma expressão que podem ser utilizados como left-values encontram-se individualmente identificados na semântica das expressões.

== Ficheiros ==

Um ficheiro é designado por principal se contiver a função principal (onde se inicia o programa).

== Declaração de variáveis ==

Uma declaração de variável indica sempre um tipo de dados (implícito ou explícito) e um identificador.

Exemplos:

* Inteiro: '''int i'''
* Real: '''real r'''
* Cadeia de caracteres: '''string s'''
* Ponteiro para inteiro: '''[int] p1''' (semelhante a '''int*''' em C)
* Ponteiro para real: '''[real] p2''' (semelhante a '''double*''' em C)
* Ponteiro para cadeia de caracteres: '''[string] p3''' (semelhante a '''char**''' em C)
* Ponteiro para ponteiro para inteiro: '''<nowiki>[[int]]</nowiki> p4''' (semelhante a '''int**''' em C)

É possível usar o pseudo-tipo '''auto''' se a declaração tiver um valor inicial: neste caso, o tipo é o do valor inicial.

Exemplo:

* Variável inteira: '''auto i = 1'''
* Variável real: '''auto f = 2.0'''
* etc.

== Símbolos globais ==

Por omissão, os símbolos são privados a um módulo, não podendo ser importados por outros módulos.

A palavra-chave '''public''' permite declarar um identificador como público, tornando-o acessível a partir de outros módulos. Quando usado com a palavra-chave '''auto''', esta é opcional. Note-se que a declaração de uma variável tem de ter sempre, ou o qualificador, ou o tipo, podendo estar ambos presentes.

A palavra-chave '''forward''' permite declarar num módulo variáveis ou funções definidas noutros módulos. Neste caso, não pode ser especificado o valor inicial das variáveis, pelo que não é possível o uso de '''auto''' em conjunto com '''forward'''.

A palavra-chave '''extern''' deve ser usada para declarar símbolos de função com tipos diferentes dos dos nativos da da linguagem P6, e.g. para importar funções definidas em C. Além de poderem ser usados para chamar as funções que designam, os símbolos assim declarados podem ser utilizados com valores convertidos de forma apropriada.

Exemplos:
* Declarar variável privada ao módulo: '''real r1 = 22.0'''
* Declarar variável pública: '''public real r2 = 7.0'''
* Declarar variável pública: '''public auto r2 = 7.0''' (igual à anterior)
* Declarar variável pública: '''public r2 = 7.0''' (igual à anterior)
* Usar definição externa de variável pública: '''forward real r2'''
* Declarar função (nativa P6) definida externamente: '''forward int<int> factorial'''
* Declarar função definida noutra linguagem (e.g. em C): '''extern [void]<int> malloc'''

== Inicialização ==

Quando existe, é a designação do objecto que segue o símbolo '''=''': inteiro, real, cadeia de caracteres, ou ponteiro. Entidades reais podem ser inicializadas por expressões inteiras (conversão implícita). A expressão de inicialização deve ser um literal se a variável for global.

A palavra '''auto''' pode ser usada em lugar do tipo para declarar uma variável. Quando usada, o tipo da variável é inferido a partir do valor inicial (nestes casos, o valor inicial é obrigatório).

Exemplos:
* Inteiro (literal): '''int i = 3'''
* Inteiro (expressão): '''int i = j + 1'''
* Real (literal): '''real r = 3.2'''
* Real (expressão): '''real r = i - 2.5'''
* Cadeia de caracteres (literal): '''string s = "olá"'''
* Cadeia de caracteres (literais): '''string s = "olá" "mãe"'''
* Ponteiro (literal): '''<nowiki>[[[real]]] p</nowiki> = null'''
* Ponteiro (expressão): '''[int] p = q + 1'''


= Funções =

Uma função permite agrupar um conjunto de instruções num corpo, executado com base num conjunto de parâmetros (os argumentos formais), quando é invocada a partir de uma expressão.

== Declaração ==

As funções têm um nome que é também o endereço dessa função. O tipo de retorno de uma função que não produz valores de retorno é '''void'''.

As funções que recebam argumentos devem indicá-los no cabeçalho. Funções sem argumentos definem um cabeçalho vazio. Os qualificadores de exportação/importação '''public''' ou '''forward''' (ver símbolos globais) podem ser aplicados às funções, mas não é possível aplicá-los às declarações dos argumentos de uma função. Não é possível especificar valores por omissão para os argumentos de uma função, nem para o valor de retorno.

A declaração de um ponteiro para uma função (ou, de forma equivalente, do seu nome) é utilizada para caracterizar um identificador exterior ou para efectuar declarações antecipadas (utilizadas para pré-declarar funções que sejam usadas antes de ser definidas, por exemplo, entre duas funções mutuamente recursivas). 

== Invocação ==

Uma função pode ser invocada através do seu nome. 
Se existirem argumentos, na invocação da função, o nome é seguido de uma lista de expressões delimitadas por parênteses curvos. Esta lista é uma sequência, possivelmente vazia, de expressões separadas por vírgulas. O número e tipo de parâmetros actuais deve ser igual ao número e tipo dos parâmetros formais da função invocada (a menos de conversões implícitas). A ordem dos parâmetros actuais deverá ser a mesma dos argumentos formais da função a ser invocada.

De acordo com a convenção Cdecl, a função chamadora coloca os argumentos na pilha e é responsável pela sua remoção, após o retorno da chamada. Assim, os parâmetros actuais devem ser colocados na pilha pela ordem inversa da sua declaração (i.e., são avaliados da direita para a esquerda antes da invocação da função e o resultado passado por cópia/valor). O endereço de retorno é colocado no topo da pilha pela chamada à função. Note que o retorno de entidades com dimensão superior a 64 bits deve fazer-se através da reserva de espaço para o retorno no chamador e passando um ponteiro para esse espaço como primeiro argumento do chamado.

== Corpo ==

O corpo de uma função consiste num bloco que contém declarações (opcionais) seguidas de instruções (opcionais). Não é possível aplicar os qualificadores de exportação ('''public''') ou de importação ('''forward''' ou '''extern''') (ver [[#Símbolos globais|símbolos globais]]) dentro do corpo de uma função.

Uma instrução '''return''' causa a interrupção da função. O valor devolvido por uma função, através de expressão usada como argumento da instrução '''return''', deve ser do tipo declarado no cabeçalho da função. Ver casos especiais acima.

É um erro especificar um valor de retorno se a função for declarada como não retornando um valor (indicada como '''void''').

Qualquer bloco (usado, por exemplo, numa instrução condicional ou de iteração) pode definir variáveis locais. 

== Função principal e execução de programas ==

Um programa é a sequência de instruções que seguem as declarações globais num ficheiro, delimitadas pelas palavras-chave '''begin''' e '''end'''. Esta sequência forma o que em algumas linguagens se chama a função principal. Os argumentos com que o programa foi chamado podem ser obtidos através de funções '''argc''' (devolve o número de argumentos); '''argv''' (devolve o n-ésimo argumento como uma cadeia de caracteres, com n>0); e '''envp''' (devolve a n-ésima variável de ambiente como uma cadeia de caracteres, com n>0). Apenas um dos módulos do programa pode definir a função principal, i.e., se existirem vários módulos, apenas um deles pode conter mais do que declarações de variáveis globais.

extern int<> argc
extern string<int> argv
extern string<int> envp

O valor de retorno da função principal é devolvido ao ambiente que invocou o programa. Este valor de retorno segue as seguintes regras (sistema operativo): 0 (zero), execução sem erros; 1 (um), argumentos inválidos (em número ou valor); 2 (dois), erro de execução. Os valores superiores a 128 indicam que o programa terminou com um sinal. Em geral, para correcto funcionamento, os programas devem devolver 0 (zero) se a execução foi bem-sucedida e um valor diferente de 0 (zero) em caso de erro.

A biblioteca de run-time (RTS) contém informação sobre outras funções de suporte disponíveis, incluindo chamadas ao sistema (ver também o manual da RTS).

= Instruções =

Excepto quando indicado, as instruções são executadas em sequência.

== Blocos ==

Cada bloco tem uma zona de declarações de variáveis locais (facultativa), seguida por uma zona com instruções (possivelmente vazia). Não é possível definir funções dentro de blocos, mas é possível declarar ponteiros de função locais.

A visibilidade das variáveis é limitada ao bloco em que foram declaradas. As entidades declaradas podem ser directamente utilizadas em sub-blocos ou passadas como argumentos para funções chamadas dentro do bloco. Caso os identificadores usados para definir as variáveis locais já estejam a ser utilizados para definir outras entidades ao alcance do bloco, o novo identificador passa a referir uma nova entidade definida no bloco até que ele termine (a entidade previamente definida continua a existir, mas não pode ser directamente referida pelo seu nome). Esta regra é também válida relativamente a
argumentos de funções (ver corpo das funções).

== Instrução condicional ==

Esta instrução tem comportamento semelhante ao da instrução '''if-else''' em C. As partes correspondentes a '''elif''' comportam-se como encadeamentos de instruções condicionais na parte '''else''' de um '''if-else''' à la C.

== Instrução de iteração ==

Esta instrução tem comportamento idêntico ao da instrução '''while''' em C.

== Instrução de terminação ==

A instrução '''stop''' termina o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''break''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de continuação ==

A instrução '''next''' reinicia o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''continue''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de retorno ==

A instrução '''return''', se existir, é a última instrução do seu bloco. Ver comportamento na [[#Corpo|descrição do corpo de uma função]].

== Expressões como instruções ==

As expressões utilizadas como instruções são sempre avaliadas, mesmo que não produzam efeitos secundários.

== Instruções de impressão ==

As notações '''!''' e '''!!''' podem ser utilizadas para apresentar valores na saída do programa. A primeira forma apresenta os valores sem mudar de linha; a segunda forma apresenta os valores mudando de linha depois de os apresentar a todos. Quando existe mais de uma expressão, as várias expressões são apresentadas sem separação. Valores numéricos (inteiros ou reais) são impressos em decimal. As cadeias de caracteres são impressas na codificação nativa. Ponteiros não podem ser impressos.

= Expressões =

Uma expressão é uma representação algébrica de uma quantidade: todas as expressões têm um tipo e devolvem um valor.

Existem [[#Expressões primitivas|expressões primitivas]] e expressões que resultam da [[#Expressões resultantes de avaliação de operadores|avaliação de operadores]].

A tabela seguinte apresenta as precedências relativas dos operadores: é a mesma para operadores na mesma linha, sendo as linhas seguintes de menor prioridade que as anteriores. A maioria dos operadores segue a semântica da linguagem C (excepto onde explicitamente indicado). Tal como em C, os valores lógicos são 0 (zero) (valor falso), e diferente de zero (valor verdadeiro).

{|
| '''Tipo de Expressão'''
| '''Operadores'''
| '''Associatividade'''
| '''Operandos'''
| '''Semântica'''
|-
| primária
| '''( ) [ ]'''
| não associativos
| -
| [[#Parênteses curvos|parênteses curvos]], [[#Indexação|indexação]], [[#Reserva de memória|reserva de memória]]
|-
| unária
| '''+ - ?'''
| não associativos
| -
| [[#Identidade e simétrico|identidade e simétrico]], [[#Expressão de indicação de posição|indicação de posição]]
|-
! style="vertical-align: top; font-weight: normal;" | "não" lógico
! style="vertical-align: top; font-weight: normal;" | '''~'''
! style="vertical-align: top; font-weight: normal;" | não associativo
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: negação
|-
! style="vertical-align: top; font-weight: normal;" | multiplicativa
! style="vertical-align: top; font-weight: normal;" | '''* / %'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | aditiva
! style="vertical-align: top; font-weight: normal;" | '''+ -'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias: se envolverem ponteiros, calculam: (i) deslocamentos, i.e., um dos operandos deve ser do tipo ponteiro e o outro do tipo inteiro (binário de 32 bits); (ii) diferenças de ponteiros, i.e., apenas quando se aplica o operador '''-''' a dois ponteiros do mesmo tipo (o resultado é o número de objectos do tipo apontado entre eles, representado como um valor inteiro ternário de 64 bits). Se a memória não for contígua, o resultado é indefinido.
|-
! style="vertical-align: top; font-weight: normal;" | comparativa
! style="vertical-align: top; font-weight: normal;" | '''< > <= >='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | igualdade
! style="vertical-align: top; font-weight: normal;" | '''== !='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | "e" lógico
! style="vertical-align: top; font-weight: normal;" | '''&&'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for falso.
|-
! style="vertical-align: top; font-weight: normal;" | "ou" lógico
! style="vertical-align: top; font-weight: normal;" | '''<nowiki>||</nowiki>'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for verdadeiro.
|-
! style="vertical-align: top; font-weight: normal;" | atribuição
! style="vertical-align: top; font-weight: normal;" | '''='''
! style="vertical-align: top; font-weight: normal;" | da direita para a esquerda
! style="vertical-align: top; font-weight: normal;" | todos os tipos
! style="vertical-align: top; font-weight: normal;" | O valor da expressão do lado direito do operador é guardado na posição indicada pelo ''left-value'' (operando esquerdo do operador). Podem ser atribuídos valores inteiros a ''left-values'' reais (conversão automática). Nos outros casos, ambos os tipos têm de concordar. O literal '''null''' é compatível com todos os tipos de ponteiros.
|}

== Expressões primitivas ==

As [[#Literais|expressões literais]] e a [[#Invocação|invocação de funções]] foram definidas acima.

=== Identificadores ===

Um identificador é uma expressão se tiver sido declarado. Um identificador pode denotar uma variável.

Um identificador é o caso mais simples de um ''[[#Left-values|left-value]]'', ou seja, uma entidade que pode ser utilizada no lado esquerdo (''left'') de uma atribuição.

=== Leitura ===

A operação de leitura de um valor inteiro ou real pode ser efectuado pela expressão indicada pela palavra-chave '''input''', que devolve o valor lido, de acordo com o tipo esperado (inteiro ou real). Caso se use como argumento dos operadores de impressão ou noutras situações que permitam vários tipos (e.g. '''!''' ou '''!!'''), deve ser lido um inteiro.

Exemplos: '''a = input''' (leitura para '''a'''), '''f(input)''' (leitura para argumento de função), '''input!!''' (leitura e impressão).

=== Parênteses curvos ===

Uma expressão entre parênteses curvos tem o valor da expressão sem os parênteses e permite alterar a prioridade dos operadores. Uma expressão entre parênteses não pode ser utilizada como ''left-value'' (ver também a [[#Indexação|expressão de indexação]]).


== Expressões resultantes de avaliação de operadores ==

=== Indexação de ponteiros ===

A indexação de ponteiros devolve o valor de uma posição de memória indicada por um ponteiro. Consiste em uma expressão ponteiro seguida do índice entre parênteses rectos. O resultado de uma indexação de ponteiros é um ''[[#Left-values|left-value]]''. Não é possível indexar ponteiros que designem funções.

Exemplo (acesso à posição 0 da zona de memória indicada por '''p'''): '''p[0]'''

=== Identidade e simétrico ===

Os operadores identidade ('''+''') e simétrico ('''-''') aplicam-se a inteiros e reais. Têm o mesmo significado que em análogo às operações correspondentes em C, mas operam sobre grandezas ternárias.

=== Reserva de memória ===

A expressão reserva de memória devolve o ponteiro que aponta para a zona de memória, na pilha da função actual, contendo espaço suficiente para o número de objectos indicados pelo seu argumento inteiro.

Exemplo (reserva vector com 5 reais, apontados por '''p'''): '''[real] p = [5]'''

=== Expressão de indicação de posição ===

O operador sufixo '''?''' aplica-se a ''left-values'', retornando o endereço (com o tipo ponteiro) correspondente.

Exemplo (indica o endereço de '''a'''): '''a?'''

=== Expressão de dimensão ===

O operador '''sizeof''' tem um único argumento e aplica-se a expressões, retornando a dimensão correspondente em bytes.

Exemplo: '''sizeof(a)''' (dimensão de '''a''').

= Exemplos e Testes =

Os exemplos abaixo não são exaustivos e não ilustram todos os aspectos da linguagem.

Estão ainda disponíveis outros [https://gitlab.rnl.tecnico.ulisboa.pt/leic-a-co26/eval/co26 pacotes de testes].

O seguinte exemplo ilustra um programa com dois módulos: um que define a função '''factorial''' e outro que define a função principal.

Definição da função '''factorial''' no ficheiro '''factorial.p6''':

<syntaxhighlight lang="text">
public factorial(int n) -> int {
if (n > 1)
return n * factorial(n - 1);
else
return 1;
}
</syntaxhighlight>

Exemplo da utilização da função '''factorial''' no ficheiro '''main.p6''':

<syntaxhighlight lang="text">
// external builtin functions (non-P6)
extern int<> argc;
extern string<int> argv;
extern int<string> atoi;

// external user functions (P6)
forward int<int> factorial;

// the main function
begin
auto value = 1;
"Teste para a função factorial."!!
if (argc() == 2) {
string s = argv(1);
value = atoi(s);
}
value, "! é ", factorial(value)!!
return 0;
end
</syntaxhighlight>

Como compilar:
<syntaxhighlight lang="text">
p6 --target asm factorial.p6
p6 --target asm main.p6
yasm -felf32 factorial.asm
yasm -felf32 main.asm
ld -melf_i386 -o main factorial.o main.o -lrts
</syntaxhighlight>

= Omissões e Erros =

Casos omissos e erros serão corrigidos em futuras versões do manual de referência.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category: Ensino]]

Code Generation

2026-05-18T15:26:47Z

Root: /* Examples */

{{NAVCompiladores}}
{{TOCright}}
== Topics ==
* Interpretation: syntax-directed and based on abstract syntax tree.
* Code generation: syntax-directed and based on abstract syntax tree.

The approach described here is based on generation from the intermediate representation in the form of an abstract syntax tree formed by the nodes created during the parsing process.

The target machine is the Postfix engine described below.

== The Postfix Machine ==

The Postfix machine is a stack machine possessing a single large stack and 0-operand instructions (SL0).

Three special purpose registers: IP (instruction pointer, a.k.a, program counter), for jumps and function calls; FP (frame pointer, a.k.a. base pointer), the basis of the frame pointer for each function; SP (stack pointer), keeps track of the top of the stack.

The stack grows in the direction of lower addresses.

Almost all operations use the stack as input and output (exceptions are instructions for returning values from functions in accordance with CDecl), and instructions that use either immediate arguments or arguments in global memory (i.e., with explicit named addressing).

The [[Postfix Reference Guide|Postfix reference guide]] contains further details about the Postfix machine and its operations.

== Basic Structures (code) ==

The mnemonics are those of the Postfix language. Comments indicate missing parts.

=== Cycles ===

Basic structure of a '''while''' cycle:

<source lang="asm">
LABEL condition
;; evaluate condition expression
JZ endcycle
;; evaluate block
JMP condition
LABEL endcycle
</source>

Basic structure of a '''do-while''' cycle:

<source lang="asm">
LABEL startcycle
;; evaluate block
LABEL condition
;; evaluate condition expression
JNZ startcycle
LABEL endcycle
</source>

Basic structure of a C-style '''for''' cycle:

<source lang="asm">
;; evaluate initializer
LABEL condition
;; evaluate condition expression
JZ endfor
;; evaluate block
LABEL increment
;; evaluate increment expression
JMP condition
LABEL endfor
</source>

=== "Break" and "Continue" Instructions ===

The C-style '''break''' and '''continue''' instructions must jump, respectively, to the end of the cycle or to its condition (for deciding on whether to execute the next iteration). In the case of '''for''' cycles, the jump to the condition is not direct, but rather via a jump to the increment label.

If there are multiple nested cycles, the code generator must keep track of the innermost one, so that it can generate the appropriate jumps. This can be achieved through the use of address stacks (one for '''break''' labels and another for '''continue''' labels).

=== If-Then and If-Then-Else Instructions ===

Basic structure of an "if-then" instruction:

<source lang="asm">
;; evaluate condition expression
JZ endif
;; evaluate then block
LABEL endif
</source>

Basic structure of an "if-then-else" instruction:

<source lang="asm">
;; evaluate condition expression
JZ else
;; evaluate then block
JMP endif
LABEL else
;; evaluate else block
LABEL endif
</source>

=== Functions ===

The function structure presented here assumes a "void" return. If a return were desired, the use of STFVAL32 or STFVAL64 would be required before the LEAVE instruction.

"sizeoflocalvars" is the number of bytes needed to store all of the function's local variables. If this value is 0 (zero), START may be used instead of ENTER.

If the function is not global (e.g. C-style "static" function), then GLOBAL should not be used.
<source lang="asm">
GLOBAL functionname,FUNC
LABEL functionname
ENTER sizeoflocalvars
;; evaluate function body
LEAVE
RET
</source>

== Basic Structures (data) ==

=== Defining global (permanent) variables ===

We include in this category C-like "static" function variables (the only difference is that they are not defined with their explicit names, but rather with a name that reflects their being visible only inside their functions). Note, however, that "static" variables, even though they exist in globally accessible memory spaces, do not have public names and, hence, are not declared GLOBAL.

Addressing of these variables is by name, thus, they have memory labels:

<source lang="asm">
;; int a
BSS ; select segment for uninitialized variables
ALIGN ; align memory
GLOBAL a, OBJ ; declare a global symbol (linker)
LABEL a ; define the label
SALLOC 4 ; allocate space (sizeof(int) == 4)
</source>

<source lang="asm">
;; int a = 3
DATA ; select segment for initialized variables
ALIGN ; align memory
GLOBAL a, OBJ ; declare a global symbol (linker)
LABEL a ; define the label
SINT 3 ; allocate space by defining initial value
</source>

<source lang="asm">
;; const int a = 3
RODATA ; select segment for constant objects
ALIGN ; align memory
GLOBAL a, OBJ ; declare a global symbol (linker)
LABEL a ; define the label
SINT 3 ; allocate space by defining initial value
</source>

<source lang="asm">
;; char *s = "abcdef"
RODATA ; select segment for constant objects (string literal)
ALIGN ; align memory
LABEL _L123 ; define the label
SSTRING "abcdef" ; allocate space by defining initial value (string literal)
DATA ; select segment for initialized variables
ALIGN ; align memory
GLOBAL s, OBJ ; declare a global symbol (linker)
LABEL s ; define the label
SADDR _L123 ; allocate space by defining initial value (address of literal)
</source>

<source lang="asm">
;; L22 example
;; var f = (int i) -> int:
;; return i
TEXT _F123 ; select segment for this (anonymous) function
ALIGN ; align memory
LABEL _F123 ; define the label
ENTER 0
LOCAL +8 ; &i
LDINT ; i
STFVAL32
LEAVE
RET
DATA ; select segment for initialized variables
ALIGN ; align memory
GLOBAL f, OBJ ; declare a global symbol (linker)
LABEL f ; define the label
SADDR _F123 ; allocate space by defining initial value (address of function)
</source>

=== Accessing global (permanent) variables ===

We include in this category C-like "static" function variables (the only difference is that they are not accessed with their explicit names, but rather with a automatic symbol table-based name).

Addressing of these variables is by name, as shown in the following examples.

<source lang="asm">
;; a = 1
INT 1 ; put 1 on the stack
DUP32 ; duplicate value
ADDR a ; put address of "a" on the stack
STINT ; write the value on the given address
</source>
If the resulting value is not needed, throw it away:

<source lang="asm">
;; a = 1; // expression as instruction
INT 1 ; put 1 on the stack
DUP32 ; duplicate value
ADDR a ; put address of "a" on the stack
STINT ; write the value on the given address
TRASH 4
</source>

<source lang="asm">
;; a = b (both global)
ADDR b ; put address of "b" on the stack
LDINT ; read the value at the given address
DUP32 ; duplicate value (= is an expression)
ADDR a ; put address of "a" on the stack
STINT ; write the value on the given address
</source>

If ADDR is immediately followed by LDINT, then the two instructions may be replaced by a single one with the same effect: ADDRV. Similarly, ADDR+STINT = ADDRA. Note that this, in most cases, will correspond to an optimization and its use by the code generator will be impossible or very limited.

<source lang="asm">
;; a = 1
INT 1 ; put 1 on the stack
DUP32 ; duplicate value (= is an expression)
ADDRA a ; write the value in the address corresponding to "a"
</source>

<source lang="asm">
;; a = b (both global)
ADDRV b ; read value in the address of "b" and put it on the stack
DUP32 ; duplicate value (= is an expression)
ADDRA a ; write the value in the address corresponding to "a"
</source>

=== Accessing local variables ===

In the following examples, we assume that both '''a''' and '''b''' are local variables (thus having negative offsets relative to the framepointer). If they were function arguments, the offsets would be positive.

<source lang="asm">
;; a = 1
INT 1 ; put 1 on the stack
DUP32 ; duplicate value (= is an expression)
LOCAL -4 ; put address of "a" (assuming offset -4) on the stack
STINT ; write the value on the given address
</source>

<source lang="asm">
;; a = b (both local)
LOCAL -8 ; put address of "b" (assuming offset -8) on the stack
LDINT ; read the value at the given address
DUP32 ; duplicate value (= is an expression)
LOCAL -4 ; put address of "a" (assuming offset -4) on the stack
STINT ; write the value on the given address
</source>

If LOCAL is immediately followed by LDINT, then the two instructions may be replaced by a single one with the same effect: LOCV. Similarly, LOCAL+STINT = LOCA. Note that this, in most cases, will correspond to an optimization and its use by the code generator will be impossible or very limited.

<source lang="asm">
;; a = 1
INT 1 ; put 1 on the stack
DUP32 ; duplicate value (= is an expression)
LOCA -4 ; write the value on the address of "a" (assuming offset -4)
</source>

<source lang="asm">
;; a = b (both local)
LOCV -8 ; read value in the address of "b" (assuming offset -8) and put it on the stack
DUP32 ; duplicate value (= is an expression)
LOCA -4 ; write the value on the address of "a" (assuming offset -4)
</source>

== Examples ==

* [[Code Generation/Example 1|Example 1]] - translating a C function to Postfix
* [[Code Generation/Example 2|Example 2]] - simple program printing a global string
* [[Code Generation/Example 3|Example 3]] - C function with pointer arithmetic to Postfix
* [[Code Generation/Example 4|Example 4]] - C while cycle
* [[Code Generation/Duplication of Floating Point Numbers on the Stack|Duplication of Floating Point Numbers on the Stack]] - this is a simple pure-Postfix example to illustrate duplication of stack values for double-precision floating point numbers.

== Exercises ==

* [[Code Generation/Exercise 5|Exercise 5]] - "gcd"
* [[Code Generation/Exercise 6|Exercise 6]] - "powmod"
* [[Code Generation/Exercise 7|Exercise 7]] - "traverse"
* [[Code Generation/Exercise 8|Exercise 8]] - set of small exercises and questions
* [[Code Generation/Exercise 9|Exercise 9]] - "mkvec" and "compute", Test 2, 2012/06/06
* [[Code Generation/Exercise 10|Exercise 10]] - "forall" (version 1), Test 2, 2015/06/29
* [[Code Generation/Exercise 11|Exercise 11]] - "forall" (version 2), Test 2, 2015/06/29
* [[Code Generation/Exercise 12|Exercise 12]] - finding elements in vector, Test 2, 2016/06/17
* [[Code Generation/Exercise 13|Exercise 13]] - '''repeat'''
* [[Code Generation/Exercise 14|Exercise 14]] - '''mop'''
* [[Code Generation/Exercise 15|Exercise 15]] - '''gcd''' (take 2)
* [[Code Generation/Exercise 16|Exercise 16]] - '''heapSort''', etc.
* [[Code Generation/Exercise 17|Exercise 17]] - '''find'''
* [[Code Generation/Exercise 18|Exercise 18]] - fragmentos com variações

[[category:Compiladores]]
[[category:Ensino]]

Postfix Reference Guide

2026-05-18T13:58:46Z

Root: /* Comparison operators for real numbers */

{{TOCright}}

The Postfix reference guide contains information about the structure and operations of the stack machine.

The original stack machine was created by Santos (2004). Is was composed by a set of macros to be used with printf functions. Each macro would “take” as arguments, either a number or a string. This was a simple and effective approach but was limited in its expressiveness.

The current postﬁx code generator class maintains the stack machine abstraction, but does not rely on macros. Instead, it deﬁnes an interface to be used by semantic analysers, as deﬁned by a strategy pattern (Gamma et al., 1995). Speciﬁc implementations provide the realization of the postﬁx commands for a particular target machine. Since it is written in C++, it's very easy to extend to new needs and implementations (new target machines).

Like the original postfix code generator, the current abstraction uses an architecture based on a stack machine, hence the name "postfix", and three registers.
# IP -- the instruction pointer -- indicates the position of the next instruction to be executed;
# SP -- the stack pointer -- indicates the position of the element currently at the stack top;
# FP -- the frame pointer -- indicates the position of the activation register of the function currently being executed.

In the following tables, the "stack" columns present the results of the actions on the values at the top of the stack. Note that only elements relevant in a given context, i.e., that of the postfix instruction being executed, are shown. The notation '''#length''' represents a set of ''length'' consecutive bytes in the stack, i.e., a vector.

{|
! class="pfrow" | OPERATION
! class="pfrow" | stack before
! class="pfrow" | stack after
! class="pfdesc" | Description of actions
|}

Consider the following fictitious example:

{|
! class="pfrow" | FAKE
! class="pfrow" | $ a #8 b
! class="pfrow" | $ a b
! class="pfdesc" | This is a fake operation
|}

In this example, before the FAKE operation, the stack had at its top '''b''', followed by eight bytes, followed by '''a'''. After executing the FAKE operation (which used those elements in some way), the stack has at its top '''b''', followed by '''a'''. The symbol '''$''' is used to denote the point in the stack not affected by the current operation (this could be the top if the stack were empty).

The following groups of operations are available in the Postfix interface:

== Segments, Values, and Labels ==

=== Segment selection ===

These operations select various segments. They do not affect the stack.

{|
! class="pfrow" | BSS
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for uninitialized values
|-
! class="pfrow" | DATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized values
|-
! class="pfrow" | RODATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized constant values
|-
! class="pfrow" | TEXT
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment (default)
|-
! class="pfrow" | TEXT name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''name''
|-
! class="pfrow" | TEXT number
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''number''
|}

=== Values (declaration in segments) ===

These operations declare values directly in various segments. They do not affect the stack.

{|
! class="pfrow" | SALLOC size
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares an uninitialized vector with length '''size''' (in bytes)
|-
! class="pfrow" | SSHORT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 16-bit integer '''value'''
|-
! class="pfrow" | SBYTE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 8-bit character '''value'''
|-
! class="pfrow" | SINT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 32-bit integer '''value'''
|-
! class="pfrow" | SBALANCED3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static balanced ternary integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | SFLOAT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static simple precision (32-bit) floating point '''value'''
|-
! class="pfrow" | SDOUBLE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static double precision (64-bit) floating point '''value'''
|-
! class="pfrow" | SPOSIT3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary posit real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | STAKUM3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary takum real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SADDR name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a name for an address (i.e., declares the address associated with '''name''')
|-
! class="pfrow" | SSTRING string
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static NULL-terminated character '''string''' (C-like) (may contain special characters)
|}

=== Labels ===

These operations handle symbols and their definitions within some segment. They do not affect the stack.

{|
! class="pfrow" | ALIGN
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Forces the alignment of code or data
|-
! class="pfrow" | LABEL name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a new label '''name'''
|-
! class="pfrow" | EXTERN name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares '''name''' as a symbol externally defined, i.e., defined in another compilation module
|-
! class="pfrow" | GLOBAL name, type
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a '''name''' with a given '''type''' (see below) -- the declaration of a name must preceed its definition
|}


In a declaration common to several modules, any number of modules may contain common or external declarations, but only one of them may contain an initialized declaration. A declaration does not need to be specified in a specific segment.

Global names may be of different types. These labels are to be used to generate the types needed for the second argument of '''GLOBAL'''.
* NONE - Unknown type
* FUNC - Name/label corresponds to a function
* OBJ - Name/label corresponds to an object (data)

== Addressing, Loading and Storing ==

Absolute addressing uses addresses based on named labels. Local addressing is used in function frames and uses offsets relative to the frame pointer to load data: negative addresses correspond to local variables, offset zero contains the previous (saved) value of the frame pointer, offset 4 (32 bits) contains the previous (saved) value of the instruction pointer, and, after offset 8, reside the function arguments.

=== Adressing operations ===

{|
! class="pfrow" | ADDR name
! class="pfrow" | $
! class="pfrow" | $ name
! class="pfdesc" | Absolute addressing: load address of '''name'''
|-
! class="pfrow" | ADDRA name
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Absolute addressing: store '''value''' to '''name'''
|-
! class="pfrow" | ADDRV name
! class="pfrow" | $
! class="pfrow" | $ [name]
! class="pfdesc" | Absolute addressing: load value at '''name'''
|-
! class="pfrow" | LOCAL offset
! class="pfrow" | $
! class="pfrow" | $ fp+offset
! class="pfdesc" | Local addressing: load address of '''offset'''
|-
! class="pfrow" | LOCA offset
! class="pfrow" | $ a
! class="pfrow" | $
! class="pfdesc" | Local addressing: writes '''a''' to '''offset'''
|-
! class="pfrow" | LOCV offset
! class="pfrow" | $
! class="pfrow" | $ [fp+offset]
! class="pfdesc" | Local addressing: load value at '''offset'''
|}

ADDRA, ADDRV, LOCA, LOCV are functionally equivalent to ADDR+STINT, ADDR+LDINT, LOCAL+STINT, LOCAL+LDINT, but the generated code is more efficient. They are compound operations (i.e., they contain not only the addressing part, but also the load/store part as well). Note that the postfix_writer visitor is, in general, incapable of generating these instructions.

=== Load operations ===

The load instructions assume that the top of the stack contains an address pointing to the data to be read. Each load instruction will replace the address at the top of the stack with the contents of the position it points to. Load operations differ only in what they load.

{|
! class="pfrow" | LDBYTE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 1 byte (char)
|-
! class="pfrow" | LDSHORT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 2 bytes (short)
|-
! class="pfrow" | LDINT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (int)
|-
! class="pfrow" | LDBALANCED3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | LDFLOAT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (float)
|-
! class="pfrow" | LDDOUBLE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (double)
|-
! class="pfrow" | LDPOSIT3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|-
! class="pfrow" | LDTAKUM3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|}

=== Store operations ===

Store instructions assume the stack contains at the top the address where data is to be stored. That data is in the stack, immediately after the address. Store instructions differ only in what they store.

{|
! class="pfrow" | STBYTE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 1 byte (char)
|-
! class="pfrow" | STSHORT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 2 bytes (short)
|-
! class="pfrow" | STINT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (int)
|-
! class="pfrow" | STBALANCED3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | STFLOAT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (float)
|-
! class="pfrow" | STDOUBLE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (double)
|-
! class="pfrow" | STPOSIT3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|-
! class="pfrow" | STTAKUM3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|}

== Simple Stack Operations ==

{|
! class="pfrow" | DUP32
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 32-bit value at the top of the stack
|-
! class="pfrow" | DUP64
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 64-bit value at the top of the stack
|-
! class="pfrow" | DUP128
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 128-bit value at the top of the stack
|-
! class="pfrow" | INT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an integer '''value'''
|-
! class="pfrow" | BALANCED3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary balanced integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | FLOAT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a 4-byte float '''value''' (32 bits, single precision)
|-
! class="pfrow" | DOUBLE value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an 8-byte float '''value''' (64 bits, double precision)
|-
! class="pfrow" | POSIT3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | TAKUM3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SP
! class="pfrow" | $
! class="pfrow" | $ sp
! class="pfdesc" | Pushes the value of the stack pointer
|-
! class="pfrow" | SWAP32
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 32-bit values at the top of the stack
|-
! class="pfrow" | SWAP64
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 64-bit values at the top of the stack
|-
! class="pfrow" | SWAP128
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 128-bit values at the top of the stack
|-
! class="pfrow" | ALLOC
! class="pfrow" | $ bytes
! class="pfrow" | $ #bytes
! class="pfdesc" | Allocates in the stack an array with size '''bytes'''. Since this operation alters the meaning of offsets in the stack, care should be taken when local variables exist.
|}

== Arithmetic Operations ==

The arithmetic operations considered here apply to both signed and unsigned integer arguments, and to double precision floating point arguments.

=== Binary integer (32-bit) operations ===

{|
! class="pfrow" | NEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | ADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | SUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | MUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | DIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | MOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|-
! class="pfrow" | UDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two natural (unsigned) integer values
|-
! class="pfrow" | UMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two natural (unsigned) integer values.
|}

=== Ternary integer (64-bit/40-trit) operations ===

{|
! class="pfrow" | BNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | BADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | BSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | BMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | BDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | BMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|}

=== Floating point (64-bit) operations ===

These operations take double precision floating point operands.

{|
! class="pfrow" | DNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | DADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | DSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | DMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | DDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary posit (128-bit/80-trit) operations ===

These operations take ternary posit operands.

{|
! class="pfrow" | PNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | PADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | PSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | PMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | PDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary takum (128-bit/80-trit) operations ===

These operations take ternary takum operands.

{|
! class="pfrow" | TNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | TADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | TSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | TMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | TDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

== Increment and Decrement Operations ==

{|
! class="pfrow" | INCR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Adds '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]+delta''
|-
! class="pfrow" | DECR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Subtracts '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]-delta''
|}

== Type Conversion Operations ==

The following instructions perform type conversions. The conversions are from and to integers (both binary and ternary) and real values (simple and double precision floating point, posit, and takum).

{|
! class="pfrow" | SRC2DST
! class="pfrow" | $ src
! class="pfrow" | $ dst
! class="pfdesc" | Converts from source format ('''src''') to destination format ('''dst''')
|}

'''SRC''' and '''DST''' in the instuction above are as follows (not all combinations are available -- see the following table):
* '''B''': Balanced ternary integer (64-bit/40-trit)
* '''D''': Double precision floating point (64-bit)
* '''F''': Single precision / simple precision floating point (32-bit)
* '''I''': Binary integer (32-bit)
* '''P''': Ternary posit (128-bit/80-trit)
* '''T''': Ternary takum (128-bit/80-trit)

{| class="wikitable" style="text-align:center;"
|+ Instruction Opcodes (From Row \ To Column)
! !! B !! D !! F !! I !! P !! T
|-
! B
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| B2I
| B2P
| B2T
|-
! D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| D2F
| D2I
| D2P
| D2T
|-
! F
| style="background:#ececec; color:gray;" | -
| F2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! I
| I2B
| I2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! P
| P2B
| P2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| P2T
|-
! T
| T2B
| T2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| T2P
| style="background:#ececec; color:gray;" | -
|}

== Comparison Operations ==

=== Binary integer comparison instructions ===

The comparison instructions are binary operations (each operand is a 32-bit binary integer) that leave at the top of the stack 0 (zero) or 1 (one), depending on the result of the comparison: respectively, '''false''' or '''true''' (32-bit binary integer). The value may be directly used to perform conditional jumps (e.g., JZ, JNZ), that use the value of the top of the stack instead of relying on special processor registers ("flags").

{|
! class="pfrow" | EQ
! class="pfrow" | $ a b
! class="pfrow" | $ a&equiv;b
! class="pfdesc" | ''equal to''
|-
! class="pfrow" | NE
! class="pfrow" | $ a b
! class="pfrow" | $ a≠b
! class="pfdesc" | ''not equal to''
|}

{|
! class="pfrow" | GT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than''
|-
! class="pfrow" | GE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to''
|-
! class="pfrow" | LE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to''
|-
! class="pfrow" | LT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than''
|}

The following consider unsigned 32-bit binary integer operands (the result is also a 32-bit binary integer):

{|
! class="pfrow" | UGT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than'' for unsigned integers
|-
! class="pfrow" | UGE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to'' for unsigned integers
|-
! class="pfrow" | ULE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to'' for unsigned integers
|-
! class="pfrow" | ULT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than'' for unsigned integers
|}

=== Comparison operators for double precision binary floating point real numbers ===

The DCMP operator compares two double precision binary floating point numbers (64 bits). The result is a 32-bit binary integer value: less than 0, if the first operand is lower than the second; 0, if they are equal; greater than 0, otherwise. 

{|
! class="pfrow" | DCMP
! class="pfrow" | $ a b
! class="pfrow" | $ i
! class="pfdesc" | "compare" -- i<0, a<b; i&equiv;0, a&equiv;b; i>0, a>b

|}

== Bitwise Operations ==

These operators take and 32-bit binary integer operands. The result is also a 32-bit binary integer.
{|
! class="pfrow" | NOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | Bitwise negation, i.e., one's complement
|-
! class="pfrow" | AND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | Bitwise AND operation
|-
! class="pfrow" | OR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | Bitwise OR operation
|-
! class="pfrow" | XOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&oplus;b
! class="pfdesc" | Bitwise XOR (exclusive OR) operation
|}

== Ternary Kleene logic operations ==

These operators take balanced ternary (64-bit/40-trit) integer operands. Note that these operators do not short-circuit Kleene logic with KAND/KOR. The result is also a balanced ternary (64-bit/40-trit) integer.
{|
! class="pfrow" | KNOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | NOT operation
|-
! class="pfrow" | KAND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | AND operation
|-
! class="pfrow" | KOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | OR operation
|}

== Rotation and Shift Operations ==

Shift and rotation operations have as maximum value the number of bits of the underlying processor register (32 bits in a ix86-family processor). Safe operation for values above that limit is not guaranteed.

{|
! class="pfrow" | ROTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rl>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the left
|-
! class="pfrow" | ROTR
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rr>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the right
|-
! class="pfrow" | SHTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<<bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the left
|-
! class="pfrow" | SHTRU
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (unsigned)
|-
! class="pfrow" | SHTRS
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (signed)
|}

== Function Definition ==

The following sections cover defining and calling functions.

=== Starting a function ===

Each function must allocate space for its local variables. This is done immediately after being called and before any other processing. The relevant operations are ENTER (to specify a given memory amount) and START (no space is reserved for local variables. Note that these operations do more than manipulate the stack: they also create an activation register for the function, i.e., they update the frame pointer and define a new stack frame.

{|
! class="pfrow" | ENTER bytes
! class="pfrow" | $
! class="pfrow" | $ fp #bytes
! class="pfdesc" | Starts a function: pushes the frame pointer (activation register) to the stack and allocates space for local variables ('''bytes''')
|-
! class="pfrow" | START
! class="pfrow" | $
! class="pfrow" | $ fp
! class="pfdesc" | Equivalent to "ENTER 0"
|}

=== Leaving a function ===

STFVAL32I/STFVAL32F or STFVAL64I/STFVAL64F must be called to specify return values in accordance with C conventions. Only return values that fit in the indicated registers need these operations. Other return values are passed by pointer.

{|
! class="pfrow" | STFVAL32I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 32-bit integer value from the stack (to eax)
|-
! class="pfrow" | STFVAL64I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 64-bit integer value from the stack (to eax:edx)
|-
! class="pfrow" | STFVAL32F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a single-precision (32-bit) floating point value from the stack (to st0)
|-
! class="pfrow" | STFVAL64F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a double-precision (64-bit) floating point value from the stack (to st0)
|}

Note that balanced-ternary numbers are represented by 64-bit binary numbers. Takums cannot be directly returned (they must be returned via pointer).

The stack frame is destroyed by the LEAVE operation. This action must be performed immediately before returning control to the caller (with RET).

{|
! class="pfrow" | LEAVE
! class="pfrow" | $ fp ...
! class="pfrow" | $
! class="pfdesc" | Ends a function: restores the frame pointer (activation register) and destroys the function-local stack data
|}

After the function's stack frame is destroyed and the activation register is restored to the caller, control must also be returned to the caller (i.e., IP must be updated).

{|
! class="pfrow" | RET
! class="pfrow" | $ addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function (the stack must contain the return address)
|-
! class="pfrow" | RETN bytes
! class="pfrow" | $ #bytes addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function and removes '''bytes''' from the caller's stack after removing the return address. This is more or less the same as "RET+TRASH bytes". '''Note that this is not compatible with the Cdecl calling conventions.'''
|}

== Function Calls ==

In a stack machine the arguments for a function call are already in the stack. Thus, it is not necessary to put them there (it is enough not to remove them).

{|
! class="pfrow" | CALL name
! class="pfrow" | $
! class="pfrow" | $ return-address
! class="pfdesc" | Calls the '''name'''d function. The '''return-address''' is pushed to the stack.
|-
! class="pfrow" | BRANCH
! class="pfrow" | $ address
! class="pfrow" | $ return-address
! class="pfdesc" | Invokes a function at the '''address''' indicated at the top of the stack. The '''return-address''' is pushed to the stack.
|}

When building functions that conform to the C calling convention, the arguments are destroyed by the caller, ''after'' the return of the callee, using TRASH and stating the total size (i.e., for all arguments).

{|
! class="pfrow" | TRASH bytes
! class="pfrow" | $ #bytes
! class="pfrow" | $
! class="pfdesc" | Removes '''bytes''' from the stack
|}

To recover the returned value by the callee, and put it in the stack, the caller must call LDFVAL32I (32-bit integer value in eax) or LDFVAL32F (32-bit single-precision floating point value in st0). An analogous procedure is valid for LDFVAL64I (64-bit integer value in eax:edx) and LDFVAL64F (64-bit double-precision floating point value in st0).

{|
! class="pfrow" | LDFVAL32I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax register to the stack
|-
! class="pfrow" | LDFVAL64I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax:edx registers to the stack
|-
! class="pfrow" | LDFVAL32F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (32 bits, single precision)
|-
! class="pfrow" | LDFVAL64F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (64 bits, double precision)
|}

== Basic Jump Operations ==

{|
! class="pfrow" | JMP label
! class="pfrow" | $
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to '''label''' (does not affect or use the stack)
|-
! class="pfrow" | LEAP
! class="pfrow" | $ address
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to the '''address''' at the top of the stack
|}

== Conditional Jump Operations ==

{|
! class="pfrow" | JZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is 0 (zero)
|-
! class="pfrow" | JNZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is non-zero
|}

The following operations combine comparisons and jumps.

{|
! class="pfrow" | JEQ label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a&equiv;b
|-
! class="pfrow" | JNE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≠b
|}

{|
! class="pfrow" | JGT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a>b
|-
! class="pfrow" | JGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b
|-
! class="pfrow" | JLE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b
|-
! class="pfrow" | JLT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if ab (unsigned)
|-
! class="pfrow" | JUGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b (unsigned)
|-
! class="pfrow" | JULE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b (unsigned)
|-
! class="pfrow" | JULT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a<b (unsigned)
|}

== Other Operations ==

{|
! class="pfrow" | NIL
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | No action is performed
|-
! class="pfrow" | NOP
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a null operation (consumes time; does not change the processor's state)
|}

[[category:Compiladores]]
[[category:Ensino]]

Postfix Reference Guide

2026-05-18T13:57:13Z

Root: /* Simple Stack Operations */

{{TOCright}}

The Postfix reference guide contains information about the structure and operations of the stack machine.

The original stack machine was created by Santos (2004). Is was composed by a set of macros to be used with printf functions. Each macro would “take” as arguments, either a number or a string. This was a simple and effective approach but was limited in its expressiveness.

The current postﬁx code generator class maintains the stack machine abstraction, but does not rely on macros. Instead, it deﬁnes an interface to be used by semantic analysers, as deﬁned by a strategy pattern (Gamma et al., 1995). Speciﬁc implementations provide the realization of the postﬁx commands for a particular target machine. Since it is written in C++, it's very easy to extend to new needs and implementations (new target machines).

Like the original postfix code generator, the current abstraction uses an architecture based on a stack machine, hence the name "postfix", and three registers.
# IP -- the instruction pointer -- indicates the position of the next instruction to be executed;
# SP -- the stack pointer -- indicates the position of the element currently at the stack top;
# FP -- the frame pointer -- indicates the position of the activation register of the function currently being executed.

In the following tables, the "stack" columns present the results of the actions on the values at the top of the stack. Note that only elements relevant in a given context, i.e., that of the postfix instruction being executed, are shown. The notation '''#length''' represents a set of ''length'' consecutive bytes in the stack, i.e., a vector.

{|
! class="pfrow" | OPERATION
! class="pfrow" | stack before
! class="pfrow" | stack after
! class="pfdesc" | Description of actions
|}

Consider the following fictitious example:

{|
! class="pfrow" | FAKE
! class="pfrow" | $ a #8 b
! class="pfrow" | $ a b
! class="pfdesc" | This is a fake operation
|}

In this example, before the FAKE operation, the stack had at its top '''b''', followed by eight bytes, followed by '''a'''. After executing the FAKE operation (which used those elements in some way), the stack has at its top '''b''', followed by '''a'''. The symbol '''$''' is used to denote the point in the stack not affected by the current operation (this could be the top if the stack were empty).

The following groups of operations are available in the Postfix interface:

== Segments, Values, and Labels ==

=== Segment selection ===

These operations select various segments. They do not affect the stack.

{|
! class="pfrow" | BSS
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for uninitialized values
|-
! class="pfrow" | DATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized values
|-
! class="pfrow" | RODATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized constant values
|-
! class="pfrow" | TEXT
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment (default)
|-
! class="pfrow" | TEXT name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''name''
|-
! class="pfrow" | TEXT number
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''number''
|}

=== Values (declaration in segments) ===

These operations declare values directly in various segments. They do not affect the stack.

{|
! class="pfrow" | SALLOC size
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares an uninitialized vector with length '''size''' (in bytes)
|-
! class="pfrow" | SSHORT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 16-bit integer '''value'''
|-
! class="pfrow" | SBYTE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 8-bit character '''value'''
|-
! class="pfrow" | SINT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 32-bit integer '''value'''
|-
! class="pfrow" | SBALANCED3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static balanced ternary integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | SFLOAT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static simple precision (32-bit) floating point '''value'''
|-
! class="pfrow" | SDOUBLE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static double precision (64-bit) floating point '''value'''
|-
! class="pfrow" | SPOSIT3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary posit real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | STAKUM3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary takum real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SADDR name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a name for an address (i.e., declares the address associated with '''name''')
|-
! class="pfrow" | SSTRING string
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static NULL-terminated character '''string''' (C-like) (may contain special characters)
|}

=== Labels ===

These operations handle symbols and their definitions within some segment. They do not affect the stack.

{|
! class="pfrow" | ALIGN
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Forces the alignment of code or data
|-
! class="pfrow" | LABEL name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a new label '''name'''
|-
! class="pfrow" | EXTERN name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares '''name''' as a symbol externally defined, i.e., defined in another compilation module
|-
! class="pfrow" | GLOBAL name, type
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a '''name''' with a given '''type''' (see below) -- the declaration of a name must preceed its definition
|}


In a declaration common to several modules, any number of modules may contain common or external declarations, but only one of them may contain an initialized declaration. A declaration does not need to be specified in a specific segment.

Global names may be of different types. These labels are to be used to generate the types needed for the second argument of '''GLOBAL'''.
* NONE - Unknown type
* FUNC - Name/label corresponds to a function
* OBJ - Name/label corresponds to an object (data)

== Addressing, Loading and Storing ==

Absolute addressing uses addresses based on named labels. Local addressing is used in function frames and uses offsets relative to the frame pointer to load data: negative addresses correspond to local variables, offset zero contains the previous (saved) value of the frame pointer, offset 4 (32 bits) contains the previous (saved) value of the instruction pointer, and, after offset 8, reside the function arguments.

=== Adressing operations ===

{|
! class="pfrow" | ADDR name
! class="pfrow" | $
! class="pfrow" | $ name
! class="pfdesc" | Absolute addressing: load address of '''name'''
|-
! class="pfrow" | ADDRA name
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Absolute addressing: store '''value''' to '''name'''
|-
! class="pfrow" | ADDRV name
! class="pfrow" | $
! class="pfrow" | $ [name]
! class="pfdesc" | Absolute addressing: load value at '''name'''
|-
! class="pfrow" | LOCAL offset
! class="pfrow" | $
! class="pfrow" | $ fp+offset
! class="pfdesc" | Local addressing: load address of '''offset'''
|-
! class="pfrow" | LOCA offset
! class="pfrow" | $ a
! class="pfrow" | $
! class="pfdesc" | Local addressing: writes '''a''' to '''offset'''
|-
! class="pfrow" | LOCV offset
! class="pfrow" | $
! class="pfrow" | $ [fp+offset]
! class="pfdesc" | Local addressing: load value at '''offset'''
|}

ADDRA, ADDRV, LOCA, LOCV are functionally equivalent to ADDR+STINT, ADDR+LDINT, LOCAL+STINT, LOCAL+LDINT, but the generated code is more efficient. They are compound operations (i.e., they contain not only the addressing part, but also the load/store part as well). Note that the postfix_writer visitor is, in general, incapable of generating these instructions.

=== Load operations ===

The load instructions assume that the top of the stack contains an address pointing to the data to be read. Each load instruction will replace the address at the top of the stack with the contents of the position it points to. Load operations differ only in what they load.

{|
! class="pfrow" | LDBYTE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 1 byte (char)
|-
! class="pfrow" | LDSHORT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 2 bytes (short)
|-
! class="pfrow" | LDINT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (int)
|-
! class="pfrow" | LDBALANCED3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | LDFLOAT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (float)
|-
! class="pfrow" | LDDOUBLE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (double)
|-
! class="pfrow" | LDPOSIT3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|-
! class="pfrow" | LDTAKUM3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|}

=== Store operations ===

Store instructions assume the stack contains at the top the address where data is to be stored. That data is in the stack, immediately after the address. Store instructions differ only in what they store.

{|
! class="pfrow" | STBYTE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 1 byte (char)
|-
! class="pfrow" | STSHORT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 2 bytes (short)
|-
! class="pfrow" | STINT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (int)
|-
! class="pfrow" | STBALANCED3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | STFLOAT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (float)
|-
! class="pfrow" | STDOUBLE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (double)
|-
! class="pfrow" | STPOSIT3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|-
! class="pfrow" | STTAKUM3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|}

== Simple Stack Operations ==

{|
! class="pfrow" | DUP32
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 32-bit value at the top of the stack
|-
! class="pfrow" | DUP64
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 64-bit value at the top of the stack
|-
! class="pfrow" | DUP128
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 128-bit value at the top of the stack
|-
! class="pfrow" | INT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an integer '''value'''
|-
! class="pfrow" | BALANCED3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary balanced integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | FLOAT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a 4-byte float '''value''' (32 bits, single precision)
|-
! class="pfrow" | DOUBLE value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an 8-byte float '''value''' (64 bits, double precision)
|-
! class="pfrow" | POSIT3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | TAKUM3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SP
! class="pfrow" | $
! class="pfrow" | $ sp
! class="pfdesc" | Pushes the value of the stack pointer
|-
! class="pfrow" | SWAP32
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 32-bit values at the top of the stack
|-
! class="pfrow" | SWAP64
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 64-bit values at the top of the stack
|-
! class="pfrow" | SWAP128
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 128-bit values at the top of the stack
|-
! class="pfrow" | ALLOC
! class="pfrow" | $ bytes
! class="pfrow" | $ #bytes
! class="pfdesc" | Allocates in the stack an array with size '''bytes'''. Since this operation alters the meaning of offsets in the stack, care should be taken when local variables exist.
|}

== Arithmetic Operations ==

The arithmetic operations considered here apply to both signed and unsigned integer arguments, and to double precision floating point arguments.

=== Binary integer (32-bit) operations ===

{|
! class="pfrow" | NEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | ADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | SUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | MUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | DIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | MOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|-
! class="pfrow" | UDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two natural (unsigned) integer values
|-
! class="pfrow" | UMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two natural (unsigned) integer values.
|}

=== Ternary integer (64-bit/40-trit) operations ===

{|
! class="pfrow" | BNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | BADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | BSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | BMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | BDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | BMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|}

=== Floating point (64-bit) operations ===

These operations take double precision floating point operands.

{|
! class="pfrow" | DNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | DADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | DSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | DMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | DDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary posit (128-bit/80-trit) operations ===

These operations take ternary posit operands.

{|
! class="pfrow" | PNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | PADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | PSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | PMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | PDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary takum (128-bit/80-trit) operations ===

These operations take ternary takum operands.

{|
! class="pfrow" | TNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | TADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | TSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | TMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | TDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

== Increment and Decrement Operations ==

{|
! class="pfrow" | INCR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Adds '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]+delta''
|-
! class="pfrow" | DECR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Subtracts '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]-delta''
|}

== Type Conversion Operations ==

The following instructions perform type conversions. The conversions are from and to integers (both binary and ternary) and real values (simple and double precision floating point, posit, and takum).

{|
! class="pfrow" | SRC2DST
! class="pfrow" | $ src
! class="pfrow" | $ dst
! class="pfdesc" | Converts from source format ('''src''') to destination format ('''dst''')
|}

'''SRC''' and '''DST''' in the instuction above are as follows (not all combinations are available -- see the following table):
* '''B''': Balanced ternary integer (64-bit/40-trit)
* '''D''': Double precision floating point (64-bit)
* '''F''': Single precision / simple precision floating point (32-bit)
* '''I''': Binary integer (32-bit)
* '''P''': Ternary posit (128-bit/80-trit)
* '''T''': Ternary takum (128-bit/80-trit)

{| class="wikitable" style="text-align:center;"
|+ Instruction Opcodes (From Row \ To Column)
! !! B !! D !! F !! I !! P !! T
|-
! B
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| B2I
| B2P
| B2T
|-
! D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| D2F
| D2I
| D2P
| D2T
|-
! F
| style="background:#ececec; color:gray;" | -
| F2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! I
| I2B
| I2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! P
| P2B
| P2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| P2T
|-
! T
| T2B
| T2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| T2P
| style="background:#ececec; color:gray;" | -
|}

== Comparison Operations ==

=== Binary integer comparison instructions ===

The comparison instructions are binary operations (each operand is a 32-bit binary integer) that leave at the top of the stack 0 (zero) or 1 (one), depending on the result of the comparison: respectively, '''false''' or '''true''' (32-bit binary integer). The value may be directly used to perform conditional jumps (e.g., JZ, JNZ), that use the value of the top of the stack instead of relying on special processor registers ("flags").

{|
! class="pfrow" | EQ
! class="pfrow" | $ a b
! class="pfrow" | $ a&equiv;b
! class="pfdesc" | ''equal to''
|-
! class="pfrow" | NE
! class="pfrow" | $ a b
! class="pfrow" | $ a≠b
! class="pfdesc" | ''not equal to''
|}

{|
! class="pfrow" | GT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than''
|-
! class="pfrow" | GE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to''
|-
! class="pfrow" | LE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to''
|-
! class="pfrow" | LT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than''
|}

The following consider unsigned 32-bit binary integer operands (the result is also a 32-bit binary integer):

{|
! class="pfrow" | UGT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than'' for unsigned integers
|-
! class="pfrow" | UGE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to'' for unsigned integers
|-
! class="pfrow" | ULE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to'' for unsigned integers
|-
! class="pfrow" | ULT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than'' for unsigned integers
|}

=== Comparison operators for real numbers ===

The DCMP operator compares two double precision binary floating point numbers (64 bits). The result is a 32-bit binary integer value: less than 0, if the first operand is lower than the second; 0, if they are equal; greater than 0, otherwise. 

{|
! class="pfrow" | DCMP
! class="pfrow" | $ a b
! class="pfrow" | $ i
! class="pfdesc" | "compare" -- i<0, a<b; i&equiv;0, a&equiv;b; i>0, a>b

|}

== Bitwise Operations ==

These operators take and 32-bit binary integer operands. The result is also a 32-bit binary integer.
{|
! class="pfrow" | NOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | Bitwise negation, i.e., one's complement
|-
! class="pfrow" | AND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | Bitwise AND operation
|-
! class="pfrow" | OR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | Bitwise OR operation
|-
! class="pfrow" | XOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&oplus;b
! class="pfdesc" | Bitwise XOR (exclusive OR) operation
|}

== Ternary Kleene logic operations ==

These operators take balanced ternary (64-bit/40-trit) integer operands. Note that these operators do not short-circuit Kleene logic with KAND/KOR. The result is also a balanced ternary (64-bit/40-trit) integer.
{|
! class="pfrow" | KNOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | NOT operation
|-
! class="pfrow" | KAND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | AND operation
|-
! class="pfrow" | KOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | OR operation
|}

== Rotation and Shift Operations ==

Shift and rotation operations have as maximum value the number of bits of the underlying processor register (32 bits in a ix86-family processor). Safe operation for values above that limit is not guaranteed.

{|
! class="pfrow" | ROTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rl>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the left
|-
! class="pfrow" | ROTR
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rr>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the right
|-
! class="pfrow" | SHTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<<bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the left
|-
! class="pfrow" | SHTRU
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (unsigned)
|-
! class="pfrow" | SHTRS
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (signed)
|}

== Function Definition ==

The following sections cover defining and calling functions.

=== Starting a function ===

Each function must allocate space for its local variables. This is done immediately after being called and before any other processing. The relevant operations are ENTER (to specify a given memory amount) and START (no space is reserved for local variables. Note that these operations do more than manipulate the stack: they also create an activation register for the function, i.e., they update the frame pointer and define a new stack frame.

{|
! class="pfrow" | ENTER bytes
! class="pfrow" | $
! class="pfrow" | $ fp #bytes
! class="pfdesc" | Starts a function: pushes the frame pointer (activation register) to the stack and allocates space for local variables ('''bytes''')
|-
! class="pfrow" | START
! class="pfrow" | $
! class="pfrow" | $ fp
! class="pfdesc" | Equivalent to "ENTER 0"
|}

=== Leaving a function ===

STFVAL32I/STFVAL32F or STFVAL64I/STFVAL64F must be called to specify return values in accordance with C conventions. Only return values that fit in the indicated registers need these operations. Other return values are passed by pointer.

{|
! class="pfrow" | STFVAL32I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 32-bit integer value from the stack (to eax)
|-
! class="pfrow" | STFVAL64I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 64-bit integer value from the stack (to eax:edx)
|-
! class="pfrow" | STFVAL32F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a single-precision (32-bit) floating point value from the stack (to st0)
|-
! class="pfrow" | STFVAL64F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a double-precision (64-bit) floating point value from the stack (to st0)
|}

Note that balanced-ternary numbers are represented by 64-bit binary numbers. Takums cannot be directly returned (they must be returned via pointer).

The stack frame is destroyed by the LEAVE operation. This action must be performed immediately before returning control to the caller (with RET).

{|
! class="pfrow" | LEAVE
! class="pfrow" | $ fp ...
! class="pfrow" | $
! class="pfdesc" | Ends a function: restores the frame pointer (activation register) and destroys the function-local stack data
|}

After the function's stack frame is destroyed and the activation register is restored to the caller, control must also be returned to the caller (i.e., IP must be updated).

{|
! class="pfrow" | RET
! class="pfrow" | $ addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function (the stack must contain the return address)
|-
! class="pfrow" | RETN bytes
! class="pfrow" | $ #bytes addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function and removes '''bytes''' from the caller's stack after removing the return address. This is more or less the same as "RET+TRASH bytes". '''Note that this is not compatible with the Cdecl calling conventions.'''
|}

== Function Calls ==

In a stack machine the arguments for a function call are already in the stack. Thus, it is not necessary to put them there (it is enough not to remove them).

{|
! class="pfrow" | CALL name
! class="pfrow" | $
! class="pfrow" | $ return-address
! class="pfdesc" | Calls the '''name'''d function. The '''return-address''' is pushed to the stack.
|-
! class="pfrow" | BRANCH
! class="pfrow" | $ address
! class="pfrow" | $ return-address
! class="pfdesc" | Invokes a function at the '''address''' indicated at the top of the stack. The '''return-address''' is pushed to the stack.
|}

When building functions that conform to the C calling convention, the arguments are destroyed by the caller, ''after'' the return of the callee, using TRASH and stating the total size (i.e., for all arguments).

{|
! class="pfrow" | TRASH bytes
! class="pfrow" | $ #bytes
! class="pfrow" | $
! class="pfdesc" | Removes '''bytes''' from the stack
|}

To recover the returned value by the callee, and put it in the stack, the caller must call LDFVAL32I (32-bit integer value in eax) or LDFVAL32F (32-bit single-precision floating point value in st0). An analogous procedure is valid for LDFVAL64I (64-bit integer value in eax:edx) and LDFVAL64F (64-bit double-precision floating point value in st0).

{|
! class="pfrow" | LDFVAL32I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax register to the stack
|-
! class="pfrow" | LDFVAL64I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax:edx registers to the stack
|-
! class="pfrow" | LDFVAL32F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (32 bits, single precision)
|-
! class="pfrow" | LDFVAL64F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (64 bits, double precision)
|}

== Basic Jump Operations ==

{|
! class="pfrow" | JMP label
! class="pfrow" | $
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to '''label''' (does not affect or use the stack)
|-
! class="pfrow" | LEAP
! class="pfrow" | $ address
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to the '''address''' at the top of the stack
|}

== Conditional Jump Operations ==

{|
! class="pfrow" | JZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is 0 (zero)
|-
! class="pfrow" | JNZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is non-zero
|}

The following operations combine comparisons and jumps.

{|
! class="pfrow" | JEQ label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a&equiv;b
|-
! class="pfrow" | JNE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≠b
|}

{|
! class="pfrow" | JGT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a>b
|-
! class="pfrow" | JGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b
|-
! class="pfrow" | JLE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b
|-
! class="pfrow" | JLT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if ab (unsigned)
|-
! class="pfrow" | JUGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b (unsigned)
|-
! class="pfrow" | JULE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b (unsigned)
|-
! class="pfrow" | JULT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a<b (unsigned)
|}

== Other Operations ==

{|
! class="pfrow" | NIL
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | No action is performed
|-
! class="pfrow" | NOP
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a null operation (consumes time; does not change the processor's state)
|}

[[category:Compiladores]]
[[category:Ensino]]

Postfix Reference Guide

2026-05-18T13:56:47Z

Root: /* Store operations */

{{TOCright}}

The Postfix reference guide contains information about the structure and operations of the stack machine.

The original stack machine was created by Santos (2004). Is was composed by a set of macros to be used with printf functions. Each macro would “take” as arguments, either a number or a string. This was a simple and effective approach but was limited in its expressiveness.

The current postﬁx code generator class maintains the stack machine abstraction, but does not rely on macros. Instead, it deﬁnes an interface to be used by semantic analysers, as deﬁned by a strategy pattern (Gamma et al., 1995). Speciﬁc implementations provide the realization of the postﬁx commands for a particular target machine. Since it is written in C++, it's very easy to extend to new needs and implementations (new target machines).

Like the original postfix code generator, the current abstraction uses an architecture based on a stack machine, hence the name "postfix", and three registers.
# IP -- the instruction pointer -- indicates the position of the next instruction to be executed;
# SP -- the stack pointer -- indicates the position of the element currently at the stack top;
# FP -- the frame pointer -- indicates the position of the activation register of the function currently being executed.

In the following tables, the "stack" columns present the results of the actions on the values at the top of the stack. Note that only elements relevant in a given context, i.e., that of the postfix instruction being executed, are shown. The notation '''#length''' represents a set of ''length'' consecutive bytes in the stack, i.e., a vector.

{|
! class="pfrow" | OPERATION
! class="pfrow" | stack before
! class="pfrow" | stack after
! class="pfdesc" | Description of actions
|}

Consider the following fictitious example:

{|
! class="pfrow" | FAKE
! class="pfrow" | $ a #8 b
! class="pfrow" | $ a b
! class="pfdesc" | This is a fake operation
|}

In this example, before the FAKE operation, the stack had at its top '''b''', followed by eight bytes, followed by '''a'''. After executing the FAKE operation (which used those elements in some way), the stack has at its top '''b''', followed by '''a'''. The symbol '''$''' is used to denote the point in the stack not affected by the current operation (this could be the top if the stack were empty).

The following groups of operations are available in the Postfix interface:

== Segments, Values, and Labels ==

=== Segment selection ===

These operations select various segments. They do not affect the stack.

{|
! class="pfrow" | BSS
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for uninitialized values
|-
! class="pfrow" | DATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized values
|-
! class="pfrow" | RODATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized constant values
|-
! class="pfrow" | TEXT
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment (default)
|-
! class="pfrow" | TEXT name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''name''
|-
! class="pfrow" | TEXT number
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''number''
|}

=== Values (declaration in segments) ===

These operations declare values directly in various segments. They do not affect the stack.

{|
! class="pfrow" | SALLOC size
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares an uninitialized vector with length '''size''' (in bytes)
|-
! class="pfrow" | SSHORT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 16-bit integer '''value'''
|-
! class="pfrow" | SBYTE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 8-bit character '''value'''
|-
! class="pfrow" | SINT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 32-bit integer '''value'''
|-
! class="pfrow" | SBALANCED3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static balanced ternary integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | SFLOAT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static simple precision (32-bit) floating point '''value'''
|-
! class="pfrow" | SDOUBLE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static double precision (64-bit) floating point '''value'''
|-
! class="pfrow" | SPOSIT3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary posit real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | STAKUM3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary takum real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SADDR name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a name for an address (i.e., declares the address associated with '''name''')
|-
! class="pfrow" | SSTRING string
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static NULL-terminated character '''string''' (C-like) (may contain special characters)
|}

=== Labels ===

These operations handle symbols and their definitions within some segment. They do not affect the stack.

{|
! class="pfrow" | ALIGN
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Forces the alignment of code or data
|-
! class="pfrow" | LABEL name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a new label '''name'''
|-
! class="pfrow" | EXTERN name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares '''name''' as a symbol externally defined, i.e., defined in another compilation module
|-
! class="pfrow" | GLOBAL name, type
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a '''name''' with a given '''type''' (see below) -- the declaration of a name must preceed its definition
|}


In a declaration common to several modules, any number of modules may contain common or external declarations, but only one of them may contain an initialized declaration. A declaration does not need to be specified in a specific segment.

Global names may be of different types. These labels are to be used to generate the types needed for the second argument of '''GLOBAL'''.
* NONE - Unknown type
* FUNC - Name/label corresponds to a function
* OBJ - Name/label corresponds to an object (data)

== Addressing, Loading and Storing ==

Absolute addressing uses addresses based on named labels. Local addressing is used in function frames and uses offsets relative to the frame pointer to load data: negative addresses correspond to local variables, offset zero contains the previous (saved) value of the frame pointer, offset 4 (32 bits) contains the previous (saved) value of the instruction pointer, and, after offset 8, reside the function arguments.

=== Adressing operations ===

{|
! class="pfrow" | ADDR name
! class="pfrow" | $
! class="pfrow" | $ name
! class="pfdesc" | Absolute addressing: load address of '''name'''
|-
! class="pfrow" | ADDRA name
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Absolute addressing: store '''value''' to '''name'''
|-
! class="pfrow" | ADDRV name
! class="pfrow" | $
! class="pfrow" | $ [name]
! class="pfdesc" | Absolute addressing: load value at '''name'''
|-
! class="pfrow" | LOCAL offset
! class="pfrow" | $
! class="pfrow" | $ fp+offset
! class="pfdesc" | Local addressing: load address of '''offset'''
|-
! class="pfrow" | LOCA offset
! class="pfrow" | $ a
! class="pfrow" | $
! class="pfdesc" | Local addressing: writes '''a''' to '''offset'''
|-
! class="pfrow" | LOCV offset
! class="pfrow" | $
! class="pfrow" | $ [fp+offset]
! class="pfdesc" | Local addressing: load value at '''offset'''
|}

ADDRA, ADDRV, LOCA, LOCV are functionally equivalent to ADDR+STINT, ADDR+LDINT, LOCAL+STINT, LOCAL+LDINT, but the generated code is more efficient. They are compound operations (i.e., they contain not only the addressing part, but also the load/store part as well). Note that the postfix_writer visitor is, in general, incapable of generating these instructions.

=== Load operations ===

The load instructions assume that the top of the stack contains an address pointing to the data to be read. Each load instruction will replace the address at the top of the stack with the contents of the position it points to. Load operations differ only in what they load.

{|
! class="pfrow" | LDBYTE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 1 byte (char)
|-
! class="pfrow" | LDSHORT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 2 bytes (short)
|-
! class="pfrow" | LDINT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (int)
|-
! class="pfrow" | LDBALANCED3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | LDFLOAT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (float)
|-
! class="pfrow" | LDDOUBLE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (double)
|-
! class="pfrow" | LDPOSIT3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|-
! class="pfrow" | LDTAKUM3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|}

=== Store operations ===

Store instructions assume the stack contains at the top the address where data is to be stored. That data is in the stack, immediately after the address. Store instructions differ only in what they store.

{|
! class="pfrow" | STBYTE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 1 byte (char)
|-
! class="pfrow" | STSHORT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 2 bytes (short)
|-
! class="pfrow" | STINT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (int)
|-
! class="pfrow" | STBALANCED3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | STFLOAT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (float)
|-
! class="pfrow" | STDOUBLE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (double)
|-
! class="pfrow" | STPOSIT3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|-
! class="pfrow" | STTAKUM3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|}

== Simple Stack Operations ==

{|
! class="pfrow" | DUP32
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 32-bit value at the top of the stack
|-
! class="pfrow" | DUP64
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 64-bit value at the top of the stack
|-
! class="pfrow" | DUP128
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 128-bit value at the top of the stack
|-
! class="pfrow" | INT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an integer '''value'''
|-
! class="pfrow" | BALANCED3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary balanced integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | FLOAT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a 4-byte float '''value''' (32 bits, single precision)
|-
! class="pfrow" | DOUBLE value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an 8-byte float '''value''' (64 bits, double precision)
|-
! class="pfrow" | TAKUM3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SP
! class="pfrow" | $
! class="pfrow" | $ sp
! class="pfdesc" | Pushes the value of the stack pointer
|-
! class="pfrow" | SWAP32
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 32-bit values at the top of the stack
|-
! class="pfrow" | SWAP64
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 64-bit values at the top of the stack
|-
! class="pfrow" | SWAP128
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 128-bit values at the top of the stack
|-
! class="pfrow" | ALLOC
! class="pfrow" | $ bytes
! class="pfrow" | $ #bytes
! class="pfdesc" | Allocates in the stack an array with size '''bytes'''. Since this operation alters the meaning of offsets in the stack, care should be taken when local variables exist.
|}

== Arithmetic Operations ==

The arithmetic operations considered here apply to both signed and unsigned integer arguments, and to double precision floating point arguments.

=== Binary integer (32-bit) operations ===

{|
! class="pfrow" | NEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | ADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | SUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | MUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | DIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | MOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|-
! class="pfrow" | UDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two natural (unsigned) integer values
|-
! class="pfrow" | UMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two natural (unsigned) integer values.
|}

=== Ternary integer (64-bit/40-trit) operations ===

{|
! class="pfrow" | BNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | BADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | BSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | BMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | BDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | BMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|}

=== Floating point (64-bit) operations ===

These operations take double precision floating point operands.

{|
! class="pfrow" | DNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | DADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | DSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | DMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | DDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary posit (128-bit/80-trit) operations ===

These operations take ternary posit operands.

{|
! class="pfrow" | PNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | PADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | PSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | PMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | PDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary takum (128-bit/80-trit) operations ===

These operations take ternary takum operands.

{|
! class="pfrow" | TNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | TADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | TSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | TMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | TDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

== Increment and Decrement Operations ==

{|
! class="pfrow" | INCR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Adds '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]+delta''
|-
! class="pfrow" | DECR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Subtracts '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]-delta''
|}

== Type Conversion Operations ==

The following instructions perform type conversions. The conversions are from and to integers (both binary and ternary) and real values (simple and double precision floating point, posit, and takum).

{|
! class="pfrow" | SRC2DST
! class="pfrow" | $ src
! class="pfrow" | $ dst
! class="pfdesc" | Converts from source format ('''src''') to destination format ('''dst''')
|}

'''SRC''' and '''DST''' in the instuction above are as follows (not all combinations are available -- see the following table):
* '''B''': Balanced ternary integer (64-bit/40-trit)
* '''D''': Double precision floating point (64-bit)
* '''F''': Single precision / simple precision floating point (32-bit)
* '''I''': Binary integer (32-bit)
* '''P''': Ternary posit (128-bit/80-trit)
* '''T''': Ternary takum (128-bit/80-trit)

{| class="wikitable" style="text-align:center;"
|+ Instruction Opcodes (From Row \ To Column)
! !! B !! D !! F !! I !! P !! T
|-
! B
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| B2I
| B2P
| B2T
|-
! D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| D2F
| D2I
| D2P
| D2T
|-
! F
| style="background:#ececec; color:gray;" | -
| F2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! I
| I2B
| I2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! P
| P2B
| P2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| P2T
|-
! T
| T2B
| T2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| T2P
| style="background:#ececec; color:gray;" | -
|}

== Comparison Operations ==

=== Binary integer comparison instructions ===

The comparison instructions are binary operations (each operand is a 32-bit binary integer) that leave at the top of the stack 0 (zero) or 1 (one), depending on the result of the comparison: respectively, '''false''' or '''true''' (32-bit binary integer). The value may be directly used to perform conditional jumps (e.g., JZ, JNZ), that use the value of the top of the stack instead of relying on special processor registers ("flags").

{|
! class="pfrow" | EQ
! class="pfrow" | $ a b
! class="pfrow" | $ a&equiv;b
! class="pfdesc" | ''equal to''
|-
! class="pfrow" | NE
! class="pfrow" | $ a b
! class="pfrow" | $ a≠b
! class="pfdesc" | ''not equal to''
|}

{|
! class="pfrow" | GT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than''
|-
! class="pfrow" | GE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to''
|-
! class="pfrow" | LE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to''
|-
! class="pfrow" | LT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than''
|}

The following consider unsigned 32-bit binary integer operands (the result is also a 32-bit binary integer):

{|
! class="pfrow" | UGT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than'' for unsigned integers
|-
! class="pfrow" | UGE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to'' for unsigned integers
|-
! class="pfrow" | ULE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to'' for unsigned integers
|-
! class="pfrow" | ULT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than'' for unsigned integers
|}

=== Comparison operators for real numbers ===

The DCMP operator compares two double precision binary floating point numbers (64 bits). The result is a 32-bit binary integer value: less than 0, if the first operand is lower than the second; 0, if they are equal; greater than 0, otherwise. 

{|
! class="pfrow" | DCMP
! class="pfrow" | $ a b
! class="pfrow" | $ i
! class="pfdesc" | "compare" -- i<0, a<b; i&equiv;0, a&equiv;b; i>0, a>b

|}

== Bitwise Operations ==

These operators take and 32-bit binary integer operands. The result is also a 32-bit binary integer.
{|
! class="pfrow" | NOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | Bitwise negation, i.e., one's complement
|-
! class="pfrow" | AND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | Bitwise AND operation
|-
! class="pfrow" | OR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | Bitwise OR operation
|-
! class="pfrow" | XOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&oplus;b
! class="pfdesc" | Bitwise XOR (exclusive OR) operation
|}

== Ternary Kleene logic operations ==

These operators take balanced ternary (64-bit/40-trit) integer operands. Note that these operators do not short-circuit Kleene logic with KAND/KOR. The result is also a balanced ternary (64-bit/40-trit) integer.
{|
! class="pfrow" | KNOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | NOT operation
|-
! class="pfrow" | KAND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | AND operation
|-
! class="pfrow" | KOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | OR operation
|}

== Rotation and Shift Operations ==

Shift and rotation operations have as maximum value the number of bits of the underlying processor register (32 bits in a ix86-family processor). Safe operation for values above that limit is not guaranteed.

{|
! class="pfrow" | ROTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rl>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the left
|-
! class="pfrow" | ROTR
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rr>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the right
|-
! class="pfrow" | SHTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<<bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the left
|-
! class="pfrow" | SHTRU
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (unsigned)
|-
! class="pfrow" | SHTRS
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (signed)
|}

== Function Definition ==

The following sections cover defining and calling functions.

=== Starting a function ===

Each function must allocate space for its local variables. This is done immediately after being called and before any other processing. The relevant operations are ENTER (to specify a given memory amount) and START (no space is reserved for local variables. Note that these operations do more than manipulate the stack: they also create an activation register for the function, i.e., they update the frame pointer and define a new stack frame.

{|
! class="pfrow" | ENTER bytes
! class="pfrow" | $
! class="pfrow" | $ fp #bytes
! class="pfdesc" | Starts a function: pushes the frame pointer (activation register) to the stack and allocates space for local variables ('''bytes''')
|-
! class="pfrow" | START
! class="pfrow" | $
! class="pfrow" | $ fp
! class="pfdesc" | Equivalent to "ENTER 0"
|}

=== Leaving a function ===

STFVAL32I/STFVAL32F or STFVAL64I/STFVAL64F must be called to specify return values in accordance with C conventions. Only return values that fit in the indicated registers need these operations. Other return values are passed by pointer.

{|
! class="pfrow" | STFVAL32I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 32-bit integer value from the stack (to eax)
|-
! class="pfrow" | STFVAL64I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 64-bit integer value from the stack (to eax:edx)
|-
! class="pfrow" | STFVAL32F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a single-precision (32-bit) floating point value from the stack (to st0)
|-
! class="pfrow" | STFVAL64F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a double-precision (64-bit) floating point value from the stack (to st0)
|}

Note that balanced-ternary numbers are represented by 64-bit binary numbers. Takums cannot be directly returned (they must be returned via pointer).

The stack frame is destroyed by the LEAVE operation. This action must be performed immediately before returning control to the caller (with RET).

{|
! class="pfrow" | LEAVE
! class="pfrow" | $ fp ...
! class="pfrow" | $
! class="pfdesc" | Ends a function: restores the frame pointer (activation register) and destroys the function-local stack data
|}

After the function's stack frame is destroyed and the activation register is restored to the caller, control must also be returned to the caller (i.e., IP must be updated).

{|
! class="pfrow" | RET
! class="pfrow" | $ addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function (the stack must contain the return address)
|-
! class="pfrow" | RETN bytes
! class="pfrow" | $ #bytes addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function and removes '''bytes''' from the caller's stack after removing the return address. This is more or less the same as "RET+TRASH bytes". '''Note that this is not compatible with the Cdecl calling conventions.'''
|}

== Function Calls ==

In a stack machine the arguments for a function call are already in the stack. Thus, it is not necessary to put them there (it is enough not to remove them).

{|
! class="pfrow" | CALL name
! class="pfrow" | $
! class="pfrow" | $ return-address
! class="pfdesc" | Calls the '''name'''d function. The '''return-address''' is pushed to the stack.
|-
! class="pfrow" | BRANCH
! class="pfrow" | $ address
! class="pfrow" | $ return-address
! class="pfdesc" | Invokes a function at the '''address''' indicated at the top of the stack. The '''return-address''' is pushed to the stack.
|}

When building functions that conform to the C calling convention, the arguments are destroyed by the caller, ''after'' the return of the callee, using TRASH and stating the total size (i.e., for all arguments).

{|
! class="pfrow" | TRASH bytes
! class="pfrow" | $ #bytes
! class="pfrow" | $
! class="pfdesc" | Removes '''bytes''' from the stack
|}

To recover the returned value by the callee, and put it in the stack, the caller must call LDFVAL32I (32-bit integer value in eax) or LDFVAL32F (32-bit single-precision floating point value in st0). An analogous procedure is valid for LDFVAL64I (64-bit integer value in eax:edx) and LDFVAL64F (64-bit double-precision floating point value in st0).

{|
! class="pfrow" | LDFVAL32I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax register to the stack
|-
! class="pfrow" | LDFVAL64I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax:edx registers to the stack
|-
! class="pfrow" | LDFVAL32F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (32 bits, single precision)
|-
! class="pfrow" | LDFVAL64F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (64 bits, double precision)
|}

== Basic Jump Operations ==

{|
! class="pfrow" | JMP label
! class="pfrow" | $
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to '''label''' (does not affect or use the stack)
|-
! class="pfrow" | LEAP
! class="pfrow" | $ address
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to the '''address''' at the top of the stack
|}

== Conditional Jump Operations ==

{|
! class="pfrow" | JZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is 0 (zero)
|-
! class="pfrow" | JNZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is non-zero
|}

The following operations combine comparisons and jumps.

{|
! class="pfrow" | JEQ label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a&equiv;b
|-
! class="pfrow" | JNE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≠b
|}

{|
! class="pfrow" | JGT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a>b
|-
! class="pfrow" | JGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b
|-
! class="pfrow" | JLE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b
|-
! class="pfrow" | JLT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if ab (unsigned)
|-
! class="pfrow" | JUGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b (unsigned)
|-
! class="pfrow" | JULE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b (unsigned)
|-
! class="pfrow" | JULT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a<b (unsigned)
|}

== Other Operations ==

{|
! class="pfrow" | NIL
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | No action is performed
|-
! class="pfrow" | NOP
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a null operation (consumes time; does not change the processor's state)
|}

[[category:Compiladores]]
[[category:Ensino]]

Postfix Reference Guide

2026-05-18T13:56:26Z

Root: /* Load operations */

{{TOCright}}

The Postfix reference guide contains information about the structure and operations of the stack machine.

The original stack machine was created by Santos (2004). Is was composed by a set of macros to be used with printf functions. Each macro would “take” as arguments, either a number or a string. This was a simple and effective approach but was limited in its expressiveness.

The current postﬁx code generator class maintains the stack machine abstraction, but does not rely on macros. Instead, it deﬁnes an interface to be used by semantic analysers, as deﬁned by a strategy pattern (Gamma et al., 1995). Speciﬁc implementations provide the realization of the postﬁx commands for a particular target machine. Since it is written in C++, it's very easy to extend to new needs and implementations (new target machines).

Like the original postfix code generator, the current abstraction uses an architecture based on a stack machine, hence the name "postfix", and three registers.
# IP -- the instruction pointer -- indicates the position of the next instruction to be executed;
# SP -- the stack pointer -- indicates the position of the element currently at the stack top;
# FP -- the frame pointer -- indicates the position of the activation register of the function currently being executed.

In the following tables, the "stack" columns present the results of the actions on the values at the top of the stack. Note that only elements relevant in a given context, i.e., that of the postfix instruction being executed, are shown. The notation '''#length''' represents a set of ''length'' consecutive bytes in the stack, i.e., a vector.

{|
! class="pfrow" | OPERATION
! class="pfrow" | stack before
! class="pfrow" | stack after
! class="pfdesc" | Description of actions
|}

Consider the following fictitious example:

{|
! class="pfrow" | FAKE
! class="pfrow" | $ a #8 b
! class="pfrow" | $ a b
! class="pfdesc" | This is a fake operation
|}

In this example, before the FAKE operation, the stack had at its top '''b''', followed by eight bytes, followed by '''a'''. After executing the FAKE operation (which used those elements in some way), the stack has at its top '''b''', followed by '''a'''. The symbol '''$''' is used to denote the point in the stack not affected by the current operation (this could be the top if the stack were empty).

The following groups of operations are available in the Postfix interface:

== Segments, Values, and Labels ==

=== Segment selection ===

These operations select various segments. They do not affect the stack.

{|
! class="pfrow" | BSS
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for uninitialized values
|-
! class="pfrow" | DATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized values
|-
! class="pfrow" | RODATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized constant values
|-
! class="pfrow" | TEXT
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment (default)
|-
! class="pfrow" | TEXT name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''name''
|-
! class="pfrow" | TEXT number
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''number''
|}

=== Values (declaration in segments) ===

These operations declare values directly in various segments. They do not affect the stack.

{|
! class="pfrow" | SALLOC size
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares an uninitialized vector with length '''size''' (in bytes)
|-
! class="pfrow" | SSHORT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 16-bit integer '''value'''
|-
! class="pfrow" | SBYTE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 8-bit character '''value'''
|-
! class="pfrow" | SINT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 32-bit integer '''value'''
|-
! class="pfrow" | SBALANCED3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static balanced ternary integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | SFLOAT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static simple precision (32-bit) floating point '''value'''
|-
! class="pfrow" | SDOUBLE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static double precision (64-bit) floating point '''value'''
|-
! class="pfrow" | SPOSIT3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary posit real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | STAKUM3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary takum real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SADDR name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a name for an address (i.e., declares the address associated with '''name''')
|-
! class="pfrow" | SSTRING string
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static NULL-terminated character '''string''' (C-like) (may contain special characters)
|}

=== Labels ===

These operations handle symbols and their definitions within some segment. They do not affect the stack.

{|
! class="pfrow" | ALIGN
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Forces the alignment of code or data
|-
! class="pfrow" | LABEL name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a new label '''name'''
|-
! class="pfrow" | EXTERN name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares '''name''' as a symbol externally defined, i.e., defined in another compilation module
|-
! class="pfrow" | GLOBAL name, type
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a '''name''' with a given '''type''' (see below) -- the declaration of a name must preceed its definition
|}


In a declaration common to several modules, any number of modules may contain common or external declarations, but only one of them may contain an initialized declaration. A declaration does not need to be specified in a specific segment.

Global names may be of different types. These labels are to be used to generate the types needed for the second argument of '''GLOBAL'''.
* NONE - Unknown type
* FUNC - Name/label corresponds to a function
* OBJ - Name/label corresponds to an object (data)

== Addressing, Loading and Storing ==

Absolute addressing uses addresses based on named labels. Local addressing is used in function frames and uses offsets relative to the frame pointer to load data: negative addresses correspond to local variables, offset zero contains the previous (saved) value of the frame pointer, offset 4 (32 bits) contains the previous (saved) value of the instruction pointer, and, after offset 8, reside the function arguments.

=== Adressing operations ===

{|
! class="pfrow" | ADDR name
! class="pfrow" | $
! class="pfrow" | $ name
! class="pfdesc" | Absolute addressing: load address of '''name'''
|-
! class="pfrow" | ADDRA name
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Absolute addressing: store '''value''' to '''name'''
|-
! class="pfrow" | ADDRV name
! class="pfrow" | $
! class="pfrow" | $ [name]
! class="pfdesc" | Absolute addressing: load value at '''name'''
|-
! class="pfrow" | LOCAL offset
! class="pfrow" | $
! class="pfrow" | $ fp+offset
! class="pfdesc" | Local addressing: load address of '''offset'''
|-
! class="pfrow" | LOCA offset
! class="pfrow" | $ a
! class="pfrow" | $
! class="pfdesc" | Local addressing: writes '''a''' to '''offset'''
|-
! class="pfrow" | LOCV offset
! class="pfrow" | $
! class="pfrow" | $ [fp+offset]
! class="pfdesc" | Local addressing: load value at '''offset'''
|}

ADDRA, ADDRV, LOCA, LOCV are functionally equivalent to ADDR+STINT, ADDR+LDINT, LOCAL+STINT, LOCAL+LDINT, but the generated code is more efficient. They are compound operations (i.e., they contain not only the addressing part, but also the load/store part as well). Note that the postfix_writer visitor is, in general, incapable of generating these instructions.

=== Load operations ===

The load instructions assume that the top of the stack contains an address pointing to the data to be read. Each load instruction will replace the address at the top of the stack with the contents of the position it points to. Load operations differ only in what they load.

{|
! class="pfrow" | LDBYTE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 1 byte (char)
|-
! class="pfrow" | LDSHORT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 2 bytes (short)
|-
! class="pfrow" | LDINT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (int)
|-
! class="pfrow" | LDBALANCED3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | LDFLOAT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (float)
|-
! class="pfrow" | LDDOUBLE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (double)
|-
! class="pfrow" | LDPOSIT3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|-
! class="pfrow" | LDTAKUM3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|}

=== Store operations ===

Store instructions assume the stack contains at the top the address where data is to be stored. That data is in the stack, immediately after the address. Store instructions differ only in what they store.

{|
! class="pfrow" | STBYTE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 1 byte (char)
|-
! class="pfrow" | STSHORT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 2 bytes (short)
|-
! class="pfrow" | STINT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (int)
|-
! class="pfrow" | STBALANCED3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | STFLOAT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (float)
|-
! class="pfrow" | STDOUBLE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (double)
|-
! class="pfrow" | STTAKUM3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|}

== Simple Stack Operations ==

{|
! class="pfrow" | DUP32
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 32-bit value at the top of the stack
|-
! class="pfrow" | DUP64
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 64-bit value at the top of the stack
|-
! class="pfrow" | DUP128
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 128-bit value at the top of the stack
|-
! class="pfrow" | INT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an integer '''value'''
|-
! class="pfrow" | BALANCED3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary balanced integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | FLOAT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a 4-byte float '''value''' (32 bits, single precision)
|-
! class="pfrow" | DOUBLE value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an 8-byte float '''value''' (64 bits, double precision)
|-
! class="pfrow" | TAKUM3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SP
! class="pfrow" | $
! class="pfrow" | $ sp
! class="pfdesc" | Pushes the value of the stack pointer
|-
! class="pfrow" | SWAP32
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 32-bit values at the top of the stack
|-
! class="pfrow" | SWAP64
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 64-bit values at the top of the stack
|-
! class="pfrow" | SWAP128
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 128-bit values at the top of the stack
|-
! class="pfrow" | ALLOC
! class="pfrow" | $ bytes
! class="pfrow" | $ #bytes
! class="pfdesc" | Allocates in the stack an array with size '''bytes'''. Since this operation alters the meaning of offsets in the stack, care should be taken when local variables exist.
|}

== Arithmetic Operations ==

The arithmetic operations considered here apply to both signed and unsigned integer arguments, and to double precision floating point arguments.

=== Binary integer (32-bit) operations ===

{|
! class="pfrow" | NEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | ADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | SUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | MUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | DIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | MOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|-
! class="pfrow" | UDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two natural (unsigned) integer values
|-
! class="pfrow" | UMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two natural (unsigned) integer values.
|}

=== Ternary integer (64-bit/40-trit) operations ===

{|
! class="pfrow" | BNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | BADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | BSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | BMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | BDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | BMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|}

=== Floating point (64-bit) operations ===

These operations take double precision floating point operands.

{|
! class="pfrow" | DNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | DADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | DSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | DMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | DDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary posit (128-bit/80-trit) operations ===

These operations take ternary posit operands.

{|
! class="pfrow" | PNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | PADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | PSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | PMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | PDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary takum (128-bit/80-trit) operations ===

These operations take ternary takum operands.

{|
! class="pfrow" | TNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | TADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | TSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | TMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | TDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

== Increment and Decrement Operations ==

{|
! class="pfrow" | INCR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Adds '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]+delta''
|-
! class="pfrow" | DECR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Subtracts '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]-delta''
|}

== Type Conversion Operations ==

The following instructions perform type conversions. The conversions are from and to integers (both binary and ternary) and real values (simple and double precision floating point, posit, and takum).

{|
! class="pfrow" | SRC2DST
! class="pfrow" | $ src
! class="pfrow" | $ dst
! class="pfdesc" | Converts from source format ('''src''') to destination format ('''dst''')
|}

'''SRC''' and '''DST''' in the instuction above are as follows (not all combinations are available -- see the following table):
* '''B''': Balanced ternary integer (64-bit/40-trit)
* '''D''': Double precision floating point (64-bit)
* '''F''': Single precision / simple precision floating point (32-bit)
* '''I''': Binary integer (32-bit)
* '''P''': Ternary posit (128-bit/80-trit)
* '''T''': Ternary takum (128-bit/80-trit)

{| class="wikitable" style="text-align:center;"
|+ Instruction Opcodes (From Row \ To Column)
! !! B !! D !! F !! I !! P !! T
|-
! B
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| B2I
| B2P
| B2T
|-
! D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| D2F
| D2I
| D2P
| D2T
|-
! F
| style="background:#ececec; color:gray;" | -
| F2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! I
| I2B
| I2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! P
| P2B
| P2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| P2T
|-
! T
| T2B
| T2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| T2P
| style="background:#ececec; color:gray;" | -
|}

== Comparison Operations ==

=== Binary integer comparison instructions ===

The comparison instructions are binary operations (each operand is a 32-bit binary integer) that leave at the top of the stack 0 (zero) or 1 (one), depending on the result of the comparison: respectively, '''false''' or '''true''' (32-bit binary integer). The value may be directly used to perform conditional jumps (e.g., JZ, JNZ), that use the value of the top of the stack instead of relying on special processor registers ("flags").

{|
! class="pfrow" | EQ
! class="pfrow" | $ a b
! class="pfrow" | $ a&equiv;b
! class="pfdesc" | ''equal to''
|-
! class="pfrow" | NE
! class="pfrow" | $ a b
! class="pfrow" | $ a≠b
! class="pfdesc" | ''not equal to''
|}

{|
! class="pfrow" | GT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than''
|-
! class="pfrow" | GE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to''
|-
! class="pfrow" | LE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to''
|-
! class="pfrow" | LT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than''
|}

The following consider unsigned 32-bit binary integer operands (the result is also a 32-bit binary integer):

{|
! class="pfrow" | UGT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than'' for unsigned integers
|-
! class="pfrow" | UGE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to'' for unsigned integers
|-
! class="pfrow" | ULE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to'' for unsigned integers
|-
! class="pfrow" | ULT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than'' for unsigned integers
|}

=== Comparison operators for real numbers ===

The DCMP operator compares two double precision binary floating point numbers (64 bits). The result is a 32-bit binary integer value: less than 0, if the first operand is lower than the second; 0, if they are equal; greater than 0, otherwise. 

{|
! class="pfrow" | DCMP
! class="pfrow" | $ a b
! class="pfrow" | $ i
! class="pfdesc" | "compare" -- i<0, a<b; i&equiv;0, a&equiv;b; i>0, a>b

|}

== Bitwise Operations ==

These operators take and 32-bit binary integer operands. The result is also a 32-bit binary integer.
{|
! class="pfrow" | NOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | Bitwise negation, i.e., one's complement
|-
! class="pfrow" | AND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | Bitwise AND operation
|-
! class="pfrow" | OR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | Bitwise OR operation
|-
! class="pfrow" | XOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&oplus;b
! class="pfdesc" | Bitwise XOR (exclusive OR) operation
|}

== Ternary Kleene logic operations ==

These operators take balanced ternary (64-bit/40-trit) integer operands. Note that these operators do not short-circuit Kleene logic with KAND/KOR. The result is also a balanced ternary (64-bit/40-trit) integer.
{|
! class="pfrow" | KNOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | NOT operation
|-
! class="pfrow" | KAND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | AND operation
|-
! class="pfrow" | KOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | OR operation
|}

== Rotation and Shift Operations ==

Shift and rotation operations have as maximum value the number of bits of the underlying processor register (32 bits in a ix86-family processor). Safe operation for values above that limit is not guaranteed.

{|
! class="pfrow" | ROTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rl>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the left
|-
! class="pfrow" | ROTR
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rr>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the right
|-
! class="pfrow" | SHTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<<bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the left
|-
! class="pfrow" | SHTRU
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (unsigned)
|-
! class="pfrow" | SHTRS
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (signed)
|}

== Function Definition ==

The following sections cover defining and calling functions.

=== Starting a function ===

Each function must allocate space for its local variables. This is done immediately after being called and before any other processing. The relevant operations are ENTER (to specify a given memory amount) and START (no space is reserved for local variables. Note that these operations do more than manipulate the stack: they also create an activation register for the function, i.e., they update the frame pointer and define a new stack frame.

{|
! class="pfrow" | ENTER bytes
! class="pfrow" | $
! class="pfrow" | $ fp #bytes
! class="pfdesc" | Starts a function: pushes the frame pointer (activation register) to the stack and allocates space for local variables ('''bytes''')
|-
! class="pfrow" | START
! class="pfrow" | $
! class="pfrow" | $ fp
! class="pfdesc" | Equivalent to "ENTER 0"
|}

=== Leaving a function ===

STFVAL32I/STFVAL32F or STFVAL64I/STFVAL64F must be called to specify return values in accordance with C conventions. Only return values that fit in the indicated registers need these operations. Other return values are passed by pointer.

{|
! class="pfrow" | STFVAL32I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 32-bit integer value from the stack (to eax)
|-
! class="pfrow" | STFVAL64I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 64-bit integer value from the stack (to eax:edx)
|-
! class="pfrow" | STFVAL32F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a single-precision (32-bit) floating point value from the stack (to st0)
|-
! class="pfrow" | STFVAL64F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a double-precision (64-bit) floating point value from the stack (to st0)
|}

Note that balanced-ternary numbers are represented by 64-bit binary numbers. Takums cannot be directly returned (they must be returned via pointer).

The stack frame is destroyed by the LEAVE operation. This action must be performed immediately before returning control to the caller (with RET).

{|
! class="pfrow" | LEAVE
! class="pfrow" | $ fp ...
! class="pfrow" | $
! class="pfdesc" | Ends a function: restores the frame pointer (activation register) and destroys the function-local stack data
|}

After the function's stack frame is destroyed and the activation register is restored to the caller, control must also be returned to the caller (i.e., IP must be updated).

{|
! class="pfrow" | RET
! class="pfrow" | $ addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function (the stack must contain the return address)
|-
! class="pfrow" | RETN bytes
! class="pfrow" | $ #bytes addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function and removes '''bytes''' from the caller's stack after removing the return address. This is more or less the same as "RET+TRASH bytes". '''Note that this is not compatible with the Cdecl calling conventions.'''
|}

== Function Calls ==

In a stack machine the arguments for a function call are already in the stack. Thus, it is not necessary to put them there (it is enough not to remove them).

{|
! class="pfrow" | CALL name
! class="pfrow" | $
! class="pfrow" | $ return-address
! class="pfdesc" | Calls the '''name'''d function. The '''return-address''' is pushed to the stack.
|-
! class="pfrow" | BRANCH
! class="pfrow" | $ address
! class="pfrow" | $ return-address
! class="pfdesc" | Invokes a function at the '''address''' indicated at the top of the stack. The '''return-address''' is pushed to the stack.
|}

When building functions that conform to the C calling convention, the arguments are destroyed by the caller, ''after'' the return of the callee, using TRASH and stating the total size (i.e., for all arguments).

{|
! class="pfrow" | TRASH bytes
! class="pfrow" | $ #bytes
! class="pfrow" | $
! class="pfdesc" | Removes '''bytes''' from the stack
|}

To recover the returned value by the callee, and put it in the stack, the caller must call LDFVAL32I (32-bit integer value in eax) or LDFVAL32F (32-bit single-precision floating point value in st0). An analogous procedure is valid for LDFVAL64I (64-bit integer value in eax:edx) and LDFVAL64F (64-bit double-precision floating point value in st0).

{|
! class="pfrow" | LDFVAL32I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax register to the stack
|-
! class="pfrow" | LDFVAL64I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax:edx registers to the stack
|-
! class="pfrow" | LDFVAL32F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (32 bits, single precision)
|-
! class="pfrow" | LDFVAL64F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (64 bits, double precision)
|}

== Basic Jump Operations ==

{|
! class="pfrow" | JMP label
! class="pfrow" | $
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to '''label''' (does not affect or use the stack)
|-
! class="pfrow" | LEAP
! class="pfrow" | $ address
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to the '''address''' at the top of the stack
|}

== Conditional Jump Operations ==

{|
! class="pfrow" | JZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is 0 (zero)
|-
! class="pfrow" | JNZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is non-zero
|}

The following operations combine comparisons and jumps.

{|
! class="pfrow" | JEQ label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a&equiv;b
|-
! class="pfrow" | JNE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≠b
|}

{|
! class="pfrow" | JGT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a>b
|-
! class="pfrow" | JGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b
|-
! class="pfrow" | JLE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b
|-
! class="pfrow" | JLT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if ab (unsigned)
|-
! class="pfrow" | JUGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b (unsigned)
|-
! class="pfrow" | JULE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b (unsigned)
|-
! class="pfrow" | JULT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a<b (unsigned)
|}

== Other Operations ==

{|
! class="pfrow" | NIL
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | No action is performed
|-
! class="pfrow" | NOP
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a null operation (consumes time; does not change the processor's state)
|}

[[category:Compiladores]]
[[category:Ensino]]

Postfix Reference Guide

2026-05-18T13:55:55Z

Root: /* Values (declaration in segments) */

{{TOCright}}

The Postfix reference guide contains information about the structure and operations of the stack machine.

The original stack machine was created by Santos (2004). Is was composed by a set of macros to be used with printf functions. Each macro would “take” as arguments, either a number or a string. This was a simple and effective approach but was limited in its expressiveness.

The current postﬁx code generator class maintains the stack machine abstraction, but does not rely on macros. Instead, it deﬁnes an interface to be used by semantic analysers, as deﬁned by a strategy pattern (Gamma et al., 1995). Speciﬁc implementations provide the realization of the postﬁx commands for a particular target machine. Since it is written in C++, it's very easy to extend to new needs and implementations (new target machines).

Like the original postfix code generator, the current abstraction uses an architecture based on a stack machine, hence the name "postfix", and three registers.
# IP -- the instruction pointer -- indicates the position of the next instruction to be executed;
# SP -- the stack pointer -- indicates the position of the element currently at the stack top;
# FP -- the frame pointer -- indicates the position of the activation register of the function currently being executed.

In the following tables, the "stack" columns present the results of the actions on the values at the top of the stack. Note that only elements relevant in a given context, i.e., that of the postfix instruction being executed, are shown. The notation '''#length''' represents a set of ''length'' consecutive bytes in the stack, i.e., a vector.

{|
! class="pfrow" | OPERATION
! class="pfrow" | stack before
! class="pfrow" | stack after
! class="pfdesc" | Description of actions
|}

Consider the following fictitious example:

{|
! class="pfrow" | FAKE
! class="pfrow" | $ a #8 b
! class="pfrow" | $ a b
! class="pfdesc" | This is a fake operation
|}

In this example, before the FAKE operation, the stack had at its top '''b''', followed by eight bytes, followed by '''a'''. After executing the FAKE operation (which used those elements in some way), the stack has at its top '''b''', followed by '''a'''. The symbol '''$''' is used to denote the point in the stack not affected by the current operation (this could be the top if the stack were empty).

The following groups of operations are available in the Postfix interface:

== Segments, Values, and Labels ==

=== Segment selection ===

These operations select various segments. They do not affect the stack.

{|
! class="pfrow" | BSS
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for uninitialized values
|-
! class="pfrow" | DATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized values
|-
! class="pfrow" | RODATA
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the data segment for initialized constant values
|-
! class="pfrow" | TEXT
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment (default)
|-
! class="pfrow" | TEXT name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''name''
|-
! class="pfrow" | TEXT number
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Specifies/selects the text (code) segment with name ''number''
|}

=== Values (declaration in segments) ===

These operations declare values directly in various segments. They do not affect the stack.

{|
! class="pfrow" | SALLOC size
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares an uninitialized vector with length '''size''' (in bytes)
|-
! class="pfrow" | SSHORT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 16-bit integer '''value'''
|-
! class="pfrow" | SBYTE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 8-bit character '''value'''
|-
! class="pfrow" | SINT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static 32-bit integer '''value'''
|-
! class="pfrow" | SBALANCED3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static balanced ternary integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | SFLOAT value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static simple precision (32-bit) floating point '''value'''
|-
! class="pfrow" | SDOUBLE value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static double precision (64-bit) floating point '''value'''
|-
! class="pfrow" | SPOSIT3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary posit real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | STAKUM3 value
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static ternary takum real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SADDR name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a name for an address (i.e., declares the address associated with '''name''')
|-
! class="pfrow" | SSTRING string
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a static NULL-terminated character '''string''' (C-like) (may contain special characters)
|}

=== Labels ===

These operations handle symbols and their definitions within some segment. They do not affect the stack.

{|
! class="pfrow" | ALIGN
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Forces the alignment of code or data
|-
! class="pfrow" | LABEL name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a new label '''name'''
|-
! class="pfrow" | EXTERN name
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares '''name''' as a symbol externally defined, i.e., defined in another compilation module
|-
! class="pfrow" | GLOBAL name, type
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Declares a '''name''' with a given '''type''' (see below) -- the declaration of a name must preceed its definition
|}


In a declaration common to several modules, any number of modules may contain common or external declarations, but only one of them may contain an initialized declaration. A declaration does not need to be specified in a specific segment.

Global names may be of different types. These labels are to be used to generate the types needed for the second argument of '''GLOBAL'''.
* NONE - Unknown type
* FUNC - Name/label corresponds to a function
* OBJ - Name/label corresponds to an object (data)

== Addressing, Loading and Storing ==

Absolute addressing uses addresses based on named labels. Local addressing is used in function frames and uses offsets relative to the frame pointer to load data: negative addresses correspond to local variables, offset zero contains the previous (saved) value of the frame pointer, offset 4 (32 bits) contains the previous (saved) value of the instruction pointer, and, after offset 8, reside the function arguments.

=== Adressing operations ===

{|
! class="pfrow" | ADDR name
! class="pfrow" | $
! class="pfrow" | $ name
! class="pfdesc" | Absolute addressing: load address of '''name'''
|-
! class="pfrow" | ADDRA name
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Absolute addressing: store '''value''' to '''name'''
|-
! class="pfrow" | ADDRV name
! class="pfrow" | $
! class="pfrow" | $ [name]
! class="pfdesc" | Absolute addressing: load value at '''name'''
|-
! class="pfrow" | LOCAL offset
! class="pfrow" | $
! class="pfrow" | $ fp+offset
! class="pfdesc" | Local addressing: load address of '''offset'''
|-
! class="pfrow" | LOCA offset
! class="pfrow" | $ a
! class="pfrow" | $
! class="pfdesc" | Local addressing: writes '''a''' to '''offset'''
|-
! class="pfrow" | LOCV offset
! class="pfrow" | $
! class="pfrow" | $ [fp+offset]
! class="pfdesc" | Local addressing: load value at '''offset'''
|}

ADDRA, ADDRV, LOCA, LOCV are functionally equivalent to ADDR+STINT, ADDR+LDINT, LOCAL+STINT, LOCAL+LDINT, but the generated code is more efficient. They are compound operations (i.e., they contain not only the addressing part, but also the load/store part as well). Note that the postfix_writer visitor is, in general, incapable of generating these instructions.

=== Load operations ===

The load instructions assume that the top of the stack contains an address pointing to the data to be read. Each load instruction will replace the address at the top of the stack with the contents of the position it points to. Load operations differ only in what they load.

{|
! class="pfrow" | LDBYTE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 1 byte (char)
|-
! class="pfrow" | LDSHORT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 2 bytes (short)
|-
! class="pfrow" | LDINT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (int)
|-
! class="pfrow" | LDBALANCED3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | LDFLOAT
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 4 bytes (float)
|-
! class="pfrow" | LDDOUBLE
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 8 bytes (double)
|-
! class="pfrow" | LDTAKUM3
! class="pfrow" | $ addr
! class="pfrow" | $ [addr]
! class="pfdesc" | Loads 16 bytes (80-trit ternary real)
|}

=== Store operations ===

Store instructions assume the stack contains at the top the address where data is to be stored. That data is in the stack, immediately after the address. Store instructions differ only in what they store.

{|
! class="pfrow" | STBYTE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 1 byte (char)
|-
! class="pfrow" | STSHORT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 2 bytes (short)
|-
! class="pfrow" | STINT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (int)
|-
! class="pfrow" | STBALANCED3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (40-trit balanced ternary integer)
|-
! class="pfrow" | STFLOAT
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 4 bytes (float)
|-
! class="pfrow" | STDOUBLE
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 8 bytes (double)
|-
! class="pfrow" | STTAKUM3
! class="pfrow" | $ val addr
! class="pfrow" | $
! class="pfdesc" | Stores 16 bytes (80-trit ternary real)
|}

== Simple Stack Operations ==

{|
! class="pfrow" | DUP32
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 32-bit value at the top of the stack
|-
! class="pfrow" | DUP64
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 64-bit value at the top of the stack
|-
! class="pfrow" | DUP128
! class="pfrow" | $ a
! class="pfrow" | $ a a
! class="pfdesc" | Duplicates the 128-bit value at the top of the stack
|-
! class="pfrow" | INT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an integer '''value'''
|-
! class="pfrow" | BALANCED3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary balanced integer '''value''' (64 bits, 40 trits)
|-
! class="pfrow" | FLOAT value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a 4-byte float '''value''' (32 bits, single precision)
|-
! class="pfrow" | DOUBLE value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes an 8-byte float '''value''' (64 bits, double precision)
|-
! class="pfrow" | TAKUM3 value
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes a ternary real '''value''' (128 bits, 80 trits)
|-
! class="pfrow" | SP
! class="pfrow" | $
! class="pfrow" | $ sp
! class="pfdesc" | Pushes the value of the stack pointer
|-
! class="pfrow" | SWAP32
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 32-bit values at the top of the stack
|-
! class="pfrow" | SWAP64
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 64-bit values at the top of the stack
|-
! class="pfrow" | SWAP128
! class="pfrow" | $ a b
! class="pfrow" | $ b a
! class="pfdesc" | Swaps the two 128-bit values at the top of the stack
|-
! class="pfrow" | ALLOC
! class="pfrow" | $ bytes
! class="pfrow" | $ #bytes
! class="pfdesc" | Allocates in the stack an array with size '''bytes'''. Since this operation alters the meaning of offsets in the stack, care should be taken when local variables exist.
|}

== Arithmetic Operations ==

The arithmetic operations considered here apply to both signed and unsigned integer arguments, and to double precision floating point arguments.

=== Binary integer (32-bit) operations ===

{|
! class="pfrow" | NEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | ADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | SUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | MUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | DIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | MOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|-
! class="pfrow" | UDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two natural (unsigned) integer values
|-
! class="pfrow" | UMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two natural (unsigned) integer values.
|}

=== Ternary integer (64-bit/40-trit) operations ===

{|
! class="pfrow" | BNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric) of integer value
|-
! class="pfrow" | BADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Integer sum of two integer values
|-
! class="pfrow" | BSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Integer subtraction of two integer values
|-
! class="pfrow" | BMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Integer multiplication of two integer values
|-
! class="pfrow" | BDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Integer division of two integer values
|-
! class="pfrow" | BMOD
! class="pfrow" | $ a b
! class="pfrow" | $ a%b
! class="pfdesc" | Remainder of the integer division of two integer values
|}

=== Floating point (64-bit) operations ===

These operations take double precision floating point operands.

{|
! class="pfrow" | DNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | DADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | DSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | DMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | DDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary posit (128-bit/80-trit) operations ===

These operations take ternary posit operands.

{|
! class="pfrow" | PNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | PADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | PSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | PMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | PDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

=== Ternary takum (128-bit/80-trit) operations ===

These operations take ternary takum operands.

{|
! class="pfrow" | TNEG
! class="pfrow" | $ a
! class="pfrow" | $ -a
! class="pfdesc" | Negation (symmetric)
|-
! class="pfrow" | TADD
! class="pfrow" | $ a b
! class="pfrow" | $ a+b
! class="pfdesc" | Sum
|-
! class="pfrow" | TSUB
! class="pfrow" | $ a b
! class="pfrow" | $ a-b
! class="pfdesc" | Subtraction
|-
! class="pfrow" | TMUL
! class="pfrow" | $ a b
! class="pfrow" | $ a*b
! class="pfdesc" | Multiplication
|-
! class="pfrow" | TDIV
! class="pfrow" | $ a b
! class="pfrow" | $ a/b
! class="pfdesc" | Division
|}

== Increment and Decrement Operations ==

{|
! class="pfrow" | INCR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Adds '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]+delta''
|-
! class="pfrow" | DECR delta
! class="pfrow" | $ address
! class="pfrow" | $ address
! class="pfdesc" | Subtracts '''delta''' to the binary integer value at the '''address''' at the top of the stack, i.e. ''[address]'' becomes ''[address]-delta''
|}

== Type Conversion Operations ==

The following instructions perform type conversions. The conversions are from and to integers (both binary and ternary) and real values (simple and double precision floating point, posit, and takum).

{|
! class="pfrow" | SRC2DST
! class="pfrow" | $ src
! class="pfrow" | $ dst
! class="pfdesc" | Converts from source format ('''src''') to destination format ('''dst''')
|}

'''SRC''' and '''DST''' in the instuction above are as follows (not all combinations are available -- see the following table):
* '''B''': Balanced ternary integer (64-bit/40-trit)
* '''D''': Double precision floating point (64-bit)
* '''F''': Single precision / simple precision floating point (32-bit)
* '''I''': Binary integer (32-bit)
* '''P''': Ternary posit (128-bit/80-trit)
* '''T''': Ternary takum (128-bit/80-trit)

{| class="wikitable" style="text-align:center;"
|+ Instruction Opcodes (From Row \ To Column)
! !! B !! D !! F !! I !! P !! T
|-
! B
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| B2I
| B2P
| B2T
|-
! D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| D2F
| D2I
| D2P
| D2T
|-
! F
| style="background:#ececec; color:gray;" | -
| F2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! I
| I2B
| I2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
|-
! P
| P2B
| P2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| P2T
|-
! T
| T2B
| T2D
| style="background:#ececec; color:gray;" | -
| style="background:#ececec; color:gray;" | -
| T2P
| style="background:#ececec; color:gray;" | -
|}

== Comparison Operations ==

=== Binary integer comparison instructions ===

The comparison instructions are binary operations (each operand is a 32-bit binary integer) that leave at the top of the stack 0 (zero) or 1 (one), depending on the result of the comparison: respectively, '''false''' or '''true''' (32-bit binary integer). The value may be directly used to perform conditional jumps (e.g., JZ, JNZ), that use the value of the top of the stack instead of relying on special processor registers ("flags").

{|
! class="pfrow" | EQ
! class="pfrow" | $ a b
! class="pfrow" | $ a&equiv;b
! class="pfdesc" | ''equal to''
|-
! class="pfrow" | NE
! class="pfrow" | $ a b
! class="pfrow" | $ a≠b
! class="pfdesc" | ''not equal to''
|}

{|
! class="pfrow" | GT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than''
|-
! class="pfrow" | GE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to''
|-
! class="pfrow" | LE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to''
|-
! class="pfrow" | LT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than''
|}

The following consider unsigned 32-bit binary integer operands (the result is also a 32-bit binary integer):

{|
! class="pfrow" | UGT
! class="pfrow" | $ a b
! class="pfrow" | $ a>b
! class="pfdesc" | ''greater than'' for unsigned integers
|-
! class="pfrow" | UGE
! class="pfrow" | $ a b
! class="pfrow" | $ a≥b
! class="pfdesc" | ''greater than or equal to'' for unsigned integers
|-
! class="pfrow" | ULE
! class="pfrow" | $ a b
! class="pfrow" | $ a≤b
! class="pfdesc" | ''less than or equal to'' for unsigned integers
|-
! class="pfrow" | ULT
! class="pfrow" | $ a b
! class="pfrow" | $ a<b
! class="pfdesc" | ''less than'' for unsigned integers
|}

=== Comparison operators for real numbers ===

The DCMP operator compares two double precision binary floating point numbers (64 bits). The result is a 32-bit binary integer value: less than 0, if the first operand is lower than the second; 0, if they are equal; greater than 0, otherwise. 

{|
! class="pfrow" | DCMP
! class="pfrow" | $ a b
! class="pfrow" | $ i
! class="pfdesc" | "compare" -- i<0, a<b; i&equiv;0, a&equiv;b; i>0, a>b

|}

== Bitwise Operations ==

These operators take and 32-bit binary integer operands. The result is also a 32-bit binary integer.
{|
! class="pfrow" | NOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | Bitwise negation, i.e., one's complement
|-
! class="pfrow" | AND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | Bitwise AND operation
|-
! class="pfrow" | OR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | Bitwise OR operation
|-
! class="pfrow" | XOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&oplus;b
! class="pfdesc" | Bitwise XOR (exclusive OR) operation
|}

== Ternary Kleene logic operations ==

These operators take balanced ternary (64-bit/40-trit) integer operands. Note that these operators do not short-circuit Kleene logic with KAND/KOR. The result is also a balanced ternary (64-bit/40-trit) integer.
{|
! class="pfrow" | KNOT
! class="pfrow" | $ a
! class="pfrow" | $ ~a
! class="pfdesc" | NOT operation
|-
! class="pfrow" | KAND
! class="pfrow" | $ a b
! class="pfrow" | $ a&and;b
! class="pfdesc" | AND operation
|-
! class="pfrow" | KOR
! class="pfrow" | $ a b
! class="pfrow" | $ a&or;b
! class="pfdesc" | OR operation
|}

== Rotation and Shift Operations ==

Shift and rotation operations have as maximum value the number of bits of the underlying processor register (32 bits in a ix86-family processor). Safe operation for values above that limit is not guaranteed.

{|
! class="pfrow" | ROTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rl>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the left
|-
! class="pfrow" | ROTR
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<rr>bits
! class="pfdesc" | Rotate '''value''' '''nbits''' to the right
|-
! class="pfrow" | SHTL
! class="pfrow" | $ value nbits
! class="pfrow" | $ value<<bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the left
|-
! class="pfrow" | SHTRU
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (unsigned)
|-
! class="pfrow" | SHTRS
! class="pfrow" | $ value nbits
! class="pfrow" | $ value>>>bits
! class="pfdesc" | Shift '''value''' '''nbits''' to the right (signed)
|}

== Function Definition ==

The following sections cover defining and calling functions.

=== Starting a function ===

Each function must allocate space for its local variables. This is done immediately after being called and before any other processing. The relevant operations are ENTER (to specify a given memory amount) and START (no space is reserved for local variables. Note that these operations do more than manipulate the stack: they also create an activation register for the function, i.e., they update the frame pointer and define a new stack frame.

{|
! class="pfrow" | ENTER bytes
! class="pfrow" | $
! class="pfrow" | $ fp #bytes
! class="pfdesc" | Starts a function: pushes the frame pointer (activation register) to the stack and allocates space for local variables ('''bytes''')
|-
! class="pfrow" | START
! class="pfrow" | $
! class="pfrow" | $ fp
! class="pfdesc" | Equivalent to "ENTER 0"
|}

=== Leaving a function ===

STFVAL32I/STFVAL32F or STFVAL64I/STFVAL64F must be called to specify return values in accordance with C conventions. Only return values that fit in the indicated registers need these operations. Other return values are passed by pointer.

{|
! class="pfrow" | STFVAL32I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 32-bit integer value from the stack (to eax)
|-
! class="pfrow" | STFVAL64I
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a 64-bit integer value from the stack (to eax:edx)
|-
! class="pfrow" | STFVAL32F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a single-precision (32-bit) floating point value from the stack (to st0)
|-
! class="pfrow" | STFVAL64F
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Removes a double-precision (64-bit) floating point value from the stack (to st0)
|}

Note that balanced-ternary numbers are represented by 64-bit binary numbers. Takums cannot be directly returned (they must be returned via pointer).

The stack frame is destroyed by the LEAVE operation. This action must be performed immediately before returning control to the caller (with RET).

{|
! class="pfrow" | LEAVE
! class="pfrow" | $ fp ...
! class="pfrow" | $
! class="pfdesc" | Ends a function: restores the frame pointer (activation register) and destroys the function-local stack data
|}

After the function's stack frame is destroyed and the activation register is restored to the caller, control must also be returned to the caller (i.e., IP must be updated).

{|
! class="pfrow" | RET
! class="pfrow" | $ addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function (the stack must contain the return address)
|-
! class="pfrow" | RETN bytes
! class="pfrow" | $ #bytes addr
! class="pfrow" | $
! class="pfdesc" | Returns from a function and removes '''bytes''' from the caller's stack after removing the return address. This is more or less the same as "RET+TRASH bytes". '''Note that this is not compatible with the Cdecl calling conventions.'''
|}

== Function Calls ==

In a stack machine the arguments for a function call are already in the stack. Thus, it is not necessary to put them there (it is enough not to remove them).

{|
! class="pfrow" | CALL name
! class="pfrow" | $
! class="pfrow" | $ return-address
! class="pfdesc" | Calls the '''name'''d function. The '''return-address''' is pushed to the stack.
|-
! class="pfrow" | BRANCH
! class="pfrow" | $ address
! class="pfrow" | $ return-address
! class="pfdesc" | Invokes a function at the '''address''' indicated at the top of the stack. The '''return-address''' is pushed to the stack.
|}

When building functions that conform to the C calling convention, the arguments are destroyed by the caller, ''after'' the return of the callee, using TRASH and stating the total size (i.e., for all arguments).

{|
! class="pfrow" | TRASH bytes
! class="pfrow" | $ #bytes
! class="pfrow" | $
! class="pfdesc" | Removes '''bytes''' from the stack
|}

To recover the returned value by the callee, and put it in the stack, the caller must call LDFVAL32I (32-bit integer value in eax) or LDFVAL32F (32-bit single-precision floating point value in st0). An analogous procedure is valid for LDFVAL64I (64-bit integer value in eax:edx) and LDFVAL64F (64-bit double-precision floating point value in st0).

{|
! class="pfrow" | LDFVAL32I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax register to the stack
|-
! class="pfrow" | LDFVAL64I
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the eax:edx registers to the stack
|-
! class="pfrow" | LDFVAL32F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (32 bits, single precision)
|-
! class="pfrow" | LDFVAL64F
! class="pfrow" | $
! class="pfrow" | $ value
! class="pfdesc" | Pushes the return '''value''' in the st0 register to the stack (64 bits, double precision)
|}

== Basic Jump Operations ==

{|
! class="pfrow" | JMP label
! class="pfrow" | $
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to '''label''' (does not affect or use the stack)
|-
! class="pfrow" | LEAP
! class="pfrow" | $ address
! class="pfrow" | $
! class="pfdesc" | Unconditional jump to the '''address''' at the top of the stack
|}

== Conditional Jump Operations ==

{|
! class="pfrow" | JZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is 0 (zero)
|-
! class="pfrow" | JNZ label
! class="pfrow" | $ value
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if the '''value''' at the top of the stack is non-zero
|}

The following operations combine comparisons and jumps.

{|
! class="pfrow" | JEQ label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a&equiv;b
|-
! class="pfrow" | JNE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≠b
|}

{|
! class="pfrow" | JGT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a>b
|-
! class="pfrow" | JGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b
|-
! class="pfrow" | JLE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b
|-
! class="pfrow" | JLT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if ab (unsigned)
|-
! class="pfrow" | JUGE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≥b (unsigned)
|-
! class="pfrow" | JULE label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a≤b (unsigned)
|-
! class="pfrow" | JULT label
! class="pfrow" | $ a b
! class="pfrow" | $
! class="pfdesc" | Jump to '''label''' if a<b (unsigned)
|}

== Other Operations ==

{|
! class="pfrow" | NIL
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | No action is performed
|-
! class="pfrow" | NOP
! class="pfrow" |
! class="pfrow" |
! class="pfdesc" | Generates a null operation (consumes time; does not change the processor's state)
|}

[[category:Compiladores]]
[[category:Ensino]]

Template:PRJCOMandatory20252026

2026-05-16T17:49:34Z

Root:

{{CDKRTS|CDK21|libcdk21-202605161833.tar.bz2|RTS7|librts7-202605092235.tar.bz2}}

File:Libcdk21-202605161833.tar.bz2

2026-05-16T17:49:12Z

Root:

Compiladores/Projecto de Compiladores/Material de Apoio ao Desenvolvimento

2026-05-16T17:48:58Z

Root: /* Material de Apoio */

{{PRJHEADER}}
{{TOCright}}

== Material de Apoio ==

O projecto, escrito em C++, deve ser desenvolvido considerando os princípios de desenvolvimento de compiladores, assim como os da boa programação com objectos e os aspectos de arquitectura dos padrões de desenho aplicáveis. Notar que esta tarefa está implicitamente facilitada pelo material de apoio, que condiciona o desenvolvimento do compilador.

O código presente nas bibliotecas de apoio (já instalado na máquina virtual) ao desenvolvimento do projecto é de uso obrigatório:

* CDK [[media:libcdk21-202605161833.tar.bz2]] - código de base para o desenvolvimento do compilador
* RTS [[media:librts7-202605092235.tar.bz2]] - código de base para os programas gerados pelo compilador (runtime)

{{CVSCode|Notar que o [[Compiladores/Projecto de Compiladores/Repositório GIT|repositório GIT]] já contém uma versão do projecto a desenvolver. Isto significa que ''antes'' de se começar a programar, o projecto deve ser obtido a partir do repositório.}}

== Pacotes binários para instalação ==

O manterial de apoio está disponível para instalação directa (não é necessário compilar) através do repositório:
* https://download.opensuse.org/repositories/home:/d4vid:/co26/openSUSE_Tumbleweed/

Este repositório pode ser adicionado a um openSUSE previamente instalado através do comando:

<nowiki>zypper ar https://download.opensuse.org/repositories/home:/d4vid:/co26/openSUSE_Tumbleweed/ CO26</nowiki>
<nowiki>zypper refresh</nowiki>

Uma vez adicionado o repositório, os pacotes acima podem ser instalados através dos comandos:

zypper install libcdk21-devel librts7-devel

{{Suggestion|Este material já está instalado na [[Compiladores/Projecto de Compiladores/Máquina Virtual|máquina virtual da disciplina]].}}

[[category:Projecto de Compiladores|P]]
[[category:Compiladores|P]]
[[category:Ensino|P]]

Compiladores/Projecto de Compiladores/Projecto 2025-2026/Manual de Referência da Linguagem P6

2026-05-16T17:02:56Z

Root: /* Exemplos e Testes */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}


'''ÉPOCA NORMAL'''

'''P6''' é uma linguagem imperativa. Este manual apresenta de forma intuitiva as características da linguagem: [[#Tipos de Dados|tipos de dados]]; [[#Manipulação de Nomes|manipulação de nomes]]; [[#Convenções Lexicais|convenções lexicais]]; [[#Gramática|estrutura/sintaxe]]; [[#Funções|especificação das funções]]; [[#Instruções|semântica das instruções]]; [[#Expressões|semântica das expressões]]; e, finalmente, [[#Exemplos|alguns exemplos]].

= Tipos de Dados =

A linguagem é fracamente tipificada (são efectuadas algumas conversões implícitas). Existem 4 tipos de dados básicos, apenas alguns dos quais são compatíveis com a [https://en.wikipedia.org/wiki/C_(programming_language) linguagem C]. O alinhamento em memória binária é sempre a 32 bits. Note-se que alguns dos tipos de dados são ternários e devem ser manipulados com as funções das ALUs disponibilizadas.

* Tipos numéricos: os inteiros são [https://en.wikipedia.org/wiki/Balanced_ternary ternários equilibrados], ocupam 40 trits (empacotados em 64 bits); os reais são ternários e estão representados no formato [https://arxiv.org/abs/2404.18603 Takum] (note-se que a definição neste artigo é para uma representação binária e não é exactamente a que é implementada pelas ALUs ternárias em uso no projecto), ocupam 80 trits (empacotados em 128 bits).
* As cadeias de caracteres são vectores de caracteres binários terminados por [https://en.wikipedia.org/wiki/ASCII ASCII] NUL (carácter com o valor zero). Variáveis e literais deste tipo só podem ser utilizados em atribuições, impressões, ou como argumentos/retornos de funções. Os caracteres são valores de 8 bits não directamente manipuláveis.
* Os ponteiros representam endereços de objectos (de qualquer tipo) e ocupam 32 bits. Podem ser objecto de operações aritméticas (deslocamentos) e permitem aceder ao valor apontado. Note-se que não é possível usar inteiros ternários directamente em aritmética de ponteiros (têm de ser convertidos para isso).

Os tipos suportados por cada operador e a operação a realizar são indicados na [[#Expressões|definição das expressões]].

Existem ainda tipos associado a valores funcionais, i.e., tipos que descrevem a interface de funções (ver abaixo). Os valores em memória associados a estes tipos são efectivamente ponteiros, mas para funções e não para dados, podendo ser usados para invocar as funções correspondentes. Estes identificadores não podem ser usados como variáveis (e.g., passados como argumentos de outras funções, etc.).

= Manipulação de Nomes =

Os nomes (identificadores) correspondem a variáveis e funções. Nos pontos que se seguem, usa-se o termo entidade para as designar indiscriminadamente, explicitando-se quando a descrição for válida apenas para um dos casos. Existem ainda nomes para funções externas à linguagem P6. Tanto em P6, como em C, os nomes das funções referem directamente a posição do código dessas funções (à la C; ver '''extern''' abaixo).

== Espaço de nomes e visibilidade dos identificadores ==

O espaço de nomes global é único, pelo que um nome utilizado para designar uma entidade num dado contexto não pode ser utilizado para designar outras (ainda que de natureza diferente).

Os identificadores são visíveis desde a declaração até ao fim do alcance: ficheiro (globais) ou bloco (locais). A reutilização de identificadores em contextos inferiores encobre declarações em contextos superiores: redeclarações locais podem encobrir as globais até ao fim de um bloco. É possível utilizar símbolos globais nos contextos dos blocos das funções, mas não é possível declará-los (ver [[#Símbolos globais|símbolos globais]]).

== Validade das variáveis ==

As entidades globais (declaradas fora de qualquer função), existem durante toda a execução do programa. As variáveis locais a uma função existem apenas durante a sua execução. Os argumentos formais são válidos enquanto a função está activa.

= Convenções Lexicais =

Para cada grupo de elementos lexicais (tokens), considera-se a maior sequência de caracteres constituindo um elemento válido. Assim, por exemplo, a designação '''>=''' é sempre um único elemento lexical (por oposição à situação ilegal de se terem dois símbolos: '''>''' seguido de '''=''').

== Caracteres brancos ==

São considerados separadores e não representam nenhum elemento lexical: '''mudança de linha''' ASCII LF ('''0x0A''', '''\n'''), '''recuo do carreto''' ASCII CR ('''0x0D''', '''\r'''), '''espaço''' ASCII SP ('''0x20''', ⌴) e '''tabulação horizontal''' ASCII HT ('''0x09''', '''\t''').

== Comentários ==

Existem dois tipos de comentários, que também funcionam como elementos separadores:

* '''explicativos''' -- começam com '''//''' e acabam no fim da linha; e
* '''operacionais''' -- começam com '''/*''' e terminam com '''*/''', podendo estar aninhados.

Se as sequências de início fizerem parte de uma cadeia de caracteres, não iniciam um comentário (ver [[#Cadeias de caracteres|definição das cadeias de caracteres]]).

== Palavras-chave ==

As seguintes palavras-chave são reservadas, não constituindo identificadores (devem ser escritas exactamente como indicado):

* tipos: '''int real string void'''
* declarações: '''extern forward public auto'''
* instruções: '''if elif else while stop next return'''
* expressões: '''input null sizeof'''
* outras: '''begin end'''

== Tipos ==

Os seguintes elementos lexicais designam tipos em declarações (ver gramática): '''int''' (inteiro), '''real''' (real), '''string''' (cadeia de caracteres).

Os tipos correspondentes a ponteiros são outros tipos delimitados por '''[''' e ''']''', designando uma indirecção e não o objecto directo (ver gramática).

Note-se que, quando se tem uma declaração '''extern''', os tipos correspondem aos compatíveis com a linguagem C na mesma arquitectura ix86 de 32 bits, i.e., '''int''' corresponde a um número binário inteiro em [https://en.wikipedia.org/wiki/Two%27s_complement complemento para 2] (32 bits), '''real''' coresponde a uma representação segundo a norma [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] de dupla precisão (64 bits), devendo ser convertidos de e para os tipos nativos da linguage P6 sempre que necessário (ver RTS).

== Operadores de expressões ==

São considerados operadores os elementos lexicais apresentados na definição das expressões.

== Delimitadores e terminadores ==

Os seguintes elementos lexicais são delimitadores/terminadores:
* ''',''' (vírgula)
* ''';''' (ponto e vírgula)
* '''!''' e '''!!''' (operações de impressão)
* '''(''' e ''')''' (delimitadores de expressões)
* '''{''' e '''}''' (delimitadores de blocos)

== Identificadores (nomes) ==

São iniciados por uma letra, seguindo-se 0 (zero) ou mais letras ou dígitos. O comprimento do nome é ilimitado e dois nomes são distintos se houver alteração de maiúscula para minúscula, ou vice-versa, de pelo menos um carácter.

== Literais ==

São notações para valores constantes de alguns tipos da linguagem (não confundir com constantes, i.e., identificadores que, em algumas linguagens, designam elementos cujo valor não pode ser alterado durante a execução do programa).

=== Inteiros ===

Um literal inteiro é um número não negativo (mas ver a seguir). Números negativos podem ser construídos pela aplicação do operador de negação unária ('''-''') a um literal (sempre positivo).

Literais inteiros decimais são constituídos por sequências de 1 (um) ou mais dígitos de '''0''' a '''9''', em que o primeiro digito não é 0 (zero), excepto no caso do número 0 (zero). Neste caso, é composto apenas pelo dígito 0 (zero) (em qualquer base).

Literais inteiros em base 9 começam sempre pelo dígito 0 (zero), sendo seguidos de um ou mais dígitos de '''0''' a '''8''' (note-se que '''09''' é um literal inválido em base 9). Exemplo: '''086 = 78'''.

Literais inteiros em base 3 (equilibrada) começam sempre com a sequência '''0t''', seguida de um ou mais símbolos dessa base: '''-''' (valor '''-1'''), '''0''' (valor '''0''') e '''+''' (valor '''1'''). Estes literais podem ser intrinsecamente negativos. Exemplos: '''0t+0-0 = 24'''; '''0t-0+0 = -24'''

Se não for possível representar um literal na máquina, devido a overflow, deverá ser gerado um erro lexical.

=== Reais em formato Takum3 ===

Os literais reais (sempre positivos) são expressos tal como em C (exclusivamente em base 10).

Não existem literais negativos (números negativos resultam da operação unária '''-''').

Note-se que um literal sem '''.''' (ponto decimal) nem parte exponencial é do tipo inteiro.

Note-se que, apesar de C normalmente usar uma representação interna em binário no formato IEEE 754, a linguagem P6 usa um formato, representado em ternário, completamente diferente (embora a forma de escrita dos literais seja a mesma).

Exemplos: '''3.14''', '''1E3''' = 1000 (número inteiro representado como real). '''12.34e-24''' = 12.34 x 10-24 (notação cientifica).


=== Cadeias de caracteres ===

As cadeias de caracteres são delimitadas por aspas ('''"''') e podem conter quaisquer caracteres, excepto ASCII NUL (0x00) e ASCII LF (0x0A). Nas cadeias, os delimitadores de comentários não têm significado especial. Se for escrito um literal que contenha '''\0''', então a cadeia termina nessa posição. Exemplo: '''ab\0xy''' tem o mesmo significado que '''ab'''.

É possível designar caracteres por sequências especiais (iniciadas por '''\'''), especialmente úteis quando não existe representação gráfica directa. As sequências especiais correspondem aos caracteres ASCII HT, LF e CR ('''\t''', '''\n''' e '''\r''', respectivamente), aspa ('''\"'''). ''backslash'' ('''\\'''), ou a quaisquer outros especificados através de 1 a 3 dígitos em base 8, designando valores de 8 bits (e.g., '''\012''' ou apenas '''\12''' se o carácter seguinte não representar um dígito em base 8). Exemplo: '''xy\012z''' tem o mesmo significado que '''xy\12z''' e que '''xy\nz'''.

Elementos lexicais distintos que representem duas ou mais cadeias consecutivas são representadas na linguagem como uma única cadeia que resulta da concatenação. Exemplo: '''"ab"''' '''"cd"''' é o mesmo que '''"abcd"'''.

=== Ponteiros ===

O único literal admissível para ponteiros corresponde ao ponteiro nulo e é indicado pela palavra-chave '''null'''. Este literal é compatível com todos os tipos de ponteiro. Os inteiros não são convertíveis em ponteiros, pelo que o valor '''0''' (zero) não é um valor inicial admissível para ponteiros.

Note-se que a aritmética de ponteiros é possível apenas com inteiros binários, mas não com inteiros ternários (estes devem ser convertidos para binário, caso seja necessário).

= Gramática =

A gramática da linguagem está resumida abaixo. Considerou-se que os elementos em tipo fixo são literais, que os parênteses curvos agrupam elementos, que elementos alternativos são separados por uma barra vertical, que elementos opcionais estão entre parênteses rectos, que os elementos que se repetem zero ou mais vezes estão entre <math>\langle</math> e <math>\rangle</math>. Alguns elementos usados na gramática também são elementos da linguagem descrita se representados em tipo fixo (e.g., parênteses).

{|
! style="width: 140px; font-weight: normal;" | ''ficheiro''
! style="width: 50px; font-weight: normal;" | <math>\rightarrow</math>
| <math>\langle</math> ''declaração'' <math>\rangle</math> [ ''programa-principal'' ]
|-
! style="width: 150px; font-weight: normal;" | ''declaração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''tipo'' ''identificador'' [ '''=''' ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] [ '''auto''' ] ''identificador'' '''=''' ''expressão'' ''';'''
|-
! style="width: 150px; font-weight: normal;" | ''programa-principal''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''begin''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''end'''
|-
! style="width: 50px; font-weight: normal;" | ''função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''variáveis'' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''variáveis''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''variável'' <math>\langle</math> ''',''' ''variável'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''tipo''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''int''' <math>|</math> '''real''' <math>|</math> '''string''' <math>|</math> '''void''' <math>|</math> '''[''' ''tipo'' ''']''' <math>|</math> ''tipo-de-função''
|-
! style="width: 50px; font-weight: normal;" | ''tipo-de-função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' '''>'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' ''tipos'' '''>'''
|-
! style="width: 50px; font-weight: normal;" | ''tipos''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' <math>\langle</math> ''',''' ''tipo'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''bloco''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''{''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''}'''
|-
! style="width: 50px; font-weight: normal;" | ''instrução''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' ''';''' <math>|</math> ''expressões'' '''!''' <math>|</math> ''expressões'' '''!!'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''stop''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''next''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''return''' [ ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''instrução-condicional'' <math>|</math> ''instrução-de-iteração'' <math>|</math> ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''instrução-condicional''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''if''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\langle</math> '''elif''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\rangle</math> [ '''else''' ''instrução'' ]
|-
! style="width: 50px; font-weight: normal;" | ''instrução-de-iteração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''while''' '''(''' ''expressão'' ''')''' ''instrução''
|-
! style="width: 50px; font-weight: normal;" | ''expressões''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' <math>\langle</math> ''',''' ''expressão'' <math>\rangle</math>
|}

== Tipos, identificadores, literais e definição de expressões ==

Algumas definições foram omitidas da gramática: tipos de dados. qualificadores e variável (ver [[#Declarações de variáveis|declarações de variáveis]]), identificador (ver [[#Identificadores (nomes)|identificadores]]), literal (ver [[#Literais|literais]]); expressão (ver [[#Expressões|expressões]]). 

Quanto a tipos de dados, '''int''' designa valores inteiros, '''real''' designa valores reais, '''string''' designa cadeias de caracteres. Os ponteiros são tipos compostos por um tipo entre parênteses rectos, e.g., '''[int]'''.

Os tipos funcionais são definidos a partir dos tipos de dados anteriormente descritos e do tipo especial '''void''' (ver a seguir). O tipo é indicado com o formato indicado na gramática, i.e., tipo de retorno seguido dos tipos dos argumentos (zero ou mais separados por vírgulas). Estes tipos servem para declarar símbolos de função sem as definir.


O tipo '''void''' apenas pode ser usado para indicar a ausência de retorno ou para declarar um ponteiro genérico. Neste caso, o aninhamento é irrelevante, i.e., '''[void]''' e '''<nowiki>[[[void]]]</nowiki>''' são equivalentes. Um ponteiro deste tipo é compatível com todos os outros tipos de ponteiros. A aritmética de ponteiros decrementa/incrementa em uma unidade o valor de um ponteiro do tipo '''[void]'''.

== Left-values ==

Os ''left-values'' são posições de memória que podem ser modificadas (excepto onde proibido pelo tipo de dados). Os elementos de uma expressão que podem ser utilizados como left-values encontram-se individualmente identificados na semântica das expressões.

== Ficheiros ==

Um ficheiro é designado por principal se contiver a função principal (onde se inicia o programa).

== Declaração de variáveis ==

Uma declaração de variável indica sempre um tipo de dados (implícito ou explícito) e um identificador.

Exemplos:

* Inteiro: '''int i'''
* Real: '''real r'''
* Cadeia de caracteres: '''string s'''
* Ponteiro para inteiro: '''[int] p1''' (semelhante a '''int*''' em C)
* Ponteiro para real: '''[real] p2''' (semelhante a '''double*''' em C)
* Ponteiro para cadeia de caracteres: '''[string] p3''' (semelhante a '''char**''' em C)
* Ponteiro para ponteiro para inteiro: '''<nowiki>[[int]]</nowiki> p4''' (semelhante a '''int**''' em C)

É possível usar o pseudo-tipo '''auto''' se a declaração tiver um valor inicial: neste caso, o tipo é o do valor inicial.

Exemplo:

* Variável inteira: '''auto i = 1'''
* Variável real: '''auto f = 2.0'''
* etc.

== Símbolos globais ==

Por omissão, os símbolos são privados a um módulo, não podendo ser importados por outros módulos.

A palavra-chave '''public''' permite declarar um identificador como público, tornando-o acessível a partir de outros módulos. Quando usado com a palavra-chave '''auto''', esta é opcional. Note-se que a declaração de uma variável tem de ter sempre, ou o qualificador, ou o tipo, podendo estar ambos presentes.

A palavra-chave '''forward''' permite declarar num módulo variáveis ou funções definidas noutros módulos. Neste caso, não pode ser especificado o valor inicial das variáveis, pelo que não é possível o uso de '''auto''' em conjunto com '''forward'''.

A palavra-chave '''extern''' deve ser usada para declarar símbolos de função com tipos diferentes dos dos nativos da da linguagem P6, e.g. para importar funções definidas em C. Além de poderem ser usados para chamar as funções que designam, os símbolos assim declarados podem ser utilizados com valores convertidos de forma apropriada.

Exemplos:
* Declarar variável privada ao módulo: '''real r1 = 22.0'''
* Declarar variável pública: '''public real r2 = 7.0'''
* Declarar variável pública: '''public auto r2 = 7.0''' (igual à anterior)
* Declarar variável pública: '''public r2 = 7.0''' (igual à anterior)
* Usar definição externa de variável pública: '''forward real r2'''
* Declarar função (nativa P6) definida externamente: '''forward int<int> factorial'''
* Declarar função definida noutra linguagem (e.g. em C): '''extern [void]<int> malloc'''

== Inicialização ==

Quando existe, é a designação do objecto que segue o símbolo '''=''': inteiro, real, cadeia de caracteres, ou ponteiro. Entidades reais podem ser inicializadas por expressões inteiras (conversão implícita). A expressão de inicialização deve ser um literal se a variável for global.

A palavra '''auto''' pode ser usada em lugar do tipo para declarar uma variável. Quando usada, o tipo da variável é inferido a partir do valor inicial (nestes casos, o valor inicial é obrigatório).

Exemplos:
* Inteiro (literal): '''int i = 3'''
* Inteiro (expressão): '''int i = j + 1'''
* Real (literal): '''real r = 3.2'''
* Real (expressão): '''real r = i - 2.5'''
* Cadeia de caracteres (literal): '''string s = "olá"'''
* Cadeia de caracteres (literais): '''string s = "olá" "mãe"'''
* Ponteiro (literal): '''<nowiki>[[[real]]] p</nowiki> = null'''
* Ponteiro (expressão): '''[int] p = q + 1'''


= Funções =

Uma função permite agrupar um conjunto de instruções num corpo, executado com base num conjunto de parâmetros (os argumentos formais), quando é invocada a partir de uma expressão.

== Declaração ==

As funções têm um nome que é também o endereço dessa função. O tipo de retorno de uma função que não produz valores de retorno é '''void'''.

As funções que recebam argumentos devem indicá-los no cabeçalho. Funções sem argumentos definem um cabeçalho vazio. Os qualificadores de exportação/importação '''public''' ou '''forward''' (ver símbolos globais) podem ser aplicados às funções, mas não é possível aplicá-los às declarações dos argumentos de uma função. Não é possível especificar valores por omissão para os argumentos de uma função, nem para o valor de retorno.

A declaração de um ponteiro para uma função (ou, de forma equivalente, do seu nome) é utilizada para caracterizar um identificador exterior ou para efectuar declarações antecipadas (utilizadas para pré-declarar funções que sejam usadas antes de ser definidas, por exemplo, entre duas funções mutuamente recursivas). 

== Invocação ==

Uma função pode ser invocada através do seu nome. 
Se existirem argumentos, na invocação da função, o nome é seguido de uma lista de expressões delimitadas por parênteses curvos. Esta lista é uma sequência, possivelmente vazia, de expressões separadas por vírgulas. O número e tipo de parâmetros actuais deve ser igual ao número e tipo dos parâmetros formais da função invocada (a menos de conversões implícitas). A ordem dos parâmetros actuais deverá ser a mesma dos argumentos formais da função a ser invocada.

De acordo com a convenção Cdecl, a função chamadora coloca os argumentos na pilha e é responsável pela sua remoção, após o retorno da chamada. Assim, os parâmetros actuais devem ser colocados na pilha pela ordem inversa da sua declaração (i.e., são avaliados da direita para a esquerda antes da invocação da função e o resultado passado por cópia/valor). O endereço de retorno é colocado no topo da pilha pela chamada à função. Note que o retorno de entidades com dimensão superior a 64 bits deve fazer-se através da reserva de espaço para o retorno no chamador e passando um ponteiro para esse espaço como primeiro argumento do chamado.

== Corpo ==

O corpo de uma função consiste num bloco que contém declarações (opcionais) seguidas de instruções (opcionais). Não é possível aplicar os qualificadores de exportação ('''public''') ou de importação ('''forward''' ou '''extern''') (ver [[#Símbolos globais|símbolos globais]]) dentro do corpo de uma função.

Uma instrução '''return''' causa a interrupção da função. O valor devolvido por uma função, através de expressão usada como argumento da instrução '''return''', deve ser do tipo declarado no cabeçalho da função. Ver casos especiais acima.

É um erro especificar um valor de retorno se a função for declarada como não retornando um valor (indicada como '''void''').

Qualquer bloco (usado, por exemplo, numa instrução condicional ou de iteração) pode definir variáveis locais. 

== Função principal e execução de programas ==

Um programa é a sequência de instruções que seguem as declarações globais num ficheiro, delimitadas pelas palavras-chave '''begin''' e '''end'''. Esta sequência forma o que em algumas linguagens se chama a função principal. Os argumentos com que o programa foi chamado podem ser obtidos através de funções '''argc''' (devolve o número de argumentos); '''argv''' (devolve o n-ésimo argumento como uma cadeia de caracteres, com n>0); e '''envp''' (devolve a n-ésima variável de ambiente como uma cadeia de caracteres, com n>0). Apenas um dos módulos do programa pode definir a função principal, i.e., se existirem vários módulos, apenas um deles pode conter mais do que declarações de variáveis globais.

extern int<> argc
extern string<int> argv
extern string<int> envp

O valor de retorno da função principal é devolvido ao ambiente que invocou o programa. Este valor de retorno segue as seguintes regras (sistema operativo): 0 (zero), execução sem erros; 1 (um), argumentos inválidos (em número ou valor); 2 (dois), erro de execução. Os valores superiores a 128 indicam que o programa terminou com um sinal. Em geral, para correcto funcionamento, os programas devem devolver 0 (zero) se a execução foi bem-sucedida e um valor diferente de 0 (zero) em caso de erro.

A biblioteca de run-time (RTS) contém informação sobre outras funções de suporte disponíveis, incluindo chamadas ao sistema (ver também o manual da RTS).

= Instruções =

Excepto quando indicado, as instruções são executadas em sequência.

== Blocos ==

Cada bloco tem uma zona de declarações de variáveis locais (facultativa), seguida por uma zona com instruções (possivelmente vazia). Não é possível definir funções dentro de blocos, mas é possível declarar ponteiros de função locais.

A visibilidade das variáveis é limitada ao bloco em que foram declaradas. As entidades declaradas podem ser directamente utilizadas em sub-blocos ou passadas como argumentos para funções chamadas dentro do bloco. Caso os identificadores usados para definir as variáveis locais já estejam a ser utilizados para definir outras entidades ao alcance do bloco, o novo identificador passa a referir uma nova entidade definida no bloco até que ele termine (a entidade previamente definida continua a existir, mas não pode ser directamente referida pelo seu nome). Esta regra é também válida relativamente a
argumentos de funções (ver corpo das funções).

== Instrução condicional ==

Esta instrução tem comportamento semelhante ao da instrução '''if-else''' em C. As partes correspondentes a '''elif''' comportam-se como encadeamentos de instruções condicionais na parte '''else''' de um '''if-else''' à la C.

== Instrução de iteração ==

Esta instrução tem comportamento idêntico ao da instrução '''while''' em C.

== Instrução de terminação ==

A instrução '''stop''' termina o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''break''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de continuação ==

A instrução '''next''' reinicia o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''continue''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de retorno ==

A instrução '''return''', se existir, é a última instrução do seu bloco. Ver comportamento na [[#Corpo|descrição do corpo de uma função]].

== Expressões como instruções ==

As expressões utilizadas como instruções são sempre avaliadas, mesmo que não produzam efeitos secundários.

== Instruções de impressão ==

As notações '''!''' e '''!!''' podem ser utilizadas para apresentar valores na saída do programa. A primeira forma apresenta os valores sem mudar de linha; a segunda forma apresenta os valores mudando de linha depois de os apresentar a todos. Quando existe mais de uma expressão, as várias expressões são apresentadas sem separação. Valores numéricos (inteiros ou reais) são impressos em decimal. As cadeias de caracteres são impressas na codificação nativa. Ponteiros não podem ser impressos.

= Expressões =

Uma expressão é uma representação algébrica de uma quantidade: todas as expressões têm um tipo e devolvem um valor.

Existem [[#Expressões primitivas|expressões primitivas]] e expressões que resultam da [[#Expressões resultantes de avaliação de operadores|avaliação de operadores]].

A tabela seguinte apresenta as precedências relativas dos operadores: é a mesma para operadores na mesma linha, sendo as linhas seguintes de menor prioridade que as anteriores. A maioria dos operadores segue a semântica da linguagem C (excepto onde explicitamente indicado). Tal como em C, os valores lógicos são 0 (zero) (valor falso), e diferente de zero (valor verdadeiro).

{|
| '''Tipo de Expressão'''
| '''Operadores'''
| '''Associatividade'''
| '''Operandos'''
| '''Semântica'''
|-
| primária
| '''( ) [ ]'''
| não associativos
| -
| [[#Parênteses curvos|parênteses curvos]], [[#Indexação|indexação]], [[#Reserva de memória|reserva de memória]]
|-
| unária
| '''+ - ?'''
| não associativos
| -
| [[#Identidade e simétrico|identidade e simétrico]], [[#Expressão de indicação de posição|indicação de posição]]
|-
! style="vertical-align: top; font-weight: normal;" | "não" lógico
! style="vertical-align: top; font-weight: normal;" | '''~'''
! style="vertical-align: top; font-weight: normal;" | não associativo
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: negação
|-
! style="vertical-align: top; font-weight: normal;" | multiplicativa
! style="vertical-align: top; font-weight: normal;" | '''* / %'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | aditiva
! style="vertical-align: top; font-weight: normal;" | '''+ -'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias: se envolverem ponteiros, calculam: (i) deslocamentos, i.e., um dos operandos deve ser do tipo ponteiro e o outro do tipo inteiro (binário de 32 bits); (ii) diferenças de ponteiros, i.e., apenas quando se aplica o operador '''-''' a dois ponteiros do mesmo tipo (o resultado é o número de objectos do tipo apontado entre eles, representado como um valor inteiro ternário de 64 bits). Se a memória não for contígua, o resultado é indefinido.
|-
! style="vertical-align: top; font-weight: normal;" | comparativa
! style="vertical-align: top; font-weight: normal;" | '''< > <= >='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | igualdade
! style="vertical-align: top; font-weight: normal;" | '''== !='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | "e" lógico
! style="vertical-align: top; font-weight: normal;" | '''&&'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for falso.
|-
! style="vertical-align: top; font-weight: normal;" | "ou" lógico
! style="vertical-align: top; font-weight: normal;" | '''<nowiki>||</nowiki>'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for verdadeiro.
|-
! style="vertical-align: top; font-weight: normal;" | atribuição
! style="vertical-align: top; font-weight: normal;" | '''='''
! style="vertical-align: top; font-weight: normal;" | da direita para a esquerda
! style="vertical-align: top; font-weight: normal;" | todos os tipos
! style="vertical-align: top; font-weight: normal;" | O valor da expressão do lado direito do operador é guardado na posição indicada pelo ''left-value'' (operando esquerdo do operador). Podem ser atribuídos valores inteiros a ''left-values'' reais (conversão automática). Nos outros casos, ambos os tipos têm de concordar. O literal '''null''' é compatível com todos os tipos de ponteiros.
|}

== Expressões primitivas ==

As [[#Literais|expressões literais]] e a [[#Invocação|invocação de funções]] foram definidas acima.

=== Identificadores ===

Um identificador é uma expressão se tiver sido declarado. Um identificador pode denotar uma variável.

Um identificador é o caso mais simples de um ''[[#Left-values|left-value]]'', ou seja, uma entidade que pode ser utilizada no lado esquerdo (''left'') de uma atribuição.

=== Leitura ===

A operação de leitura de um valor inteiro ou real pode ser efectuado pela expressão indicada pela palavra-chave '''input''', que devolve o valor lido, de acordo com o tipo esperado (inteiro ou real). Caso se use como argumento dos operadores de impressão ou noutras situações que permitam vários tipos (e.g. '''!''' ou '''!!'''), deve ser lido um inteiro.

Exemplos: '''a = input''' (leitura para '''a'''), '''f(input)''' (leitura para argumento de função), '''input!!''' (leitura e impressão).

=== Parênteses curvos ===

Uma expressão entre parênteses curvos tem o valor da expressão sem os parênteses e permite alterar a prioridade dos operadores. Uma expressão entre parênteses não pode ser utilizada como ''left-value'' (ver também a [[#Indexação|expressão de indexação]]).


== Expressões resultantes de avaliação de operadores ==

=== Indexação de ponteiros ===

A indexação de ponteiros devolve o valor de uma posição de memória indicada por um ponteiro. Consiste em uma expressão ponteiro seguida do índice entre parênteses rectos. O resultado de uma indexação de ponteiros é um ''[[#Left-values|left-value]]''. Não é possível indexar ponteiros que designem funções.

Exemplo (acesso à posição 0 da zona de memória indicada por '''p'''): '''p[0]'''

=== Identidade e simétrico ===

Os operadores identidade ('''+''') e simétrico ('''-''') aplicam-se a inteiros e reais. Têm o mesmo significado que em análogo às operações correspondentes em C, mas operam sobre grandezas ternárias.

=== Reserva de memória ===

A expressão reserva de memória devolve o ponteiro que aponta para a zona de memória, na pilha da função actual, contendo espaço suficiente para o número de objectos indicados pelo seu argumento inteiro.

Exemplo (reserva vector com 5 reais, apontados por '''p'''): '''[real] p = [5]'''

=== Expressão de indicação de posição ===

O operador sufixo '''?''' aplica-se a ''left-values'', retornando o endereço (com o tipo ponteiro) correspondente.

Exemplo (indica o endereço de '''a'''): '''a?'''

=== Expressão de dimensão ===

O operador '''sizeof''' tem um único argumento e aplica-se a expressões, retornando a dimensão correspondente em bytes.

Exemplo: '''sizeof(a)''' (dimensão de '''a''').

= Exemplos e Testes =

Os exemplos abaixo não são exaustivos e não ilustram todos os aspectos da linguagem.

Estão ainda disponíveis outros [https://gitlab.rnl.tecnico.ulisboa.pt/leic-a-co26/eval/co26 pacotes de testes].

O seguinte exemplo ilustra um programa com dois módulos: um que define a função '''factorial''' e outro que define a função principal.

Definição da função '''factorial''' no ficheiro '''factorial.p6''':

<syntaxhighlight lang="text">
public factorial(int n) -> int {
if (n > 1)
return n * factorial(n - 1);
else
return 1;
}
</syntaxhighlight>

Exemplo da utilização da função '''factorial''' no ficheiro '''main.p6''':

<syntaxhighlight lang="text">
// external builtin functions (non-P6)
extern int<> argc;
extern string<int> argv;
extern int<string> atoi;

// external user functions (P6)
forward int<int> factorial;

// the main function
begin
auto value = 1;
"Teste para a função factorial."!!
if (argc() == 2) {
string s = argv(1);
value = atoi(s);
}
value, "! é ", factorial(value)!!
return 0;
end
</syntaxhighlight>

Como compilar:
<syntaxhighlight lang="text">
p6 --target asm factorial.p6
p6 --target asm main.p6
yasm -felf32 factorial.asm
yasm -felf32 main.asm
ld -melf_i386 -o main factorial.o main.o -lrts
</syntaxhighlight>

= Omissões e Erros =

Casos omissos e erros serão corrigidos em futuras versões do manual de referência.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category: Ensino]]

Compiladores/Projecto de Compiladores/Projecto 2025-2026/Manual de Referência da Linguagem P6

2026-05-16T16:50:20Z

Root: /* Exemplos e Testes */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}


'''ÉPOCA NORMAL'''

'''P6''' é uma linguagem imperativa. Este manual apresenta de forma intuitiva as características da linguagem: [[#Tipos de Dados|tipos de dados]]; [[#Manipulação de Nomes|manipulação de nomes]]; [[#Convenções Lexicais|convenções lexicais]]; [[#Gramática|estrutura/sintaxe]]; [[#Funções|especificação das funções]]; [[#Instruções|semântica das instruções]]; [[#Expressões|semântica das expressões]]; e, finalmente, [[#Exemplos|alguns exemplos]].

= Tipos de Dados =

A linguagem é fracamente tipificada (são efectuadas algumas conversões implícitas). Existem 4 tipos de dados básicos, apenas alguns dos quais são compatíveis com a [https://en.wikipedia.org/wiki/C_(programming_language) linguagem C]. O alinhamento em memória binária é sempre a 32 bits. Note-se que alguns dos tipos de dados são ternários e devem ser manipulados com as funções das ALUs disponibilizadas.

* Tipos numéricos: os inteiros são [https://en.wikipedia.org/wiki/Balanced_ternary ternários equilibrados], ocupam 40 trits (empacotados em 64 bits); os reais são ternários e estão representados no formato [https://arxiv.org/abs/2404.18603 Takum] (note-se que a definição neste artigo é para uma representação binária e não é exactamente a que é implementada pelas ALUs ternárias em uso no projecto), ocupam 80 trits (empacotados em 128 bits).
* As cadeias de caracteres são vectores de caracteres binários terminados por [https://en.wikipedia.org/wiki/ASCII ASCII] NUL (carácter com o valor zero). Variáveis e literais deste tipo só podem ser utilizados em atribuições, impressões, ou como argumentos/retornos de funções. Os caracteres são valores de 8 bits não directamente manipuláveis.
* Os ponteiros representam endereços de objectos (de qualquer tipo) e ocupam 32 bits. Podem ser objecto de operações aritméticas (deslocamentos) e permitem aceder ao valor apontado. Note-se que não é possível usar inteiros ternários directamente em aritmética de ponteiros (têm de ser convertidos para isso).

Os tipos suportados por cada operador e a operação a realizar são indicados na [[#Expressões|definição das expressões]].

Existem ainda tipos associado a valores funcionais, i.e., tipos que descrevem a interface de funções (ver abaixo). Os valores em memória associados a estes tipos são efectivamente ponteiros, mas para funções e não para dados, podendo ser usados para invocar as funções correspondentes. Estes identificadores não podem ser usados como variáveis (e.g., passados como argumentos de outras funções, etc.).

= Manipulação de Nomes =

Os nomes (identificadores) correspondem a variáveis e funções. Nos pontos que se seguem, usa-se o termo entidade para as designar indiscriminadamente, explicitando-se quando a descrição for válida apenas para um dos casos. Existem ainda nomes para funções externas à linguagem P6. Tanto em P6, como em C, os nomes das funções referem directamente a posição do código dessas funções (à la C; ver '''extern''' abaixo).

== Espaço de nomes e visibilidade dos identificadores ==

O espaço de nomes global é único, pelo que um nome utilizado para designar uma entidade num dado contexto não pode ser utilizado para designar outras (ainda que de natureza diferente).

Os identificadores são visíveis desde a declaração até ao fim do alcance: ficheiro (globais) ou bloco (locais). A reutilização de identificadores em contextos inferiores encobre declarações em contextos superiores: redeclarações locais podem encobrir as globais até ao fim de um bloco. É possível utilizar símbolos globais nos contextos dos blocos das funções, mas não é possível declará-los (ver [[#Símbolos globais|símbolos globais]]).

== Validade das variáveis ==

As entidades globais (declaradas fora de qualquer função), existem durante toda a execução do programa. As variáveis locais a uma função existem apenas durante a sua execução. Os argumentos formais são válidos enquanto a função está activa.

= Convenções Lexicais =

Para cada grupo de elementos lexicais (tokens), considera-se a maior sequência de caracteres constituindo um elemento válido. Assim, por exemplo, a designação '''>=''' é sempre um único elemento lexical (por oposição à situação ilegal de se terem dois símbolos: '''>''' seguido de '''=''').

== Caracteres brancos ==

São considerados separadores e não representam nenhum elemento lexical: '''mudança de linha''' ASCII LF ('''0x0A''', '''\n'''), '''recuo do carreto''' ASCII CR ('''0x0D''', '''\r'''), '''espaço''' ASCII SP ('''0x20''', ⌴) e '''tabulação horizontal''' ASCII HT ('''0x09''', '''\t''').

== Comentários ==

Existem dois tipos de comentários, que também funcionam como elementos separadores:

* '''explicativos''' -- começam com '''//''' e acabam no fim da linha; e
* '''operacionais''' -- começam com '''/*''' e terminam com '''*/''', podendo estar aninhados.

Se as sequências de início fizerem parte de uma cadeia de caracteres, não iniciam um comentário (ver [[#Cadeias de caracteres|definição das cadeias de caracteres]]).

== Palavras-chave ==

As seguintes palavras-chave são reservadas, não constituindo identificadores (devem ser escritas exactamente como indicado):

* tipos: '''int real string void'''
* declarações: '''extern forward public auto'''
* instruções: '''if elif else while stop next return'''
* expressões: '''input null sizeof'''
* outras: '''begin end'''

== Tipos ==

Os seguintes elementos lexicais designam tipos em declarações (ver gramática): '''int''' (inteiro), '''real''' (real), '''string''' (cadeia de caracteres).

Os tipos correspondentes a ponteiros são outros tipos delimitados por '''[''' e ''']''', designando uma indirecção e não o objecto directo (ver gramática).

Note-se que, quando se tem uma declaração '''extern''', os tipos correspondem aos compatíveis com a linguagem C na mesma arquitectura ix86 de 32 bits, i.e., '''int''' corresponde a um número binário inteiro em [https://en.wikipedia.org/wiki/Two%27s_complement complemento para 2] (32 bits), '''real''' coresponde a uma representação segundo a norma [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] de dupla precisão (64 bits), devendo ser convertidos de e para os tipos nativos da linguage P6 sempre que necessário (ver RTS).

== Operadores de expressões ==

São considerados operadores os elementos lexicais apresentados na definição das expressões.

== Delimitadores e terminadores ==

Os seguintes elementos lexicais são delimitadores/terminadores:
* ''',''' (vírgula)
* ''';''' (ponto e vírgula)
* '''!''' e '''!!''' (operações de impressão)
* '''(''' e ''')''' (delimitadores de expressões)
* '''{''' e '''}''' (delimitadores de blocos)

== Identificadores (nomes) ==

São iniciados por uma letra, seguindo-se 0 (zero) ou mais letras ou dígitos. O comprimento do nome é ilimitado e dois nomes são distintos se houver alteração de maiúscula para minúscula, ou vice-versa, de pelo menos um carácter.

== Literais ==

São notações para valores constantes de alguns tipos da linguagem (não confundir com constantes, i.e., identificadores que, em algumas linguagens, designam elementos cujo valor não pode ser alterado durante a execução do programa).

=== Inteiros ===

Um literal inteiro é um número não negativo (mas ver a seguir). Números negativos podem ser construídos pela aplicação do operador de negação unária ('''-''') a um literal (sempre positivo).

Literais inteiros decimais são constituídos por sequências de 1 (um) ou mais dígitos de '''0''' a '''9''', em que o primeiro digito não é 0 (zero), excepto no caso do número 0 (zero). Neste caso, é composto apenas pelo dígito 0 (zero) (em qualquer base).

Literais inteiros em base 9 começam sempre pelo dígito 0 (zero), sendo seguidos de um ou mais dígitos de '''0''' a '''8''' (note-se que '''09''' é um literal inválido em base 9). Exemplo: '''086 = 78'''.

Literais inteiros em base 3 (equilibrada) começam sempre com a sequência '''0t''', seguida de um ou mais símbolos dessa base: '''-''' (valor '''-1'''), '''0''' (valor '''0''') e '''+''' (valor '''1'''). Estes literais podem ser intrinsecamente negativos. Exemplos: '''0t+0-0 = 24'''; '''0t-0+0 = -24'''

Se não for possível representar um literal na máquina, devido a overflow, deverá ser gerado um erro lexical.

=== Reais em formato Takum3 ===

Os literais reais (sempre positivos) são expressos tal como em C (exclusivamente em base 10).

Não existem literais negativos (números negativos resultam da operação unária '''-''').

Note-se que um literal sem '''.''' (ponto decimal) nem parte exponencial é do tipo inteiro.

Note-se que, apesar de C normalmente usar uma representação interna em binário no formato IEEE 754, a linguagem P6 usa um formato, representado em ternário, completamente diferente (embora a forma de escrita dos literais seja a mesma).

Exemplos: '''3.14''', '''1E3''' = 1000 (número inteiro representado como real). '''12.34e-24''' = 12.34 x 10-24 (notação cientifica).


=== Cadeias de caracteres ===

As cadeias de caracteres são delimitadas por aspas ('''"''') e podem conter quaisquer caracteres, excepto ASCII NUL (0x00) e ASCII LF (0x0A). Nas cadeias, os delimitadores de comentários não têm significado especial. Se for escrito um literal que contenha '''\0''', então a cadeia termina nessa posição. Exemplo: '''ab\0xy''' tem o mesmo significado que '''ab'''.

É possível designar caracteres por sequências especiais (iniciadas por '''\'''), especialmente úteis quando não existe representação gráfica directa. As sequências especiais correspondem aos caracteres ASCII HT, LF e CR ('''\t''', '''\n''' e '''\r''', respectivamente), aspa ('''\"'''). ''backslash'' ('''\\'''), ou a quaisquer outros especificados através de 1 a 3 dígitos em base 8, designando valores de 8 bits (e.g., '''\012''' ou apenas '''\12''' se o carácter seguinte não representar um dígito em base 8). Exemplo: '''xy\012z''' tem o mesmo significado que '''xy\12z''' e que '''xy\nz'''.

Elementos lexicais distintos que representem duas ou mais cadeias consecutivas são representadas na linguagem como uma única cadeia que resulta da concatenação. Exemplo: '''"ab"''' '''"cd"''' é o mesmo que '''"abcd"'''.

=== Ponteiros ===

O único literal admissível para ponteiros corresponde ao ponteiro nulo e é indicado pela palavra-chave '''null'''. Este literal é compatível com todos os tipos de ponteiro. Os inteiros não são convertíveis em ponteiros, pelo que o valor '''0''' (zero) não é um valor inicial admissível para ponteiros.

Note-se que a aritmética de ponteiros é possível apenas com inteiros binários, mas não com inteiros ternários (estes devem ser convertidos para binário, caso seja necessário).

= Gramática =

A gramática da linguagem está resumida abaixo. Considerou-se que os elementos em tipo fixo são literais, que os parênteses curvos agrupam elementos, que elementos alternativos são separados por uma barra vertical, que elementos opcionais estão entre parênteses rectos, que os elementos que se repetem zero ou mais vezes estão entre <math>\langle</math> e <math>\rangle</math>. Alguns elementos usados na gramática também são elementos da linguagem descrita se representados em tipo fixo (e.g., parênteses).

{|
! style="width: 140px; font-weight: normal;" | ''ficheiro''
! style="width: 50px; font-weight: normal;" | <math>\rightarrow</math>
| <math>\langle</math> ''declaração'' <math>\rangle</math> [ ''programa-principal'' ]
|-
! style="width: 150px; font-weight: normal;" | ''declaração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''tipo'' ''identificador'' [ '''=''' ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] [ '''auto''' ] ''identificador'' '''=''' ''expressão'' ''';'''
|-
! style="width: 150px; font-weight: normal;" | ''programa-principal''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''begin''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''end'''
|-
! style="width: 50px; font-weight: normal;" | ''função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''variáveis'' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''variáveis''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''variável'' <math>\langle</math> ''',''' ''variável'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''tipo''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''int''' <math>|</math> '''real''' <math>|</math> '''string''' <math>|</math> '''void''' <math>|</math> '''[''' ''tipo'' ''']''' <math>|</math> ''tipo-de-função''
|-
! style="width: 50px; font-weight: normal;" | ''tipo-de-função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' '''>'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' ''tipos'' '''>'''
|-
! style="width: 50px; font-weight: normal;" | ''tipos''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' <math>\langle</math> ''',''' ''tipo'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''bloco''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''{''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''}'''
|-
! style="width: 50px; font-weight: normal;" | ''instrução''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' ''';''' <math>|</math> ''expressões'' '''!''' <math>|</math> ''expressões'' '''!!'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''stop''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''next''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''return''' [ ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''instrução-condicional'' <math>|</math> ''instrução-de-iteração'' <math>|</math> ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''instrução-condicional''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''if''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\langle</math> '''elif''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\rangle</math> [ '''else''' ''instrução'' ]
|-
! style="width: 50px; font-weight: normal;" | ''instrução-de-iteração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''while''' '''(''' ''expressão'' ''')''' ''instrução''
|-
! style="width: 50px; font-weight: normal;" | ''expressões''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' <math>\langle</math> ''',''' ''expressão'' <math>\rangle</math>
|}

== Tipos, identificadores, literais e definição de expressões ==

Algumas definições foram omitidas da gramática: tipos de dados. qualificadores e variável (ver [[#Declarações de variáveis|declarações de variáveis]]), identificador (ver [[#Identificadores (nomes)|identificadores]]), literal (ver [[#Literais|literais]]); expressão (ver [[#Expressões|expressões]]). 

Quanto a tipos de dados, '''int''' designa valores inteiros, '''real''' designa valores reais, '''string''' designa cadeias de caracteres. Os ponteiros são tipos compostos por um tipo entre parênteses rectos, e.g., '''[int]'''.

Os tipos funcionais são definidos a partir dos tipos de dados anteriormente descritos e do tipo especial '''void''' (ver a seguir). O tipo é indicado com o formato indicado na gramática, i.e., tipo de retorno seguido dos tipos dos argumentos (zero ou mais separados por vírgulas). Estes tipos servem para declarar símbolos de função sem as definir.


O tipo '''void''' apenas pode ser usado para indicar a ausência de retorno ou para declarar um ponteiro genérico. Neste caso, o aninhamento é irrelevante, i.e., '''[void]''' e '''<nowiki>[[[void]]]</nowiki>''' são equivalentes. Um ponteiro deste tipo é compatível com todos os outros tipos de ponteiros. A aritmética de ponteiros decrementa/incrementa em uma unidade o valor de um ponteiro do tipo '''[void]'''.

== Left-values ==

Os ''left-values'' são posições de memória que podem ser modificadas (excepto onde proibido pelo tipo de dados). Os elementos de uma expressão que podem ser utilizados como left-values encontram-se individualmente identificados na semântica das expressões.

== Ficheiros ==

Um ficheiro é designado por principal se contiver a função principal (onde se inicia o programa).

== Declaração de variáveis ==

Uma declaração de variável indica sempre um tipo de dados (implícito ou explícito) e um identificador.

Exemplos:

* Inteiro: '''int i'''
* Real: '''real r'''
* Cadeia de caracteres: '''string s'''
* Ponteiro para inteiro: '''[int] p1''' (semelhante a '''int*''' em C)
* Ponteiro para real: '''[real] p2''' (semelhante a '''double*''' em C)
* Ponteiro para cadeia de caracteres: '''[string] p3''' (semelhante a '''char**''' em C)
* Ponteiro para ponteiro para inteiro: '''<nowiki>[[int]]</nowiki> p4''' (semelhante a '''int**''' em C)

É possível usar o pseudo-tipo '''auto''' se a declaração tiver um valor inicial: neste caso, o tipo é o do valor inicial.

Exemplo:

* Variável inteira: '''auto i = 1'''
* Variável real: '''auto f = 2.0'''
* etc.

== Símbolos globais ==

Por omissão, os símbolos são privados a um módulo, não podendo ser importados por outros módulos.

A palavra-chave '''public''' permite declarar um identificador como público, tornando-o acessível a partir de outros módulos. Quando usado com a palavra-chave '''auto''', esta é opcional. Note-se que a declaração de uma variável tem de ter sempre, ou o qualificador, ou o tipo, podendo estar ambos presentes.

A palavra-chave '''forward''' permite declarar num módulo variáveis ou funções definidas noutros módulos. Neste caso, não pode ser especificado o valor inicial das variáveis, pelo que não é possível o uso de '''auto''' em conjunto com '''forward'''.

A palavra-chave '''extern''' deve ser usada para declarar símbolos de função com tipos diferentes dos dos nativos da da linguagem P6, e.g. para importar funções definidas em C. Além de poderem ser usados para chamar as funções que designam, os símbolos assim declarados podem ser utilizados com valores convertidos de forma apropriada.

Exemplos:
* Declarar variável privada ao módulo: '''real r1 = 22.0'''
* Declarar variável pública: '''public real r2 = 7.0'''
* Declarar variável pública: '''public auto r2 = 7.0''' (igual à anterior)
* Declarar variável pública: '''public r2 = 7.0''' (igual à anterior)
* Usar definição externa de variável pública: '''forward real r2'''
* Declarar função (nativa P6) definida externamente: '''forward int<int> factorial'''
* Declarar função definida noutra linguagem (e.g. em C): '''extern [void]<int> malloc'''

== Inicialização ==

Quando existe, é a designação do objecto que segue o símbolo '''=''': inteiro, real, cadeia de caracteres, ou ponteiro. Entidades reais podem ser inicializadas por expressões inteiras (conversão implícita). A expressão de inicialização deve ser um literal se a variável for global.

A palavra '''auto''' pode ser usada em lugar do tipo para declarar uma variável. Quando usada, o tipo da variável é inferido a partir do valor inicial (nestes casos, o valor inicial é obrigatório).

Exemplos:
* Inteiro (literal): '''int i = 3'''
* Inteiro (expressão): '''int i = j + 1'''
* Real (literal): '''real r = 3.2'''
* Real (expressão): '''real r = i - 2.5'''
* Cadeia de caracteres (literal): '''string s = "olá"'''
* Cadeia de caracteres (literais): '''string s = "olá" "mãe"'''
* Ponteiro (literal): '''<nowiki>[[[real]]] p</nowiki> = null'''
* Ponteiro (expressão): '''[int] p = q + 1'''


= Funções =

Uma função permite agrupar um conjunto de instruções num corpo, executado com base num conjunto de parâmetros (os argumentos formais), quando é invocada a partir de uma expressão.

== Declaração ==

As funções têm um nome que é também o endereço dessa função. O tipo de retorno de uma função que não produz valores de retorno é '''void'''.

As funções que recebam argumentos devem indicá-los no cabeçalho. Funções sem argumentos definem um cabeçalho vazio. Os qualificadores de exportação/importação '''public''' ou '''forward''' (ver símbolos globais) podem ser aplicados às funções, mas não é possível aplicá-los às declarações dos argumentos de uma função. Não é possível especificar valores por omissão para os argumentos de uma função, nem para o valor de retorno.

A declaração de um ponteiro para uma função (ou, de forma equivalente, do seu nome) é utilizada para caracterizar um identificador exterior ou para efectuar declarações antecipadas (utilizadas para pré-declarar funções que sejam usadas antes de ser definidas, por exemplo, entre duas funções mutuamente recursivas). 

== Invocação ==

Uma função pode ser invocada através do seu nome. 
Se existirem argumentos, na invocação da função, o nome é seguido de uma lista de expressões delimitadas por parênteses curvos. Esta lista é uma sequência, possivelmente vazia, de expressões separadas por vírgulas. O número e tipo de parâmetros actuais deve ser igual ao número e tipo dos parâmetros formais da função invocada (a menos de conversões implícitas). A ordem dos parâmetros actuais deverá ser a mesma dos argumentos formais da função a ser invocada.

De acordo com a convenção Cdecl, a função chamadora coloca os argumentos na pilha e é responsável pela sua remoção, após o retorno da chamada. Assim, os parâmetros actuais devem ser colocados na pilha pela ordem inversa da sua declaração (i.e., são avaliados da direita para a esquerda antes da invocação da função e o resultado passado por cópia/valor). O endereço de retorno é colocado no topo da pilha pela chamada à função. Note que o retorno de entidades com dimensão superior a 64 bits deve fazer-se através da reserva de espaço para o retorno no chamador e passando um ponteiro para esse espaço como primeiro argumento do chamado.

== Corpo ==

O corpo de uma função consiste num bloco que contém declarações (opcionais) seguidas de instruções (opcionais). Não é possível aplicar os qualificadores de exportação ('''public''') ou de importação ('''forward''' ou '''extern''') (ver [[#Símbolos globais|símbolos globais]]) dentro do corpo de uma função.

Uma instrução '''return''' causa a interrupção da função. O valor devolvido por uma função, através de expressão usada como argumento da instrução '''return''', deve ser do tipo declarado no cabeçalho da função. Ver casos especiais acima.

É um erro especificar um valor de retorno se a função for declarada como não retornando um valor (indicada como '''void''').

Qualquer bloco (usado, por exemplo, numa instrução condicional ou de iteração) pode definir variáveis locais. 

== Função principal e execução de programas ==

Um programa é a sequência de instruções que seguem as declarações globais num ficheiro, delimitadas pelas palavras-chave '''begin''' e '''end'''. Esta sequência forma o que em algumas linguagens se chama a função principal. Os argumentos com que o programa foi chamado podem ser obtidos através de funções '''argc''' (devolve o número de argumentos); '''argv''' (devolve o n-ésimo argumento como uma cadeia de caracteres, com n>0); e '''envp''' (devolve a n-ésima variável de ambiente como uma cadeia de caracteres, com n>0). Apenas um dos módulos do programa pode definir a função principal, i.e., se existirem vários módulos, apenas um deles pode conter mais do que declarações de variáveis globais.

extern int<> argc
extern string<int> argv
extern string<int> envp

O valor de retorno da função principal é devolvido ao ambiente que invocou o programa. Este valor de retorno segue as seguintes regras (sistema operativo): 0 (zero), execução sem erros; 1 (um), argumentos inválidos (em número ou valor); 2 (dois), erro de execução. Os valores superiores a 128 indicam que o programa terminou com um sinal. Em geral, para correcto funcionamento, os programas devem devolver 0 (zero) se a execução foi bem-sucedida e um valor diferente de 0 (zero) em caso de erro.

A biblioteca de run-time (RTS) contém informação sobre outras funções de suporte disponíveis, incluindo chamadas ao sistema (ver também o manual da RTS).

= Instruções =

Excepto quando indicado, as instruções são executadas em sequência.

== Blocos ==

Cada bloco tem uma zona de declarações de variáveis locais (facultativa), seguida por uma zona com instruções (possivelmente vazia). Não é possível definir funções dentro de blocos, mas é possível declarar ponteiros de função locais.

A visibilidade das variáveis é limitada ao bloco em que foram declaradas. As entidades declaradas podem ser directamente utilizadas em sub-blocos ou passadas como argumentos para funções chamadas dentro do bloco. Caso os identificadores usados para definir as variáveis locais já estejam a ser utilizados para definir outras entidades ao alcance do bloco, o novo identificador passa a referir uma nova entidade definida no bloco até que ele termine (a entidade previamente definida continua a existir, mas não pode ser directamente referida pelo seu nome). Esta regra é também válida relativamente a
argumentos de funções (ver corpo das funções).

== Instrução condicional ==

Esta instrução tem comportamento semelhante ao da instrução '''if-else''' em C. As partes correspondentes a '''elif''' comportam-se como encadeamentos de instruções condicionais na parte '''else''' de um '''if-else''' à la C.

== Instrução de iteração ==

Esta instrução tem comportamento idêntico ao da instrução '''while''' em C.

== Instrução de terminação ==

A instrução '''stop''' termina o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''break''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de continuação ==

A instrução '''next''' reinicia o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''continue''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de retorno ==

A instrução '''return''', se existir, é a última instrução do seu bloco. Ver comportamento na [[#Corpo|descrição do corpo de uma função]].

== Expressões como instruções ==

As expressões utilizadas como instruções são sempre avaliadas, mesmo que não produzam efeitos secundários.

== Instruções de impressão ==

As notações '''!''' e '''!!''' podem ser utilizadas para apresentar valores na saída do programa. A primeira forma apresenta os valores sem mudar de linha; a segunda forma apresenta os valores mudando de linha depois de os apresentar a todos. Quando existe mais de uma expressão, as várias expressões são apresentadas sem separação. Valores numéricos (inteiros ou reais) são impressos em decimal. As cadeias de caracteres são impressas na codificação nativa. Ponteiros não podem ser impressos.

= Expressões =

Uma expressão é uma representação algébrica de uma quantidade: todas as expressões têm um tipo e devolvem um valor.

Existem [[#Expressões primitivas|expressões primitivas]] e expressões que resultam da [[#Expressões resultantes de avaliação de operadores|avaliação de operadores]].

A tabela seguinte apresenta as precedências relativas dos operadores: é a mesma para operadores na mesma linha, sendo as linhas seguintes de menor prioridade que as anteriores. A maioria dos operadores segue a semântica da linguagem C (excepto onde explicitamente indicado). Tal como em C, os valores lógicos são 0 (zero) (valor falso), e diferente de zero (valor verdadeiro).

{|
| '''Tipo de Expressão'''
| '''Operadores'''
| '''Associatividade'''
| '''Operandos'''
| '''Semântica'''
|-
| primária
| '''( ) [ ]'''
| não associativos
| -
| [[#Parênteses curvos|parênteses curvos]], [[#Indexação|indexação]], [[#Reserva de memória|reserva de memória]]
|-
| unária
| '''+ - ?'''
| não associativos
| -
| [[#Identidade e simétrico|identidade e simétrico]], [[#Expressão de indicação de posição|indicação de posição]]
|-
! style="vertical-align: top; font-weight: normal;" | "não" lógico
! style="vertical-align: top; font-weight: normal;" | '''~'''
! style="vertical-align: top; font-weight: normal;" | não associativo
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: negação
|-
! style="vertical-align: top; font-weight: normal;" | multiplicativa
! style="vertical-align: top; font-weight: normal;" | '''* / %'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | aditiva
! style="vertical-align: top; font-weight: normal;" | '''+ -'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias: se envolverem ponteiros, calculam: (i) deslocamentos, i.e., um dos operandos deve ser do tipo ponteiro e o outro do tipo inteiro (binário de 32 bits); (ii) diferenças de ponteiros, i.e., apenas quando se aplica o operador '''-''' a dois ponteiros do mesmo tipo (o resultado é o número de objectos do tipo apontado entre eles, representado como um valor inteiro ternário de 64 bits). Se a memória não for contígua, o resultado é indefinido.
|-
! style="vertical-align: top; font-weight: normal;" | comparativa
! style="vertical-align: top; font-weight: normal;" | '''< > <= >='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | igualdade
! style="vertical-align: top; font-weight: normal;" | '''== !='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | "e" lógico
! style="vertical-align: top; font-weight: normal;" | '''&&'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for falso.
|-
! style="vertical-align: top; font-weight: normal;" | "ou" lógico
! style="vertical-align: top; font-weight: normal;" | '''<nowiki>||</nowiki>'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for verdadeiro.
|-
! style="vertical-align: top; font-weight: normal;" | atribuição
! style="vertical-align: top; font-weight: normal;" | '''='''
! style="vertical-align: top; font-weight: normal;" | da direita para a esquerda
! style="vertical-align: top; font-weight: normal;" | todos os tipos
! style="vertical-align: top; font-weight: normal;" | O valor da expressão do lado direito do operador é guardado na posição indicada pelo ''left-value'' (operando esquerdo do operador). Podem ser atribuídos valores inteiros a ''left-values'' reais (conversão automática). Nos outros casos, ambos os tipos têm de concordar. O literal '''null''' é compatível com todos os tipos de ponteiros.
|}

== Expressões primitivas ==

As [[#Literais|expressões literais]] e a [[#Invocação|invocação de funções]] foram definidas acima.

=== Identificadores ===

Um identificador é uma expressão se tiver sido declarado. Um identificador pode denotar uma variável.

Um identificador é o caso mais simples de um ''[[#Left-values|left-value]]'', ou seja, uma entidade que pode ser utilizada no lado esquerdo (''left'') de uma atribuição.

=== Leitura ===

A operação de leitura de um valor inteiro ou real pode ser efectuado pela expressão indicada pela palavra-chave '''input''', que devolve o valor lido, de acordo com o tipo esperado (inteiro ou real). Caso se use como argumento dos operadores de impressão ou noutras situações que permitam vários tipos (e.g. '''!''' ou '''!!'''), deve ser lido um inteiro.

Exemplos: '''a = input''' (leitura para '''a'''), '''f(input)''' (leitura para argumento de função), '''input!!''' (leitura e impressão).

=== Parênteses curvos ===

Uma expressão entre parênteses curvos tem o valor da expressão sem os parênteses e permite alterar a prioridade dos operadores. Uma expressão entre parênteses não pode ser utilizada como ''left-value'' (ver também a [[#Indexação|expressão de indexação]]).


== Expressões resultantes de avaliação de operadores ==

=== Indexação de ponteiros ===

A indexação de ponteiros devolve o valor de uma posição de memória indicada por um ponteiro. Consiste em uma expressão ponteiro seguida do índice entre parênteses rectos. O resultado de uma indexação de ponteiros é um ''[[#Left-values|left-value]]''. Não é possível indexar ponteiros que designem funções.

Exemplo (acesso à posição 0 da zona de memória indicada por '''p'''): '''p[0]'''

=== Identidade e simétrico ===

Os operadores identidade ('''+''') e simétrico ('''-''') aplicam-se a inteiros e reais. Têm o mesmo significado que em análogo às operações correspondentes em C, mas operam sobre grandezas ternárias.

=== Reserva de memória ===

A expressão reserva de memória devolve o ponteiro que aponta para a zona de memória, na pilha da função actual, contendo espaço suficiente para o número de objectos indicados pelo seu argumento inteiro.

Exemplo (reserva vector com 5 reais, apontados por '''p'''): '''[real] p = [5]'''

=== Expressão de indicação de posição ===

O operador sufixo '''?''' aplica-se a ''left-values'', retornando o endereço (com o tipo ponteiro) correspondente.

Exemplo (indica o endereço de '''a'''): '''a?'''

=== Expressão de dimensão ===

O operador '''sizeof''' tem um único argumento e aplica-se a expressões, retornando a dimensão correspondente em bytes.

Exemplo: '''sizeof(a)''' (dimensão de '''a''').

= Exemplos e Testes =

Os exemplos abaixo não são exaustivos e não ilustram todos os aspectos da linguagem.

Estão ainda disponíveis outros [https://gitlab.rnl.tecnico.ulisboa.pt/leic-a-co26/eval/co26 pacotes de testes].

O seguinte exemplo ilustra um programa com dois módulos: um que define a função '''factorial''' e outro que define a função principal.

Definição da função '''factorial''' no ficheiro '''factorial.p6''':

<source lang="text">
public factorial(int n) -> int {
if (n > 1)
return n * factorial(n - 1);
else
return 1;
}
</source>

Exemplo da utilização da função '''factorial''' no ficheiro '''main.p6''':

<source lang="text">
// external builtin functions (non-P6)
extern int<> argc;
extern string<int> argv;
extern int<string> atoi;

// external user functions (P6)
forward int<int> factorial;

// the main function
begin
auto value = 1;
"Teste para a função factorial."!!
if (argc() == 2) {
string s = argv(1);
value = atoi(s);
}
value, "! é ", factorial(value)!!
return 0;
end
</source>

Como compilar:
<source lang="text">
p6 --target asm factorial.p6
p6 --target asm main.p6
yasm -felf32 factorial.asm
yasm -felf32 main.asm
ld -melf_i386 -o main factorial.o main.o -lrts
</source>

= Omissões e Erros =

Casos omissos e erros serão corrigidos em futuras versões do manual de referência.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category: Ensino]]

Compiladores/Pautas 2025-2026

2026-05-15T13:20:27Z

Root: /* Pautas do Projecto (época normal) */

{{TOCright}}
Além dos resultados de avaliação, as páginas das pautas contêm também os critérios de avaliação e aprovação.
* {{PautaAberta}} indica avaliação em curso
* {{PautaFechada}} indica avaliação terminada (classificações definitivas)
* {{ProvaPorRealizar}} indica avaliação prevista

== Pautas da Disciplina ==

* [[Compiladores/Pautas 2025-2026/Pauta Global da Disciplina|Pauta Global da Disciplina]] -- próxima avaliação: (ver Fénix)
* {{PautaAberta}} [[Compiladores/Pautas 2025-2026/Pauta das Aulas Práticas|Pauta das Aulas Práticas]] (época nornal)

== Pautas do Projecto (época normal) ==

* {{PautaAberta}} [[Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega "zero"|Pauta do Projecto: Entrega "zero"]]
* {{PautaAberta}} [[Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega Intermédia|Pauta do Projecto: Entrega Intermédia]]
* {{ProvaPorRealizar}} [[Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega Final|Pauta do Projecto: Entrega Final]]
* [[Compiladores/Pautas 2025-2026/Pauta Global do Projecto|Pauta Global do Projecto]]

[[category:Compiladores 2025-2026]]
[[category:Compiladores]]
[[category: Ensino]]

Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega Intermédia

2026-05-15T11:16:19Z

Root: /* Critérios de Avaliação */

{{PRJCompiladoreAvisosEN20252026}}
{{PRJCOMandatory20252026}}
{{TOCright}}

== Pauta ==
Aqui: https://bit.ly/co26-pautas (ver Fénix)

== Prazo de Revisão ==



A entrega intermédia pode ser revista até à data da entrega final do projecto.

== Critérios de Avaliação ==
'''LER COM ATENÇÃO'''

'''A entrega intermédia é obrigatória.'''

A entrega intermédia vale 6 valores em 20.

'''A avaliação é realizada sobre a versão existente no repositório no final do prazo para a entrega intermédia. Projectos que não apresentem alterações relevantes relativamente ao conteúdo inicial do repositório ou relativamente à entrega inicial não serão considerados.'''

A avaliação da entrega intermédia considera a execução de intervenções em várias regiões do código do compilador em desenvolvimento, assim como a gestão do projecto correspondente.

Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina. De forma semelhante, a reciclagem de código de compiladores exemplo deve ser feita criteriosamente, por forma a evitar inclusão de código errado ou inútil.

Estas condições são aplicáveis à data da entrega intermédia.

'''Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.'''

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #BDDD8D;" | '''VALORAÇÕES'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Existem '''6 valores''' (dos 20 disponíveis para o projecto) associados a esta entrega:

* '''gestão do projecto: 1 valor'''
** projecto com a estrutura correcta no repositório: '''0.5 valores''' (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório)
** projecto compila e produz compilador "p6" ("p6", com letras minúsculas: variações correspondem a "não compilação"): '''0.5 valores'''

'''Se o projecto compilar''', poderão ser atribuídos mais 5 valores (desenvolvimento do compilador), distribuídos como se segue:

* '''Flex (completo): 1.5 valores'''
** Tokens correspondentes aos símbolos e palavras-chave (simples ajuste do Simple/Tritak)
** Identificadores (simples ajuste do Simple/Tritak)
** Inteiros (a base 10 já está implementada no Simple/Tritak)
** Reais (extensão dos inteiros)
** Strings (extensão do Simple/Tritak)
** O Flex deve retornar os tokens ao byacc (sobre DEBUG, ver abaixo) -- o não retorno de tokens penaliza fortemente toda a componente Flex (ver penalizações)

* '''Bison (completo): 1 valor'''
** Regras correspondentes a literais de reais e strings (simples extensão do Simple/Tritak)
** Regras correspondentes a ciclos, etc. (simples extensão e adaptação do Simple/Tritak)
** Regras correspondentes a declarações de variáveis
** Regras correspondentes a declarações/definições de funções
** As acções correspondentes às regras definidas no Bison devem estar implementadas (simples criação de nós) -- a não implementação corresponde a penalizações (var abaixo)

* '''Nós (nodes) (completo): 1 valor'''
** Todos os nós necessários para a linguagem (utilizados na especificação Bison e em passos subsequentes) devem ser criados
** A não criação de nós motivada pela ausência de definição de acções no Bison é penalizada (ver abaixo)

* '''Semântica (visitors) ('''xml_writer''' completo; '''postfix_writer''' ver a seguir): 1.5 valores'''
** O "visitor" '''xml_writer''' deve estar completamente implementado (ver também DEBUG abaixo)
** O "visitor" '''type_checker''' deve ter todos os métodos (correspondentes aos nós, tal como o '''xml_writer'''), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
** O "visitor" '''postfix_writer''' deve ter todos os métodos (correspondentes aos nós, tal como o '''xml_writer'''), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
** Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (mesmo que não modificados numa primeira instância)
** A presença de implementações de semântica no '''postfix_writer''' (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega

|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #FFCC99;" | '''PENALIZAÇÕES'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Existem penalizações relativas à (deficiente) execução do projecto.

São considerados os seguintes aspectos preliminares:

# A linguagem do projecto contém a linguagem Simple, pelo que não há razão para não utilizar completamente o compilador Simple, eventualmente com pequenas alterações (including a passagem de binário para ternário).
# A semântica da linguagem do projecto contém a da linguagem Simple, pelo que a implementação de alguns aspectos da linguagem do projecto não requer qualquer reimplementação relativamente ao Simple.
# O compilador Simple foi fornecido completamente funcional, assim como a versão inicial do compilador do projecto no respositório (igual ao Simple e apenas alterado para ter o nome apropriado).
# A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples)
# O código dos métodos do visitor '''xml_writer''' corresponde a uma simples impressão dos atributos dos nós, através de uma travessia da árvore que formam e que os contém.
# O compilador é obrigatoriamente desenvolvido em C++.

Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:

* Destruição de funcionalidade do compilador Simple sem substituição por funcionalidade equivalente do compilador do projecto: '''4 valores'''
Não definição dos nós para regras Bison em avaliação (ver acima) ou não utilização de nós definidos para a escrita dessas acções: '''2 valores'''
* A utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras) terá uma '''penalização máxima de 1 valor'''
* Não utilização de qualquer material obrigatório: '''6 valores (e considera-se projecto não realizado)'''

|}

=== DEBUG ===

O despiste de problemas em especificações Flex pode ser realizado de forma simples utilizando os métodos descritos em [[The Flex Lexical Analyzer#How to Debug a Flex Specification|How to Debug a Flex Specification]].

O visitor '''xml_writer''' foi concebido para produzir uma representação textual hierárquica (árvore XML) correspondente ao programa em compilação.
É muito útil para inspeccionar a construção da árvore de nós por parte do Bison, permitindo, inclusivamente, a apresentação gráfica.

== Legenda ==
As questões relativas às colunas "Problemas" devem ser resolvidas quanto antes (nos horários de dúvidas ou, sendo possível, por correio electrónico).

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Problemas na análise lexical'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |
* .* - uso indevido do padrão
* chars - definição indevida (não existem na linguagem)
* comments - problemas com comentários (em excesso ou em falta)
* doubles - problemas com vírgula flutuante (definições incompletas)

* ids - problems com identificadores
* int - problemas com inteiros (definições incompletas ou excessivas)
* keywords - problemas com palavras-chave (a mais ou a menos)

* (bad) patterns - problemas genéricos com escrita de padrões lexicais
* string - problemas na definição de strings (composição, concatenação indevida, etc.)
* [outros] - casos específicos (contactar professor responsável)

|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Problemas na análise sintáctica'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |
* conflicts - conflitos no analisador LALR(1) (não avaliado nesta entrega)
* decls - problemas nas declarações (e.g. mistura com expressões ou com instruções)
* empty rules - regras sem semântica associada
* exprs - problemas nas expressões (em falta ou com inclusão de casos errados)
* calls - problemas nas chamadas a funções (e.g. não estão definidos como expressões)
* funcs - problemas (vários) nas definições de funções
* lvals - problemas na definição de left-values (e.g. ausência de definições ou incompletas)
* precs - problemas na definição de precedências (tipicamente, em excesso, deficientes, ou sem correspondência com o manual)
* precs* - problemas graves na definição de precedências (tipicamente, em excesso, deficientes, ou sem correspondência com o manual)
* tokens - problemas na definição de tokens (tipicamente, em excesso ou sem correspondência com o manual)
* read - problemas na definição da expressão de leitura (verificar manual de referência)
* semantics - problemas na definição de acções semânticas
* (simple) - contém apenas a definição original (linguagem Simple)
* strings - problemas na definção de cadeias de caracteres
* syntax - problemas na definição da gramática ou na semântica (nó) correspondente (verificar manual de referência)
* start - problemas na definição da raiz da árvore sintáctica (compiler->ast(...))
* [outras anotações] - casos específicos (contactar professor responsável)

|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Problemas na análise semântica e na geração de código (nós e XML)'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Nos nós:

* [outros nós] - nós com problemas (nós excedentários ou em falta ou com problemas na definição)
* [outras anotações] - casos específicos (contactar professor responsável)

No visitor '''xml_writer''':
* ast - o método "ast" do compilador não foi chamado no parser (.y), pelo que a AST está indefinida
* empty - métodos vazios ou funcionalmente vazios
* (incomp) - código incompleto
* [outras anotações] - casos específicos (contactar professor responsável)

|}

[[category:Compiladores 2025-2026]]
[[category:Compiladores]]
[[category:Ensino]]

Compiladores/Pautas 2025-2026/Pauta do Projecto: Entrega Intermédia

2026-05-15T11:14:49Z

Root: /* Critérios de Avaliação */

{{PRJCompiladoreAvisosEN20252026}}
{{PRJCOMandatory20252026}}
{{TOCright}}

== Pauta ==
Aqui: https://bit.ly/co26-pautas (ver Fénix)

== Prazo de Revisão ==



A entrega intermédia pode ser revista até à data da entrega final do projecto.

== Critérios de Avaliação ==
'''LER COM ATENÇÃO'''

'''A entrega intermédia é obrigatória.'''

A entrega intermédia vale 6 valores em 20.

'''A avaliação é realizada sobre a versão existente no repositório no final do prazo para a entrega intermédia. Projectos que não apresentem alterações relevantes relativamente ao conteúdo inicial do repositório ou relativamente à entrega inicial não serão considerados.'''

A avaliação da entrega intermédia considera a execução de intervenções em várias regiões do código do compilador em desenvolvimento, assim como a gestão do projecto correspondente.

Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina. De forma semelhante, a reciclagem de código de compiladores exemplo deve ser feita criteriosamente, por forma a evitar inclusão de código errado ou inútil.

Estas condições são aplicáveis à data da entrega intermédia.

'''Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.'''

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #BDDD8D;" | '''VALORAÇÕES'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Existem '''6 valores''' (dos 20 disponíveis para o projecto) associados a esta entrega:

* '''gestão do projecto: 1 valor'''
** projecto com a estrutura correcta no repositório: '''0.5 valores''' (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório)
** projecto compila e produz compilador "p6" ("p6", com letras minúsculas: variações correspondem a "não compilação"): '''0.5 valores'''

'''Se o projecto compilar''', poderão ser atribuídos mais 5 valores (desenvolvimento do compilador), distribuídos como se segue:

* '''Flex (completo): 1.5 valores'''
** Tokens correspondentes aos símbolos e palavras-chave (simples ajuste do Simple)
** Identificadores (simples ajuste do Simple/Tritak)
** Inteiros (a base 10 já está implementada no Simple/Tritak)
** Reais (extensão dos inteiros)
** Strings (extensão do Simple/Tritak)
** O Flex deve retornar os tokens ao byacc (sobre DEBUG, ver abaixo) -- o não retorno de tokens penaliza fortemente toda a componente Flex (ver penalizações)

* '''Bison (completo): 1 valor'''
** Regras correspondentes a literais de reais e strings (simples extensão do Simple/Tritak)
** Regras correspondentes a ciclos, etc. (simples extensão e adaptação do Simple/Tritak)
** Regras correspondentes a declarações de variáveis
** Regras correspondentes a declarações/definições de funções
** As acções correspondentes às regras definidas no Bison devem estar implementadas (simples criação de nós) -- a não implementação corresponde a penalizações (var abaixo)

* '''Nós (nodes) (completo): 1 valor'''
** Todos os nós necessários para a linguagem (utilizados na especificação Bison e em passos subsequentes) devem ser criados
** A não criação de nós motivada pela ausência de definição de acções no Bison é penalizada (ver abaixo)

* '''Semântica (visitors) ('''xml_writer''' completo; '''postfix_writer''' ver a seguir): 1.5 valores'''
** O "visitor" '''xml_writer''' deve estar completamente implementado (ver também DEBUG abaixo)
** O "visitor" '''type_checker''' deve ter todos os métodos (correspondentes aos nós, tal como o '''xml_writer'''), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
** O "visitor" '''postfix_writer''' deve ter todos os métodos (correspondentes aos nós, tal como o '''xml_writer'''), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
** Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (mesmo que não modificados numa primeira instância)
** A presença de implementações de semântica no '''postfix_writer''' (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega

|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #FFCC99;" | '''PENALIZAÇÕES'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Existem penalizações relativas à (deficiente) execução do projecto.

São considerados os seguintes aspectos preliminares:

# A linguagem do projecto contém a linguagem Simple, pelo que não há razão para não utilizar completamente o compilador Simple, eventualmente com pequenas alterações (including a passagem de binário para ternário).
# A semântica da linguagem do projecto contém a da linguagem Simple, pelo que a implementação de alguns aspectos da linguagem do projecto não requer qualquer reimplementação relativamente ao Simple.
# O compilador Simple foi fornecido completamente funcional, assim como a versão inicial do compilador do projecto no respositório (igual ao Simple e apenas alterado para ter o nome apropriado).
# A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples)
# O código dos métodos do visitor '''xml_writer''' corresponde a uma simples impressão dos atributos dos nós, através de uma travessia da árvore que formam e que os contém.
# O compilador é obrigatoriamente desenvolvido em C++.

Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:

* Destruição de funcionalidade do compilador Simple sem substituição por funcionalidade equivalente do compilador do projecto: '''4 valores'''
Não definição dos nós para regras Bison em avaliação (ver acima) ou não utilização de nós definidos para a escrita dessas acções: '''2 valores'''
* A utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras) terá uma '''penalização máxima de 1 valor'''
* Não utilização de qualquer material obrigatório: '''6 valores (e considera-se projecto não realizado)'''

|}

=== DEBUG ===

O despiste de problemas em especificações Flex pode ser realizado de forma simples utilizando os métodos descritos em [[The Flex Lexical Analyzer#How to Debug a Flex Specification|How to Debug a Flex Specification]].

O visitor '''xml_writer''' foi concebido para produzir uma representação textual hierárquica (árvore XML) correspondente ao programa em compilação.
É muito útil para inspeccionar a construção da árvore de nós por parte do Bison, permitindo, inclusivamente, a apresentação gráfica.

== Legenda ==
As questões relativas às colunas "Problemas" devem ser resolvidas quanto antes (nos horários de dúvidas ou, sendo possível, por correio electrónico).

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Problemas na análise lexical'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |
* .* - uso indevido do padrão
* chars - definição indevida (não existem na linguagem)
* comments - problemas com comentários (em excesso ou em falta)
* doubles - problemas com vírgula flutuante (definições incompletas)

* ids - problems com identificadores
* int - problemas com inteiros (definições incompletas ou excessivas)
* keywords - problemas com palavras-chave (a mais ou a menos)

* (bad) patterns - problemas genéricos com escrita de padrões lexicais
* string - problemas na definição de strings (composição, concatenação indevida, etc.)
* [outros] - casos específicos (contactar professor responsável)

|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Problemas na análise sintáctica'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |
* conflicts - conflitos no analisador LALR(1) (não avaliado nesta entrega)
* decls - problemas nas declarações (e.g. mistura com expressões ou com instruções)
* empty rules - regras sem semântica associada
* exprs - problemas nas expressões (em falta ou com inclusão de casos errados)
* calls - problemas nas chamadas a funções (e.g. não estão definidos como expressões)
* funcs - problemas (vários) nas definições de funções
* lvals - problemas na definição de left-values (e.g. ausência de definições ou incompletas)
* precs - problemas na definição de precedências (tipicamente, em excesso, deficientes, ou sem correspondência com o manual)
* precs* - problemas graves na definição de precedências (tipicamente, em excesso, deficientes, ou sem correspondência com o manual)
* tokens - problemas na definição de tokens (tipicamente, em excesso ou sem correspondência com o manual)
* read - problemas na definição da expressão de leitura (verificar manual de referência)
* semantics - problemas na definição de acções semânticas
* (simple) - contém apenas a definição original (linguagem Simple)
* strings - problemas na definção de cadeias de caracteres
* syntax - problemas na definição da gramática ou na semântica (nó) correspondente (verificar manual de referência)
* start - problemas na definição da raiz da árvore sintáctica (compiler->ast(...))
* [outras anotações] - casos específicos (contactar professor responsável)

|}

{| class="mw-collapsible mw-collapsed wikitable" align="right" style="border-style: solid; border-width: 1px; border-color: #bbbbaa; background: #f7f8ff;"
! style="padding-left:10px; padding-right:10px; border-style: solid; border-width: 0px; border-bottom-width: 0px; border-color: #bbbbaa; background: #d7d8ed;" | '''Problemas na análise semântica e na geração de código (nós e XML)'''
|-
! style="padding-left:10px; padding-right:10px; font-weight: normal; border-style: solid; border-width: 1px; border-color: #bbbbaa; " |

Nos nós:

* [outros nós] - nós com problemas (nós excedentários ou em falta ou com problemas na definição)
* [outras anotações] - casos específicos (contactar professor responsável)

No visitor '''xml_writer''':
* ast - o método "ast" do compilador não foi chamado no parser (.y), pelo que a AST está indefinida
* empty - métodos vazios ou funcionalmente vazios
* (incomp) - código incompleto
* [outras anotações] - casos específicos (contactar professor responsável)

|}

[[category:Compiladores 2025-2026]]
[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:36:16Z

Root:

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<syntaxhighlight lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</syntaxhighlight>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<syntaxhighlight lang="c++">
#pragma once
#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
</syntaxhighlight>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<syntaxhighlight lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</syntaxhighlight>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<syntaxhighlight lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</syntaxhighlight>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<syntaxhighlight lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</syntaxhighlight>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<syntaxhighlight lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</syntaxhighlight>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:35:57Z

Root: /* The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros */

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<source lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</source>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<syntaxhighlight lang="c++">
#pragma once
#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
</syntaxhighlight>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<syntaxhighlight lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</syntaxhighlight>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<syntaxhighlight lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</syntaxhighlight>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<syntaxhighlight lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</syntaxhighlight>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<syntaxhighlight lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</syntaxhighlight>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:35:44Z

Root: /* The ASSERT_UNSPEC macro */

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<source lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</source>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<syntaxhighlight lang="c++">
#pragma once
#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
</syntaxhighlight>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<syntaxhighlight lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</syntaxhighlight>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<source lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</source>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<syntaxhighlight lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</syntaxhighlight>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<syntaxhighlight lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</syntaxhighlight>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:35:24Z

Root: /* The C code generator */

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<source lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</source>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<syntaxhighlight lang="c++">
#pragma once
#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
</syntaxhighlight>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<source lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</source>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<source lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</source>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<syntaxhighlight lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</syntaxhighlight>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<syntaxhighlight lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</syntaxhighlight>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:35:10Z

Root: /* The type checking visitor */

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<source lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</source>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<syntaxhighlight lang="c++">
#pragma once
#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
</syntaxhighlight>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<source lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</source>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<source lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</source>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<syntaxhighlight lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</syntaxhighlight>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<source lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</source>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:34:54Z

Root: /* Symbol representation */

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<source lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</source>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<syntaxhighlight lang="c++">
#pragma once
#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
</syntaxhighlight>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<source lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</source>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<source lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</source>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<source lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</source>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<source lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</source>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis/The Tiny language: semantic analysis example and C generation

2026-05-14T17:34:26Z

Root: /* Gramática e Criação de Nós da Árvore Sintáctica Abstracta */

{{TOCright}}
Considere a seguinte gramárica (ε representa a produção nula), onde os operadores '''tWRITE''' (não associativo), '''=''' (associativo à direita) e '''+''' (associativo à esquerda) têm precedências crescentes.

O primeiro objectivo é escrever, utilizando as classes disponibilizadas na CDK (subclasses de cdk::basic_node), uma especificação YACC para a gramática dada, contendo as acções semânticas que permitem construir a árvore sintáctica.

O segundo objectivo é escrever os métodos de o tradutor para C (padrão de desenho Visitor) a árvore sintáctica anteriormente obtida. Esta tradução implica que os símbolos encontrados sejam recordados, para verificar futuras utilizações. Para tal, a classe '''tiny::symbol''' (que representa cada símbolo; esquematizado aqui e que se baseia no símbolo do compilador Simple) e a classe '''cdk::symbol_table''' serão utilizadas.
<source lang="text">
prog → decls exprs '.'
decls → ε | decls decl ';'
decl → tINT tID | tSTR tID init
init → ε | '=' tSTRING
exprs → expr | exprs ',' expr
expr → tINTEGER | tID | tID '=' expr | expr '+' expr | tWRITE expr
</source>

== Gramática e Criação de Nós da Árvore Sintáctica Abstracta ==

In the answer to this exercise, we will consider the node tree defined as shown below (in a YACC-like syntax). Note that careful attention must be given to the choices between '''cdk::nil_node''' nodes and '''nullptr''' (null pointers) (these can be tested for performing special/exceptional actions, while Nil nodes are more useful when tests are undesirable and uniform behavior on the part of the code generator is desired).

We follow the same nomenclature used in the Simple compiler: '''LINE''' is a macro corresponding to the source line and all nodes are either CDK nodes or derived from them (as in Simple).

Completing (and, possibly, correcting) the following code, so that it runs, is left as an exercise.
{{CollapsedCode|File tiny.y|
<syntaxhighlight lang="c++">
%{
#include <algorithm>
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include "ast/all.h"
%}
%parse-param {std::shared_ptr<cdk::compiler> compiler}
%union {
//--- don't change *any* of these: if you do, you'll break the compiler.
YYSTYPE() : type(cdk::primitive_type::create(0, cdk::TYPE_VOID)) {}
~YYSTYPE() {}
YYSTYPE(const YYSTYPE &other) { *this = other; }
YYSTYPE& operator=(const YYSTYPE &other) { type = other.type; return *this; }
std::shared_ptr<cdk::basic_type> type; /* expression type */
//-- don't change *any* of these --- END!

int i;
std::string *s;
cdk::basic_node *n;
cdk::expression_node *e;
}
%token tINT tSTR tWRITE
%token tINTEGER
%token<s> tID tSTRING
%type<e> expr init
%type<n> prog decls exprs decl
%%
prog: decls exprs '.' { $$ = new program_node(LINE, $1, $2); }

decls: /* empty */ { $$ = new cdk::nil_node(LINE); }
| decls decl ';' { $$ = new cdk::sequence_node(LINE, $2, $1); }
;

decl: tINT tID {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_INT), *$2, nullptr);
delete $2;
}
| tSTR tID init {
$$ = new declaration_node(LINE, cdk::primitive_type::create(4, cdk::TYPE_STRING), *$2, $3);
delete $2;
}
;

init: /* empty */ { $$ = nullptr; /* must match the last argument in declaration_node */ }
| '=' tSTRING { $$ = new cdk::string_node(LINE, $2); }
;

exprs: expr { $$ = new cdk::sequence_node(LINE, $1); }
| exprs ',' expr { $$ = new cdk::sequence_node(LINE, $3, $1); }
;

expr: tINTEGER { $$ = new cdk::integer_node(LINE, $1); }
| tID { $$ = new cdk::rvalue_node(LINE, new cdk::variable_node(LINE, *$1)); delete $1; }
| tID '=' expr { $$ = new cdk::assignment_node(LINE, new cdk::variable_node(LINE, *$1), $3); delete $1; }
| expr '+' expr { $$ = new cdk::add_node(LINE, $1, $3); }
| tWRITE expr { $$ = new write_node(LINE, $2); }
;
</syntaxhighlight>
}}

In this code we assume that each declaration node contains two attributes: an integer, representing the declaration's type; a node, representing the identifier being declared; and an optional expression ('''nullptr''' if that is the case), representing the initial value of the variable being declared. Likewise, assignment nodes have two children: an identifier, corresponding to the left-value; and the expression to be assigned. Write nodes have a single child (the expression to be printed) (note that, in this simple grammar, write nodes are also integer expressions). The program node (the main node) has two children: a node containing declarations and another containing expressions.

The other nodes are as described in the CDK.

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h|
<source lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny

#endif
</source>
}}

== Type Checking ==

The type checking visitor class could process the whole AST in one go, tagging all types and possible errors. Then, in a following step, the code generator would use this information without further use of a type checker. While this favors a step-by-step processing of the AST, it mandates the full implementation of the type checking visitor (i.e., all methods would have to be non-empty). The approach shown in this example, however, can be use partially implemented visitors, since it only needs to provide implementations for the nodes that have types to be checked. In this approach, the code generator creates a type checker ''whenever'' it needs to perform a check.

=== The ASSERT_UNSPEC macro ===
The type checker avoids visiting the same nodes by testing (initial assertion) whether it has done so before.
<source lang="c">
#define ASSERT_UNSPEC { \
if (node->type() != nullptr && !node->is_typed(cdk::TYPE_UNSPEC)) \
return; \
}
</source>

Note that the use of this macro is restricted to visits to nodes that have a type, i.e., expressions.

=== The CHECK_TYPES and ASSERT_SAFE_EXPRESSIONS macros ===

The code generator may use the following macros at the start of a visit method, to ensure that the expressions present in a node are safe to use, i.e., that they are semantically consistent.

<source lang="c">
#define CHECK_TYPES(compiler, symtab, node) { \
try { \
tiny::type_checker checker(compiler, symtab, this); \
(node)->accept(&checker, 0); \
} \
catch (const std::string &problem) { \
std::cerr << (node)->lineno() << ": " << problem << std::endl; \
return; \
} \
}

#define ASSERT_SAFE_EXPRESSIONS CHECK_TYPES(_compiler, _symtab, node)
</source>

=== The type checking visitor ===
{{CollapsedCode|File type_checker.cpp|
<source lang="c++">
void tiny::type_checker::do_declaration_node(declaration_node *const node, int lvl) {
std::string &id = node->identifier();
auto symbol = tiny::make_symbol(node->type(), id, 0);
if (!_symtab.insert(id, symbol))
throw id + " redeclared";

if (node->initializer()) {
node->initializer()->accept(this, lvl+2);
if (node->type() != node->initializer()->type())
throw std::string("wrong type for initializer");
}

_parent->set_new_symbol(symbol);
}

void tiny::type_checker::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_UNSPEC;
node->type(cdk::primitive_type::create(4, cdk::TYPE_STRING));
}

void tiny::type_checker::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_UNSPEC;
const std::string &id = node->name();
auto symbol = _symtab.find(id);
if (!symbol) throw id + " undeclared";
node->type(symbol->type());
}

void tiny::type_checker::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_UNSPEC;
node->lvalue()->accept(this, lvl+4);
node->rvalue()->accept(this, lvl+4);
if (node->lvalue()->type() != node->rvalue()->type())
throw std::string("wrong types in assignment");
node->type(node->lvalue()->type());
}

void tiny::type_checker::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_UNSPEC;

node->left()->accept(this, lvl+2);
if (!node->left()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (left)");

node->right()->accept(this, lvl+2);
if (!node->right()->is_typed(cdk::TYPE_INT))
throw std::string("integer expression expected in add operator (right)");

node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}

void tiny::type_checker::do_write_node(write_node *const node, int lvl) {
ASSERT_UNSPEC;
node->argument()->accept(this, lvl+2);
if (!(node->argument()->is_typed(cdk::TYPE_INT) || node->argument()->is_typed(cdk::TYPE_STRING)))
throw std::string("wrong type in write expression");
node->type(cdk::primitive_type::create(4, cdk::TYPE_INT));
}
</source>
}}

== Code Generation ==

The following code presents just the bare minimum for defining the code generation visitors (the omitted parts are as in Simple).

=== The C code generator ===
{{CollapsedCode|File c_writer.cpp|
<source lang="c++">
void tiny::c_writer::do_program_node(program_node *const node, int lvl) {
os() << "int main() {\n";
node->declarations()->accept(this, lvl+2);
node->expressions()->accept(this, lvl+2);
os() << " return 0;\n}\n";
}

void tiny::c_writer::do_sequence_node(cdk::sequence_node *const node, int lvl) {
for (size_t i = 0; i < node->size(); i++) {
os() << std::string(lvl+2, ' ');
node->node(i)->accept(this, lvl);
os() << ";\n";
}
}

void tiny::c_writer::do_declaration_node(declaration_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
std::string &id = node->identifier();
if (new_symbol() != nullptr) {
os() << std::string(lvl+2, ' ');
if (node->is_typed(cdk::TYPE_INT)) os() << "int " << id;
else os() << "char *" << id;
if (node->initializer()) os() << " = \"" << *node->initializer() << "\"";
reset_new_symbol();
}
}

void tiny::c_writer::do_integer_node(cdk::integer_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_string_node(cdk::string_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->value();
}

void tiny::c_writer::do_variable_node(cdk::variable_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
os() << node->name();
}

void tiny::c_writer::do_assignment_node(cdk::assignment_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->lvalue()->accept(this, lvl);
os() << " = ";
node->rvalue()->accept(this, lvl);
}

void tiny::c_writer::do_add_node(cdk::add_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
node->left()->accept(this, lvl);
os() << " + ";
node->right()->accept(this, lvl);
}

void tiny::c_writer::do_write_node(write_node *const node, int lvl) {
ASSERT_SAFE_EXPRESSIONS;
if (node->argument()->is_typed(cdk::TYPE_INT)) {
os() << "printf(\"%d\\n\", ";
node->argument()->accept(this, lvl+2);
os() << ")";
}
else {
os() << "printf(\"%s\\n\", \"";
node->argument()->accept(this, lvl+2);
os() << "\")";
}
}
</source>
}}

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:32:28Z

Root: /* Class cdk::tensor_type */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::balanced3_type ===
{{CollapsedCode|File balanced3_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <string>
#include <cdk/types/basic_type.h>
#include <cdk/types/treg_value.h>
#include <cdk/types/treg_alu.h>

namespace cdk {

/**
* Balanced ternary integer type (40-trit, stored as treg_t).
*
* Usage in the scanner / parser:
* balanced3_type::value_type *v = new balanced3_type::value_type(42);
* // ... in parser: new balanced3_node(LINE, *$1); delete $1;
*/
struct balanced3_type : public basic_type {

struct value_type : public treg_value {

/** Zero (all trits zero = bias in each half). */
value_type() { treg_alu::clear(*this); }

/** From raw halves. */
value_type(uint64_t h0, uint64_t h1, uint64_t h2) { set_half(0, h0); set_half(1, h1); set_half(2, h2); }

/**
* From integer — the primary scanner constructor.
* Converts a C integer to 40-trit balanced ternary via the ALU.
*/
explicit value_type(int val) : value_type(static_cast<long long>(val)) {}
explicit value_type(long long val) {
treg_alu::load_int(*this, val);
}

/** Back to integer (Horner's method, 40 trits). */
long long to_int64() const {
return treg_alu::store_int(*this);
}

int to_int() const {
long long v = to_int64();
if (v > 2147483647LL) return 2147483647;
if (v < -2147483648LL) return -2147483648;
return static_cast<int>(v);
}

/** Decimal string representation of the integer value. */
std::string to_string() const {
return treg_alu::balanced3_to_string(*this);
}

bool operator==(const value_type &o) const {
return half(0) == o.half(0) && half(1) == o.half(1) && half(2) == o.half(2);
}
bool operator!=(const value_type &o) const { return !(*this == o); }
};

public:

explicit balanced3_type(explicit_call_disabled) :
basic_type(8, TYPE_BALANCED3) { // packed: single uint64_t (40 trits)
}

~balanced3_type() = default;

public:

static auto create() {
return std::make_shared<balanced3_type>(explicit_call_disabled());
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<balanced3_type>(type);
}

public:

std::string to_string() const override { return "balanced3"; }

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::posit3_type ===
{{CollapsedCode|File posit3_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/basic_type.h>
#include <cdk/types/treg_value.h>
#include <cdk/types/treg_alu.h>

namespace cdk {

/**
* Logarithmic ternary posit real type (80-trit, stored as treg_t).
*
* The value_type wraps treg_value, exposing constructors for the
* scanner to create values from decimal string literals:
*
* auto *v = new posit3_type::value_type("3.14");
* // in parser: new posit3_node(LINE, *$1); delete $1;
*/
struct posit3_type : public basic_type {

struct value_type : public treg_value {

/** Zero. */
value_type() { treg_alu::clear(*this); }

/** From raw halves. */
value_type(uint64_t h0, uint64_t h1, uint64_t h2) { set_half(0, h0); set_half(1, h1); set_half(2, h2); }

/**
* From decimal string — the primary scanner constructor.
* Parses the string and converts to 80-trit logarithmic posit
* entirely via balanced ternary arithmetic (no floating-point).
*/
explicit value_type(const char *s) {
treg_alu::load_posit3(*this, s);
}

/** From balanced3 integer value. */
explicit value_type(const balanced3_type::value_type &b3) {
treg_alu::load_posit3_from_balanced3(*this, b3);
}

/** Decimal string representation of the real value. */
std::string to_string() const {
return treg_alu::posit3_to_string(*this);
}

bool operator==(const value_type &o) const {
return half(0) == o.half(0) && half(1) == o.half(1) && half(2) == o.half(2);
}
bool operator!=(const value_type &o) const { return !(*this == o); }
};

public:

explicit posit3_type(explicit_call_disabled) :
basic_type(16, TYPE_POSIT3) {
// packed: two uint64_t halves (80 trits)
}

~posit3_type() = default;

public:

static auto create() {
return std::make_shared<posit3_type>(explicit_call_disabled());
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<posit3_type>(type);
}

public:

std::string to_string() const override { return "posit3"; }

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::takum3_type ===
{{CollapsedCode|File takum3_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/basic_type.h>
#include <cdk/types/treg_value.h>
#include <cdk/types/treg_alu.h>

namespace cdk {

/**
* Logarithmic ternary takum real type (80-trit, stored as treg_t).
*
* Hunhold Definition 2 (2024) adapted for balanced ternary with base 3.
* Fixed 2-trit regime field; variable characteristic and mantissa.
*/
struct takum3_type : public basic_type {

struct value_type : public treg_value {

/** Zero. */
value_type() { treg_alu::clear(*this); }

/** From raw halves. */
value_type(uint64_t h0, uint64_t h1, uint64_t h2) { set_half(0, h0); set_half(1, h1); set_half(2, h2); }

/**
* From decimal string — the primary scanner constructor.
* Parses the string and converts to 80-trit logarithmic takum
* entirely via balanced ternary arithmetic (no floating-point).
*/
explicit value_type(const char *s) {
treg_alu::load_takum3(*this, s);
}

/** From balanced3 integer value. */
explicit value_type(const balanced3_type::value_type &b3) {
treg_alu::load_takum3_from_balanced3(*this, b3);
}

/** Decimal string representation of the real value. */
std::string to_string() const {
return treg_alu::takum3_to_string(*this);
}

bool operator==(const value_type &o) const {
return half(0) == o.half(0) && half(1) == o.half(1) && half(2) == o.half(2);
}
bool operator!=(const value_type &o) const { return !(*this == o); }
};

public:

explicit takum3_type(explicit_call_disabled) :
basic_type(16, TYPE_TAKUM3) {
}

~takum3_type() = default;

public:

static auto create() {
return std::make_shared<takum3_type>(explicit_call_disabled());
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<takum3_type>(type);
}

public:

std::string to_string() const override { return "takum3"; }

};

} // cdk
</syntaxhighlight>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<syntaxhighlight lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>
#include <cdk/types/balanced3_type.h>
#include <cdk/types/posit3_type.h>
#include <cdk/types/takum3_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</syntaxhighlight>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|
<syntaxhighlight lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</syntaxhighlight>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:29:07Z

Root: /* The Symbol Table */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<syntaxhighlight lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>
#include <cdk/types/balanced3_type.h>
#include <cdk/types/posit3_type.h>
#include <cdk/types/takum3_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</syntaxhighlight>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|
<syntaxhighlight lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</syntaxhighlight>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:28:27Z

Root: /* Convenience functions for handling types */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<syntaxhighlight lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>
#include <cdk/types/balanced3_type.h>
#include <cdk/types/posit3_type.h>
#include <cdk/types/takum3_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</syntaxhighlight>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:27:21Z

Root: /* Representing and Manipulating Types */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<syntaxhighlight lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</syntaxhighlight>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:26:11Z

Root: /* Class cdk::lvalue_node */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:25:23Z

Root: /* Class cdk::expression_node */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<source lang="c++">
#ifndef __CDK15_LVALUE_NODE_H__
#define __CDK15_LVALUE_NODE_H__

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:24:52Z

Root: /* Class cdk::typed_node */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<source lang="c++">
#ifndef __CDK15_AST_EXPRESSIONNODE_NODE_H__
#define __CDK15_AST_EXPRESSIONNODE_NODE_H__

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<source lang="c++">
#ifndef __CDK15_LVALUE_NODE_H__
#define __CDK15_LVALUE_NODE_H__

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:24:03Z

Root: /* Class cdk::primitive_type */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<source lang="c++">
#ifndef __CDK15_AST_TYPEDNODE_NODE_H__
#define __CDK15_AST_TYPEDNODE_NODE_H__

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<source lang="c++">
#ifndef __CDK15_AST_EXPRESSIONNODE_NODE_H__
#define __CDK15_AST_EXPRESSIONNODE_NODE_H__

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<source lang="c++">
#ifndef __CDK15_LVALUE_NODE_H__
#define __CDK15_LVALUE_NODE_H__

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:23:43Z

Root: /* Class cdk::basic_type */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<source lang="c++">
#ifndef __CDK15_AST_TYPEDNODE_NODE_H__
#define __CDK15_AST_TYPEDNODE_NODE_H__

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<source lang="c++">
#ifndef __CDK15_AST_EXPRESSIONNODE_NODE_H__
#define __CDK15_AST_EXPRESSIONNODE_NODE_H__

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<source lang="c++">
#ifndef __CDK15_LVALUE_NODE_H__
#define __CDK15_LVALUE_NODE_H__

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</syntaxhighlight>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</source>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:23:22Z

Root: /* Symbol representation */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<source lang="c++">
#ifndef __CDK15_AST_TYPEDNODE_NODE_H__
#define __CDK15_AST_TYPEDNODE_NODE_H__

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<source lang="c++">
#ifndef __CDK15_AST_EXPRESSIONNODE_NODE_H__
#define __CDK15_AST_EXPRESSIONNODE_NODE_H__

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<source lang="c++">
#ifndef __CDK15_LVALUE_NODE_H__
#define __CDK15_LVALUE_NODE_H__

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</source>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</source>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<syntaxhighlight lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</syntaxhighlight>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

Semantic Analysis

2026-05-14T17:22:56Z

Root: /* Class cdk::functional_type */

{{NAVCompiladores}}
{{TOCright}}

Semantic analysis is mostly concerned with types associated with language objects and how these types are used by the language constructs that depend on them, such as functions and arithmetic operators.

Types can be implicitly specified (e.g., in literals) and inferred (e.g., from operations). This is the case of languages such as Python and other scripting languages, able to make type inference at run time. It can also in languages such as C++ ('''auto''') and Java ('''var'''), that make type inference at compile time.

On the other hand, typed entities may be explicitly declared. This is how most statically compiled languages work: the program's entities are explicitly typed and types may be verified by the compiler.

This section focuses on type checking, based on the abstract syntax tree's nodes, specifically those that declare typed entities (declarations of typed program entities, such as functions and variables), and those that use those entities (functions and operators). The entities themselves, of course, must remember their own types, so that they may require compliance.

== Representing Typed Information in the AST ==

Type information is present in the AST itself. This information may be directly set by the parser, during syntactic analysis, e.g. in declarations, or it may be set -- the most usual way -- during semantic analysis.

The main nodes involved in representing types are the following:

* '''typed_node''' -- this is the superclass of any node that bears a type. It also provides a convenient interface for checking and managing types.
* '''expression_node''' -- this is a subclass of '''typed_node''' that represents program expressions, that is, any value that can be used by a program. Expressions may be primitive, e.g. literals, or composed by other expressions, e.g. operators.
* '''lvalue_node''' -- left-values denote the write-compatible memory locations, these are not the usual values denoted by expression nodes, although any left-value can be converted into an expression, either by considering the memory address it represents (a pointer), or the value at that location ('''rvalue_node'''). Left-values are usually known as variables:'''variable_node''', in the simplest case; '''index_node''' (for instance) in a more elaborate one.
* Other cases of typed nodes correspond, in certain languages, to function and variable declarations.

=== Class cdk::typed_node ===

{{CollapsedCode|File typed_node.h|
<source lang="c++">
#ifndef __CDK15_AST_TYPEDNODE_NODE_H__
#define __CDK15_AST_TYPEDNODE_NODE_H__

#include <cdk/ast/basic_node.h>
#include <cdk/types/types.h>
#include <memory>

namespace cdk {

/**
* Typed nodes store a type description.
*/
class typed_node: public basic_node {
protected:
// This must be a pointer, so that we can anchor a dynamic
// object and be able to change/delete it afterwards.
std::shared_ptr<basic_type> _type;

public:
/**
* @param lineno the source code line number corresponding to
* the node
*/
typed_node(int lineno) :
basic_node(lineno), _type(nullptr) {
}

std::shared_ptr<basic_type> type() {
return _type;
}
void type(std::shared_ptr<basic_type> type) {
_type = type;
}

bool is_typed(typename_type name) const {
return _type->name() == name;
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::expression_node ===

{{CollapsedCode|File expression_node.h|
<source lang="c++">
#ifndef __CDK15_AST_EXPRESSIONNODE_NODE_H__
#define __CDK15_AST_EXPRESSIONNODE_NODE_H__

#include <cdk/ast/typed_node.h>

namespace cdk {

/**
* Expressions are typed nodes that have a value.
*/
class expression_node: public typed_node {

protected:
/**
* @param lineno the source code line corresponding to the node
*/
expression_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Class cdk::lvalue_node ===

{{CollapsedCode|File lvalue_node.h|
<source lang="c++">
#ifndef __CDK15_LVALUE_NODE_H__
#define __CDK15_LVALUE_NODE_H__

#include <cdk/ast/typed_node.h>
#include <string>

namespace cdk {

/**
* Class for describing syntactic tree leaves for lvalues.
*/
class lvalue_node: public typed_node {
protected:
lvalue_node(int lineno) :
typed_node(lineno) {
}

};

} // cdk

#endif
</source>
}}

=== Declarations and definitions ===
Declarations and definitions can be seen as typed nodes since they declare entities that bear types. The precise definition of these nodes depends on the language and, thus, the nodes are not provided by the CDK. In general, though, they all have to be able to store one or more names (the entity or entities) being declared/defined (variables, functions, and so on) and, possibly, other information (e.g., access qualifiers).

== Representing and Manipulating Types ==

Types are used to characterize the memory used by the various language entities (described by one or more AST nodes).

Types should not be confused with AST nodes.

The CDK has four base definitions. They are, in general, sufficient for most languages, and are easily extended.

* '''basic_type''' -- this is the abstract superclass. It is used mostly to refer to unknown or general types.
* '''primitive_type''' -- this class is used to represent any "atomic" data type (that is, unstructured or non-reference types).
* '''reference_type''' -- this class is used to describe reference/pointer types.
* '''structured_type''' -- this class allows for the definition of complex (i.e., hierarchical) data types: it is suitable for describing tuples or structures/classes.
* '''functional_type''' -- this class allows for the definition of types for function objects: it is suitable for describing input/output types for functions.
* '''tensor_type''' -- this class allows for the definition of types for tensor objects (multidimensional arrays).

=== Class cdk::basic_type ===
In addition to providing a base representation for all type references, it also provides two operators for comparing any two types.
{{CollapsedCode|File basic_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cstdlib>
#include <memory>
#include <string>

namespace cdk {

/** This class represents a general type concept. */
class basic_type {
size_t _size = 0; // in bytes
typename_type _name = TYPE_UNSPEC;

protected:
struct explicit_call_disabled {};

protected:

basic_type() : _size(0), _name(TYPE_UNSPEC) { }
basic_type(size_t size, typename_type name) : _size(size), _name(name) { }

virtual ~basic_type() noexcept = 0;

public:
size_t size() const { return _size; }
typename_type name() const { return _name; }

public:
virtual std::string to_string() const = 0;
};

inline bool operator==(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return t1->size() == t2->size() && t1->name() == t2->name();
}
inline bool operator!=(const std::shared_ptr<basic_type> t1, const std::shared_ptr<basic_type> t2) {
return !(t1 == t2);
}

} // cdk
</source>
}}

=== Class cdk::primitive_type ===
{{CollapsedCode|File primitive_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/typename_type.h>
#include <cdk/types/basic_type.h>
#include <cstdlib>

namespace cdk {

/** Primitive (i.e., non-structured non-indirect) types. */
class primitive_type: public basic_type {
public:
explicit primitive_type(explicit_call_disabled, size_t size, typename_type name) :
basic_type(size, name) {
}

~primitive_type() = default;

public:
static auto create(size_t size, typename_type name) {
return std::make_shared<primitive_type>(explicit_call_disabled(), size, name);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<primitive_type>(type);
}

public:
std::string to_string() const {
if (name() == TYPE_INT) return "integer";
if (name() == TYPE_DOUBLE) return "double";
if (name() == TYPE_STRING) return "string";
if (name() == TYPE_VOID) return "void";
return "UNKNOWN-TYPE:" + std::to_string(name());
}

};

} // cdk
</source>
}}

=== Class cdk::reference_type ===
{{CollapsedCode|File reference_type.h|
<source lang="c++">
#pragma once

#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a reference type concept (such as a C pointer or a C++ reference). */
struct reference_type: public basic_type {
std::shared_ptr<basic_type> _referenced = nullptr;

public:
explicit reference_type(explicit_call_disabled, size_t size, std::shared_ptr<basic_type> referenced) :
basic_type(size, TYPE_POINTER), _referenced(referenced) {
}

~reference_type() = default;

std::shared_ptr<basic_type> referenced() const { return _referenced; }

public:
std::string to_string() const { return "@" + _referenced->to_string(); }

public:

static auto create(size_t size, std::shared_ptr<basic_type> referenced) {
return std::make_shared<reference_type>(explicit_call_disabled(), size, referenced);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<reference_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::structured_type ===
{{CollapsedCode|File structured_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

/** This class represents a structured type concept. */
class structured_type: public basic_type {
std::vector<std::shared_ptr<basic_type>> _components;

private:
size_t compute_size(const std::vector<std::shared_ptr<basic_type>> &components) {
size_t size = 0;
for (auto component : components)
size += component->size();
return size;
}

public:
explicit structured_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &components) :
basic_type(compute_size(components), TYPE_STRUCT), _components(components) {
// EMPTY
}

~structured_type() = default;

public:
std::shared_ptr<basic_type> component(size_t ix) { return _components[ix]; }
const std::vector<std::shared_ptr<basic_type>>& components() const { return _components; }
size_t length() const { return _components.size(); }

public:
std::string to_string() const {
std::string result = "<";
return std::accumulate(_components.begin(), _components.end(), result,
[] (auto a, auto b) { return a + "," + b->to_string(); });
}

public:

static auto create(const std::vector<std::shared_ptr<basic_type>> &types) {
return std::make_shared<structured_type>(explicit_call_disabled(), types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<structured_type>(type);
}

};

} // cdk
</source>
}}

=== Class cdk::functional_type ===
{{CollapsedCode|File functional_type.h|
<syntaxhighlight lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>
#include <cdk/types/structured_type.h>

namespace cdk {

/** This class represents a functional type concept. */
class functional_type: public basic_type {
std::shared_ptr<structured_type> _input;
std::shared_ptr<structured_type> _output;

public:
// size 4 is because this is actually just a pointer
explicit functional_type(explicit_call_disabled, const std::vector<std::shared_ptr<basic_type>> &input,
const std::vector<std::shared_ptr<basic_type>> &output) :
basic_type(4, TYPE_FUNCTIONAL), _input(structured_type::create(input)), _output(structured_type::create(output)) {
// EMPTY
}

~functional_type() = default;

public:
std::shared_ptr<basic_type> input(size_t ix) { return _input->component(ix); }
const std::shared_ptr<structured_type> &input() const { return _input; }
size_t input_length() const { return _input->length(); }
std::shared_ptr<basic_type> output(size_t ix) { return _output->component(ix); }
const std::shared_ptr<structured_type> &output() const { return _output; }
size_t output_length() const { return _output->length(); }

public:
std::string to_string() const { return _input->to_string() + ":" + _output->to_string(); }

public:
static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::vector<std::shared_ptr<basic_type>> &output_types) {
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &input_types,
const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::vector<std::shared_ptr<basic_type>> &output_types) {
std::vector<std::shared_ptr<basic_type>> input_types;
return std::make_shared<functional_type>(explicit_call_disabled(), input_types, output_types);
}

static auto create(const std::shared_ptr<basic_type> &output_type) {
std::vector<std::shared_ptr<basic_type>> output_types = { output_type };
return create(output_types);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<functional_type>(type);
}

};

} // cdk
</syntaxhighlight>
}}

=== Class cdk::tensor_type ===
{{CollapsedCode|File tensor_type.h|
<source lang="c++">
#pragma once

#include <vector>
#include <numeric>
#include <cdk/types/basic_type.h>

namespace cdk {

class tensor_type: public basic_type {
std::vector<size_t> _dims;

public:

// size 4 is because this is actually just a pointer
explicit tensor_type(explicit_call_disabled, const std::vector<size_t> &dims) :
basic_type(4, TYPE_TENSOR), _dims(dims) {
// EMPTY
}

~tensor_type() = default;

public:
size_t dim(size_t ix) const { return _dims.at(ix); }
const std::vector<size_t> &dims() const { return _dims; }
size_t n_dims() const { return _dims.size(); }

size_t size() const {
size_t size = 0;
if (_dims.size() >= 1) size = _dims.at(0);
for (size_t ix = 1; ix < _dims.size(); ix++)
size *= _dims.at(ix);
return size;
}

public:
std::string to_string() const {
std::string s = "[";
if (_dims.size() >= 1) s += std::to_string(_dims.at(0));
for (size_t ix = 1; ix < _dims.size(); ix++)
s += ',' + std::to_string(_dims.at(ix));
return s + "]";
}

public:

static auto create(const std::vector<size_t> &dims) {
return std::make_shared<tensor_type>(explicit_call_disabled(), dims);
}

static auto cast(std::shared_ptr<basic_type> type) {
return std::dynamic_pointer_cast<tensor_type>(type);
}

};

} // cdk
</source>
}}

=== Convenience functions for handling types ===
The following functions are provided for convenience: they allow for writing clearer code.

Implementations have been omitted for the sake of clarity (they are available in the CDK).
{{CollapsedCode|File types.h|
<source lang="c++">
#pragma once
#include <memory>
#include <cdk/types/basic_type.h>
#include <cdk/types/primitive_type.h>
#include <cdk/types/reference_type.h>
#include <cdk/types/structured_type.h>
#include <cdk/types/functional_type.h>
#include <cdk/types/tensor_type.h>

namespace cdk {

inline std::string to_string(std::shared_ptr<basic_type> type) {
return type->to_string();
}

} // cdk
</source>
}}

== The Symbol Table ==

A interface pública da tabela de símbolos é a seguinte (foram omitidas todas as partes não públicas, assim como os métodos de construção/destruição):

* '''push''' - create a new context and make it current.
* '''pop''' - destroy the current context: the previous context becomes the current one. If the first context is reached no operation is performed.
* '''insert''' - define a new identifier in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if this is a new identifier (may shadow another defined in an upper context). Returns false if the identifier already exists in the current context.
* '''replace_local''' - replace the data corresponding to a symbol in the current context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''replace''' - replace the data corresponding to a symbol (look for the symbol in all available contexts, starting with the innermost one): ''name'' is the symbol's name; ''symbol'' is the symbol. Returns true if the symbol exists; false if the symbol does not exist in any of the contexts.
* '''find_local''' - search for a symbol in the local (current) context: ''name'' is the symbol's name; ''symbol'' is the symbol. Returns the symbol if it exists; and nullptr if the symbol does not exist in the current context.
* '''find''' - search for a symbol in the avaible contexts, starting with the first one and proceeding until reaching the outermost context. ''name'' is the symbol's name; from how many contexts up from the current one (zero). Returns nullptr if the symbol cannot be found in any of the contexts; or, the symbol and corresponding attributes.

{{CollapsedCode|File symbol_table.h (interface summary)|

<source lang="c++">
namespace cdk {

template<typename Symbol>
class symbol_table {
public:
void push();

void pop();

bool insert(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace_local(const std::string &name, std::shared_ptr<Symbol> symbol);

bool replace(const std::string &name, std::shared_ptr<Symbol> symbol);

std::shared_ptr<Symbol> find_local(const std::string &name);

std::shared_ptr<Symbol> find(const std::string &name, size_t from = 0) const;

};
</source>
}}

== Symbol representation ==

Symbols describe named program entities and store their properties. They provide support for the semantic processor: declarations create new symbols. Expressions and left-values refer to those symbols.

A simple representation in this case could be done in the following way. Note that this definition is just an example and contains only minimal information. It should be extended to account for the needs of the language being implemented.

{{CollapsedCode|File symbol.h (Tiny language)|
<source lang="c++">
#ifndef __TINY_TARGETS_SYMBOL_H__
#define __TINY_TARGETS_SYMBOL_H__

#include <string>
#include <memory>
#include <cdk/types/basic_type.h>

namespace tiny {

class symbol {
std::string _name; // identifier
std::shared_ptr<cdk::basic_type> _type; // type (type id + type size)
public:
// constructors, destructor, getters, etc.

public:
// critical for type checking (interface similar to that of class cdk::typed_node)
std::shared_ptr<cdk::basic_type> type() const { return _type; }
void set_type(std::shared_ptr<cdk::basic_type> t) { _type = t; }
bool is_typed(cdk::typename_type name) const { return _type->name() == name; }
};

// this function simplifies symbol creation in the type_checker visitor (see below)
inline auto make_symbol(const std::string &name, std::shared_ptr<cdk::basic_type> type, /* rest of ctor args */) {
return std::make_shared<symbol>(name, type, /* rest of ctor args */);
}

} // tiny
#endif
</source>
}}

== Type Checking: Using Visitors ==

Type checking is the process of verifying whether the types used in the various language constructs are appropriate. It can be performed at compile time (static type checking) or at run time.

The type checking discussed here is the static approach, i.e., checking whether the types used for objects and the operations that manipulate them at compile time are consistent.

In the approach followed by CDK-based compilers, code generation is carried out by visitors that are responsible for traversing the abstract syntax tree and generate, evaluating each node. Node evaluation may depend on the specificities of the data types being manipulated, the simplest of which is the data type's size, important in all memory-related operations.

== Vídeo Explicativo ==
O vídeo seguinte explica os tópicos apresentados nesta página (aplicação a várias linguagens).

* Linguagem UDF (2024/2025): https://www.youtube.com/watch?v=x9uJ_Wn6360

== Examples ==
=== Type checking example: the Tiny language ===

The following example considers a simple grammar and performs the whole of the semantic analysis process and, finally, generates the corresponding C code. The semantic analysis process must account for variables (they must be declared before they can be used) and for their types (all types must be used correctly).

* [[Semantic Analysis/The Tiny language: semantic analysis example and C generation|The Tiny language: semantic analysis example and C generation]]

=== Type checking example: the Simple language ===

The following example considers an evolution of Compact, called Simple. Where Compact forces some verification via syntactic analysis (thus, presenting low flexibility), Simple has a richer grammar and, consequently, admits constructions that may not be correct in what concerns types of operators, functions, and their arguments. Type checking in this case is built-in, since, without it, it would be impossible to guarantee the correctness of any expression.

* [[Semantic Analysis/The Simple language: semantic analysis|The Simple language: semantic analysis]]


== Exercises ==

* [[Semantic Analysis/Exercise 01|Exercise 01]] - The "Let" language

[[category:Compiladores]]
[[category:Ensino]]

File:XYc.jpg

2026-05-11T15:27:33Z

Root: Root uploaded a new version of File:XYc.jpg

File:RXb2.jpg

2026-05-11T15:18:59Z

Root: Root uploaded a new version of File:RXb2.jpg

File:RXb1.jpg

2026-05-11T15:10:54Z

Root: Root uploaded a new version of File:RXb1.jpg

File:AM2.jpg

2026-05-11T14:46:03Z

Root: Root uploaded a new version of File:AM2.jpg

File:AM1.jpg

2026-05-11T14:45:21Z

Root: Root uploaded a new version of File:AM1.jpg

Bottom-Up Parsing/Exercise 14: LALR(1)

2026-05-11T13:35:17Z

Root: /* Solução */

== Problema ==

Consider the following grammar, where A is the initial symbol and '''{ x, y, z }''' is the set of terminal symbols:
<source lang="text">
A → M z x | z M x | z x z
M → y | ε
</source>
# Compute the set of LALR(1) states for the grammar. Build the corresponding LALR(1) parse table.
# Compact the parse table, eliminating and propagating reductions.
# Show the parsing process for input '''zyx''' (including the actions/gotos and the input and stack states). In case of conflict, assume YACC's behavior.

== Solução ==

Na imagem, os conflitos indicados para a regra 2 são para a regra 5.

Note-se que a solução apresentada é para SLR(1) e LALR(1) (a vermelho).

{{CollapsedCode|Solução completa|
[[Image:Mzx1.jpg|768px]]
}}

[[category:Compiladores]]
[[category: Ensino]]

File:Mzx1.jpg

2026-05-11T13:32:06Z

Root: Root uploaded a new version of File:Mzx1.jpg

File:Librts7-202605092235.tar.bz2

2026-05-09T21:48:22Z

Root:

Compiladores/Projecto de Compiladores/Material de Apoio ao Desenvolvimento

2026-05-09T21:48:07Z

Root:

{{PRJHEADER}}
{{TOCright}}

== Material de Apoio ==

O projecto, escrito em C++, deve ser desenvolvido considerando os princípios de desenvolvimento de compiladores, assim como os da boa programação com objectos e os aspectos de arquitectura dos padrões de desenho aplicáveis. Notar que esta tarefa está implicitamente facilitada pelo material de apoio, que condiciona o desenvolvimento do compilador.

O código presente nas bibliotecas de apoio (já instalado na máquina virtual) ao desenvolvimento do projecto é de uso obrigatório:

* CDK [[media:libcdk21-202605092235.tar.bz2]] - código de base para o desenvolvimento do compilador
* RTS [[media:librts7-202605092235.tar.bz2]] - código de base para os programas gerados pelo compilador (runtime)

{{CVSCode|Notar que o [[Compiladores/Projecto de Compiladores/Repositório GIT|repositório GIT]] já contém uma versão do projecto a desenvolver. Isto significa que ''antes'' de se começar a programar, o projecto deve ser obtido a partir do repositório.}}

== Pacotes binários para instalação ==

O manterial de apoio está disponível para instalação directa (não é necessário compilar) através do repositório:
* https://download.opensuse.org/repositories/home:/d4vid:/co26/openSUSE_Tumbleweed/

Este repositório pode ser adicionado a um openSUSE previamente instalado através do comando:

<nowiki>zypper ar https://download.opensuse.org/repositories/home:/d4vid:/co26/openSUSE_Tumbleweed/ CO26</nowiki>
<nowiki>zypper refresh</nowiki>

Uma vez adicionado o repositório, os pacotes acima podem ser instalados através dos comandos:

zypper install libcdk21-devel librts7-devel

{{Suggestion|Este material já está instalado na [[Compiladores/Projecto de Compiladores/Máquina Virtual|máquina virtual da disciplina]].}}

[[category:Projecto de Compiladores|P]]
[[category:Compiladores|P]]
[[category:Ensino|P]]

File:Libcdk21-202605092235.tar.bz2

2026-05-09T21:47:36Z

Root:

Template:PRJCOMandatory20252026

2026-05-09T21:45:07Z

Root:

{{CDKRTS|CDK21|libcdk21-202605092235.tar.bz2|RTS7|librts7-202605092235.tar.bz2}}

Compiladores/Projecto de Compiladores/Projecto 2025-2026/Manual de Referência da Linguagem P6

2026-05-07T15:44:02Z

Root: /* Declaração */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}


'''ÉPOCA NORMAL'''

'''P6''' é uma linguagem imperativa. Este manual apresenta de forma intuitiva as características da linguagem: [[#Tipos de Dados|tipos de dados]]; [[#Manipulação de Nomes|manipulação de nomes]]; [[#Convenções Lexicais|convenções lexicais]]; [[#Gramática|estrutura/sintaxe]]; [[#Funções|especificação das funções]]; [[#Instruções|semântica das instruções]]; [[#Expressões|semântica das expressões]]; e, finalmente, [[#Exemplos|alguns exemplos]].

= Tipos de Dados =

A linguagem é fracamente tipificada (são efectuadas algumas conversões implícitas). Existem 4 tipos de dados básicos, apenas alguns dos quais são compatíveis com a [https://en.wikipedia.org/wiki/C_(programming_language) linguagem C]. O alinhamento em memória binária é sempre a 32 bits. Note-se que alguns dos tipos de dados são ternários e devem ser manipulados com as funções das ALUs disponibilizadas.

* Tipos numéricos: os inteiros são [https://en.wikipedia.org/wiki/Balanced_ternary ternários equilibrados], ocupam 40 trits (empacotados em 64 bits); os reais são ternários e estão representados no formato [https://arxiv.org/abs/2404.18603 Takum] (note-se que a definição neste artigo é para uma representação binária e não é exactamente a que é implementada pelas ALUs ternárias em uso no projecto), ocupam 80 trits (empacotados em 128 bits).
* As cadeias de caracteres são vectores de caracteres binários terminados por [https://en.wikipedia.org/wiki/ASCII ASCII] NUL (carácter com o valor zero). Variáveis e literais deste tipo só podem ser utilizados em atribuições, impressões, ou como argumentos/retornos de funções. Os caracteres são valores de 8 bits não directamente manipuláveis.
* Os ponteiros representam endereços de objectos (de qualquer tipo) e ocupam 32 bits. Podem ser objecto de operações aritméticas (deslocamentos) e permitem aceder ao valor apontado. Note-se que não é possível usar inteiros ternários directamente em aritmética de ponteiros (têm de ser convertidos para isso).

Os tipos suportados por cada operador e a operação a realizar são indicados na [[#Expressões|definição das expressões]].

Existem ainda tipos associado a valores funcionais, i.e., tipos que descrevem a interface de funções (ver abaixo). Os valores em memória associados a estes tipos são efectivamente ponteiros, mas para funções e não para dados, podendo ser usados para invocar as funções correspondentes. Estes identificadores não podem ser usados como variáveis (e.g., passados como argumentos de outras funções, etc.).

= Manipulação de Nomes =

Os nomes (identificadores) correspondem a variáveis e funções. Nos pontos que se seguem, usa-se o termo entidade para as designar indiscriminadamente, explicitando-se quando a descrição for válida apenas para um dos casos. Existem ainda nomes para funções externas à linguagem P6. Tanto em P6, como em C, os nomes das funções referem directamente a posição do código dessas funções (à la C; ver '''extern''' abaixo).

== Espaço de nomes e visibilidade dos identificadores ==

O espaço de nomes global é único, pelo que um nome utilizado para designar uma entidade num dado contexto não pode ser utilizado para designar outras (ainda que de natureza diferente).

Os identificadores são visíveis desde a declaração até ao fim do alcance: ficheiro (globais) ou bloco (locais). A reutilização de identificadores em contextos inferiores encobre declarações em contextos superiores: redeclarações locais podem encobrir as globais até ao fim de um bloco. É possível utilizar símbolos globais nos contextos dos blocos das funções, mas não é possível declará-los (ver [[#Símbolos globais|símbolos globais]]).

== Validade das variáveis ==

As entidades globais (declaradas fora de qualquer função), existem durante toda a execução do programa. As variáveis locais a uma função existem apenas durante a sua execução. Os argumentos formais são válidos enquanto a função está activa.

= Convenções Lexicais =

Para cada grupo de elementos lexicais (tokens), considera-se a maior sequência de caracteres constituindo um elemento válido. Assim, por exemplo, a designação '''>=''' é sempre um único elemento lexical (por oposição à situação ilegal de se terem dois símbolos: '''>''' seguido de '''=''').

== Caracteres brancos ==

São considerados separadores e não representam nenhum elemento lexical: '''mudança de linha''' ASCII LF ('''0x0A''', '''\n'''), '''recuo do carreto''' ASCII CR ('''0x0D''', '''\r'''), '''espaço''' ASCII SP ('''0x20''', ⌴) e '''tabulação horizontal''' ASCII HT ('''0x09''', '''\t''').

== Comentários ==

Existem dois tipos de comentários, que também funcionam como elementos separadores:

* '''explicativos''' -- começam com '''//''' e acabam no fim da linha; e
* '''operacionais''' -- começam com '''/*''' e terminam com '''*/''', podendo estar aninhados.

Se as sequências de início fizerem parte de uma cadeia de caracteres, não iniciam um comentário (ver [[#Cadeias de caracteres|definição das cadeias de caracteres]]).

== Palavras-chave ==

As seguintes palavras-chave são reservadas, não constituindo identificadores (devem ser escritas exactamente como indicado):

* tipos: '''int real string void'''
* declarações: '''extern forward public auto'''
* instruções: '''if elif else while stop next return'''
* expressões: '''input null sizeof'''
* outras: '''begin end'''

== Tipos ==

Os seguintes elementos lexicais designam tipos em declarações (ver gramática): '''int''' (inteiro), '''real''' (real), '''string''' (cadeia de caracteres).

Os tipos correspondentes a ponteiros são outros tipos delimitados por '''[''' e ''']''', designando uma indirecção e não o objecto directo (ver gramática).

Note-se que, quando se tem uma declaração '''extern''', os tipos correspondem aos compatíveis com a linguagem C na mesma arquitectura ix86 de 32 bits, i.e., '''int''' corresponde a um número binário inteiro em [https://en.wikipedia.org/wiki/Two%27s_complement complemento para 2] (32 bits), '''real''' coresponde a uma representação segundo a norma [https://en.wikipedia.org/wiki/IEEE_754 IEEE 754] de dupla precisão (64 bits), devendo ser convertidos de e para os tipos nativos da linguage P6 sempre que necessário (ver RTS).

== Operadores de expressões ==

São considerados operadores os elementos lexicais apresentados na definição das expressões.

== Delimitadores e terminadores ==

Os seguintes elementos lexicais são delimitadores/terminadores:
* ''',''' (vírgula)
* ''';''' (ponto e vírgula)
* '''!''' e '''!!''' (operações de impressão)
* '''(''' e ''')''' (delimitadores de expressões)
* '''{''' e '''}''' (delimitadores de blocos)

== Identificadores (nomes) ==

São iniciados por uma letra, seguindo-se 0 (zero) ou mais letras ou dígitos. O comprimento do nome é ilimitado e dois nomes são distintos se houver alteração de maiúscula para minúscula, ou vice-versa, de pelo menos um carácter.

== Literais ==

São notações para valores constantes de alguns tipos da linguagem (não confundir com constantes, i.e., identificadores que, em algumas linguagens, designam elementos cujo valor não pode ser alterado durante a execução do programa).

=== Inteiros ===

Um literal inteiro é um número não negativo (mas ver a seguir). Números negativos podem ser construídos pela aplicação do operador de negação unária ('''-''') a um literal (sempre positivo).

Literais inteiros decimais são constituídos por sequências de 1 (um) ou mais dígitos de '''0''' a '''9''', em que o primeiro digito não é 0 (zero), excepto no caso do número 0 (zero). Neste caso, é composto apenas pelo dígito 0 (zero) (em qualquer base).

Literais inteiros em base 9 começam sempre pelo dígito 0 (zero), sendo seguidos de um ou mais dígitos de '''0''' a '''8''' (note-se que '''09''' é um literal inválido em base 9). Exemplo: '''086 = 78'''.

Literais inteiros em base 3 (equilibrada) começam sempre com a sequência '''0t''', seguida de um ou mais símbolos dessa base: '''-''' (valor '''-1'''), '''0''' (valor '''0''') e '''+''' (valor '''1'''). Estes literais podem ser intrinsecamente negativos. Exemplos: '''0t+0-0 = 24'''; '''0t-0+0 = -24'''

Se não for possível representar um literal na máquina, devido a overflow, deverá ser gerado um erro lexical.

=== Reais em formato Takum3 ===

Os literais reais (sempre positivos) são expressos tal como em C (exclusivamente em base 10).

Não existem literais negativos (números negativos resultam da operação unária '''-''').

Note-se que um literal sem '''.''' (ponto decimal) nem parte exponencial é do tipo inteiro.

Note-se que, apesar de C normalmente usar uma representação interna em binário no formato IEEE 754, a linguagem P6 usa um formato, representado em ternário, completamente diferente (embora a forma de escrita dos literais seja a mesma).

Exemplos: '''3.14''', '''1E3''' = 1000 (número inteiro representado como real). '''12.34e-24''' = 12.34 x 10-24 (notação cientifica).


=== Cadeias de caracteres ===

As cadeias de caracteres são delimitadas por aspas ('''"''') e podem conter quaisquer caracteres, excepto ASCII NUL (0x00) e ASCII LF (0x0A). Nas cadeias, os delimitadores de comentários não têm significado especial. Se for escrito um literal que contenha '''\0''', então a cadeia termina nessa posição. Exemplo: '''ab\0xy''' tem o mesmo significado que '''ab'''.

É possível designar caracteres por sequências especiais (iniciadas por '''\'''), especialmente úteis quando não existe representação gráfica directa. As sequências especiais correspondem aos caracteres ASCII HT, LF e CR ('''\t''', '''\n''' e '''\r''', respectivamente), aspa ('''\"'''). ''backslash'' ('''\\'''), ou a quaisquer outros especificados através de 1 a 3 dígitos em base 8, designando valores de 8 bits (e.g., '''\012''' ou apenas '''\12''' se o carácter seguinte não representar um dígito em base 8). Exemplo: '''xy\012z''' tem o mesmo significado que '''xy\12z''' e que '''xy\nz'''.

Elementos lexicais distintos que representem duas ou mais cadeias consecutivas são representadas na linguagem como uma única cadeia que resulta da concatenação. Exemplo: '''"ab"''' '''"cd"''' é o mesmo que '''"abcd"'''.

=== Ponteiros ===

O único literal admissível para ponteiros corresponde ao ponteiro nulo e é indicado pela palavra-chave '''null'''. Este literal é compatível com todos os tipos de ponteiro. Os inteiros não são convertíveis em ponteiros, pelo que o valor '''0''' (zero) não é um valor inicial admissível para ponteiros.

Note-se que a aritmética de ponteiros é possível apenas com inteiros binários, mas não com inteiros ternários (estes devem ser convertidos para binário, caso seja necessário).

= Gramática =

A gramática da linguagem está resumida abaixo. Considerou-se que os elementos em tipo fixo são literais, que os parênteses curvos agrupam elementos, que elementos alternativos são separados por uma barra vertical, que elementos opcionais estão entre parênteses rectos, que os elementos que se repetem zero ou mais vezes estão entre <math>\langle</math> e <math>\rangle</math>. Alguns elementos usados na gramática também são elementos da linguagem descrita se representados em tipo fixo (e.g., parênteses).

{|
! style="width: 140px; font-weight: normal;" | ''ficheiro''
! style="width: 50px; font-weight: normal;" | <math>\rightarrow</math>
| <math>\langle</math> ''declaração'' <math>\rangle</math> [ ''programa-principal'' ]
|-
! style="width: 150px; font-weight: normal;" | ''declaração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''tipo'' ''identificador'' [ '''=''' ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] [ '''auto''' ] ''identificador'' '''=''' ''expressão'' ''';'''
|-
! style="width: 150px; font-weight: normal;" | ''programa-principal''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''begin''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''end'''
|-
! style="width: 50px; font-weight: normal;" | ''função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| [ ''qualificador'' ] ''identificador'' '''(''' ''variáveis'' ''')''' '''->''' ''tipo'' ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''variáveis''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''variável'' <math>\langle</math> ''',''' ''variável'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''tipo''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''int''' <math>|</math> '''real''' <math>|</math> '''string''' <math>|</math> '''void''' <math>|</math> '''[''' ''tipo'' ''']''' <math>|</math> ''tipo-de-função''
|-
! style="width: 50px; font-weight: normal;" | ''tipo-de-função''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' '''>'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' '''<''' ''tipos'' '''>'''
|-
! style="width: 50px; font-weight: normal;" | ''tipos''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''tipo'' <math>\langle</math> ''',''' ''tipo'' <math>\rangle</math>
|-
! style="width: 50px; font-weight: normal;" | ''bloco''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''{''' <math>\langle</math> ''declaração'' <math>\rangle</math> <math>\langle</math> ''instrução'' <math>\rangle</math> '''}'''
|-
! style="width: 50px; font-weight: normal;" | ''instrução''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' ''';''' <math>|</math> ''expressões'' '''!''' <math>|</math> ''expressões'' '''!!'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''stop''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''next''' [ ''literal-inteiro'' ] ''';''' <math>|</math> '''return''' [ ''expressão'' ] ''';'''
|-
! style="width: 50px; font-weight: normal;" |
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''instrução-condicional'' <math>|</math> ''instrução-de-iteração'' <math>|</math> ''bloco''
|-
! style="width: 50px; font-weight: normal;" | ''instrução-condicional''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''if''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\langle</math> '''elif''' '''(''' ''expressão'' ''')''' ''instrução'' <math>\rangle</math> [ '''else''' ''instrução'' ]
|-
! style="width: 50px; font-weight: normal;" | ''instrução-de-iteração''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| '''while''' '''(''' ''expressão'' ''')''' ''instrução''
|-
! style="width: 50px; font-weight: normal;" | ''expressões''
! style="width: 50px; font-weight: normal;" |<math>\rightarrow</math>
| ''expressão'' <math>\langle</math> ''',''' ''expressão'' <math>\rangle</math>
|}

== Tipos, identificadores, literais e definição de expressões ==

Algumas definições foram omitidas da gramática: tipos de dados. qualificadores e variável (ver [[#Declarações de variáveis|declarações de variáveis]]), identificador (ver [[#Identificadores (nomes)|identificadores]]), literal (ver [[#Literais|literais]]); expressão (ver [[#Expressões|expressões]]). 

Quanto a tipos de dados, '''int''' designa valores inteiros, '''real''' designa valores reais, '''string''' designa cadeias de caracteres. Os ponteiros são tipos compostos por um tipo entre parênteses rectos, e.g., '''[int]'''.

Os tipos funcionais são definidos a partir dos tipos de dados anteriormente descritos e do tipo especial '''void''' (ver a seguir). O tipo é indicado com o formato indicado na gramática, i.e., tipo de retorno seguido dos tipos dos argumentos (zero ou mais separados por vírgulas). Estes tipos servem para declarar símbolos de função sem as definir.


O tipo '''void''' apenas pode ser usado para indicar a ausência de retorno ou para declarar um ponteiro genérico. Neste caso, o aninhamento é irrelevante, i.e., '''[void]''' e '''<nowiki>[[[void]]]</nowiki>''' são equivalentes. Um ponteiro deste tipo é compatível com todos os outros tipos de ponteiros. A aritmética de ponteiros decrementa/incrementa em uma unidade o valor de um ponteiro do tipo '''[void]'''.

== Left-values ==

Os ''left-values'' são posições de memória que podem ser modificadas (excepto onde proibido pelo tipo de dados). Os elementos de uma expressão que podem ser utilizados como left-values encontram-se individualmente identificados na semântica das expressões.

== Ficheiros ==

Um ficheiro é designado por principal se contiver a função principal (onde se inicia o programa).

== Declaração de variáveis ==

Uma declaração de variável indica sempre um tipo de dados (implícito ou explícito) e um identificador.

Exemplos:

* Inteiro: '''int i'''
* Real: '''real r'''
* Cadeia de caracteres: '''string s'''
* Ponteiro para inteiro: '''[int] p1''' (semelhante a '''int*''' em C)
* Ponteiro para real: '''[real] p2''' (semelhante a '''double*''' em C)
* Ponteiro para cadeia de caracteres: '''[string] p3''' (semelhante a '''char**''' em C)
* Ponteiro para ponteiro para inteiro: '''<nowiki>[[int]]</nowiki> p4''' (semelhante a '''int**''' em C)

É possível usar o pseudo-tipo '''auto''' se a declaração tiver um valor inicial: neste caso, o tipo é o do valor inicial.

Exemplo:

* Variável inteira: '''auto i = 1'''
* Variável real: '''auto f = 2.0'''
* etc.

== Símbolos globais ==

Por omissão, os símbolos são privados a um módulo, não podendo ser importados por outros módulos.

A palavra-chave '''public''' permite declarar um identificador como público, tornando-o acessível a partir de outros módulos. Quando usado com a palavra-chave '''auto''', esta é opcional. Note-se que a declaração de uma variável tem de ter sempre, ou o qualificador, ou o tipo, podendo estar ambos presentes.

A palavra-chave '''forward''' permite declarar num módulo variáveis ou funções definidas noutros módulos. Neste caso, não pode ser especificado o valor inicial das variáveis, pelo que não é possível o uso de '''auto''' em conjunto com '''forward'''.

A palavra-chave '''extern''' deve ser usada para declarar símbolos de função com tipos diferentes dos dos nativos da da linguagem P6, e.g. para importar funções definidas em C. Além de poderem ser usados para chamar as funções que designam, os símbolos assim declarados podem ser utilizados com valores convertidos de forma apropriada.

Exemplos:
* Declarar variável privada ao módulo: '''real r1 = 22.0'''
* Declarar variável pública: '''public real r2 = 7.0'''
* Declarar variável pública: '''public auto r2 = 7.0''' (igual à anterior)
* Declarar variável pública: '''public r2 = 7.0''' (igual à anterior)
* Usar definição externa de variável pública: '''forward real r2'''
* Declarar função (nativa P6) definida externamente: '''forward int<int> factorial'''
* Declarar função definida noutra linguagem (e.g. em C): '''extern [void]<int> malloc'''

== Inicialização ==

Quando existe, é a designação do objecto que segue o símbolo '''=''': inteiro, real, cadeia de caracteres, ou ponteiro. Entidades reais podem ser inicializadas por expressões inteiras (conversão implícita). A expressão de inicialização deve ser um literal se a variável for global.

A palavra '''auto''' pode ser usada em lugar do tipo para declarar uma variável. Quando usada, o tipo da variável é inferido a partir do valor inicial (nestes casos, o valor inicial é obrigatório).

Exemplos:
* Inteiro (literal): '''int i = 3'''
* Inteiro (expressão): '''int i = j + 1'''
* Real (literal): '''real r = 3.2'''
* Real (expressão): '''real r = i - 2.5'''
* Cadeia de caracteres (literal): '''string s = "olá"'''
* Cadeia de caracteres (literais): '''string s = "olá" "mãe"'''
* Ponteiro (literal): '''<nowiki>[[[real]]] p</nowiki> = null'''
* Ponteiro (expressão): '''[int] p = q + 1'''


= Funções =

Uma função permite agrupar um conjunto de instruções num corpo, executado com base num conjunto de parâmetros (os argumentos formais), quando é invocada a partir de uma expressão.

== Declaração ==

As funções têm um nome que é também o endereço dessa função. O tipo de retorno de uma função que não produz valores de retorno é '''void'''.

As funções que recebam argumentos devem indicá-los no cabeçalho. Funções sem argumentos definem um cabeçalho vazio. Os qualificadores de exportação/importação '''public''' ou '''forward''' (ver símbolos globais) podem ser aplicados às funções, mas não é possível aplicá-los às declarações dos argumentos de uma função. Não é possível especificar valores por omissão para os argumentos de uma função, nem para o valor de retorno.

A declaração de um ponteiro para uma função (ou, de forma equivalente, do seu nome) é utilizada para caracterizar um identificador exterior ou para efectuar declarações antecipadas (utilizadas para pré-declarar funções que sejam usadas antes de ser definidas, por exemplo, entre duas funções mutuamente recursivas). 

== Invocação ==

Uma função pode ser invocada através do seu nome. 
Se existirem argumentos, na invocação da função, o nome é seguido de uma lista de expressões delimitadas por parênteses curvos. Esta lista é uma sequência, possivelmente vazia, de expressões separadas por vírgulas. O número e tipo de parâmetros actuais deve ser igual ao número e tipo dos parâmetros formais da função invocada (a menos de conversões implícitas). A ordem dos parâmetros actuais deverá ser a mesma dos argumentos formais da função a ser invocada.

De acordo com a convenção Cdecl, a função chamadora coloca os argumentos na pilha e é responsável pela sua remoção, após o retorno da chamada. Assim, os parâmetros actuais devem ser colocados na pilha pela ordem inversa da sua declaração (i.e., são avaliados da direita para a esquerda antes da invocação da função e o resultado passado por cópia/valor). O endereço de retorno é colocado no topo da pilha pela chamada à função. Note que o retorno de entidades com dimensão superior a 64 bits deve fazer-se através da reserva de espaço para o retorno no chamador e passando um ponteiro para esse espaço como primeiro argumento do chamado.

== Corpo ==

O corpo de uma função consiste num bloco que contém declarações (opcionais) seguidas de instruções (opcionais). Não é possível aplicar os qualificadores de exportação ('''public''') ou de importação ('''forward''' ou '''extern''') (ver [[#Símbolos globais|símbolos globais]]) dentro do corpo de uma função.

Uma instrução '''return''' causa a interrupção da função. O valor devolvido por uma função, através de expressão usada como argumento da instrução '''return''', deve ser do tipo declarado no cabeçalho da função. Ver casos especiais acima.

É um erro especificar um valor de retorno se a função for declarada como não retornando um valor (indicada como '''void''').

Qualquer bloco (usado, por exemplo, numa instrução condicional ou de iteração) pode definir variáveis locais. 

== Função principal e execução de programas ==

Um programa é a sequência de instruções que seguem as declarações globais num ficheiro, delimitadas pelas palavras-chave '''begin''' e '''end'''. Esta sequência forma o que em algumas linguagens se chama a função principal. Os argumentos com que o programa foi chamado podem ser obtidos através de funções '''argc''' (devolve o número de argumentos); '''argv''' (devolve o n-ésimo argumento como uma cadeia de caracteres, com n>0); e '''envp''' (devolve a n-ésima variável de ambiente como uma cadeia de caracteres, com n>0). Apenas um dos módulos do programa pode definir a função principal, i.e., se existirem vários módulos, apenas um deles pode conter mais do que declarações de variáveis globais.

extern int<> argc
extern string<int> argv
extern string<int> envp

O valor de retorno da função principal é devolvido ao ambiente que invocou o programa. Este valor de retorno segue as seguintes regras (sistema operativo): 0 (zero), execução sem erros; 1 (um), argumentos inválidos (em número ou valor); 2 (dois), erro de execução. Os valores superiores a 128 indicam que o programa terminou com um sinal. Em geral, para correcto funcionamento, os programas devem devolver 0 (zero) se a execução foi bem-sucedida e um valor diferente de 0 (zero) em caso de erro.

A biblioteca de run-time (RTS) contém informação sobre outras funções de suporte disponíveis, incluindo chamadas ao sistema (ver também o manual da RTS).

= Instruções =

Excepto quando indicado, as instruções são executadas em sequência.

== Blocos ==

Cada bloco tem uma zona de declarações de variáveis locais (facultativa), seguida por uma zona com instruções (possivelmente vazia). Não é possível definir funções dentro de blocos, mas é possível declarar ponteiros de função locais.

A visibilidade das variáveis é limitada ao bloco em que foram declaradas. As entidades declaradas podem ser directamente utilizadas em sub-blocos ou passadas como argumentos para funções chamadas dentro do bloco. Caso os identificadores usados para definir as variáveis locais já estejam a ser utilizados para definir outras entidades ao alcance do bloco, o novo identificador passa a referir uma nova entidade definida no bloco até que ele termine (a entidade previamente definida continua a existir, mas não pode ser directamente referida pelo seu nome). Esta regra é também válida relativamente a
argumentos de funções (ver corpo das funções).

== Instrução condicional ==

Esta instrução tem comportamento semelhante ao da instrução '''if-else''' em C. As partes correspondentes a '''elif''' comportam-se como encadeamentos de instruções condicionais na parte '''else''' de um '''if-else''' à la C.

== Instrução de iteração ==

Esta instrução tem comportamento idêntico ao da instrução '''while''' em C.

== Instrução de terminação ==

A instrução '''stop''' termina o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''break''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de continuação ==

A instrução '''next''' reinicia o n-ésimo ciclo mais interior em que a instrução se encontrar (quando o argumento é omitido, assume-se '''n=1'''), tal como a instrução '''continue''' em C. Esta instrução só pode existir dentro de um ciclo, sendo a última instrução do seu bloco.

{{Suggestion|Note-se que, tal como na restante aritmética de ponteiros, o valor inteiro, neste caso, corresponde a uma entidade binária com 32 bits.}}

== Instrução de retorno ==

A instrução '''return''', se existir, é a última instrução do seu bloco. Ver comportamento na [[#Corpo|descrição do corpo de uma função]].

== Expressões como instruções ==

As expressões utilizadas como instruções são sempre avaliadas, mesmo que não produzam efeitos secundários.

== Instruções de impressão ==

As notações '''!''' e '''!!''' podem ser utilizadas para apresentar valores na saída do programa. A primeira forma apresenta os valores sem mudar de linha; a segunda forma apresenta os valores mudando de linha depois de os apresentar a todos. Quando existe mais de uma expressão, as várias expressões são apresentadas sem separação. Valores numéricos (inteiros ou reais) são impressos em decimal. As cadeias de caracteres são impressas na codificação nativa. Ponteiros não podem ser impressos.

= Expressões =

Uma expressão é uma representação algébrica de uma quantidade: todas as expressões têm um tipo e devolvem um valor.

Existem [[#Expressões primitivas|expressões primitivas]] e expressões que resultam da [[#Expressões resultantes de avaliação de operadores|avaliação de operadores]].

A tabela seguinte apresenta as precedências relativas dos operadores: é a mesma para operadores na mesma linha, sendo as linhas seguintes de menor prioridade que as anteriores. A maioria dos operadores segue a semântica da linguagem C (excepto onde explicitamente indicado). Tal como em C, os valores lógicos são 0 (zero) (valor falso), e diferente de zero (valor verdadeiro).

{|
| '''Tipo de Expressão'''
| '''Operadores'''
| '''Associatividade'''
| '''Operandos'''
| '''Semântica'''
|-
| primária
| '''( ) [ ]'''
| não associativos
| -
| [[#Parênteses curvos|parênteses curvos]], [[#Indexação|indexação]], [[#Reserva de memória|reserva de memória]]
|-
| unária
| '''+ - ?'''
| não associativos
| -
| [[#Identidade e simétrico|identidade e simétrico]], [[#Expressão de indicação de posição|indicação de posição]]
|-
! style="vertical-align: top; font-weight: normal;" | "não" lógico
! style="vertical-align: top; font-weight: normal;" | '''~'''
! style="vertical-align: top; font-weight: normal;" | não associativo
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: negação
|-
! style="vertical-align: top; font-weight: normal;" | multiplicativa
! style="vertical-align: top; font-weight: normal;" | '''* / %'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | aditiva
! style="vertical-align: top; font-weight: normal;" | '''+ -'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C (% é apenas para inteiros), mas para entidades ternárias: se envolverem ponteiros, calculam: (i) deslocamentos, i.e., um dos operandos deve ser do tipo ponteiro e o outro do tipo inteiro (binário de 32 bits); (ii) diferenças de ponteiros, i.e., apenas quando se aplica o operador '''-''' a dois ponteiros do mesmo tipo (o resultado é o número de objectos do tipo apontado entre eles, representado como um valor inteiro ternário de 64 bits). Se a memória não for contígua, o resultado é indefinido.
|-
! style="vertical-align: top; font-weight: normal;" | comparativa
! style="vertical-align: top; font-weight: normal;" | '''< > <= >='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | igualdade
! style="vertical-align: top; font-weight: normal;" | '''== !='''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros, reais, ponteiros
! style="vertical-align: top; font-weight: normal;" | análoga à do C, mas para entidades ternárias
|-
! style="vertical-align: top; font-weight: normal;" | "e" lógico
! style="vertical-align: top; font-weight: normal;" | '''&&'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for falso.
|-
! style="vertical-align: top; font-weight: normal;" | "ou" lógico
! style="vertical-align: top; font-weight: normal;" | '''<nowiki>||</nowiki>'''
! style="vertical-align: top; font-weight: normal;" | da esquerda para a direita
! style="vertical-align: top; font-weight: normal;" | inteiros
! style="vertical-align: top; font-weight: normal;" | Lógica de Kleene: o 2º argumento só é avaliado se o 1º não for verdadeiro.
|-
! style="vertical-align: top; font-weight: normal;" | atribuição
! style="vertical-align: top; font-weight: normal;" | '''='''
! style="vertical-align: top; font-weight: normal;" | da direita para a esquerda
! style="vertical-align: top; font-weight: normal;" | todos os tipos
! style="vertical-align: top; font-weight: normal;" | O valor da expressão do lado direito do operador é guardado na posição indicada pelo ''left-value'' (operando esquerdo do operador). Podem ser atribuídos valores inteiros a ''left-values'' reais (conversão automática). Nos outros casos, ambos os tipos têm de concordar. O literal '''null''' é compatível com todos os tipos de ponteiros.
|}

== Expressões primitivas ==

As [[#Literais|expressões literais]] e a [[#Invocação|invocação de funções]] foram definidas acima.

=== Identificadores ===

Um identificador é uma expressão se tiver sido declarado. Um identificador pode denotar uma variável.

Um identificador é o caso mais simples de um ''[[#Left-values|left-value]]'', ou seja, uma entidade que pode ser utilizada no lado esquerdo (''left'') de uma atribuição.

=== Leitura ===

A operação de leitura de um valor inteiro ou real pode ser efectuado pela expressão indicada pela palavra-chave '''input''', que devolve o valor lido, de acordo com o tipo esperado (inteiro ou real). Caso se use como argumento dos operadores de impressão ou noutras situações que permitam vários tipos (e.g. '''!''' ou '''!!'''), deve ser lido um inteiro.

Exemplos: '''a = input''' (leitura para '''a'''), '''f(input)''' (leitura para argumento de função), '''input!!''' (leitura e impressão).

=== Parênteses curvos ===

Uma expressão entre parênteses curvos tem o valor da expressão sem os parênteses e permite alterar a prioridade dos operadores. Uma expressão entre parênteses não pode ser utilizada como ''left-value'' (ver também a [[#Indexação|expressão de indexação]]).


== Expressões resultantes de avaliação de operadores ==

=== Indexação de ponteiros ===

A indexação de ponteiros devolve o valor de uma posição de memória indicada por um ponteiro. Consiste em uma expressão ponteiro seguida do índice entre parênteses rectos. O resultado de uma indexação de ponteiros é um ''[[#Left-values|left-value]]''. Não é possível indexar ponteiros que designem funções.

Exemplo (acesso à posição 0 da zona de memória indicada por '''p'''): '''p[0]'''

=== Identidade e simétrico ===

Os operadores identidade ('''+''') e simétrico ('''-''') aplicam-se a inteiros e reais. Têm o mesmo significado que em análogo às operações correspondentes em C, mas operam sobre grandezas ternárias.

=== Reserva de memória ===

A expressão reserva de memória devolve o ponteiro que aponta para a zona de memória, na pilha da função actual, contendo espaço suficiente para o número de objectos indicados pelo seu argumento inteiro.

Exemplo (reserva vector com 5 reais, apontados por '''p'''): '''[real] p = [5]'''

=== Expressão de indicação de posição ===

O operador sufixo '''?''' aplica-se a ''left-values'', retornando o endereço (com o tipo ponteiro) correspondente.

Exemplo (indica o endereço de '''a'''): '''a?'''

=== Expressão de dimensão ===

O operador '''sizeof''' tem um único argumento e aplica-se a expressões, retornando a dimensão correspondente em bytes.

Exemplo: '''sizeof(a)''' (dimensão de '''a''').

= Exemplos e Testes =

Os exemplos abaixo não são exaustivos e não ilustram todos os aspectos da linguagem.

Estão ainda disponíveis outros [https://gitlab.rnl.tecnico.ulisboa.pt/leic-a-co26/eval/co26 pacotes de testes].

O seguinte exemplo ilustra um programa com dois módulos: um que define a função '''factorial''' e outro que define a função principal.

Definição da função '''factorial''' no ficheiro '''factorial.p6''':

<source lang="text">
public factorial(int n) -> int {
if (n > 1)
return n * factorial(n - 1);
else
return 1;
};
</source>

Exemplo da utilização da função '''factorial''' no ficheiro '''main.p6''':

<source lang="text">
// external builtin functions (non-P6)
extern int<> argc;
extern string<int> argv;
extern int<string> atoi;

// external user functions (P6)
forward int<int> factorial;

// the main function
begin
auto value = 1;
"Teste para a função factorial."!!
if (argc() == 2) {
string s = argv(1);
value = atoi(s);
}
value, "! é ", factorial(value)!!
return 0;
end
</source>

Como compilar:
<source lang="text">
p6 --target asm factorial.p6
p6 --target asm main.p6
yasm -felf32 factorial.asm
yasm -felf32 main.asm
ld -melf_i386 -o main factorial.o main.o -lrts
</source>

= Omissões e Erros =

Casos omissos e erros serão corrigidos em futuras versões do manual de referência.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category: Ensino]]

Compiladores/Projecto de Compiladores/Avaliação do Projecto (Época Normal)

2026-05-06T08:22:41Z

Root: /* Teste Prático */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}
== Método de Avaliação do Projecto ==

A avaliação relativa à componente do Projecto processa-se em várias fases:

* [[#Entrega Zero (inicial) - Projecto Base|Entrega Zero (inicial): projecto base]] ('''obrigatória''': ver condições abaixo)
* [[#Entrega Intermédia - Gerador de XML|Entrega Intermédia: gerador de XML]] ('''obrigatória''': ver condições abaixo)
* [[#Entrega Final - Compilador Completo|Entrega Final: compilador completo]] ('''obrigatória''': ver condições abaixo)
* [[#Teste Prático|Teste prático]] ('''obrigatório''': ver condições abaixo)


O Projecto (trabalho conducente às entregas acima mencionadas e abaixo descritas) é realizado por grupos de, no máximo, 2 (dois) elementos, durante o período estabelecido.

O Teste Prático é realizado individualmente, em data e local a agendar.

'''A não realização de componentes obrigatórias tem como consequência a classificação de zero valores na componente de projecto e exclusão da avaliação em época normal.'''


'''TODAS AS ENTREGAS SÃO OBRIGATÓRIAS E SÃO REALIZADAS ATÉ ÀS 17:00 DAS RESPECTIVAS DATAS'''

== Cálculo da Nota do Projecto e Condições de Aprovação ==

Componentes de avaliação:
* '''PRJ''' - nota final do projecto
* '''E0''' - nota da entrega "zero"
* '''EI''' - nota da entrega intermédia
* '''EF''' - nota da entrega final
* '''TP''' - nota do teste prático

A nota do teste prático condiciona a distância ao mínimo entre as notas do teste prático e a do projecto: desde um mínimo de 12.5% de acréscimo à menor das duas (abaixo de 7.5 valores no TP), até um máximo de 25% (para 20 valores no TP). O acréscimo é linear entre 7.5 e 20.

Ou seja:
* '''PRJ = min(E0+EI+EF, TP) + | TP - E0 - EI - EF | * max(12.5, TP+5) / 100'''

'''Condições necessárias para aprovação à disciplina (necessárias todas):'''
* '''PRJ >= 9.5''' (sem arredondamento)
* '''PRJ != NA'''
* '''TP > 0'''
* '''TP != NA'''

== Entrega Zero (inicial) - Projecto Base ==

A Entrega "Zero" avalia o estado do projecto relativamente à concepção dos nós que representam os conceitos da linguagem (sem ser necessário tratar ainda do seu reconhecimento ou processamento).

'''Esta entrega é obrigatória e tem uma classificação máxima de 2 valores.'''

Não serão executados testes automáticos nesta entrega.

Nesta fase, além da estrutura básica do compilador, todas as classes dos nós da linguagem, assim como os esqueletos dos "visitors" (xml_writer, postfix_writer, etc.) devem estar implementados. Não é ainda necessário ter implementado nenhum código de análise lexical, sintáctica ou semântica.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega "zero"]].

'''Considerando que é um passo crucial na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Entrega Intermédia - Gerador de XML ==

A Entrega Intermédia avalia o estado do projecto relativamente a um mínimo de funcionalidade.

'''Esta entrega é obrigatória e tem uma classificação máxima de 6 valores.'''

Não serão executados testes automáticos nesta entrega.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega intermédia]].

'''A não realização da Entrega Intermédia conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Entrega Final - Compilador Completo ==

A Entrega Final pressupõe que todo o projecto foi implementado.

'''Esta entrega é obrigatória e tem uma classificação máxima de 12 valores.'''

Serão executados testes automáticos nesta entrega.

Os testes correspondem a uma série de programas que deverão ser compilados pelo resultado do projecto de cada grupo e cuja execução deve corresponder a um conjunto de resultados padrão.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega final]].

'''A não realização da Entrega Final conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Teste Prático ==

O Teste Prático consiste em fazer pequenas alterações/extensões ao projecto descrito no enunciado. O teste é realizado com base na implementação submetida para a avaliação correspondente à entrega final.

Este teste avalia o conhecimento do aluno relativamente ao projecto entregue, assim como a sua capacidade de realizar alterações ao código do projecto.

O teste prático é como uma discussão de projecto, pelo que não existem repescagens como nos testes escritos. Alunos que faltem ao teste prático estão automaticamente reprovados à disciplina.

'''A não realização do Teste Prático conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente.'''

Concretamente, o teste prático corresponde à resolução uma pergunta que aborda os seguintes três tópicos:
análise lexical;
análise sintáctica; e
análise semântica e geração de código.
Cada tópico pode ser resolvido com mais ou menos profundidade (embora isso implique funcionamento possivelmente deficiente a jusante) e será avaliado independentemente.

Ver também [[Compiladores/Projecto_de_Compiladores/Teste_Prático_(Época_Normal)|calendário do teste prático]].

== Considerações Adicionais sobre a Avaliação do Projecto ==

'''O projecto deverá ser desenvolvido atempadamente ao longo do semestre.'''

As versões intermédias registadas no Gitlab poderão ser testadas, pelo que deverão ser periodicamente actualizadas. O projecto é constituído por um projecto Gitlab designado pelo número do grupo que o executa. O repositório GIT disponibilizado já contém uma versão vazia do projecto. Apenas os ficheiros registados no projecto Gitlab serão considerados na avaliação.

'''Não serão consideradas quaisquer alterações aos ficheiros disponibilizados: eventuais cópias desses ficheiros serão automaticamente substituídas durante a avaliação da funcionalidade do código submetido.'''

A avaliação executa testes automáticos aos programas na linguagem a implementar: caso os testes falhem por causas imputáveis ao grupo, a nota reflectirá apenas os testes bem sucedidos. Para tal, o compilador deve chamar-se '''p6''' e não "P6", "proj", "compiladores", "projecto", ou outro nome (a makefile fornecida já faz este trabalho). As restantes componentes da nota são obtidas pela análise do código e resultado do teste prático (realizado individualmente). O código é avaliado quanto à sua correcção, simplicidade, extensibilidade e legibilidade: devem existir comentários das partes mais complexas, mas não devem ser excessivos nem óbvios (diminuem a legibilidade), nem muito escassos (impedem a compreensão). O teste prático avalia a capacidade de efectuar alterações ao código entregue.

'''Qualquer alteração à especificação da linguagem é penalizada, mesmo que possa ser entendida como um melhoramento.'''

Notar que o facto de os testes automáticos terem sido superados não reflecte a qualidade do código, quer do ponto de vista de engenharia de software, quer do ponto de vista da correcta aplicação dos princípios leccionados na disciplina. No entanto, a funcionalidade do compilador final também é importante, pelo que '''é preferível um compilador que realize, correctamente, apenas parte da funcionalidade a um quase completo mas que nem sequer compila ou que não gera nenhum programa correcto'''.

== Compromisso de Honra ==

A entrega de quaisquer trabalhos pressupõe o compromisso de honra que foram realizados pelos autores referenciados. A quebra deste compromisso, i.e., a tentativa de apropriação de trabalhos alheios, terá como consequência a reprovação de todos os alunos envolvidos (incluindo os que possibilitaram a ocorrência) no ano lectivo actual, sem prejuízo de acções disciplinares previstas pelo IST.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category:Ensino]]

Compiladores/Projecto de Compiladores/Avaliação do Projecto (Época Normal)

2026-05-06T08:21:07Z

Root: /* Entrega Final - Compilador Completo */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}
== Método de Avaliação do Projecto ==

A avaliação relativa à componente do Projecto processa-se em várias fases:

* [[#Entrega Zero (inicial) - Projecto Base|Entrega Zero (inicial): projecto base]] ('''obrigatória''': ver condições abaixo)
* [[#Entrega Intermédia - Gerador de XML|Entrega Intermédia: gerador de XML]] ('''obrigatória''': ver condições abaixo)
* [[#Entrega Final - Compilador Completo|Entrega Final: compilador completo]] ('''obrigatória''': ver condições abaixo)
* [[#Teste Prático|Teste prático]] ('''obrigatório''': ver condições abaixo)


O Projecto (trabalho conducente às entregas acima mencionadas e abaixo descritas) é realizado por grupos de, no máximo, 2 (dois) elementos, durante o período estabelecido.

O Teste Prático é realizado individualmente, em data e local a agendar.

'''A não realização de componentes obrigatórias tem como consequência a classificação de zero valores na componente de projecto e exclusão da avaliação em época normal.'''


'''TODAS AS ENTREGAS SÃO OBRIGATÓRIAS E SÃO REALIZADAS ATÉ ÀS 17:00 DAS RESPECTIVAS DATAS'''

== Cálculo da Nota do Projecto e Condições de Aprovação ==

Componentes de avaliação:
* '''PRJ''' - nota final do projecto
* '''E0''' - nota da entrega "zero"
* '''EI''' - nota da entrega intermédia
* '''EF''' - nota da entrega final
* '''TP''' - nota do teste prático

A nota do teste prático condiciona a distância ao mínimo entre as notas do teste prático e a do projecto: desde um mínimo de 12.5% de acréscimo à menor das duas (abaixo de 7.5 valores no TP), até um máximo de 25% (para 20 valores no TP). O acréscimo é linear entre 7.5 e 20.

Ou seja:
* '''PRJ = min(E0+EI+EF, TP) + | TP - E0 - EI - EF | * max(12.5, TP+5) / 100'''

'''Condições necessárias para aprovação à disciplina (necessárias todas):'''
* '''PRJ >= 9.5''' (sem arredondamento)
* '''PRJ != NA'''
* '''TP > 0'''
* '''TP != NA'''

== Entrega Zero (inicial) - Projecto Base ==

A Entrega "Zero" avalia o estado do projecto relativamente à concepção dos nós que representam os conceitos da linguagem (sem ser necessário tratar ainda do seu reconhecimento ou processamento).

'''Esta entrega é obrigatória e tem uma classificação máxima de 2 valores.'''

Não serão executados testes automáticos nesta entrega.

Nesta fase, além da estrutura básica do compilador, todas as classes dos nós da linguagem, assim como os esqueletos dos "visitors" (xml_writer, postfix_writer, etc.) devem estar implementados. Não é ainda necessário ter implementado nenhum código de análise lexical, sintáctica ou semântica.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega "zero"]].

'''Considerando que é um passo crucial na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Entrega Intermédia - Gerador de XML ==

A Entrega Intermédia avalia o estado do projecto relativamente a um mínimo de funcionalidade.

'''Esta entrega é obrigatória e tem uma classificação máxima de 6 valores.'''

Não serão executados testes automáticos nesta entrega.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega intermédia]].

'''A não realização da Entrega Intermédia conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Entrega Final - Compilador Completo ==

A Entrega Final pressupõe que todo o projecto foi implementado.

'''Esta entrega é obrigatória e tem uma classificação máxima de 12 valores.'''

Serão executados testes automáticos nesta entrega.

Os testes correspondem a uma série de programas que deverão ser compilados pelo resultado do projecto de cada grupo e cuja execução deve corresponder a um conjunto de resultados padrão.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega final]].

'''A não realização da Entrega Final conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Teste Prático ==

O Teste Prático consiste em fazer pequenas alterações/extensões ao projecto descrito no enunciado. O teste é realizado com base na implementação submetida para a avaliação correspondente à entrega final.

Este teste avalia o conhecimento do aluno relativamente ao projecto entregue, assim como a sua capacidade de realizar alterações ao código do projecto.

O teste prático é como uma discussão de projecto, pelo que não existem repescagens como nos testes escritos. Alunos que faltem ao teste prático estão automaticamente reprovados à disciplina.

'''A não realização do Teste Prático conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente.'''

Concretamente, o teste prático corresponde à resolução uma pergunta que aborda os seguintes três tópicos:
análise lexical;
análise sintáctica; e
análise semântica e geração de código.
Cada tópico pode ser resolvido com mais ou menos profundidade (embora isso implique funcionamento possivelmente deficiente a jusante) e será avaliado independentemente.

== Considerações Adicionais sobre a Avaliação do Projecto ==

'''O projecto deverá ser desenvolvido atempadamente ao longo do semestre.'''

As versões intermédias registadas no Gitlab poderão ser testadas, pelo que deverão ser periodicamente actualizadas. O projecto é constituído por um projecto Gitlab designado pelo número do grupo que o executa. O repositório GIT disponibilizado já contém uma versão vazia do projecto. Apenas os ficheiros registados no projecto Gitlab serão considerados na avaliação.

'''Não serão consideradas quaisquer alterações aos ficheiros disponibilizados: eventuais cópias desses ficheiros serão automaticamente substituídas durante a avaliação da funcionalidade do código submetido.'''

A avaliação executa testes automáticos aos programas na linguagem a implementar: caso os testes falhem por causas imputáveis ao grupo, a nota reflectirá apenas os testes bem sucedidos. Para tal, o compilador deve chamar-se '''p6''' e não "P6", "proj", "compiladores", "projecto", ou outro nome (a makefile fornecida já faz este trabalho). As restantes componentes da nota são obtidas pela análise do código e resultado do teste prático (realizado individualmente). O código é avaliado quanto à sua correcção, simplicidade, extensibilidade e legibilidade: devem existir comentários das partes mais complexas, mas não devem ser excessivos nem óbvios (diminuem a legibilidade), nem muito escassos (impedem a compreensão). O teste prático avalia a capacidade de efectuar alterações ao código entregue.

'''Qualquer alteração à especificação da linguagem é penalizada, mesmo que possa ser entendida como um melhoramento.'''

Notar que o facto de os testes automáticos terem sido superados não reflecte a qualidade do código, quer do ponto de vista de engenharia de software, quer do ponto de vista da correcta aplicação dos princípios leccionados na disciplina. No entanto, a funcionalidade do compilador final também é importante, pelo que '''é preferível um compilador que realize, correctamente, apenas parte da funcionalidade a um quase completo mas que nem sequer compila ou que não gera nenhum programa correcto'''.

== Compromisso de Honra ==

A entrega de quaisquer trabalhos pressupõe o compromisso de honra que foram realizados pelos autores referenciados. A quebra deste compromisso, i.e., a tentativa de apropriação de trabalhos alheios, terá como consequência a reprovação de todos os alunos envolvidos (incluindo os que possibilitaram a ocorrência) no ano lectivo actual, sem prejuízo de acções disciplinares previstas pelo IST.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category:Ensino]]

Compiladores/Projecto de Compiladores/Avaliação do Projecto (Época Normal)

2026-05-06T08:20:22Z

Root: /* Entrega Intermédia - Gerador de XML */

{{PRJCompiladoreAvisosEN20252026}}

{{PRJCOMandatory20252026}}
{{TOCright}}
== Método de Avaliação do Projecto ==

A avaliação relativa à componente do Projecto processa-se em várias fases:

* [[#Entrega Zero (inicial) - Projecto Base|Entrega Zero (inicial): projecto base]] ('''obrigatória''': ver condições abaixo)
* [[#Entrega Intermédia - Gerador de XML|Entrega Intermédia: gerador de XML]] ('''obrigatória''': ver condições abaixo)
* [[#Entrega Final - Compilador Completo|Entrega Final: compilador completo]] ('''obrigatória''': ver condições abaixo)
* [[#Teste Prático|Teste prático]] ('''obrigatório''': ver condições abaixo)


O Projecto (trabalho conducente às entregas acima mencionadas e abaixo descritas) é realizado por grupos de, no máximo, 2 (dois) elementos, durante o período estabelecido.

O Teste Prático é realizado individualmente, em data e local a agendar.

'''A não realização de componentes obrigatórias tem como consequência a classificação de zero valores na componente de projecto e exclusão da avaliação em época normal.'''


'''TODAS AS ENTREGAS SÃO OBRIGATÓRIAS E SÃO REALIZADAS ATÉ ÀS 17:00 DAS RESPECTIVAS DATAS'''

== Cálculo da Nota do Projecto e Condições de Aprovação ==

Componentes de avaliação:
* '''PRJ''' - nota final do projecto
* '''E0''' - nota da entrega "zero"
* '''EI''' - nota da entrega intermédia
* '''EF''' - nota da entrega final
* '''TP''' - nota do teste prático

A nota do teste prático condiciona a distância ao mínimo entre as notas do teste prático e a do projecto: desde um mínimo de 12.5% de acréscimo à menor das duas (abaixo de 7.5 valores no TP), até um máximo de 25% (para 20 valores no TP). O acréscimo é linear entre 7.5 e 20.

Ou seja:
* '''PRJ = min(E0+EI+EF, TP) + | TP - E0 - EI - EF | * max(12.5, TP+5) / 100'''

'''Condições necessárias para aprovação à disciplina (necessárias todas):'''
* '''PRJ >= 9.5''' (sem arredondamento)
* '''PRJ != NA'''
* '''TP > 0'''
* '''TP != NA'''

== Entrega Zero (inicial) - Projecto Base ==

A Entrega "Zero" avalia o estado do projecto relativamente à concepção dos nós que representam os conceitos da linguagem (sem ser necessário tratar ainda do seu reconhecimento ou processamento).

'''Esta entrega é obrigatória e tem uma classificação máxima de 2 valores.'''

Não serão executados testes automáticos nesta entrega.

Nesta fase, além da estrutura básica do compilador, todas as classes dos nós da linguagem, assim como os esqueletos dos "visitors" (xml_writer, postfix_writer, etc.) devem estar implementados. Não é ainda necessário ter implementado nenhum código de análise lexical, sintáctica ou semântica.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega "zero"]].

'''Considerando que é um passo crucial na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Entrega Intermédia - Gerador de XML ==

A Entrega Intermédia avalia o estado do projecto relativamente a um mínimo de funcionalidade.

'''Esta entrega é obrigatória e tem uma classificação máxima de 6 valores.'''

Não serão executados testes automáticos nesta entrega.

Ver pormenores na [[Compiladores#Pautas|pauta da avaliação da entrega intermédia]].

'''A não realização da Entrega Intermédia conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Entrega Final - Compilador Completo ==

A Entrega Final pressupõe que todo o projecto foi implementado.

'''Esta entrega é obrigatória e tem uma classificação máxima de 12 valores.'''

Serão executados testes automáticos nesta entrega.

Os testes correspondem a uma série de programas que deverão ser compilados pelo resultado do projecto de cada grupo e cuja execução deve corresponder a um conjunto de resultados padrão.

'''A não realização da Entrega Final conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente. A ausência de material relevante para a entrega será considerada uma não entrega, conduzindo a reprovação.'''

== Teste Prático ==

O Teste Prático consiste em fazer pequenas alterações/extensões ao projecto descrito no enunciado. O teste é realizado com base na implementação submetida para a avaliação correspondente à entrega final.

Este teste avalia o conhecimento do aluno relativamente ao projecto entregue, assim como a sua capacidade de realizar alterações ao código do projecto.

O teste prático é como uma discussão de projecto, pelo que não existem repescagens como nos testes escritos. Alunos que faltem ao teste prático estão automaticamente reprovados à disciplina.

'''A não realização do Teste Prático conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente reprovação à disciplina no ano lectivo corrente.'''

Concretamente, o teste prático corresponde à resolução uma pergunta que aborda os seguintes três tópicos:
análise lexical;
análise sintáctica; e
análise semântica e geração de código.
Cada tópico pode ser resolvido com mais ou menos profundidade (embora isso implique funcionamento possivelmente deficiente a jusante) e será avaliado independentemente.

== Considerações Adicionais sobre a Avaliação do Projecto ==

'''O projecto deverá ser desenvolvido atempadamente ao longo do semestre.'''

As versões intermédias registadas no Gitlab poderão ser testadas, pelo que deverão ser periodicamente actualizadas. O projecto é constituído por um projecto Gitlab designado pelo número do grupo que o executa. O repositório GIT disponibilizado já contém uma versão vazia do projecto. Apenas os ficheiros registados no projecto Gitlab serão considerados na avaliação.

'''Não serão consideradas quaisquer alterações aos ficheiros disponibilizados: eventuais cópias desses ficheiros serão automaticamente substituídas durante a avaliação da funcionalidade do código submetido.'''

A avaliação executa testes automáticos aos programas na linguagem a implementar: caso os testes falhem por causas imputáveis ao grupo, a nota reflectirá apenas os testes bem sucedidos. Para tal, o compilador deve chamar-se '''p6''' e não "P6", "proj", "compiladores", "projecto", ou outro nome (a makefile fornecida já faz este trabalho). As restantes componentes da nota são obtidas pela análise do código e resultado do teste prático (realizado individualmente). O código é avaliado quanto à sua correcção, simplicidade, extensibilidade e legibilidade: devem existir comentários das partes mais complexas, mas não devem ser excessivos nem óbvios (diminuem a legibilidade), nem muito escassos (impedem a compreensão). O teste prático avalia a capacidade de efectuar alterações ao código entregue.

'''Qualquer alteração à especificação da linguagem é penalizada, mesmo que possa ser entendida como um melhoramento.'''

Notar que o facto de os testes automáticos terem sido superados não reflecte a qualidade do código, quer do ponto de vista de engenharia de software, quer do ponto de vista da correcta aplicação dos princípios leccionados na disciplina. No entanto, a funcionalidade do compilador final também é importante, pelo que '''é preferível um compilador que realize, correctamente, apenas parte da funcionalidade a um quase completo mas que nem sequer compila ou que não gera nenhum programa correcto'''.

== Compromisso de Honra ==

A entrega de quaisquer trabalhos pressupõe o compromisso de honra que foram realizados pelos autores referenciados. A quebra deste compromisso, i.e., a tentativa de apropriação de trabalhos alheios, terá como consequência a reprovação de todos os alunos envolvidos (incluindo os que possibilitaram a ocorrência) no ano lectivo actual, sem prejuízo de acções disciplinares previstas pelo IST.

[[category:Projecto de Compiladores]]
[[category:Compiladores]]
[[category:Ensino]]