☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta DRAM. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta DRAM. Mostrar todas as mensagens

quarta-feira, 13 de agosto de 2014

🧙 JACK-OF-ALL-TRADES E A DUNGEON DOS 64 BITS — QUANDO O COBOL DESCOBRIU QUE 4 GB NÃO ERAM QUATRO BILHÕES DE GAVETAS

 

Bellacosa Mainframe fala sobre memorias de computador

☕ Um Café no Bellacosa Mainframe

🧙 JACK-OF-ALL-TRADES E A DUNGEON DOS 64 BITS — QUANDO O COBOL DESCOBRIU QUE 4 GB NÃO ERAM QUATRO BILHÕES DE GAVETAS

RAM, ROM, PROM, EPROM, Flash, SRAM, DRAM, cache, memória virtual, SIMM, DIMM, 8, 16, 24, 31, 32 e 64 bits — e o dia em que um programador COBOL descobriu que a memória do computador tinha mais níveis que uma dungeon.



🎬 PRÓLOGO — PRECISAMOS DE MAIS MEMÓRIA!

O jovem programador COBOL entrou na War Room carregando uma folha impressa.

Era um daqueles textos antigos sobre computadores.

Na primeira página estava escrito:

“É normal encontrar nos computadores de hoje 32 a 64 MB de memória.”

Ele olhou para aquilo.

Olhou para o notebook.

Olhou novamente para o papel.

— Mestre... isso está errado!

Jack, de Jack-of-All-Trades, Party of None, examinou o documento como quem recebe um mapa antigo encontrado no fundo de uma dungeon.

— Não necessariamente.

— Mas 64 MB?

— Você está cometendo o primeiro erro do arqueólogo de tecnologia: julgar uma máquina de 1997 usando a régua de 2026.

O texto falava de DIP, SIPP, SIMM de 30 pinos, SIMM de 72 pinos, DIMM de 168 pinos, 80386, 80486 e Pentium.

Aquilo não era apenas documentação técnica antiga.

Era um fóssil.

E fósseis contam histórias.

Jack puxou uma cadeira.

— Hoje você não vai simplesmente aprender RAM. Vai descobrir por que um processador de 8 bits podia acessar 64 KB, por que um processador de 16 bits chegou a 16 MB, por que o IBM System/360 usava 24 bits, por que o mainframe resolveu inventar 31 bits, de onde surgiram os 4 GB dos PCs de 32 bits e por que uma máquina de 64 bits não significa automaticamente 16 exabytes de RAM.

O Padawan COBOL arregalou os olhos.

— Isso tudo é memória?

— Não. Isso tudo são as consequências de termos memória.



🧠 CAPÍTULO 1 — CPU RÁPIDA COM MEMÓRIA LENTA CONTINUA ESPERANDO

Comecemos pelo fundamento.

Um computador precisa essencialmente manipular instruções e dados.

A CPU executa instruções, mas essas instruções e os dados utilizados por elas precisam estar em algum lugar.

Imagine um cozinheiro absurdamente rápido.

Ele consegue preparar um prato em dez segundos.

Existe apenas um problema: os ingredientes chegam da despensa a cada cinco minutos.

Não adianta contratar um cozinheiro duas vezes mais rápido.

Ele continuará esperando o tomate.

Com processadores ocorre algo semelhante.

Podemos representar uma hierarquia simplificada assim:

CPU
 │
 ├── Registradores
 │
 ├── Cache L1
 │
 ├── Cache L2
 │
 ├── Cache L3
 │
 ├── RAM
 │
 ├── SSD / NVMe
 │
 └── armazenamento mais distante

Quanto mais próximo da CPU, normalmente encontramos memória:

  • mais rápida;

  • menor;

  • mais cara por byte.

Quanto mais distante:

  • maior;

  • mais barata por byte;

  • mais lenta.

Esse é um dos grandes compromissos da engenharia de computadores.

Queremos tudo ao mesmo tempo:

MUITA capacidade
+
MUITA velocidade
+
BAIXÍSSIMA latência
+
BAIXO consumo
+
persistência
+
BAIXO custo

Infelizmente, o vendedor dessa memória perfeita ainda não apareceu.



🏰 CAPÍTULO 2 — RAM NÃO É UMA COISA SÓ

