309 lines
5.3 KiB
Markdown
309 lines
5.3 KiB
Markdown
< [Voltar](chapter-2.md) | [Sumário](table-of-contens.md) | [Adiante](chapter-4.md) >
|
|
|
|
# 🧠 **Memória: Stack, Heap e Alocação**
|
|
|
|
## 1. Visão Geral
|
|
|
|
PROMETEU trata **memória como um recurso explícito**.
|
|
|
|
Nada é alocado “por conveniência”.
|
|
|
|
Nada cresce “automaticamente”.
|
|
|
|
Nada é invisível.
|
|
|
|
Este capítulo define:
|
|
|
|
- os **espaços de memória** da PROMETEU VM
|
|
- como **Stack** e **Heap** funcionam
|
|
- o custo e as consequências da **alocação dinâmica**
|
|
- como a memória se relaciona com **CAP e certificação**
|
|
|
|
---
|
|
|
|
## 2. Espaços de Memória da PROMETEU VM
|
|
|
|
A memória da PROMETEU VM é dividida em regiões com responsabilidades claras:
|
|
|
|
```
|
|
+---------------------------+
|
|
|Constant Pool |
|
|
+---------------------------+
|
|
|Global Space |
|
|
+---------------------------+
|
|
|Call Stack |
|
|
| (Frames + Locals) |
|
|
+---------------------------+
|
|
| Operand Stack |
|
|
+---------------------------+
|
|
| Heap |
|
|
+---------------------------+
|
|
|
|
```
|
|
|
|
Cada região:
|
|
|
|
- tem semântica própria
|
|
- tem limites definidos
|
|
- tem impacto direto no custo de execução
|
|
|
|
---
|
|
|
|
## 3. Operand Stack
|
|
|
|
### 3.1 Definição
|
|
|
|
A **Operand Stack** é usada para:
|
|
|
|
- passagem de operandos entre instruções
|
|
- resultados intermediários
|
|
- avaliação de expressões
|
|
|
|
Ela é:
|
|
|
|
- **LIFO**
|
|
- de crescimento automático dentro do frame
|
|
- **resetada** entre frames (exceto valores persistidos explicitamente)
|
|
|
|
---
|
|
|
|
### 3.2 Características
|
|
|
|
- não armazena estruturas complexas
|
|
- armazena valores primitivos ou referências
|
|
- overflow ou underflow são **erros fatais**
|
|
|
|
> A pilha de operandos é barata, rápida e temporária.
|
|
>
|
|
|
|
---
|
|
|
|
## 4. Call Stack (Stack de Chamadas)
|
|
|
|
### 4.1 Frames de Execução
|
|
|
|
Cada chamada de função cria um **Call Frame**, contendo:
|
|
|
|
- variáveis locais
|
|
- parâmetros
|
|
- endereço de retorno
|
|
- contexto de execução
|
|
|
|
Frames são criados com:
|
|
|
|
```
|
|
PUSH_FRAME n
|
|
```
|
|
|
|
E destruídos com:
|
|
|
|
```
|
|
POP_FRAME
|
|
```
|
|
|
|
---
|
|
|
|
### 4.2 Custos e Limites
|
|
|
|
- criação de frame tem custo explícito
|
|
- profundidade máxima de stack é limitada
|
|
- recursão profunda é desencorajada
|
|
|
|
PROMETEU favorece:
|
|
|
|
- iteração
|
|
- estado explícito
|
|
- controle consciente de profundidade
|
|
|
|
---
|
|
|
|
## 5. Global Space
|
|
|
|
### 5.1 Definição
|
|
|
|
O **Global Space** armazena:
|
|
|
|
- variáveis globais
|
|
- estado persistente do jogo
|
|
- referências de longo prazo
|
|
|
|
Globais:
|
|
|
|
- sobrevivem entre frames
|
|
- ocupam memória permanentemente
|
|
- contam para o uso total de memória
|
|
|
|
---
|
|
|
|
### 5.2 Uso consciente
|
|
|
|
PROMETEU incentiva:
|
|
|
|
- poucas globais
|
|
- estruturas compactas
|
|
- inicialização explícita
|
|
|
|
Globais são equivalentes a **RAM estática** em microcontroladores.
|
|
|
|
---
|
|
|
|
## 6. Heap
|
|
|
|
### 6.1 Definição
|
|
|
|
O **Heap** é a região de memória dinâmica da PROMETEU VM.
|
|
|
|
É usado para:
|
|
|
|
- objetos
|
|
- arrays
|
|
- tabelas
|
|
- estruturas compostas
|
|
|
|
Toda alocação no heap é feita explicitamente com:
|
|
|
|
```
|
|
ALLOC size
|
|
```
|
|
|
|
---
|
|
|
|
### 6.2 Custos da Alocação
|
|
|
|
Alocar memória:
|
|
|
|
- consome **ciclos**
|
|
- consome **heap disponível**
|
|
- aumenta pressão sobre o sistema
|
|
|
|
PROMETEU trata alocação como uma operação **cara por definição**.
|
|
|
|
> Alocar é uma decisão arquitetural, não um detalhe.
|
|
>
|
|
|
|
---
|
|
|
|
## 7. Limites de Heap
|
|
|
|
### 7.1 Heap Finito
|
|
|
|
O heap:
|
|
|
|
- tem tamanho máximo definido
|
|
- pode variar conforme o CAP ativo
|
|
- nunca cresce dinamicamente
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
Heap Limit:32KB
|
|
Heap Used:28KB
|
|
```
|
|
|
|
Ultrapassar o limite:
|
|
|
|
- não trava o jogo
|
|
- gera erro de execução
|
|
- aparece no relatório de certificação
|
|
|
|
---
|
|
|
|
### 7.2 Heap e CAP
|
|
|
|
Durante uma JAM ou avaliação:
|
|
|
|
- o pico de heap é medido
|
|
- o valor é comparado ao limite do CAP
|
|
- não conformidades são registradas
|
|
|
|
O jogo **continua rodando**, mas a evidência fica registrada.
|
|
|
|
---
|
|
|
|
## 8. Garbage Collection (GC)
|
|
|
|
### 8.1 Existência do GC
|
|
|
|
PROMETEU pode utilizar **Garbage Collection simples**, com as seguintes propriedades:
|
|
|
|
- não incremental (v0.1)
|
|
- custo explícito
|
|
- pausas observáveis
|
|
- comportamento documentado
|
|
|
|
GC **não é invisível**.
|
|
|
|
---
|
|
|
|
### 8.2 Custo do GC
|
|
|
|
Quando o GC ocorre:
|
|
|
|
- ciclos são consumidos
|
|
- o frame pode sofrer impacto
|
|
- o evento é registrado
|
|
|
|
PROMETEU ensina:
|
|
|
|
> “Criar lixo tem custo.”
|
|
>
|
|
|
|
---
|
|
|
|
## 9. Boas Práticas de Memória
|
|
|
|
PROMETEU encoraja explicitamente:
|
|
|
|
- reutilização de estruturas
|
|
- alocação fora do loop principal
|
|
- buffers persistentes
|
|
- pooling manual
|
|
|
|
E desencoraja:
|
|
|
|
- alocação por frame
|
|
- estruturas temporárias descartáveis
|
|
- crescimento não planejado
|
|
|
|
---
|
|
|
|
## 10. Relação com Microcontroladores
|
|
|
|
O modelo de memória PROMETEU é intencionalmente similar a MCUs reais:
|
|
|
|
| MCU | PROMETEU |
|
|
| --- | --- |
|
|
| RAM estática | Global Space |
|
|
| Stack | Call Stack |
|
|
| Heap | Heap |
|
|
| Falha de alocação | Erro explícito |
|
|
| Fragmentação | Responsabilidade do dev |
|
|
|
|
Isso cria transferência direta de aprendizado.
|
|
|
|
---
|
|
|
|
## 11. Implicações Pedagógicas
|
|
|
|
Este modelo permite ensinar:
|
|
|
|
- diferença entre stack e heap
|
|
- custo de alocação
|
|
- lifetime de dados
|
|
- impacto arquitetural de decisões simples
|
|
- relação entre memória e tempo
|
|
|
|
Tudo com **feedback imediato e visível**.
|
|
|
|
---
|
|
|
|
## 12. Resumo
|
|
|
|
- PROMETEU possui espaços de memória bem definidos
|
|
- stack é temporária e barata
|
|
- heap é finita e cara
|
|
- alocação tem custo explícito
|
|
- GC é visível e mensurável
|
|
- memória participa da certificação
|
|
|
|
< [Voltar](chapter-2.md) | [Sumário](table-of-contens.md) | [Adiante](chapter-4.md) > |