Há algumas semanas postei o artigo sobre diferentes arquiteturas de processadores. A parte em que menciono que RISCs consomem mais RAM que CISCs acabou despertando o interesse do Anderson Rincon em realizar este benchmark para tirar a duvida já que possui computadores com as duas arquiteturas.
Em 25 passos concisos, você conhecerá o básico sobre a tecnologia do blockchain. Nenhuma fórmula matemática, código de programa ou jargão de ciência da computação será usado. Não são necessários conhecimentos prévios sobre ciência da computação, matemática, programação ou criptografia, pois a terminologia é explicada por meio de figuras, analogias e metáforas.
Este livro elimina a lacuna entre os livros puramente técnicos sobre blockchain e as obras que enfocam exclusivamente os negócios. Para isso, explicaremos tanto os conceitos técnicos que compõem o blockchain quanto as suas funções em aplicações relevantes aos negócios.
Você aprenderá:
• o que é o blockchain;
• por que o programa é necessário e quais problemas ele resolve;
• por que há tanta empolgação em relação ao blockchain e ao seu potencial;
• quais são os principais componentes e seus propósitos;
• como os componentes funcionam e interagem;
• quais são as limitações, por que elas existem e o que tem sido feito para superá-las;
• quais são os principais cenários das aplicações.
Sobre o autor:
Daniel Drescher é um profissional experiente na área bancária e já trabalhou com segurança de transações eletrônicas em diversos bancos. Suas atividades recentes tiveram como foco a automação, o aprendizado de máquina (machine learning) e big data no contexto de transações seguras. Entre outras realizações, Daniel tem doutorado em econometria pela Technical University de Berlim e mestrado em engenharia de software pela Universidade de Oxford.
A treta começa com um software chamado Raccoon. Raccoon é uma plataforma open source (sob os termos da licença Apache 2) e independente para download de aplicativos da Google Play Store. O objetivo é te dar acesso seguro aos aplicativos Android sem ter que comprometer o seu smartphone.
O problema quando as pessoas começaram a reportar bugs e recebiam a seguinte resposta como no exemplo mostrado em seu blog:
Usuário: Oi, eu gostaria de reportar um bug em sua aplicação.
Eu: Ótimo! Então por favor, abra um ticket de suporte.
Usuário: Mas, parece que eu preciso pagar por isso?
Eu: Daí?
Usuário: Eu só quero te dizer que seu app está quebrado, assim você pode concertar.
Eu: Sim, essa é uma solicitação de suporte, por favvor abra um ticket.
Usuário: ...
Pode parecer estranho a situação que acabaram de ler por estarmos acostumados a receber as coisas tudo de graça no mundo open source MAS, algo que eu sempre digo é:
Não confundam Free e open source software com Freeware.
A palavra inglesa free pode realmente confundir as pessoas uma vez que pode significar tanto livre quanto de graça. Por exemplo na frase food for free (comida de graça e não comida livre). porém a palavra free em free software refere-se a liberdade (daí software livre) enquanto que em freeware refere-se a de graça (software gratuito).
O problema é que a falta de leitura faz com que as pessoas que defendem software livre com unhas e dentes passem a condenar e abominar os que cobram por algum tipo de valor financeiro pelo serviço sendo que tudo isto já é previsto dentro das licenças (no caso da GPL é previsto a liberdade de distribuir cópias do software e até mesmo cobrar se achar interessante ou se desejar. Já a Apache 2 (que é open source) prevê no ultimo termo (termo nono) que você pode escolher oferecer e cobrar uma taxa por suporte, garantia, indenização e outros direitos). Ou seja, não há nada de errado no que o autor está fazendo.
Em seu blog o autor menciona que ele desenvolveu a aplicação para solucionar seu problema e consequentemente disponibilizou gratuitamente junto ao seu código fonte. Então, se o procurarem para reportar um bug, ou as pessoas podem enviar o patch incluso no bugreport ou pagar para que ele solucione o problema (o que é totalmente lógico). O autor diz fica feliz em ajudar, mas além do seu tempo ser valioso, vender o suporte é o que manter as luzes acesas já que aquilo deixou de ser livre quando começou a lhe custar algum valor como manter o servidor web funcionando.
As pessoas ainda não entenderam que o real sentido de software livre e de código aberto não se trata de receber e utilizar programas gratuitamente; trata-se de lhe oferecer condições de realizar o seu trabalho sem restrições. O que nos remete a celebre frase de Linus Torvalds:
Você suspira pelos bons tempos do Minix-1.1, quando os homens eram homens e escreviam seus próprios "device drivers"? Você está sem um bom projeto em mãos e deseja trabalhar num S.O. que possa modificar de acordo com as suas necessidades? Acha frustrante quando tudo funciona no Minix? Chega de noite ao computador para conseguir que os programas funcionem? Então esta mensagem pode ser exactamente para você. :-)
Pois é, era exatamente sobre poder realizar seu trabalho que Linus Torvalds estava se referindo. Na época, mesmo o Minix sendo de código aberto, possuía restrições em seu licenciamento onde não era permitido a modificação do seu código fonte. Ou seja, as pessoas estavam limitadas a o que podiam ou não fazer no Minix mesmo podendo visualizar o código e até serem capazes de melhorá-lo. Até que é compreensível e uma ideia interessante já que a intenção era aguçar a habilidade de programação. Mas essa ideia de qualquer jeito frustrava a maioria dos seus usuários (e foi exatamente isso que inspirou Linus a escrever tal frase).
Então uma dica muito interessante a ser dada aos que criticam esta atitude acreditando que, o que moralmente deveria ser feita, é disponibilizar o software (inclusive o código fonte) simplesmente é:
Desenvolva o seu projeto e o disponibilize gratuitamente e não ache queas pessoas devam fazer o mesmo simplesmente porque você acredita.
Então se você também quiser me ajudar, não esqueça de conferir o meu curso de migração para Linux e aprenda Linux de verdade comigo e assim você me ajuda a manter o meu canal e o meu blog ;)
A internet das coisas é um dos mais promissores e revolucionários conceitos presentes na ciência da computação. Porém, o conhecimento necessário para trabalhar com plataformas de hardware e microcontroladores nem sempre é de domínio de profissionais com carreira mais direcionada ao mundo do software. Sendo assim, existe uma lacuna que impede que esses desenvolvedores usufruam completamente essa nova onda da internet das coisas.
Este livro busca diminuir tal distância. O grande objetivo é mostrar ao leitor como podemos compartilhar as informações oriundas de sensores e interagir com atuadores, usando linguagens e plataformas com forte presença no mundo contemporâneo, como Java, JavaScript, Firebase e linguagem C.
O livro é de interesse, principalmente, para desenvolvedores de sistema que querem aplicar seus conhecimentos a fim de entrar de cabeça no mundo da Internet das Coisas. Porém, também tem forte apelo a profissionais com bastante conhecimento em plataformas como o Arduino, NodeMCU e Raspberry Pi, os quais desejam fazer o caminho inverso. Ou seja, saber mais sobre como integrar seu conhecimento e expandir o poder de suas placas microcontroladas.
Os principais assuntos abordados no livro são:
Arduino
Protocolo Firmata
Arduino e Java
Arduino e JavaScript
Johnny Five
ExpressJS
Temboo
Blynk
Wyliodrin
Android Things
Firebase
Sobre o autor
Ricardo da Silva Ogliari é bacharel em Ciência da Computação pela Universidade de Passo Fundo, especialista em Web: Estratégias de Inovação e Tecnologia pelo Senac SP e MBA em Desenvolvimento de Jogos e Aplicativos Móveis pela FIAP. Desenvolvedor mobile há mais de uma década. Professor em cursos de pós-graduação em instituições de ensino como Universidade de Passo Fundo, Senac e Faculdade de Pato Branco. Coautor do livro Android: do Básico ao Avançado. Palestrante em eventos nacionais e internacionais, como FISL, TDC, Campus Party, QCon e RubyConf. Autor de artigos para revistas nacionais como iMasters e Mobile Magazine.
Eu já escrevi uma série chamada "Dando uma olhada na arquitetura dos processadores" onde debato como o processador é constituído internamente (andei até mesmo dando uma atualizada tratando da arquitetura de Havard mostrando em que se difere da arquitetura de Von Neumann e pretendo adicionar mais coisas. Mas vamos deixar isso para o futuro Deus permitindo que eu faça).
O que é arquitetura de processador?
De acordo com o Dicionario de Termos da computação e da Internet (Dictionary of Computer and Internet Terms) arquitetura de processador é um conjunto de instruções que decodificam e executam operações aritméticas e lógicas. Esse conjunto de instruções são denominados ISA (Instruction Set Architecture) e, nas minhas palavras, arquitetura dos processadores é a forma como essas instruções são organizadas. Apesar de popularmente acabarmos tendo contato com apenas com X86, existe uma boa variedade de arquiteturas como CISC, RISC, EPIC e ZISC e Linux é uma fonte abundante para adquirir conhecimento sobre elas.
Dentro das arquiteturas existe uma gama de fabricantes diferentes. Então agora vamos estudar um pouco sobre as arquiteturas, suas variedades e aonde geralmente são aplicadas.
CISC
CISC (Complex Instruction Set Computers) é uma arquitetura construída com muitas instruções de linguagens de máquina diferentes. Tem como objetivo em seu design completar uma tarefa em poucas linhas de código assembly fazendo com que o compilador tenha pouco trabalho para traduzir o código de alto nível. O problema disso é que as suas tarefas acabam exigindo múltiplos ciclos, fazendo com que leve pelo menos duas vezes mais tempo para executá-las.
Ressalva, não confunda CISC com CICS. CICS (Costumer Information Control System) é uma extensão da IBM utilizada no IBM System Z que tem como objetivo tornar fácil escrever programas e permitir usuários entrar, recuperar e atualizar dados através do seu terminal (fortemente utilizado em sistemas de pontos de venda, reservas de hotel e sistemas de cobrança).
Popularmente conhecemos a arquitetura CISC devido aos x86 da Intel, da AMD e da Via (após ter adquirido a antiga Cyrix); mas há outras empresas que também já fabricaram processadores CISC difrentes de x86 como o VAX, o IBM System/370 e houve também o Motorola 6800 (também conhecido como m68k ou simplesmente 68k) na década de 80 que foi o primeiro processador de 32 bits amplamente utilizado e foi o processador do vídeo game Mega Drive, do Macintosh (pois é, a migração de PowerPC para Intel e depois de Intel para ARM não são as únicas experiencias que a Apple já teve em sua história), dos computadores da HP e da Sun Microsystem. Falando em Sun Microsystem, foi devido o Motorola 6800 que os desenvolvedores de SunOS tornaram o GCC funcional para uso em produção (o que até então, era simplesmente um compilador inviável).
Parece estranho afirmar, mas deve ser dito. Foi o x86 que tornou os PCs interessantes (especificamente o 386 a partir de 1986); mas historicamente o x86 parou de fazer sentido para o mercado há algum tempo. Basta repararmos como exemplo Apple em 2018 que vendeu 217.7 milhões de Iphones e 18.2 milhões de Macs (mais de 10 vezes mais dispositivos ARM, o que a chamou a sua atenção para abandonar o x86).
Abreviação de Reduced Instruction Set Computer (Computador com conjunto de instruções reduzidas) é a arquitetura que realiza processos de forma mais simplificada e que foi projetada para desempenho. Devido haver poucas instruções a serem escolhidas, ela leva menos tempo para identificá-las tornando os resultados mais eficientes e executando os processos mais rapidamente. Foi criada inicialmente na IBM por John Cocke e sua equipe de pesquisadores em 1.974 como controlador de central telefônica (a telefonia sempre tendo importância na computação)
John Cocke e o primeiro protótipo de computador RISC que o garantiu os premios Turing Award em 1987, the US National Medal of Technology em 1991 e o the US National Medal of Science em 1994.
A arquitetura RISC é tão interessante que há um ditado que diz que "O mundo é RISC". E não é de se duvidar já que a arquitetura é utilizada desde Supercomputadores como é o caso do Fugaku a microcontroladores como o H8/300 da Hitachi.
Alguns exemplos de processadores RISC são o Dec Alpha (primeiro processador de 64 bits e primeira arquitetura que Linux foi portado em Novembro de 1994); ARM que é muito famoso em dispositivos móveis devido a seu baixo consumo de energia conservando a bateria por mais tempo; Spark da Sun Microsystem (divisão da Oracle); o PowerPC (que foi desenvolvido pela IBM, Motrola e Apple para competir com a Intel e foi especialmente projetado para emular programas outros tipos de CPU eficientemente. Foi utilizado também no PlayStation 3, no Xbox 360 e consoles da Nintendo como Game Cube, Nintendo Wii e Nintendo Wii U e pelo sistema operacional OS/2); o MIPS, o Cris (utilizado em dispositivos de rede) e até mesmo a série de chips Super FX da empresa britânica Argonaut Games (adquirida pela Synopsy) que foi utilizado em jogos do Super Nintendo como o StarFox e Yoshi's Island possibilitando a renderização de centenas de polígonos 3D simultaneamente e desenhando efeitos em 2D.
Em Mario World 2: Yoshi's Island foi utilizado o chip Super FX 2 que é um Risc customizado e que possibilitou ao jogo ter elementos 3D e 2D (sim, o jogo é 2.5D), cores vivas e amplas, efeitos de iluminação, semitransparência e objetos passarem uns pelos outros).
RISC VS CISC
Ambos possuem vantagens e desvantagens e ambos conseguem executar os mesmos tipos de programa; o que vai diferenciar é como é o código de máquina do programa. A principio da leitura deste artigo, o RISC aparenta ser superior ao CISC, mas nem tudo são as mil maravilha.
RISC tende a ser mais rápido que CISC SE o acesso a memória for muito rápido; do contrário (se o acesso a memória for relativamente lento) o CISC tende a ser mais rápido que RISC. Além do mais, máquinas RISC tendem a buscar mais instruções da memória para realizar o mesmo trabalho que CISC (ou seja, utiliza-se mais RAM que CISC).
RISC híbrido
RISCs puros utilizam uma instrução por ciclo de clock. Foi aí que eu conheci a geração de RISCs hibridos que utilizam correção nas instruções de comprimento de 16 bits com registradores e endereço de espaço de 32 bits. Isso torna mais fácil para os compiladores gerarem melhores códigos RISC e retomam grande parte da densidade de código dos projetos CISC. Mais informações sobre chips híbridos podem ser conferidos clicando nesses dois links da Renesas e da Design & Recue.
A maioria dos fabricantes hoje tentam combinar as vantagens de cada arquitetura dentro dos seus processadores. A Intel por exemplo, introduziu através do Pentium a possibilidade de seu processador traduzir internamente instruções CISC em RISC (podendo executar duas instruções por ciclo assim como o RISC) e o J64 que planejam uma aproximação do x86-64 ao j4 com compatibilidade a 32 bits (seu design foi elaborado no ano passado). Portanto, dificilmente temos CISCs puros quanto RISCs puros assim como dificilmente encontramos kernel totalmente monolítico quanto totalmente micro-kernel.
A AMD também tinha um projeto de ARM chamado K12 focado em eficiência energética
Foi uma arquitetura RISC desenvolvida pela HP tendo uma ideia de arquitetura mais precisa (daí o PA do seu nome que é a silga de Precision Architecture) porém esse processador foi substituído pela arquitetura EPIC.
Abreviação de Explicitly Parallel Instruction Computing (Computação com instrução explicitamente paralela), foi criada em parceria entre a HP e a Intel para a criação da família Itanium (também conhecida como IA-64) para substituir o PA-RISC. Itanium foi desenvolvido como uma arquitetura de alto desempenho extremamente paralela realizando tal tarefa ao passar as instruções para o compilador que reorganiza o código para o máximo de paralelismo possível enquanto que o hardware foca em executar as instruções. E aqui mora o grande problema, nos compiladores que foi mais critico implementar do que a Intel esperava; o que resultou em um hardware muito caro e com baixa quantidade de software disponível para a arquitetura.
ZISC
ZISC (Zero instruction set computer) é uma arquitetura que se baseia nos princípios de correspondência de padrões e ausência de microinstruções. De acordo com documento de patentes do Google sobre circuito neural (ou neurochip ou redes neurais), essa é a arquitetura talvez mais apropriada para as tecnologias neurais devido a forma como trabalha.
DSP
DSP trata-se na verdade de um processador de sinal de digital (daí o seu nome Digital Signal Processor) que é utilizado para processar áudio (até redução de ruído) e vídeo e é fortemente utilizado em mesas de som e instrumentos musicais. Mas também foi utilizado em cartuchos do Super Nintendo para processar jogos como Super Mario Kart.
Talvez você deva estar pensando por que estou falando deste tipo de chip como uma arquitetura. Bom, a minha ideia era falar sobre DSP no mesmo artigo "Dando uma olhada na arquitetura de processadores" porque, assim como FPU que era chip separado e hoje é incorporado aos processadores, o mesmo pode ocorrer com os DSPs podendo o seu processador possuir instruções DSP adicionadas a ele. De acordo com informações do J-Core (que é um processador que eu acompanho bastante o seu desenvolvimento) as instruções DSP podem quebrar a pipeline do estilo do RISC e eles possuem um novo design de DSP em desenvolvimento.
alguns exemplos de DSP que o Linux possui suporte são o Hexagone o C6xda Texas Instrument.
Bom, finalizo este artigo por aqui acreditando já estar bom por enquanto dado uma boa base de estudo para todo mundo. Pode ser que eu venha atualizá-lo no futuro assim como faço com os demais artigos.