RAM significa Random Access Memory.

“Acesso aleatório” não quer dizer que o computador escolhe posições aleatoriamente.

Significa que podemos acessar diferentes posições diretamente sem precisar percorrer sequencialmente tudo o que existe antes delas.

Existem diferentes tecnologias de RAM.

Duas são fundamentais para entender nossa história:

DRAM e SRAM.



💧 CAPÍTULO 3 — DRAM: A MEMÓRIA QUE PRECISA SER LEMBRADA DE NÃO ESQUECER

DRAM significa Dynamic Random Access Memory.

A ideia clássica de uma célula DRAM envolve essencialmente:

1 transistor
+
1 capacitor

O capacitor armazena carga elétrica.

O problema?

Capacitores não mantêm essa carga eternamente.

Ela vaza.

Portanto, a informação precisa ser periodicamente restaurada.

Esse processo chama-se:

refresh.

Imagine milhares de milhões de pequenos baldes furados.

Você coloca água neles.

Antes que esvaziem completamente, precisa verificar e restaurar os níveis correspondentes aos dados armazenados.

É uma analogia imperfeita, mas ajuda a visualizar a ideia.

A grande vantagem da DRAM é sua densidade.

Podemos colocar enorme quantidade de células numa determinada área de silício.

Consequentemente, ela se tornou excelente candidata para a memória principal dos computadores.



⚡ CAPÍTULO 4 — SRAM: CARA, RÁPIDA E PERTO DO CHEFE

SRAM significa Static Random Access Memory.

Ela não depende do mesmo mecanismo periódico de refresh da DRAM enquanto permanece energizada.

Uma célula SRAM tradicional pode utilizar uma estrutura com vários transistores, frequentemente associada ao modelo 6T, de seis transistores.

Isso significa mais componentes por bit.

Resultado:

SRAM
mais rápida
mais cara
menos densa

DRAM
mais lenta
mais barata
mais densa

Então alguém teve uma excelente ideia:

— E se colocarmos pequenas quantidades de SRAM muito rápida perto da CPU e grandes quantidades de DRAM como memória principal?

Bem-vindo ao mundo do cache.


🏎️ CAPÍTULO 5 — CACHE: NÃO MANDE JACK VOLTAR À CIDADE PARA BUSCAR UMA POÇÃO

Imagine Jack dentro de uma dungeon.

Ele utiliza constantemente:

  • espada;

  • poção;

  • mapa;

  • ferramentas.

Seria absurdo voltar à cidade cada vez que precisasse de uma poção.

Então ele carrega perto dele aquilo que provavelmente utilizará.

Cache funciona sob uma filosofia semelhante.

Processadores modernos possuem diferentes níveis:

CPU
 │
 ├─ L1
 │
 ├─ L2
 │
 └─ L3
      │
      RAM

Entram aqui dois conceitos importantíssimos.

Localidade temporal

Se usamos determinado dado agora, existe boa chance de utilizá-lo novamente em breve.

Localidade espacial

Se acessamos determinado endereço, existe boa chance de acessarmos dados próximos.

Considere:

PERFORM VARYING WS-I FROM 1 BY 1
        UNTIL WS-I > 1000
    ADD WS-VALOR(WS-I) TO WS-TOTAL
END-PERFORM

Percorrer estruturas de maneira previsível pode colaborar com mecanismos de cache e prefetch.

Essa é uma das razões pelas quais estruturas de dados não são apenas abstrações de programação.

Elas também possuem consequências físicas.

Seu COBOL vive muito acima dos transistores.

Mas os transistores continuam pagando a conta.


🏺 CAPÍTULO 6 — ROM: A BIBLIOTECA QUE SOBREVIVE AO POWER OFF

ROM significa Read Only Memory.

Historicamente, ROM descrevia memória não volátil cujo conteúdo permanecia armazenado mesmo sem alimentação.

Nas tradicionais Mask ROMs, o conteúdo era determinado durante a fabricação.

Isso funcionava muito bem para produtos produzidos em enorme escala.

Depois apareceram outras tecnologias.


🔥 CAPÍTULO 7 — PROM: QUEIME UMA VEZ

PROM significa:

Programmable Read Only Memory.

Ela podia ser programada depois da fabricação.

Porém, normalmente apenas uma vez.

Daí nasceu uma expressão clássica:

