0 pensou em “Uma introdução ao Assembly. No Apple IIgs.”
Tem um paralelo que acho interessante: antigamente gente “normal” usava BASIC, e ficava embasbacada com o desempenho quase mágico de assembly. Só que era ordens de magnitude mais difícil de programar, e exigia um conhecimento profundo não só da linguagem mas também do hardware subjacente, que era algo hermético mas cujos resultados faziam valer a pena.
Hoje em dia assembly é muito, muito menos relevante; gente “normal” programa em Java, C#, Objective-C, o pessoal mais pro usa C/C++ e assembly é um detalhezinho com que só quem mexe com drivers ou kernel se preocupa. Mas ainda existe algo que ocupa aquele nicho do assembly de antigamente, uma forma de desenvolver que lhe dá resultados absurdamente superiores aos que gente “normal” alcança, mas que é muito mais difícil e que exige um conhecimento maior de como o programa interage com o hardware: CUDA (e OpenCL).
Quem usa GPUs (o hardware 3D das placas de vídeo) para resolver problemas obtém desempenho tão brutalmente superior que em muitas áreas ninguém nem cogita usar outra coisa. Um exemplo é reconhecimento de imagens: desde que o primeiro cara que usou GPUs arregaçou a concorrência que todo mundo só pensa nisso: http://blogs.nvidia.com/blog/2014/09/07/imagenet/
Então pros nostálgicos que sentem saudades da época me que “assembly separava os meninos dos homens”, fica a dica: hoje é GPU/CUDA/OpenCL que dá poderes mágicos pra quem passa pelo sacrifício de entender como funciona e como usar. 🙂
Há alguns anos eu disse que se os Corel, Photoshop e AutoCADs da vida usassem a capacidade de processamento das placas de vídeo você só precisaria de um Pentium 3 🙂
Os programas vetoriais 2D (Corel, Adobe Illustrator, Inkscape) realmente não usam absolutamente nada, e por isso são tão lerdos. Isso está finalmente mudando, a NVIDIA agora suporta path rendering (os “gráficos vetoriais” do Corel e Ilustrator), a diferença de desempenho é brutal. Em breve saem versões com suporte a isso.
Em plataformas clássicas o assembly passa a ser uma opção interessante para se explorar um pouco mais o hardware que além de bem menos complexo do que nas plataformas atuais, está suficientemente documentado pra permitir que até mesmo a toupeira que agora escreve se atrever a fazer um jogo com razoável qualidade usando só assembly 🙂
Ah, sim, vida de 8-bit developer hoje em dia é melzinho na chupeta comparado com aquela época! 🙂 Só de ter documentação farta (até excessiva), assemblers, disassemblers, debuggers, emuladores, storage confiável e gente com quem trocar ideia já faz uma diferença gigantesca.
É por isso que eu acho bobo quem compara o Star Castle moderno para 2600 com o Yar’s Revenge (que foi o que deu pra fazer na época baseado no mesmo arcade); é covardia comparar a facilidade que se tem hoje com o trabalho de quem foi pioneiro nos 1980s.
No VIC 20 ate no BASIC voce precisava conhecer o hardware, pois nao existiam comandos especificos para manipulacao de som e graficos. Para mudar a cor de fundo da tela, por exemplo, usava-se POKE 36879,x ou para ajustar o volume POKE 36878,x. Para ler um caracter da tela dava-se um PEEK diretamente da memoria de video, ja que o BASIC tambem nao oferecia esta facilidade. Era simples e fazia o usuario entender como realmente funcionam os computadores. Considero as linguagens de hoje muitissimo mais complicadas do que o que faziamos na decada de 80.
Ter que usar POKE pra acessar recurso de hardware é só serviço PORCO da Commodore, exemplo de como o BASIC do VIC-20 (e do C64) é fraco. Não consigo ver isso como “recurso didático”, chamo só de precariedade mesmo. É como dizer que carro que dá defeito é bom porque faz o usuário a aprender mecânica…
E claro que as linguagens de hoje são muitíssimo mais complicadas que as de antigamente, é por isso que um programador sozinho hoje faz em 1/10 do tempo o que um time de 10 fazia nos 1980s. 😀
Existem alternativas extremamente didáticas e simples hoje em dia (um Arduino é melhor para aprender hardware que qualquer micro 8-bit, Scratch ou mesmo Python são linguagens para iniciantes melhores que qualquer BASIC), mas aí a gente foge do escopo, já que deixa de ser “retro”, e não quero discutir nostalgia alheia, não. 😀
Para voce entender melhor veja o manual que acompanhava o VIC 20. Ha uma otima explicacao sobre o mapeamento de memoria, como se comunicar com o hardware com muitos exemplos de programas. Isso era o manual basico, que vinha com todas as unidades. Por isso o susto ao passar para o Assembly ou linguagem de maquina era minimo.
Mas era outro tempo. A mentalidade era outra. O legal era fazer mais com menos e usar a criatividade. Todo garoto de 8 anos era um programador BASIC. O pessoal mais novo nao compreende isso.
O que o BASIC fez ao colocar uma linguagem de programacao mesmo que simples tao disponivel aos usuarios provavelmente nunca vai ser igualado. E isso merece todo o respeito.
Por frases como “para eu entender melhor” e “o pessoal mais novo nao compreende isso” eu imagino que você ache que eu sou novinho, né? 😀 Aos 9 eu programava em assembly Z80 num TK-85, pode ter certeza de que eu sei do que você está falando.
Eu respeito o aspecto histórico disso tudo (se não respeitasse não estaria comentando aqui no retrocomputaria), só estou dizendo que existe coisa melhor hoje (se você levantar o véu da nostalgia um pouquinho você enxerga). E não subestime o que a criançada programa hoje em dia, não deixa nada a dever pro que a gente fazia naquela época.
Me desculpe por isso, é que realmente pareceu pelo seu post.
No stress 🙂
Murilo, a “criançada” hj em dia, na sua gde maioria, n quer programar. A gente programava por diversão, por curiosidade, por prazer… E tb por n ter + nada o q fazer no computador, ou por n ter software. Aí íamos copiando código das páginas da MicroSistemas (o SourceForge – ou GitHub, q seja – da nossa geração), e modificando o programa “p/ ver no q ia dar”. Aprendemos muito assim.
Hj em dia a geração abecedário (é tanta letra, D, X, Y, Z, XPTO, sei lá) n tem interesse. Simplesmente eles tem outras coisas q atraem o seu interesse. Alguns tem interesse em coisas como Raspberry Pi, Arduino, servidores, redes, TCP/IP, Linux, segurança, shell script… Mas a maioria olha as disciplinas de programação no mínimo, enviesados.
Tem tb a falta do desafio: Uma das coisas q me desmotivou a programar p/ PC era q parecia q tudo já tinha sido feito. Claro, o Linux provou o contrário, mas aí eu já tinha desistido de ganhar a vida programando. E nos últimos 15 anos lecionei p/ adultos e adolescentes (inclusive disciplinas de programação), em escolas técnicas de informática (ensino médio) e faculdades.
Como recuperar isso? Davi Braben mostrou o caminho c/ o Raspberry Pi, resta estimular esse pessoal p/ largar o LoL de lado e escrever código. Afinal, como já disseram, “escrever código aberto é uma das melhores coisas que um ser humano pode fazer vestido”. =)
Ricardo, nos 1980s a fração que “queria programar” era irrisória. A maioria usava os microcomputadores como videogame com teclado mesmo (o MSX fez sucesso no Brasil porque ele tinha os melhores joguinhos). O único microcomputador da cidade em que cresci era o meu! Nós éramos exceções naquela época. Hoje em dia é a mesma coisa, a maioria da molecada não tem interesse nem dá conta de escrever código, ainda é algo de nicho.
Antigamente o interesse vinha de “controlar a televisão”, coisa que ninguém fazia (não tinha nem videocassete direito…). Hoje em dia isso é trivial e não desperta tesão nenhum mesmo não. E achar que “fazer joguim” tem graça também só entrega nossa idade, já existem mais joguinhos bacanas disponíveis do que as pessoas conseguem consumir.
O que deixa a molecada com brilho nos olhos hoje é computação *tangível*: automação, robótica, drones (e adjacências: impressão 3D…). É por isso que Arduino faz um sucesso estrondoso. É nisso que temos que investir se queremos incentivar disseminação de conhecimento e inovação tecnológica. Se antes aprendíamos a programar para fazer joguim, a molecada hoje aprende a programar para construir e controlar robôs, brinquedos, dispositivos domésticos, etc.
Tem um paralelo que acho interessante: antigamente gente “normal” usava BASIC, e ficava embasbacada com o desempenho quase mágico de assembly. Só que era ordens de magnitude mais difícil de programar, e exigia um conhecimento profundo não só da linguagem mas também do hardware subjacente, que era algo hermético mas cujos resultados faziam valer a pena.
Hoje em dia assembly é muito, muito menos relevante; gente “normal” programa em Java, C#, Objective-C, o pessoal mais pro usa C/C++ e assembly é um detalhezinho com que só quem mexe com drivers ou kernel se preocupa. Mas ainda existe algo que ocupa aquele nicho do assembly de antigamente, uma forma de desenvolver que lhe dá resultados absurdamente superiores aos que gente “normal” alcança, mas que é muito mais difícil e que exige um conhecimento maior de como o programa interage com o hardware: CUDA (e OpenCL).
Quem usa GPUs (o hardware 3D das placas de vídeo) para resolver problemas obtém desempenho tão brutalmente superior que em muitas áreas ninguém nem cogita usar outra coisa. Um exemplo é reconhecimento de imagens: desde que o primeiro cara que usou GPUs arregaçou a concorrência que todo mundo só pensa nisso:
http://blogs.nvidia.com/blog/2014/09/07/imagenet/
Então pros nostálgicos que sentem saudades da época me que “assembly separava os meninos dos homens”, fica a dica: hoje é GPU/CUDA/OpenCL que dá poderes mágicos pra quem passa pelo sacrifício de entender como funciona e como usar. 🙂
Há alguns anos eu disse que se os Corel, Photoshop e AutoCADs da vida usassem a capacidade de processamento das placas de vídeo você só precisaria de um Pentium 3 🙂
Os programas vetoriais 2D (Corel, Adobe Illustrator, Inkscape) realmente não usam absolutamente nada, e por isso são tão lerdos. Isso está finalmente mudando, a NVIDIA agora suporta path rendering (os “gráficos vetoriais” do Corel e Ilustrator), a diferença de desempenho é brutal. Em breve saem versões com suporte a isso.
https://developer.nvidia.com/nv-path-rendering-videos
Em plataformas clássicas o assembly passa a ser uma opção interessante para se explorar um pouco mais o hardware que além de bem menos complexo do que nas plataformas atuais, está suficientemente documentado pra permitir que até mesmo a toupeira que agora escreve se atrever a fazer um jogo com razoável qualidade usando só assembly 🙂
Ah, sim, vida de 8-bit developer hoje em dia é melzinho na chupeta comparado com aquela época! 🙂 Só de ter documentação farta (até excessiva), assemblers, disassemblers, debuggers, emuladores, storage confiável e gente com quem trocar ideia já faz uma diferença gigantesca.
É por isso que eu acho bobo quem compara o Star Castle moderno para 2600 com o Yar’s Revenge (que foi o que deu pra fazer na época baseado no mesmo arcade); é covardia comparar a facilidade que se tem hoje com o trabalho de quem foi pioneiro nos 1980s.
http://www.eurogamer.net/articles/2012-05-02-man-makes-star-castle-for-atari-2600-30-years-after-atari-said-it-couldnt-be-done
No VIC 20 ate no BASIC voce precisava conhecer o hardware, pois nao existiam comandos especificos para manipulacao de som e graficos. Para mudar a cor de fundo da tela, por exemplo, usava-se POKE 36879,x ou para ajustar o volume POKE 36878,x. Para ler um caracter da tela dava-se um PEEK diretamente da memoria de video, ja que o BASIC tambem nao oferecia esta facilidade. Era simples e fazia o usuario entender como realmente funcionam os computadores. Considero as linguagens de hoje muitissimo mais complicadas do que o que faziamos na decada de 80.
Ter que usar POKE pra acessar recurso de hardware é só serviço PORCO da Commodore, exemplo de como o BASIC do VIC-20 (e do C64) é fraco. Não consigo ver isso como “recurso didático”, chamo só de precariedade mesmo. É como dizer que carro que dá defeito é bom porque faz o usuário a aprender mecânica…
E claro que as linguagens de hoje são muitíssimo mais complicadas que as de antigamente, é por isso que um programador sozinho hoje faz em 1/10 do tempo o que um time de 10 fazia nos 1980s. 😀
Existem alternativas extremamente didáticas e simples hoje em dia (um Arduino é melhor para aprender hardware que qualquer micro 8-bit, Scratch ou mesmo Python são linguagens para iniciantes melhores que qualquer BASIC), mas aí a gente foge do escopo, já que deixa de ser “retro”, e não quero discutir nostalgia alheia, não. 😀
Para voce entender melhor veja o manual que acompanhava o VIC 20. Ha uma otima explicacao sobre o mapeamento de memoria, como se comunicar com o hardware com muitos exemplos de programas. Isso era o manual basico, que vinha com todas as unidades. Por isso o susto ao passar para o Assembly ou linguagem de maquina era minimo.
Mas era outro tempo. A mentalidade era outra. O legal era fazer mais com menos e usar a criatividade. Todo garoto de 8 anos era um programador BASIC. O pessoal mais novo nao compreende isso.
O que o BASIC fez ao colocar uma linguagem de programacao mesmo que simples tao disponivel aos usuarios provavelmente nunca vai ser igualado. E isso merece todo o respeito.
Por frases como “para eu entender melhor” e “o pessoal mais novo nao compreende isso” eu imagino que você ache que eu sou novinho, né? 😀 Aos 9 eu programava em assembly Z80 num TK-85, pode ter certeza de que eu sei do que você está falando.
Eu respeito o aspecto histórico disso tudo (se não respeitasse não estaria comentando aqui no retrocomputaria), só estou dizendo que existe coisa melhor hoje (se você levantar o véu da nostalgia um pouquinho você enxerga). E não subestime o que a criançada programa hoje em dia, não deixa nada a dever pro que a gente fazia naquela época.
Me desculpe por isso, é que realmente pareceu pelo seu post.
No stress 🙂
Murilo, a “criançada” hj em dia, na sua gde maioria, n quer programar. A gente programava por diversão, por curiosidade, por prazer… E tb por n ter + nada o q fazer no computador, ou por n ter software. Aí íamos copiando código das páginas da MicroSistemas (o SourceForge – ou GitHub, q seja – da nossa geração), e modificando o programa “p/ ver no q ia dar”. Aprendemos muito assim.
Hj em dia a geração abecedário (é tanta letra, D, X, Y, Z, XPTO, sei lá) n tem interesse. Simplesmente eles tem outras coisas q atraem o seu interesse. Alguns tem interesse em coisas como Raspberry Pi, Arduino, servidores, redes, TCP/IP, Linux, segurança, shell script… Mas a maioria olha as disciplinas de programação no mínimo, enviesados.
Tem tb a falta do desafio: Uma das coisas q me desmotivou a programar p/ PC era q parecia q tudo já tinha sido feito. Claro, o Linux provou o contrário, mas aí eu já tinha desistido de ganhar a vida programando. E nos últimos 15 anos lecionei p/ adultos e adolescentes (inclusive disciplinas de programação), em escolas técnicas de informática (ensino médio) e faculdades.
Como recuperar isso? Davi Braben mostrou o caminho c/ o Raspberry Pi, resta estimular esse pessoal p/ largar o LoL de lado e escrever código. Afinal, como já disseram, “escrever código aberto é uma das melhores coisas que um ser humano pode fazer vestido”. =)
Ricardo, nos 1980s a fração que “queria programar” era irrisória. A maioria usava os microcomputadores como videogame com teclado mesmo (o MSX fez sucesso no Brasil porque ele tinha os melhores joguinhos). O único microcomputador da cidade em que cresci era o meu! Nós éramos exceções naquela época. Hoje em dia é a mesma coisa, a maioria da molecada não tem interesse nem dá conta de escrever código, ainda é algo de nicho.
Antigamente o interesse vinha de “controlar a televisão”, coisa que ninguém fazia (não tinha nem videocassete direito…). Hoje em dia isso é trivial e não desperta tesão nenhum mesmo não. E achar que “fazer joguim” tem graça também só entrega nossa idade, já existem mais joguinhos bacanas disponíveis do que as pessoas conseguem consumir.
O que deixa a molecada com brilho nos olhos hoje é computação *tangível*: automação, robótica, drones (e adjacências: impressão 3D…). É por isso que Arduino faz um sucesso estrondoso. É nisso que temos que investir se queremos incentivar disseminação de conhecimento e inovação tecnológica. Se antes aprendíamos a programar para fazer joguim, a molecada hoje aprende a programar para construir e controlar robôs, brinquedos, dispositivos domésticos, etc.