- O Debian Linux foi inicializado em uma placa real que usa apenas o Intel 4004 de 4 bits de 1971 como CPU, mostrando os limites extremos de um microprocessador antigo e da estratificação de software
- O Linux não roda diretamente no 4004; ele inicializa sobre um emulador de MIPS R3000/DECstation 2100 feito em assembly para 4004, e parte do disco e do console foi simplificada com hypercalls e drivers paravirtualizados
- Por causa do limite de 4 KB de ROM, das operações de 4 bits, da ausência de operações lógicas, da pilha de chamadas rasa e do endereçamento peculiar da RAM 4002, foram necessários contornos como ROM banking, lookup tables, status nibble e RAM virtual baseada em PSRAM
- Após otimizações, o tempo estimado para inicializar o Linux em um 4004 real a 740 KHz é de 4,76 dias; a placa criada foi overclockada para 790 KHz, fazendo o MIPS virtual operar a cerca de 74,73 Hz
- O resultado foi projetado como uma placa de arte retrô para pendurar na parede, com VFD 40x2, 32 LEDs de PC, cartão SD, SPI PSRAM e UART, e o código-fonte e as imagens de disco foram publicados para uso não comercial
Inicializando Debian Linux em um 4004 real
- Linux/4004 é um projeto que inicializou o Debian Linux em uma placa real que usa o Intel 4004 de 1971 como única CPU
- O 4004 é apresentado como o primeiro microprocessador produzido comercialmente no mundo, e o projeto usa um chip Intel 4004 real da década de 1970
- O vídeo de demonstração teve velocidade variável por trechos para reduzir o tédio, e o relógio e o calendário exibidos na tela estão corretos
- Um vídeo de caráter original, reproduzido em velocidade constante, também é disponibilizado separadamente
Por que o 4004?
- Em 2012, Linux foi executado em um microcontrolador AVR de 8 bits, estabelecendo o recorde de “executar Linux no menor hardware”, e depois também foi conduzido o projeto mais prático LinuxCard
- Em 2023, surgiram uma tentativa de bater o recorde com AVR e um projeto de inicializar Linux em um MOS 6510, fazendo CPUs de nível ainda mais baixo virarem o alvo
- Para voltar ainda mais no tempo do que os candidatos Intel 8080 e 8008, foi escolhido o Intel 4004 de 1971
- Como o 4004 é um chip de 4 bits, ele permite estabelecer com clareza um patamar abaixo dos CPUs de 8 bits
Limitações do Intel 4004
- O 4004 opera em unidades de 4 bits, e a maioria das instruções tem 1 byte e é executada em 8 ciclos de clock
- Algumas instruções de 2 bytes exigem 16 ciclos
- FIN é uma exceção: é uma instrução de 1 byte, mas leva 16 ciclos
- O conjunto de instruções não tem operações lógicas como AND, OR, XOR e é centrado basicamente em ADD e SUB
- A carry flag funciona de forma peculiar: na entrada de SUB, age como borrow; depois de SUB, age como not borrow, algo confirmado em hardware real
- Os registradores internos são 16 de 4 bits, o PC é de 12 bits e a pilha de retorno em hardware tem 4 níveis
- Como a entrada no topo da pilha é usada como PC, o aninhamento real de funções fica limitado a no máximo 3 níveis
- Não há interrupções, e a forma mais próxima de tratar eventos externos é fazer polling do pino TEST em desvios condicionais
Estrutura de memória e I/O
- O 4004 não trata diretamente as instruções de memória; chips conectados ao barramento, como 4001/4002/4289/4265/4308, decodificam e executam essas instruções
- O 4001 é um chip ROM com 256 bytes de mask ROM e uma porta de I/O de 4 bits, e o conteúdo da ROM e a configuração da porta de I/O são fixados na fabricação
- O 4002 é um chip RAM com 320 bits de DRAM, circuito de refresh e uma porta de 4 bits apenas de saída
- Um banco de RAM pode ser composto por 4 chips 4002
- Cada banco de RAM tem 256 nibble endereçáveis diretamente e, separadamente, 64 status nibble acessados de outra forma
- O 4289 é um controlador de ROM que combina as funções do 4008 e do 4009, permitindo conectar o 4004 com relativa facilidade a EEPROM/EPROM de 5 V
- O acesso à memória exige um procedimento em várias etapas, como selecionar o banco, carregar o endereço em um par de registradores, enviar o endereço ao barramento com SRC e executar RDM/WRM
- Os status nibble eram úteis para acessar rapidamente dados usados com frequência e ajudaram a aumentar em cerca de 30% a velocidade do emulador MIPS
Preparação da placa de desenvolvimento e do emulador
- A placa de desenvolvimento inicial para validação era composta por um 4201 clock generator, CPU 4004, RAM 4002-1, controlador de ROM 4289 e um ATMEGA48 fazendo o papel de ROM
- A alimentação começa em 5 V, e o terminal positivo de um boost converter isolado de 5 V para 10 V é aterrado para gerar uma alimentação de -10 V para os chips MCS-04
- O primeiro programa para o 4004 foi um código que piscava um LED conectado ao pino de saída 0 do 4002, e passou a funcionar após aumentar a limitação de corrente
- Antes de fabricar a placa real, foi escrito um emulador do 4004 chamado u4004
- Ele emula não só o núcleo do 4004, mas também cartão SD virtual, SPI UART, VFD, disposição do 4002 e LEDs de PC
- O objetivo era validar antes o estado dos pinos SPI e o comportamento dos periféricos, que seriam difíceis de depurar no hardware real
Emular MIPS em vez de rodar Linux diretamente
- O Linux não pode ser executado diretamente no 4004
- Não existe compilador C para o 4004, e foi considerado difícil portar diretamente o kernel Linux devido às limitações da arquitetura
- Limites de aninhamento de chamadas, espaço de endereçamento de ROM/RAM e operações de 4 bits impedem a execução direta
- Em vez disso, foi escrito um emulador de MIPS R3000 sobre o 4004, e sobre ele foi inicializado o Linux para DECstation 2100
- O MIPS foi escolhido por ser mais fácil de emular dentro do espaço de código do 4004 do que outros candidatos
- ARM tem muitos shift operand arbitrários
- RISC-V foi considerado lento por causa do modo de endereçamento
- x86 pode ultrapassar 4 KB só com a decodificação de instruções
- PPC é complexo demais
- O objetivo inicial era colocar o emulador inteiro dentro dos 4 KB de ROM endereçáveis por padrão pelo 4004
Contornos na implementação do emulador MIPS
- Só a decodificação das instruções MIPS já consumia bastante espaço de ROM
- A dispatch table de 64 opcodes de topo exigia 128 bytes
- Incluindo subtabelas adicionais, a decodificação principal exigia 359 bytes
- Os 32 registradores de 32 bits do MIPS totalizam 1024 bits, ou 256 nibble na perspectiva do 4004, ocupando um banco inteiro de RAM
- O TLB do MIPS originalmente tem 64 entradas, mas como o Linux não exige exatamente 64, ele foi reduzido para 16 entradas
- O número de entradas do TLB foi projetado para também permitir configurações de 4, 8, 12 e 16 entradas
- Como o 4004 não tem operações lógicas, AND/OR/XOR/NOR foram implementados com soma e carry, shift e loops
- Mais tarde, depois que o espaço de ROM aumentou, isso foi otimizado com uma lookup table de 256 entradas
- Shift também precisou ser implementado apenas com a instrução de rotação de 1 bit via carry do 4004, e depois foi melhorado com cópia por nibble e até 3 bit shifts
- O tratamento do registrador
$zerodo MIPS economiza espaço de ROM ao explorar a natureza circular da pilha de retorno do 4004- Quando o destino é
$zero, em vez de retornar, o fluxo segue para o processamento da próxima instrução, economizando 3 bytes e 3 ciclos por callsite
- Quando o destino é
ROM banking e melhorias de desempenho
- Como 4 KB de ROM não bastavam para incluir também o código de SD card, PSRAM, VFD e UART, foram usados 8 KB de ROM divididos em dois bancos
- A troca de banco de ROM é controlada por um pino de saída do 4002, e veneers foram colocados para permitir call/return entre bancos
- Depois que o espaço de ROM aumentou, tornou-se possível otimizar o desempenho
- AND/OR/XOR passaram a ser implementados cada um com uma lookup table de 256 entradas
- Com uma lookup table de multiplicação por nibble, multiplication ficou 8 vezes mais rápida do que a implementação anterior por bits
- A lookup table de operações lógicas explora a característica de que o JIN do 4004, quando está no fim de uma página de ROM, faz jump com base na próxima página
- A tabela de multiplicação foi implementada combinando a leitura de dados em byte da ROM via FIN com a evasão do tratamento da entrada 0
Configuração final do hardware
- A placa final foi projetada como uma art board focada em componentes through-hole com estética dos anos 1970
- Inclui trilhas grossas em ângulo reto, sem vias, furos para pendurar na parede e um display VFD
- Os principais componentes são os seguintes
- CPU 4004 ou 4040
- 4201 clock generator
- chips de RAM 4002
- 4289 ROM controller
- EEPROM
- 1 ou 2 SPI PSRAM
- slot para cartão SD
- SC16IS741A SPI UART
- VFD 40x2
- 32 LEDs indicadores do PC
- A SPI PSRAM é usada como RAM MIPS virtual
- A primeira PSRAM precisa ter pelo menos 4 MB, pois o kernel deve ser carregado de forma contínua
- A segunda PSRAM pode ficar vazia ou ser instalada com qualquer tamanho arbitrário de 128 KB ou mais
- Foi usado o VFD Futaba M402SD10FJ, e foi informado que o Noritake CU40025-UW6J é compatível
- O UART foi escolhido como o componente de montagem em superfície SC16IS741A por causa das limitações de controle de fluxo do MAX3100, que era um candidato a SPI UART through-hole
Alimentação e level shifting
- Os componentes MCS-04 usam tensões incomuns da família -15 V e lógica invertida
- Em termos de sistema, é mais simples pensar nisso como alimentação de -10 V e +5 V
- A placa recebe +5 V por um conector de borda USB-C e também gera +3,3 V e -10 V
- O regulador step-down de +3,3 V é baseado no LM2574
- A alimentação de -10 V foi alterada para uma configuração com MAX774, FET externo, diodo maior e indutor maior, porque o MAX764 da primeira revisão não conseguia fornecer corrente suficiente
- No fim, ela fornece mais de 700 mA em -10 V, com ripple inferior a 200 mV
- O level shifting para converter a saída do 4002 para o domínio de 3,3 V foi difícil, e foi resolvido com uma combinação de pulldown de 10K, resistor de 2,7K, clamp TVS e divisor resistivo
Ferramentas de depuração e defeito real
- Como o 4004 não tem funções de depuração embutidas, o barramento MCS-04 foi capturado por longos períodos com um Saleae Logic
- Foi escrito um decoder do barramento MCS-04 para analisar estado do barramento, endereço ROM, valor lido da ROM, disassembly e valores de leitura/escrita de RAM/I/O
- Depois, ele foi contribuído ao Saleae e incluído no software geral do Saleae
- Na placa revision 1.1, havia um problema em que os caracteres exibidos ocasionalmente saíam corrompidos
- Por exemplo,
iaparecia comoheCcomoB, como se o bit menos significativo desaparecesse
- Por exemplo,
- A análise confirmou que, durante o
memcpy()do kernel, no chip 4002 onde o$t1emulado era armazenado, o bit inferior de um determinado nibble às vezes caía de 1 para 0 - Depois de substituir esse 4002, a saída de texto voltou ao normal
Caminho de boot
- O firmware primeiro faz probe da quantidade de chips de memória no terceiro banco de RAM para determinar o número de entradas TLB
- Em seguida, inicializa o VFD, o UART e o cartão SD
- Se a inicialização do cartão SD falhar, exibe
"Failed to init SD card. Halting here and now!" - Essa é a única string em todo o firmware
- Se a inicialização do cartão SD falhar, exibe
- O firmware não usa ROM virtual; em vez disso, carrega o primeiro setor do cartão SD na RAM em
0x80000000e então salta para ele - O loader de 446 bytes do primeiro setor procura uma partição do tipo
0xBBna tabela de partições, lê para0x80001000e salta para lá - O segundo loader tem cerca de 14 KB e foi escrito em C
- Monta a partição ativa como FAT12/16/32
- Faz o parse de
vmlinuxcomo ELF, carrega na RAM e salta para o entrypoint - Passa machine type, magic value, mapeamento de RAM e uma tabela de callbacks para impressão no console inicial
Disco e acesso ao cartão SD
- O acesso a disco usa o driver de disco paravirtualizado PVD do projeto LinuxCard
- Em vez de emular um chip SII SCSI e um disco SCSI em assembly 4004, as hypercalls de leitura/escrita de setor funcionam como DMA do ponto de vista do MIPS virtual
- A RAM total da placa Linux/4004 é de 440 bytes incluindo os status nibbles, ou 352 bytes sem eles
- Como o estado dos registradores MIPS e a TLB ocupam uma parte grande cada um, não há espaço para um buffer de setor SD de 512 bytes
- Os dados de um setor SD não são colocados na RAM do 4004; em vez disso, são lidos diretamente para a PSRAM ou gravados da PSRAM para o SD usando barramentos SPI separados para o cartão SD e a PSRAM
- Ler ou gravar um setor SD leva pouco mais de 1 segundo
- Os requisitos de timing de inicialização ACMD41 da especificação SD não podiam ser atendidos com SPI bit-banged, mas os cartões SD testados foram inicializados mesmo em 5 KHz e com intervalos acima de 200 ms
Velocidade de execução e resultados das otimizações
- Depois de emular um cartão SD real e a SPI PSRAM, a estimativa inicial de boot era de 8,9 dias em um 4004 de 740 KHz
- Os principais resultados das otimizações foram os seguintes
- operações lógicas e multiplication lookup table: 8,4 dias
- loop unrolling das rotinas de envio/recepção de nibble da PSRAM: 7,25 dias
- cópia de memória especializada e loop unrolling: 6,63 dias
- remoção da área de armazenamento da instrução atual e rastreamento de liveness: 6,50 dias
- melhoria de shift: 6,19 dias
- loop unrolling do envio de endereços da PSRAM: 6,01 dias
- redução da configuração do kernel Linux, console dummy 1x1 e uso de tiny init: 5,33 dias
- remoção do suporte a block devices acima de 2 TB e desativação do recurso ext4
huge_files: 4,81 dias - fast path dedicado para instruction fetch: 4,76 dias
- O boot em 4,76 dias corresponde, em um 4004 de 740 KHz, a uma máquina MIPS de cerca de 70 Hz
- A placa construída usa o 4201 em modo divide-by-7 com um crystal de 5,5296 MHz e foi overclockada para 790 KHz
- O instruction mix do 4004 na placa Linux/4004 é de 8,8% de instruções de 16 ciclos e 91,2% de instruções de 8 ciclos, com velocidade efetiva de 90.640 instructions/s
- O timer interrupt virtual é de 16 Hz e entrega IRQ a cada 65.536 instruções virtuais, então a CPU virtual se percebe como rodando a 1,05 MHz
- O guest MIPS efetivamente emulado roda a cerca de 70 Hz em 740 KHz e cerca de 74,73 Hz em 790 KHz
- O tempo é esticado em 14.030 vezes, e 1 segundo virtual equivale a cerca de 3 horas e 54 minutos no mundo real
Configuração do Linux e experiência de uso
- O kernel Linux foi reduzido para cerca de 2,5 MB ao remover subsistemas, filesystems e configurações desnecessárias, como TCP/IP
- Usar apenas
init=/bin/shdeixaria o sistema sem session,$PATH,/proc,/sysetc., então foi criado o tiny init/sbin/uMIPSinit- Monta
/proce/sys - Define o hostname e o
$PATH - Executa o
shnovamente toda vez que ele termina
- Monta
- Mesmo com apenas 4,5 MB de RAM, por exemplo um chip de 4 MB + um chip de 512 KB, é possível dar boot até o prompt do shell sem swap
- Com swap ativado, é possível compilar o código-fonte do kernel no próprio dispositivo
- Espera-se que o build do código-fonte do kernel leve vários anos
- O plano é usar o journal do ext4 para, mesmo que a energia caia, recuperar o filesystem após o reboot e reiniciar a compilação
Objetivo como art board
- Este projeto teve desde o início um objetivo artístico em parte
- A placa foi projetada para poder ser pendurada na parede e tem VFD, layout de PCB em estilo retrô e LEDs de PC
- Ela inclui um programa que desenha o conjunto de Mandelbrot em modo texto no VFD e na porta serial
- A versão com ponto flutuante
/root/mandelbrotleva cerca de 30 dias para desenhar uma imagem de 13 linhas x 40 colunas, porque o Linux precisa emular operações de ponto flutuante - A versão apenas com inteiros
/root/mandelbrot_nofptermina em menos de 9 horas
- A versão com ponto flutuante
Custo dos componentes e reprodutibilidade
- Como um objetivo importante era permitir que outras pessoas reproduzissem o projeto, o 4265 foi evitado por ser difícil de encontrar
- O 4201 foi escolhido por ser mais simples que um circuito de clock alternativo, e o 4289 foi escolhido por ser mais fácil de obter do que a combinação 4008+4009
- A placa foi projetada para também aceitar um 4040 no lugar do 4004, e como os recursos extras do 4040 não são usados, a compatibilidade com o 4004 é mantida
- Os chips 4002 para a TLB podem ser instalados em quantidades de 1, 2, 3 ou 4, permitindo usá-los como TLBs de 4, 8, 12 ou 16 entradas, respectivamente
- Um número menor de entradas na TLB reduz o desempenho
- Esse banco também é responsável pelos 16 bits mais altos dos LEDs de exibição do PC, então, se apenas parte deles for instalada, alguns LEDs não funcionarão
- Componentes da década de 1970 são caros
- 4004: cerca de $250
- 4040: cerca de $60
- 4201: cerca de $50
- 4002-1: cerca de $7
- 4002-2: cerca de $25
- 4289: cerca de $70
- Componentes modernos são relativamente baratos, e o SPI VFD pode ser difícil de encontrar, mas houve um caso de compra por $15 no eBay
- Também há suporte para uma configuração sem o VFD instalado, interagindo apenas pela porta serial
Processo de produção do vídeo
- A cena real de boot foi fotografada ao longo de cerca de 9 dias para virar um vídeo
- Tirando fotos em 1920x1080 a cada 2 segundos, são gerados cerca de 1,76 GB por hora, e 9 dias de captura resultam em cerca de 379 GB e aproximadamente 388 mil arquivos
- Dispositivos Android tiveram problemas de travamento ou superaquecimento durante capturas longas, e o iPhone SE3 era estável para fotografar, mas havia problemas de espaço de armazenamento e de descarregar as fotos
- No fim, foi usado um iPhone 12 Pro Max de 512 GB para capturar tudo continuamente, depois ele foi montado no Linux com ifuse, e cerca de 400 mil arquivos foram copiados com
cp -Rvfao longo de mais de 10 horas - O vídeo final foi produzido com comandos do ffmpeg, e os trechos tediosos receberam velocidade variável
- A velocidade de reprodução varia de 5 FPS, ou seja, 10x em tempo real, até 960 FPS, ou seja, 1920x em tempo real
- Uma versão separada, sem edição, usa captura a 0,5 FPS e reprodução a 60 FPS, resultando em 120x em tempo real
Materiais publicados e licença
- A imagem de disco para o cartão SD é fornecida como download separado
- O download principal inclui o seguinte
- MCS-04 bus analyzer para o software Saleae
- código-fonte do emulador i4004 DECstation 2100
- código-fonte do MIPS MBR e do bootloader de segundo estágio
- config do kernel e informações de versão
- código-fonte do emulador u4004 para a placa Linux/4004
- A licença é gratuita para uso não comercial, e o uso comercial exige uma licença separada
- Em qualquer tipo de uso, é preciso dar crédito ao criador original nas formas source e binary
2 comentários
Então o autor original é aquele sujeito que desta vez foi retirado do palco na DEF CON por causa do badge. Não vou tomar partido, mas a habilidade dele é realmente impressionante.
Comentários do Hacker News
Uau, eu achava que o NetBSD moderno já era lento em um m68030 de 15 MHz, barramento de memória de 16 bits e 10 MB de RAM, mas isso aqui é realmente insano
Isso mostra bem que, quando os computadores começaram a ter armazenamento permanente, espaço de endereçamento aberto e MMU, no fim dos anos 80 e começo dos 90, eles basicamente chegaram à computação moderna
Um Amiga 3000 ou um computador i80486 também consegue executar as mesmas coisas que um computador moderno; hoje eles rodam muito mais rápido, ou têm coisas como GPUs que não existiam na época, mas funcionalmente não há grande diferença
É legal ver o Dmitry mostrando o quanto dá para definir de forma flexível a palavra funcional
As jogadas eram enviadas por correio de verdade, e uma partida podia levar meses ou anos
Quando a resposta chegava, você podia já ter esquecido a estratégia original, o que acrescentava outro nível de dificuldade ao xadrez; este projeto é basicamente um Linux por correspondência
Quando a saída do comando aparecer, você pode já ter esquecido por que executou aquele comando
Na verdade, isso já era possível por volta do fim dos anos 1960, não no fim dos anos 80/início dos 90
Acho que portar o Linux para um IBM Model 67 [1] também seria possível, e talvez até fácil, já que o GCC já consegue mirar esse conjunto de instruções
A MMU também é suficiente, e embora a limitação de no máximo 2 MB de memória de núcleo rápida seja apertada, ficaria numa categoria parecida com aquela máquina 68030, só um pouco mais lenta
Virtualização completa e limites de memória e E/S impostos por hardware também foram inventados cedo, mas esses recursos demoraram para chegar aos minicomputadores e microcomputadores, e demoraram muito mais ainda para o software popular tirar proveito deles
[1] https://en.wikipedia.org/wiki/IBM_System/360_Model_67
Qualquer sistema Turing-completo pode executar qualquer coisa; pode ser extremamente lento, mas executa
Com tempo suficiente, até o ChatGPT poderia rodar em um 4004
É meio como colocar um carro numa roda: você ganha mais três rodas
O crachá da Hackaday Supercon 2002 (https://hackaday.com/2022/10/12/the-2022-supercon-badge-is-a...) implementava uma CPU virtual de 4 bits e um painel de controle em que era possível inserir instruções diretamente, executar e avançar passo a passo
O painel de controle tinha uma tela em que dava para ver uma página de memória bit a bit, então foi muito divertido implementar ali um jogo de tiro espacial
Também foi interessante comparar a arquitetura Voya4 com o 4004; havia compromissos parecidos, mas o Voya4 tem a vantagem de 50 anos de experiência em conjuntos de instruções de CPU
Só que a abordagem do dimitygr não funcionaria naquele crachá, porque a memória e a RAM ficam todas embutidas dentro do PIC24 que implementa o emulador da CPU
A propósito, CPUs de 4 bits ainda são fabricadas e usadas. Muitos controles remotos infravermelhos produzidos em massa são programados com MCUs de 4 bits. Veja a folha de dados em https://www.emmicroelectronic.com/sites/default/files/produc...
Quando me perguntavam se dava para rodar algo em uma máquina sem desempenho suficiente, eu costumava citar bastante o exemplo do AVR; agora tenho um novo exemplo para linkar
Pela frequência e pelo consumo de energia, fico curioso para saber quanta RF ele emite, e se daria para detectar e decodificar isso no waterfall de um SDR
Ainda estou lendo, mas, até este ponto, vi a palavra “soubroutine”, que parece ser um erro de digitação
Uau, esse projeto não deve ter saído barato. Graças aos colecionadores do eBay
E talvez tenha sido a única situação em que eu escolheria LCD em vez de VFD
Se fosse rodar uma compilação de vários anos, acho que, quando terminasse, o VFD estaria destruído por burn-in
Infelizmente, parece que o pessoal das universidades não lê muito o HN
Uau, impressionante
Dá para ver o que está em execução agora olhando os bits altos do PC
P.S.: Ainda assim, é mais rápido do que carregar um kernel por uma ISO virtual no IPMI horrível de um servidor pela internet ;D
nmnovmlinux, dá para mapear facilmente para as funções do kernelDepois de entrar no espaço de usuário, também dá para distinguir o binário principal (bem abaixo de 0x01000000) das bibliotecas compartilhadas (carregadas em endereços altos, perto de 0x77000000)
Tanto o boot quanto a execução eram dolorosamente lentos
Foi um texto realmente fascinante
Eu já tinha lido um pouco sobre o 4004, então sabia que era um chip estranho, mas o grau de esquisitice supera a imaginação
Agora fiquei com vontade de ver quão bem daria para construir uma CPU com a mesma contagem de transistores
Não é tão menor assim que um 6502, e acho que, se fosse de 8 bits, a programação seria muito mais fácil
A gravação do vídeo levou 9 dias, e foram 4 horas por segundo de emulação
E também fico curioso para saber por que estão usando Windows 95
Para o vídeo, eu precisava de um notebook com porta serial real, não USB
Esse notebook atendia aos requisitos e custou 20 dólares no eBay
Pessoalmente, acho o Windows 2000 o Windows mais bonito, então instalei para o vídeo de demonstração
Muito legal
Eu queria que meu conhecimento tivesse aumentado o suficiente para entender a maior parte deste projeto, mas, por enquanto, ele foi difícil demais para minhas habilidades limitadas em ciência da computação
Ainda assim, o destaque que consegui entender completamente foi “Section 14.b & 14.c - Getting the data...”
Bastaram apenas 400 mil arquivos, cerca de 275 fotos por dia durante 4 anos
Vivemos mesmo em uma época estranha: mesmo com desempenho de processamento, armazenamento e rede tão abundante, os apps de sincronização de mídia que parecem ser os mais usados travam ou sincronizam lentamente, o AirDrop falha, e nem existe uma função de UI para “selecionar tudo” :)
Algo assim precisa de um Prêmio Nobel
Poderiam acrescentar uma categoria de reconhecimento para aplicações estranhas e peculiares da ciência da computação
Na seção “Why MIPS?”, foi dito que “algumas são inevitavelmente lentas por causa de um modo de endereçamento ruim (RISCV)”; qual é o problema com o modo de endereçamento do RISC-V?
Em algumas instruções do RISC-V, os bits de valores imediatos não são armazenados de forma contínua
Nas instruções MIPS, os bits de valores como soma imediata, carregamento de constantes e desvios são sempre armazenados em ordem
No RISC-V, os bits às vezes ficam embaralhados
Por exemplo, em um desvio incondicional, os bits do deslocamento de destino são armazenados na ordem bit 19, bits 9-0, bit 10, bits 18-11
Em hardware, basta conectar os fios corretamente, então o custo de reordenar é praticamente zero; em software, porém, é preciso muita manipulação de bits para corrigir isso
O motivo de o RISC-V fazer assim é simplificar o projeto de hardware