“queimar uma PROM”.

Depois de programada, não havia um confortável:

CTRL+Z

O hardware não conhecia arrependimento.


☀️ CAPÍTULO 8 — EPROM: COLOQUE O CHIP NO SOL... NÃO, NÃO FAÇA ISSO

EPROM significa:

Erasable Programmable Read Only Memory.

Ela podia ser apagada e novamente programada.

E aqui aparece uma das imagens mais famosas da eletrônica antiga: o chip com uma pequena janela de quartzo.

Através dela, luz ultravioleta apropriada podia ser utilizada para apagar a memória.

O processo era aproximadamente:

gravar
  ↓
testar
  ↓
deu errado
  ↓
retirar chip
  ↓
apagar com UV
  ↓
programar novamente

Muitos chips tinham um adesivo cobrindo aquela janela.

Não era decoração vintage.

A cobertura ajudava a evitar exposição indesejada.

Para um programador moderno acostumado a clicar em Update Firmware, isso parece arqueologia alienígena.

Mas foi revolucionário.


⚡ CAPÍTULO 9 — EEPROM E FLASH: FINALMENTE PARARAMOS DE PEGAR A LÂMPADA UV

EEPROM trouxe a possibilidade de apagar eletricamente a memória programável.

Flash desenvolveu essa família tecnológica em direção a maior densidade e operações adequadas ao armazenamento moderno.

É essa evolução que tornou perfeitamente normal atualizar firmware eletronicamente.

Daí chegamos aos sistemas modernos nos quais firmware pode ser atualizado sem retirar um chip da placa.

E aqui cabe uma correção histórica importante.

Dizer simplesmente:

“BIOS é uma ROM”

pode funcionar numa introdução histórica, mas é simplificação para máquinas modernas.

Hoje firmware é normalmente armazenado em memória Flash apropriada.

Além disso, PCs modernos utilizam predominantemente UEFI, sucessor arquitetural do BIOS tradicional.


🔋 CAPÍTULO 10 — CMOS NÃO É EXATAMENTE AQUILO QUE VOCÊ PENSA

Outro fóssil linguístico.

Muita gente aprendeu:

“CMOS é uma memória.”

CMOS significa:

Complementary Metal-Oxide-Semiconductor.

É fundamentalmente uma tecnologia de circuitos.

Nos PCs, memória e circuitos associados à configuração do firmware ficaram popularmente conhecidos como “CMOS”.

Daí expressões como:

CMOS Setup
CMOS Battery
Clear CMOS

Quando retiramos a bateria da placa-mãe, não estamos simplesmente “apagando o BIOS”.

Estamos interferindo na manutenção de configurações e no circuito RTC associado, conforme a implementação.

Essa diferença parece pequena.

Mas arquitetura de computadores é justamente a ciência de descobrir que todas as diferenças pequenas voltam para cobrar juros vinte anos depois.


🦕 CAPÍTULO 11 — DIP, SIPP, SIMM E DIMM: O JURASSIC PARK DA MEMÓRIA

Nas primeiras gerações de micros, chips DRAM podiam aparecer individualmente em encapsulamentos DIP.

Depois alguém percebeu:

— Talvez instalar um monte de chips individualmente não seja a melhor ideia do universo.

Surgiram módulos.

A evolução histórica passou por tecnologias como:

DIP
 ↓
SIPP
 ↓
SIMM
 ↓
DIMM

SIPP tinha pequenos pinos.

SIMM passou a utilizar contatos na borda do módulo.

Então tivemos os famosos SIMMs de 30 pinos.

Muitos deles forneciam caminho de dados de 8 bits.

Um 80386 com barramento de dados de 32 bits precisava de:

8 + 8 + 8 + 8 = 32

Logo:

quatro módulos.

Não era superstição da placa-mãe.

Era arquitetura.


🧮 CAPÍTULO 12 — POR QUE O PENTIUM QUERIA DOIS SIMMS?

SIMMs de 72 pinos normalmente ofereciam caminho de dados de 32 bits.

O Pentium clássico possuía barramento externo de dados de 64 bits.

Então:

32 + 32 = 64

Dois módulos.

Quando chegamos aos DIMMs com caminho de dados de 64 bits:

1 × 64 = 64

um único módulo podia satisfazer aquela largura.

Perceba a lição:

a forma física da memória acompanha a evolução da arquitetura.

O pente conta uma história.

Você só precisa saber lê-la.


🚀 CAPÍTULO 13 — SDRAM, DDR, DDR2, DDR3, DDR4, DDR5

A história obviamente não parou no DIMM de 168 pinos.

Vieram diferentes gerações:

SDRAM
  ↓
DDR
  ↓
DDR2
  ↓
DDR3
  ↓
DDR4
  ↓
DDR5

DDR significa Double Data Rate.

Com o passar das gerações, aumentaram dramaticamente largura de banda, densidade e sofisticação dos controladores.

Por isso aquela antiga comparação baseada apenas em:

60 ns
70 ns
80 ns

não descreve adequadamente a memória moderna.

Hoje precisamos considerar também:

  • MT/s;

  • latência;

  • timings;

  • canais;

  • ranks;

  • banks;

  • controladores;

  • padrão de acesso.

“Memória mais rápida” deixou de ser uma pergunta simples.

Mais rápida para fazer o quê?


🚚 CAPÍTULO 14 — LATÊNCIA NÃO É LARGURA DE BANDA

Imagine duas estradas.

Na primeira, o primeiro caminhão chega rapidamente, mas só passa um caminhão por vez.

Na segunda, o primeiro demora um pouco mais, mas depois chegam cem caminhões simultaneamente.

Temos duas propriedades diferentes.

Latência: quanto demoramos para começar a receber aquilo que pedimos.

Largura de banda: quanto conseguimos transportar por unidade de tempo.

Uma aplicação pode ser sensível a uma.

Outra, à outra.

E algumas conseguem sofrer com as duas.

Parabéns.

Você acaba de entrar oficialmente na engenharia de performance.


🐌 CAPÍTULO 15 — “ACABOU A RAM, USA O DISCO”

Essa frase é didaticamente útil, mas tecnicamente merece expansão.

Sistemas operacionais modernos trabalham com memória virtual.

Um processo trabalha com endereços virtuais.

Existe tradução desses endereços para recursos físicos.

Simplificando brutalmente:

Programa
   ↓
endereço virtual
   ↓
MMU
   ↓
tabelas de páginas
   ↓
memória física

Quando uma página necessária não está residente na memória física, pode ocorrer um page fault.

O sistema operacional toma as providências necessárias.

Em determinadas situações, dados precisam ser trazidos do armazenamento auxiliar.

O problema aparece quando isso ocorre excessivamente.

Temos o famoso:

thrashing.

A máquina trabalha freneticamente para administrar memória em vez de executar trabalho útil.

É como Jack passar a aventura inteira reorganizando a mochila.

Tecnicamente ocupado.

Heroicamente inútil.


🧙 CAPÍTULO 16 — “8 BITS SÓ ENDEREÇAM 256 BYTES”, CERTO?

Errado.

E esta é provavelmente a armadilha mais importante desta aula.

Se tivermos N bits de endereço, podemos representar:

2N2^N

posições.

Se cada posição identifica um byte:

2N bytes2^N\ bytes

Mas “CPU de 8 bits” não significa necessariamente “endereço de 8 bits”.

Processadores como Z80 e 6502 eram considerados de 8 bits, mas utilizavam endereçamento de 16 bits.

Logo:

216=65.5362^{16}=65.536

64 KB.

Portanto:

CPU: 8 bits
Endereço: 16 bits
Espaço: 64 KB

É por isso que máquinas de 8 bits podiam possuir dezenas de KB.


⚔️ CAPÍTULO 17 — 16 BITS: O 8086 E O REINO DE 1 MB

O Intel 8086 era uma CPU de 16 bits.

Mas possuía capacidade de produzir endereços físicos de 20 bits.

Então:

220=1.048.5762^{20}=1.048.576

1 MB.

Para conseguir isso utilizando seus registradores e sua arquitetura segmentada, o x86 utilizava pares segmento:offset.

Simplificadamente:

endereço físico =
segmento × 16 + offset

E daí nasceu uma quantidade impressionante de diversão arquitetural que futuras gerações tiveram o privilégio de herdar.


🧱 CAPÍTULO 18 — OS 640 KB QUE ASSOMBRARAM O DOS

O IBM PC e seus descendentes organizaram o espaço inferior de 1 MB reservando regiões para diferentes finalidades.

De maneira extremamente simplificada:

0 KB
│
│ memória convencional
│
640 KB
│
│ vídeo
│ hardware
│ ROMs
│ BIOS
│
1 MB

Daí surgiram termos lendários:

Conventional Memory
Upper Memory
EMS
XMS
HIMEM.SYS
EMM386

Quem configurou CONFIG.SYS e AUTOEXEC.BAT para liberar memória para jogos conhece um tipo de sofrimento que deveria valer créditos acadêmicos.


🏹 CAPÍTULO 19 — 80286: 16 BITS E 16 MB

Agora Jack colocou outra armadilha sobre a mesa.

O 80286 continuava sendo uma CPU fundamentalmente de 16 bits.

Mas seu endereçamento físico chegava a 24 bits.

Logo:

224=16.777.2162^{24}=16.777.216

16 MB.

Compare:

8086
CPU 16-bit
endereço 20-bit
1 MB

80286
CPU 16-bit
endereço 24-bit
16 MB

Conclusão:

o rótulo “16-bit” sozinho não determina a quantidade máxima de memória.

Guarde isso.

Vamos precisar dessa chave para abrir a dungeon do mainframe.


🏛️ CAPÍTULO 20 — IBM SYSTEM/360 E OS 24 BITS

Em 1964, a IBM apresentou a família System/360.

Aqui temos uma das decisões arquiteturais mais importantes da história da computação empresarial.

Embora seus registradores gerais tivessem 32 bits, o endereçamento original utilizava 24 bits.

Logo:

224=16MB2^{24}=16MB

Dezesseis megabytes.

Em 2026 isso parece quase uma piada.

Em 1964 era um espaço arquitetural gigantesco.

E mais importante:

essa decisão deixaria marcas que sobreviveriam por décadas.


👻 CAPÍTULO 21 — O FANTASMA DOS 16 MB AINDA VIVE

No universo IBM mainframe aparecem expressões como:

below the line

e

above the line.

A famosa 16 MB line é herança do endereçamento de 24 bits.

Visualmente:

0
│
│ BELOW THE LINE
│
16 MB
──────────────────
│
│ ABOVE THE LINE
│

Isso é arqueologia computacional viva.

Você pode estar estudando um ambiente moderno e encontrar terminologia originada em limitações arquiteturais de muitas décadas atrás.


🤨 CAPÍTULO 22 — IBM, POR QUE 31 BITS?

Depois do universo de 24 bits, a arquitetura IBM evoluiu para endereçamento de 31 bits.

Não 32.

Trinta e um.

O Padawan COBOL levantou a mão.

— Mestre Jack, alguém perdeu um bit?

— Não. Encontraram compatibilidade.

Historicamente, o bit mais significativo tinha implicações herdadas relacionadas ao modo de endereçamento e convenções de software.

A IBM precisava ampliar o espaço preservando compatibilidade.

Com 31 bits:

231=2.147.483.6482^{31}=2.147.483.648

2 GB.

Daí surge outra fronteira famosa:

2 GB Bar.


🍺 CAPÍTULO 23 — BELOW THE BAR E ABOVE THE BAR

Agora nosso mapa fica:

0
│
│ BELOW THE LINE
│
16 MB
────────────────── LINE
│
│ ABOVE THE LINE
│
│
2 GB
══════════════════ BAR
│
│ ABOVE THE BAR
│

A terminologia começa a fazer sentido.

Line: 16 MB.

Bar: 2 GB.

Não são nomes inventados apenas para atormentar o aluno.

São marcas da evolução da arquitetura.


🧭 CAPÍTULO 24 — AMODE 24, AMODE 31 E AMODE 64

No mainframe encontramos o conceito de Addressing Mode, ou AMODE.

Você pode encontrar referências a:

AMODE 24
AMODE 31
AMODE 64

Simplificando:

AMODE 24

O programa trabalha com endereçamento compatível com o universo de 24 bits.

Limite conceitual:

16 MB.

AMODE 31

Endereçamento de 31 bits.

Limite:

2 GB.

AMODE 64

Entramos no universo de endereçamento de 64 bits da z/Architecture.

O espaço potencial torna-se colossal.

E aqui Jack colocou uma placa na parede:

NÃO CONFUNDA ESPAÇO VIRTUAL COM RAM INSTALADA.

Voltaremos a ela.


💻 CAPÍTULO 25 — 80386 E O UNIVERSO DOS 4 GB

Nos PCs, o Intel 80386 marcou a consolidação do x86 de 32 bits.

Com 32 bits de endereço:

232=4.294.967.2962^{32}=4.294.967.296

aproximadamente:

4 GB.

É daí que vem o famoso limite associado aos sistemas x86 de 32 bits.

Mas novamente existe uma pegadinha.

Parte do espaço físico pode precisar ser utilizada para mapear dispositivos e regiões de hardware.

Por isso alguém podia instalar 4 GB e encontrar algo como:

3,x GB utilizáveis

em determinadas configurações e sistemas de 32 bits.

A RAM não tinha desaparecido misteriosamente.

O espaço de endereçamento estava sendo disputado.


🪄 CAPÍTULO 26 — PAE: 32 BITS COM MAIS DE 4 GB?

Sim.

Physical Address Extension, ou PAE, permitiu a determinados sistemas x86 de 32 bits utilizar endereçamento físico maior.

Com 36 bits físicos:

236=64GB2^{36}=64GB

Isso possibilitava administrar até 64 GB de memória física em implementações clássicas.

Mas atenção:

isso não transformava magicamente cada ponteiro de uma aplicação 32-bit num ponteiro linear de 36 bits.

O sistema operacional podia administrar memória física maior enquanto processos individuais continuavam sujeitos às características do espaço virtual da arquitetura.

Outra lição:

memória física e espaço virtual não são a mesma coisa.


🌌 CAPÍTULO 27 — 64 BITS: CHEGAMOS A 16 EXABYTES?

Matematicamente:

264=18.446.744.073.709.551.6162^{64}=18.446.744.073.709.551.616

bytes.

Isso equivale a aproximadamente:

16 exabytes, usando unidades binárias.

Então meu notebook 64-bit aceita 16 EB de RAM?

Não.

Calma, Padawan.

“Arquitetura de 64 bits” não significa que todos os 64 bits possíveis sejam necessariamente implementados para endereçamento físico em determinada CPU.

Existem vários limites:

arquitetura
     ↓
CPU implementada
     ↓
controlador de memória
     ↓
plataforma
     ↓
placa-mãe
     ↓
firmware
     ↓
sistema operacional
     ↓
processo

O menor limite aplicável vence.


🧮 CAPÍTULO 28 — A TABELA QUE O PADAWAN DEVE GUARDAR

A matemática fundamental é:

Bits de endereçoEspaço teórico
8256 bytes
1664 KB
201 MB
2416 MB
312 GB
324 GB
3664 GB
6416 EB

Mas NÃO leia isso como:

CPU 8-bit = 256 bytes
CPU 16-bit = 64 KB
CPU 32-bit = 4 GB

Isso seria errado.

Leia como:

N bits efetivamente utilizados como endereço byte-addressable oferecem 2^N bytes de espaço.

Essa pequena diferença separa decorar tabela de compreender arquitetura.


🏦 CAPÍTULO 29 — COBOL NÃO QUER SABER EM QUAL CAPACITOR ESTÁ WS-SALDO

Considere:

01 WS-CLIENTE.
   05 WS-CONTA        PIC 9(10).
   05 WS-SALDO        PIC S9(13)V99 COMP-3.

Você trabalha com:

WS-CONTA
WS-SALDO

Você não pergunta:

“Em qual chip DRAM está o nibble correspondente ao terceiro dígito do COMP-3?”

Ainda bem.

Existem várias camadas entre seu programa e a eletrônica.

Simplificadamente:

Programa COBOL
      ↓
linguagem / runtime
      ↓
Address Space
      ↓
endereço virtual
      ↓
tradução
      ↓
memória real
      ↓
hardware

No z/OS, um conceito fundamental nessa história é DAT — Dynamic Address Translation.

Ela participa da tradução entre os mundos virtual e real.

Isso permite uma abstração poderosa:

seu programa trabalha com endereços sem precisar conhecer a posição física dos componentes de memória.


🛡️ CAPÍTULO 30 — ECC: QUANDO UM BIT ERRADO PODE CUSTAR DINHEIRO

Memória física não é perfeita.

Erros podem acontecer.

Em ambientes corporativos, um bit errado pode ser muito mais sério do que uma tela azul num computador doméstico.

Imagine:

0000000000001000

sofrendo alteração indevida.

Dependendo do contexto, aquele bit pode representar parte de:

  • saldo;

  • índice;

  • ponteiro;

  • instrução;

  • registro;

  • estrutura interna.

Por isso servidores utilizam sofisticados mecanismos de detecção e correção de erros, incluindo tecnologias baseadas em ECC — Error Correcting Code.

No universo mainframe, confiabilidade de memória faz parte de uma filosofia muito maior de RAS:

Reliability, Availability and Serviceability.

Porque num sistema bancário:

“reinicia aí para ver se volta”

não é uma estratégia arquitetural particularmente elegante.


👻 CAPÍTULO 31 — ROWHAMMER: QUANDO A FÍSICA VIRA SEGURANÇA

Existe uma curiosidade fascinante envolvendo DRAM.

Pesquisadores descobriram que acessos repetidos e cuidadosamente organizados a determinadas linhas de memória poderiam, em certas tecnologias e circunstâncias, influenciar células próximas e provocar alterações de bits.

O fenômeno ficou conhecido como:

Rowhammer.

Observe a cadeia:

física
 ↓
transistores
 ↓
DRAM
 ↓
arquitetura
 ↓
sistema operacional
 ↓
segurança

Isso ensina algo precioso.

Cybersecurity não termina no código.

Às vezes o problema está vários andares abaixo dele.


🎮 CAPÍTULO 32 — VRAM NÃO É MAIS “A MEMÓRIA DA TELA”

Outro conceito que evoluiu dramaticamente.

Antigamente era relativamente razoável explicar memória de vídeo como a memória utilizada para representar aquilo que aparecia no monitor.

Hoje GPUs armazenam e manipulam:

framebuffers
texturas
geometria
shaders
buffers
modelos
dados computacionais
estruturas de IA

Tecnologias como GDDR e HBM atendem necessidades específicas de enorme largura de banda.

GPU deixou há muito tempo de ser simplesmente “a coisa que desenha pixels”.

E a memória acompanhou essa transformação.


🧪 CAPÍTULO 33 — PASSO A PASSO: COMO ANALISAR UM LIMITE DE MEMÓRIA

Quando alguém perguntar:

“Qual é o máximo de RAM desse sistema?”

não responda imediatamente.

Faça a investigação de Jack.

Passo 1 — Descubra a arquitetura

É:

8-bit?
16-bit?
32-bit?
64-bit?

Mas não pare aí.

Passo 2 — Descubra quantos bits de endereço são efetivamente implementados

Essa informação é muito mais importante para determinar o espaço endereçável.

Passo 3 — Separe virtual de físico

Pergunte:

Estamos falando de espaço virtual de um processo ou memória física instalada?

Passo 4 — Verifique o processador

A CPU pode implementar menos endereço físico do que o limite matemático da arquitetura sugere.

Passo 5 — Verifique a plataforma

Placa-mãe, chipset/controlador, sockets e slots impõem limites.

Passo 6 — Verifique o sistema operacional

O SO pode impor limites adicionais.

Passo 7 — Verifique a aplicação

Uma aplicação pode ter restrições próprias.

No mainframe, pergunte também sobre:

AMODE
RMODE
Address Space
Below/Above the Line
Below/Above the Bar

Agora você está fazendo arquitetura.

Não simplesmente lendo “64-bit” na embalagem.


📜 CAPÍTULO 34 — DUAS LINHAS DO TEMPO SE ENCONTRAM

Nos microcomputadores tivemos aproximadamente:

8-bit
 ↓
16-bit
 ↓
386 / 32-bit
 ↓
x86-64

Enquanto no universo IBM mainframe:

24-bit
 ↓
31-bit
 ↓
64-bit

Os caminhos são diferentes.

Os problemas fundamentais são semelhantes.

Precisamos:

  • representar endereços;

  • traduzir endereços;

  • proteger memória;

  • compartilhar recursos;

  • entregar dados rapidamente à CPU;

  • manter compatibilidade;

  • aumentar capacidade sem destruir o passado.

E talvez essa última característica seja especialmente importante no mainframe.


🏺 CAPÍTULO 35 — O MAINFRAME É UMA CIDADE CONSTRUÍDA SOBRE OUTRAS CIDADES

Essa é uma das melhores maneiras de compreender IBM Z.

Não imagine apenas uma máquina nova substituindo completamente a anterior.

Imagine Roma.

Você cava.

Encontra uma construção medieval.

Cava novamente.

Encontra Roma Imperial.

Mais fundo.

República.

No mainframe:

z/Architecture
      ↓
ESA
      ↓
370-XA
      ↓
System/370
      ↓
System/360

Conceitos modernos convivem com decisões históricas.

Daí encontramos:

24 bits
31 bits
64 bits

16 MB Line
2 GB Bar

AMODE 24
AMODE 31
AMODE 64

Não é bagunça.

É evolução com compatibilidade.


🥚 CAPÍTULO 36 — EASTER EGG: 03:17 NA WAR ROOM

Às 03:17 da madrugada, Jack encontrou o jovem programador COBOL olhando fixamente para o dump.

— O que aconteceu?

— Storage problem.

— Quanto storage?

— Não sei.

— Real ou virtual?

Silêncio.

— Below ou above the bar?

Silêncio maior.

— Qual AMODE?

O Padawan abriu outra tela.

Jack pegou o café.

— Então não temos um problema de storage.

— Não?

— Temos um problema de vocabulário.

Primeira regra da War Room:

dar nome correto ao problema reduz metade da dungeon.

A segunda regra é não executar restart antes de coletar evidências.

Mas essa fica para outro café.


☕ CAPÍTULO 37 — O QUE UM PROGRAMADOR COBOL DEVE REALMENTE APRENDER DISSO?

Você não precisa projetar uma célula DRAM para escrever COBOL.

Também não precisa decorar quantos pinos tinha cada SIMM fabricado em 1994.

Mas compreender essa história muda sua percepção do sistema.

Quando você vê:

STORAGE
ADDRESS
POINTER
AMODE
RMODE
PAGE
FRAME
CACHE
BUFFER

essas palavras deixam de ser feitiços encontrados num manual IBM.

Elas passam a fazer parte de um modelo mental.

E esse modelo começa muito abaixo do COBOL.


🧙 EPÍLOGO — JACK ENCONTROU O VERDADEIRO MONSTRO DA DUNGEON

O Padawan fechou o velho manual.

Agora a frase:

“Computadores atuais possuem normalmente 32 a 64 MB”

não parecia mais ridícula.

Parecia histórica.

Aquele texto havia atravessado uma era na qual:

386
486
Pentium
SIMM
DIMM
EPROM
BIOS
DRAM de dezenas de ns

representavam o estado da arte ou sua transição.

Depois vieram:

SDRAM
DDR
DDR2
DDR3
DDR4
DDR5
UEFI
NVMe
multicore
NUMA
virtualização
HBM
IA

Mas Jack apontou para a primeira frase do velho documento:

“Uma CPU veloz só terá eficiência se a memória for também veloz.”

Décadas depois, a batalha continuava.

Mudamos os processadores.

Mudamos os módulos.

Mudamos os barramentos.

Passamos de KB para MB, de MB para GB e de GB para TB.

Construímos cache sobre cache.

Criamos memória virtual.

Criamos prefetch.

Inventamos controladores inteligentes.

Saímos de 24 bits para 31.

De 31 para 64.

E mesmo assim, no fundo da máquina, o processador continua fazendo a mesma pergunta:

Cadê o meu dado?

Jack levantou a caneca.

— Agora você entendeu memória.

O Padawan sorriu.

— Entendi.

— Ótimo.

— Posso otimizar o programa?

Jack quase derrubou o café.

— Não.

— Por quê?

— Porque primeiro você mede.

Na tela da War Room apareceu:

03:17:00

CPU WAITING
CACHE MISS
PAGE FAULT

Jack apontou para o monitor.

— Está vendo?

— Sim.

— O computador mais moderno do mundo continua praticando a tradição mais antiga da informática.

— Qual?

Jack tomou o último gole.

Esperar alguém buscar o dado.

☕💾

Bellacosa Mainframe — porque antes de otimizar o COBOL, descubra em qual andar da dungeon está o gargalo.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...