Ocasionalmente alguém cai no meu blog procurando a "Biografia de Bill Gates". A biografia que eu conheço e lí é Gates de Stephen Mames e Paul Andrews. A história do surgimento da industria dos computadores pessoais (incluindo a Microsoft) pode ser lida em Fire in the Valley de Paul Freiberger e Michael Swaine.
Da leitura destes livros me veio uma imagem de Bill Gates diferente daquilo que a media normalmente apresenta. Sem dúvida ele tem grande conhecimento técnico e é um grande programador. Também é inegável o seu faro em reconhecer oportunidades. Entretanto, tudo isso me parece secundário frente ao que considero ter sido o principal motivador de Bill: fechar o negócio. Para mim é esta agressividade comercial a principal marca da Microsoft, pelo menos até o ano 2000. Agressividade esta que às vezes encrencou a Microsoft e que levou a práticas algumas vezes consideradas ilegais pela justiça americana.
Relato abaixo duas situações famosas, descritas em detalhes nos livros que citei, e que acredito reforçarem a minha opinião sobre Bill Gates.
O Surgimento da Microsoft
A maioria das pessoas já ouviu falar de como Paul Allen foi correndo mostrar para Bill Gates a edição de janeiro de 1975 da revista Popular Electronics que trazia na capa o Altair 8800 da MITS e neste momento os dois decidiram fazer um interpretador BASIC para ele. Muitos talvez saibam que Bill Gates ofereceu o produto para a Altair, apesar de não ter começado o desenvolvimento, e como a primeira versão foi construída rapidamente. O que poucos sabem é que este foi um mau negócio na ponta do lápis.
O Altair 8800 que aparecia na capa era um mockup de papelão (o protótipo, que não incluia ainda o famoso barramento S-100, foi perdido no transporte). Para aparecer na capa da revista, Ed Roberts (o dono da MITS) chutou um preço bem baixo e corria o risco de ter prejuizo. A solução era lucrar nos acessórios e o principal deles era a placa de memória. O kit original vinha com apenas 256 bytes de Ram, quem queria fazer algo sério precisava da placa de 4K e do BASIC da Microsoft. A placa de memória tinha uma margem imensa e um imenso problema: não funcionava. Não demorou muito para alguém se cansar da placa de memória da MITS, projetar uma e descobrir que dava para vender uma placa que funcionava por um preço bem inferior. Ed Roberts resolveu apelar para o seu trunfo: o BASIC. A MITS tinha um contrato de exclusividade do BASIC da Microsoft para processadores 8080 e compatíveis e Ed Roberts passou a vender o BASIC por $150 para quem comprasse a placa da MITS e $500 para os outros. A reação dos clientes foi a pirataria do BAISC, que resultou em uma famosa "Carta Aberta aos Hobistas" do Bill Gates.
A exclusividade da MITS estava prejudicando a Microsoft com mais que as baixas vendas do BASIC. Embora a Microsoft tivesse fechado acordo com outros fabricantes que usavam outros processadores, o primeiro grande negócio em vista era com a Tandy/Radio Shack cujo TRS-80 usava o Z80 que estava coberto pela exclusividade da MITS. Em meados de 1977 a Microsoft estava em dificuldades financeiras. A sorte da Microsoft foi que Ed Roberts tinha negligenciado itens básicos do acordo, inclusive não pagando os royalties combinados. Com base nisto a Microsoft conseguiu cancelar o acordo na justiça e fechar o negócio com a Tandy e equilibrar as contas.
O Sistema Operacional do PC-IBM
Quando a IBM resolveu desenvolver o seu computador pessoal, ela decidiu usar componentes de mercado, inclusive o BASIC da Microsoft e o sistema operacional CP/M da Digital Research. Como todos sabem o PC-IBM acabou sendo lançado com um sistema operacional da Microsoft, o MS-DOS.
Até o final de sua vida, Gary Kildall (dono da Digital Research) teve que agüentar a versão de que ele tinha ido passear em seu avião ao invés de atender a IBM. Na verdade, Kildall cuidava mais da parte técnica da Digital Research, quem cuidava dos contratos com os fabricantes de hardware era a sua esposa, Dorothy.
No dia da visita da IBM, Gary foi cumprir uma visita agendada anteriormente com outro cliente (pilotando realmente o seu avião) e Dorothy atendeu os representantes da IBM. Antes de dizer qualquer coisa, um advogado da IBM solicitou que ela assinasse um NDA (Non-Disclosure Agreement). Dorothy fez aquilo que todos nós sabemos ser o certo antes de assinar um documento: leu-o cuidadosamente. O documento era terrivelmente favorável à IBM. Dorothy fez aquilo que os advogados sempre recomendam: recusou-se a assinar e passou a negociar o texto do contrato. Embora este impasse tenha sido vencido, a relação entre a Digital Research e a IBM nunca foi boa. Também não ajudou nada o fato do CP/M-86 ter sido repetidamente adiado.
Como foi que Bill Gates se comportou quando a IBM entrou em contato com ele? A reação inicial dele foi: "a IBM é uma grande companhia". Ao contrário de Kildall, Gates se envolvia diretamente nas negociações. E não teve dúvidas em cancelar uma reunião com o chairman da Atari para atender a IBM, vestir um terno e gravata e convocar para a reunião um assistente - Steve Balmer. Ao ser apresentado o NDA, Bill Gates deu uma passada de olhos e assinou sem hesitar.
Enquanto que a diferença de cultura entre as empresas era um problema na relação entre a Digital Research e a IBM, Bill Gates se esforçava para agradar a IBM, apesar de tanto a Microsoft como a Digital Research terem um bando de hippies nos seus quadros. Quando, preocupada com os atrasos e os conflitos com a Digital Research, a IBM perguntou a Bill Gates se ele poderia fornecer também um sistema operacional, ele já tinha a resposta na ponta da língua (embora ainda não tivesse o produto).
terça-feira, março 27, 2007
segunda-feira, março 26, 2007
Construindo um Compilador - Parte 3
Vamos começar a estudar nesta parte como fazer um analisador sintático. Na parte anterior, usamos uma máquina de estados (também chamada de autômato finito) para fazer a análise léxica. Na máquina de estados do analisador léxico os itens léxicos são reconhecidos analisando a entrada sequêncialmente da esquerda para a direita.
Na análise sintática esta forma de operação não é suficiente. O reconhecimento de uma construção sintática requer o reconhecimento de vários trechos, não necessáriamente da esquerda para a direita. Além disso, é comum um item ser definido de forma recursiva. Consideremos este exemplo de linguagem, onde os itens léxicos são num, '*', '/', '+', '-', '(' e ')':
e vamos analisar o seguinte "programa fonte":
10 + ( 70 - 4 * 5 )
o reconhecimento dos vários itens léxicos e sintáticos gera um árvore:
A figura acima sugere duas estatégias básicas para a análise sintática:
Considerando a expressão de exemplo, teríamos os seguintes passos iniciais:
No próximo post vamos ver em detalhes como se implementa este algorítimo.
Na análise sintática esta forma de operação não é suficiente. O reconhecimento de uma construção sintática requer o reconhecimento de vários trechos, não necessáriamente da esquerda para a direita. Além disso, é comum um item ser definido de forma recursiva. Consideremos este exemplo de linguagem, onde os itens léxicos são num, '*', '/', '+', '-', '(' e ')':
e vamos analisar o seguinte "programa fonte":10 + ( 70 - 4 * 5 )
o reconhecimento dos vários itens léxicos e sintáticos gera um árvore:
A figura acima sugere duas estatégias básicas para a análise sintática:- análise ascendente, onde itens sintáticos mais complexos vão sendo reconhecidos a partir de itens sintáticos mais simples.
- análise descentente, onde se procura identificar itens sintáticos cada ver mais simples.
Considerando a expressão de exemplo, teríamos os seguintes passos iniciais:
- O nosso objetivo inicial é reconhecer uma expressão.
- O primeiro item de uma expressão tem que ser um termo, salvamos na pilha o ponto em que estamos no reconhecimento da expressão e passamos a tentar reconhecer um termo.
- O primeiro item de um termo tem que ser um fator, salvamos na pilha o ponto em que estamos no reconhecimento do termo e passamos a tentar reconhecer um fator.
- Um fator pode começar com um '(' ou com um número. No nosso caso encontramos o número '10' e com isto concluímos o reconhecimento de um fator.
- Retiramos da pilha o nosso objetivo. Estamos reconhecendo um termo, já reconhecemos um fator. As alteranativas seguintes são '*', '/' ou final do reconhecimento. Como o item seguinte é um '+', damos por encerrado o reconhecimento do termo.
- Voltamos assim ao reconhecimento da expressão. Já reconhecemos um termo, as alternativas seguintes são '+', '-' ou fim do reconhecimento.
- Como temos um '+', passamos a reconhecer um novo termo
No próximo post vamos ver em detalhes como se implementa este algorítimo.
quarta-feira, março 14, 2007
Três Livros Sobre C#
No ano passado incluí na minha coleção três livros sobre C# de características bem difererentes:
Pro C# 2005 and the .NET 2.0 Platform, Third Edition
Andrew Troelsen
Um livro bastante ambicioso, que tenta descrever a linguagem C#, a plataforma .Net e o framework .Net (e ainda encontra espaço para falar de conceitos gerais sobre programação orientada a objetos). É um livro imenso (ainda estou no primeiro terço), mas que gostaria de ter lido quando comecei a aprender C#. É claro que alguns assuntos como Windows Forms, ASP.Net, ADO.Net e Web Services ficam um pouco corridos (afinal existem livros inteiros sobre estes assuntos), mas é um dos poucos livros que explica bem o básico (no sentido de fundamento não de simples).
ASP.NET 2.0 Website Programming
Marco Bellinaso
A idéia do livro é ótima: descrever a construção de um site real do começo ao fim. Cada capítulo possui três partes: o problema, o projeto e a solução. Na primeira são descritos os requisitos, na segunda são discutidas as alternativas para atendê-los e na terceira é apresentado com detalhes a implementação adotada. O código todo está disponível para download (inclusive foi adotado como um dos exemplos pela Microsoft, veja aqui) e o site está on-line em http://www.dotnet2themax.com/thebeerhouse/.
O autor não foge de assuntos complexos nem economiza linhas de código e utiliza os recursos mais recentes do C# e do ASP.Net. O único porém é a diagramação do livro que deixa a leitura cansativa.
Altamente recomendado para quem desenvolver uma aplicação Web mais real que os Next/Next/Finish dos wizards do Visual Studio.
Visual C# 2005 - A Developer´s Notebook
Jesse Liberty
Este é um livro curto, que se concentra em algumas poucas (e importantes) novidades do C# 2.0 e Visual Studio 2005 e se destaca pela parte visual (imita um caderno com direito a um quadriculado de fundo e manchas de copo). O texto é muito bom, mas nem sempre muito profundo ou completo. Resumindo, é um livro extremamente agradável de ler, voltado para quem já conhece as versões anteriores do C# e quer se atualizar.
PS: Para quem está aguardando a terceira parte da série sobre Compiladores, peço um pouco de paciência, pois as coisas estão um pouco corridas.
Pro C# 2005 and the .NET 2.0 Platform, Third Edition
Andrew Troelsen
Um livro bastante ambicioso, que tenta descrever a linguagem C#, a plataforma .Net e o framework .Net (e ainda encontra espaço para falar de conceitos gerais sobre programação orientada a objetos). É um livro imenso (ainda estou no primeiro terço), mas que gostaria de ter lido quando comecei a aprender C#. É claro que alguns assuntos como Windows Forms, ASP.Net, ADO.Net e Web Services ficam um pouco corridos (afinal existem livros inteiros sobre estes assuntos), mas é um dos poucos livros que explica bem o básico (no sentido de fundamento não de simples).
ASP.NET 2.0 Website Programming
Marco Bellinaso
A idéia do livro é ótima: descrever a construção de um site real do começo ao fim. Cada capítulo possui três partes: o problema, o projeto e a solução. Na primeira são descritos os requisitos, na segunda são discutidas as alternativas para atendê-los e na terceira é apresentado com detalhes a implementação adotada. O código todo está disponível para download (inclusive foi adotado como um dos exemplos pela Microsoft, veja aqui) e o site está on-line em http://www.dotnet2themax.com/thebeerhouse/.
O autor não foge de assuntos complexos nem economiza linhas de código e utiliza os recursos mais recentes do C# e do ASP.Net. O único porém é a diagramação do livro que deixa a leitura cansativa.
Altamente recomendado para quem desenvolver uma aplicação Web mais real que os Next/Next/Finish dos wizards do Visual Studio.
Visual C# 2005 - A Developer´s Notebook
Jesse Liberty
Este é um livro curto, que se concentra em algumas poucas (e importantes) novidades do C# 2.0 e Visual Studio 2005 e se destaca pela parte visual (imita um caderno com direito a um quadriculado de fundo e manchas de copo). O texto é muito bom, mas nem sempre muito profundo ou completo. Resumindo, é um livro extremamente agradável de ler, voltado para quem já conhece as versões anteriores do C# e quer se atualizar.
PS: Para quem está aguardando a terceira parte da série sobre Compiladores, peço um pouco de paciência, pois as coisas estão um pouco corridas.
quarta-feira, março 07, 2007
Livro do Mês - Montenegro
Em torno da compra deste livro existe um história. No começo de dezembro, meu pai pediu de presente de Natal o livro "Casimiro Montenegro Filho A Trajetoria De Um Visionario" de Ozires Silva e Décio Fischetti. Procurando na internet, encontrei o livro nas Livrarias Cultura e Siciliano. Nos dois locais o livro estava com prazo de 6 dias úteis, porém a Siciliano tinha um preço um pouco menor e ofertas de parcelamento e frete grátis para compras acima de um certo valor.
Deste forma, resolvi comprar na Siciliano este livro junto com outros para dar de presente aos sobrinhos. Descobri também nas buscas a existência de um outro livro sobre o mesmo assunto: "Montenegro - As aventuras do marechal que fez uma revolução nos céus do Brasil" de Fernando Morais (autor de Olga e Chatô, que eu já tinha ouvido falar mas ainda não li). Resolvi surpreender meu pai e comprar os dois livros, o que me dava como vantagem adicional uma segurança extra no caso do livro não chegar a tempo para o Natal.
E realmente o livro não veio. Como desconfiei desde o começo, o prazo de 6 dias significava que o livro não estava em estoque e tinha que ser encomendado à editora. Por motivos que desconheço, a editora não entregou o livro à Siciliano (que me manteve informado sobre o atraso e desde o começo deu a opção de cancelar o pedido). A Livraria Cultura teve mais sucesso e o livro chegou até a ser objeto da "entrega foguete" (entrega no mesmo dia para São Paulo). Em meados de fevereiro resolvi entregar os pontos e cancelar o pedido na Siciliano e comprar da Cultura. Neste ponto a Cultura estava indicando prazo de 3 dias e poucas unidades em estoque (no momento está com prazo de 15 dias úteis). No lugar da entrega foguete as opções de frete eram expresso e normal. A entrega normal tinha um preço baixo (R$ 3) e um prazo razoável (3 dias) e foi minha opção. O livro chegou em dois dias via Sedex, de Porto Alegre (onde a Cultura tem uma loja).
Folheando o livro antes de entregar para o meu pai fiquei com a impressão de ser inferior ao do Fernando Morais, o que veio a ser confirmado pelo meu pai. Curioso sobre o assunto do livro, peguei emprestado o Montenegro do Fernando Marais para ler e é ele o "livro do mês" de fevereiro.
Montenegro - As aventuras do marechal que fez uma revolução nos céus do Brasil
O livro é a biografia de Casimiro Montenegro Filho, um cearense nascido em 1904 e foi o principal responsável pela criação do ITA (origem do interesse do meu pai).
O primeiro sentimento que me veio lendo o livro foi o meu grande desconhecimento da história do Brasil, talvez fruto de ter feito primário e ginásio numa época em que se ensinava que Tiradentes tinha a mesma aparência que Jesus. A história de Montenegro se entrelaça com a história do Brasil, dos acontecimentos que testemunhou na infância até a ditadura militar de 64 que o afastou do ITA, passando pelas revoluções de 30 e 32.
Na minha cabeça, o ITA era uma escola militar e uma fábrica de loucos. Nada sabia das idéias e motivos por trás da sua criação. Embora Montenegro fosse um militar, na sua concepção o ITA era um instituto primordialmente civil. Inspirado no MIT americano, o ITA foi uma tentativa de criação de um instituto de ensino de alto nível, com independência administrativa, para formar profissionais altamente qualificados e viabilizar o surgimento de uma industria aeronáutica nacional. A existência da Embraer é uma prova de que grande parte dos objetivos foram cumpridos (embora a independência nunca tenha vindo por completo e foi sufocada após o golpe de 64).
As dificuldades para a construção do ITA foram imensas. Burocracias, intrigas, invejas e paranoias se somaram à audácia de um idéia extremamente ambiciosa.
É bastante claro o esforço do autor em obter informações precisas sobre os fatos, não hesitando em apresentar múltiplas versões quando as pesquisas foram inconclusivas. O livro é bastante cativante, fazendo o leitor se apaixonar pela causa de Montenegro, passando a vibrar com as conquistas e sofrer com os reveses. Os inúmeros 'causos' relatados oferecem ao mesmo tempo um tom humorístico e uma idéia dos inúmeros contratempos enfrentados.
Na história de Montenegro estão elementos que continuam presentes: as intrigas políticas, a questão da educação, os sonhos de fazer no Brasil coisas no mesmo nível que o Primeiro Mundo.
Leitura altamente recomendada.
Deste forma, resolvi comprar na Siciliano este livro junto com outros para dar de presente aos sobrinhos. Descobri também nas buscas a existência de um outro livro sobre o mesmo assunto: "Montenegro - As aventuras do marechal que fez uma revolução nos céus do Brasil" de Fernando Morais (autor de Olga e Chatô, que eu já tinha ouvido falar mas ainda não li). Resolvi surpreender meu pai e comprar os dois livros, o que me dava como vantagem adicional uma segurança extra no caso do livro não chegar a tempo para o Natal.
E realmente o livro não veio. Como desconfiei desde o começo, o prazo de 6 dias significava que o livro não estava em estoque e tinha que ser encomendado à editora. Por motivos que desconheço, a editora não entregou o livro à Siciliano (que me manteve informado sobre o atraso e desde o começo deu a opção de cancelar o pedido). A Livraria Cultura teve mais sucesso e o livro chegou até a ser objeto da "entrega foguete" (entrega no mesmo dia para São Paulo). Em meados de fevereiro resolvi entregar os pontos e cancelar o pedido na Siciliano e comprar da Cultura. Neste ponto a Cultura estava indicando prazo de 3 dias e poucas unidades em estoque (no momento está com prazo de 15 dias úteis). No lugar da entrega foguete as opções de frete eram expresso e normal. A entrega normal tinha um preço baixo (R$ 3) e um prazo razoável (3 dias) e foi minha opção. O livro chegou em dois dias via Sedex, de Porto Alegre (onde a Cultura tem uma loja).
Folheando o livro antes de entregar para o meu pai fiquei com a impressão de ser inferior ao do Fernando Morais, o que veio a ser confirmado pelo meu pai. Curioso sobre o assunto do livro, peguei emprestado o Montenegro do Fernando Marais para ler e é ele o "livro do mês" de fevereiro.
Montenegro - As aventuras do marechal que fez uma revolução nos céus do Brasil
O livro é a biografia de Casimiro Montenegro Filho, um cearense nascido em 1904 e foi o principal responsável pela criação do ITA (origem do interesse do meu pai).
O primeiro sentimento que me veio lendo o livro foi o meu grande desconhecimento da história do Brasil, talvez fruto de ter feito primário e ginásio numa época em que se ensinava que Tiradentes tinha a mesma aparência que Jesus. A história de Montenegro se entrelaça com a história do Brasil, dos acontecimentos que testemunhou na infância até a ditadura militar de 64 que o afastou do ITA, passando pelas revoluções de 30 e 32.
Na minha cabeça, o ITA era uma escola militar e uma fábrica de loucos. Nada sabia das idéias e motivos por trás da sua criação. Embora Montenegro fosse um militar, na sua concepção o ITA era um instituto primordialmente civil. Inspirado no MIT americano, o ITA foi uma tentativa de criação de um instituto de ensino de alto nível, com independência administrativa, para formar profissionais altamente qualificados e viabilizar o surgimento de uma industria aeronáutica nacional. A existência da Embraer é uma prova de que grande parte dos objetivos foram cumpridos (embora a independência nunca tenha vindo por completo e foi sufocada após o golpe de 64).
As dificuldades para a construção do ITA foram imensas. Burocracias, intrigas, invejas e paranoias se somaram à audácia de um idéia extremamente ambiciosa.
É bastante claro o esforço do autor em obter informações precisas sobre os fatos, não hesitando em apresentar múltiplas versões quando as pesquisas foram inconclusivas. O livro é bastante cativante, fazendo o leitor se apaixonar pela causa de Montenegro, passando a vibrar com as conquistas e sofrer com os reveses. Os inúmeros 'causos' relatados oferecem ao mesmo tempo um tom humorístico e uma idéia dos inúmeros contratempos enfrentados.
Na história de Montenegro estão elementos que continuam presentes: as intrigas políticas, a questão da educação, os sonhos de fazer no Brasil coisas no mesmo nível que o Primeiro Mundo.
Leitura altamente recomendada.
terça-feira, março 06, 2007
Fontes do DOS para Download
De vez enquando dou uma olhada no statcounter para ver por onde as pessoas chegaram a este blog, tipicamente por uma busca no google.
Uma busca curiosa foi pelos fontes do DOS. Embora até onde eu saiba a Microsoft não publicou os fontes do MS-DOS, quem estiver curioso sobre como fazer um sistema compatível tem pelo menos duas opções:
Uma busca curiosa foi pelos fontes do DOS. Embora até onde eu saiba a Microsoft não publicou os fontes do MS-DOS, quem estiver curioso sobre como fazer um sistema compatível tem pelo menos duas opções:
- FreeDOS: um projeto de software livre, é usado pelo excelente DosBox para simular um PC antigo e permitir rodar programas antigos (particularmente jogos).
- DR-DOS: tem uma história longa e curiosa. A Digital Research era a lider dos sistemas operacionais para os computadores profissionais de 8 bits com o CP/M-80. No lançamento do PC, a IBM deu preferência ao MS-DOS. Após anos tentando sem sucesso vender o CP/M-86, a Digital Research aproveitou um momento em que a Microsoft estava ocupada com os projetos do Windows e do OS/2 para lançar o DR-DOS. Altamente compatível com o MS-DOS, o DR-DOS 5 vinha com utilitários adicionais e utilizava os recursos de gerenciamento de memória do 386. A resposta da Microsoft foi o MS-DOS 5 e uma série de ações que posteriormente foram julgadas anti-competitivas (alguns documentos a respeitos podem ser vistos aqui). A Novell adquiriu a Digital Research e lançou um bundle do DR-DOS 6 com um pacote de rede local peer-to-peer (durante toda a vida do MS-DOS, a comunicação via rede local sempre foi um item a parte e que era explorado por empresas como a Novell e a Lantastic). Apesar de todo este esforço, o DR-DOS nunca conseguiu decolar e entre várias mudanças de dono acabou tendo os fontes liberados para o uso não comercial.
segunda-feira, março 05, 2007
Construindo um Compilador - Parte 2
Nesta parte vamos ver como se constrói um analisador léxico. Como vimos na parte 1, ele é responsável por reconhecer os itens léxicos no fonte.
Itens léxicos típicos são identificadores de variáveis e rotinas, palavras reservadas, constantes e símbolos. Cada um destes itens se caracteriza por uma seqüência de caracteres que segue uma regra simples (por exemplo, "um identificador deve começar por uma letra e possuir somente letras e números"). Isto recomenda o uso de máquinas de estado para o reconhecer os itens léxicos. Toda vez que o analisador léxico é chamado para reconhecer o próximo item léxico, ele parte de um estado inicial e vai mudando de estado a cada caractere examinado, até reconhecer o item ou detectar uma seqüência inválida de caracteres (um "erro léxico").
Por exemplo, vamos considerar um caso simples, em que os itens léxicos são números inteiros decimais e as operações + e -. De uma forma livre, teríamos o seguinte analisador léxico na linguagem C:
Para não estender mais o código, não estamos guardando o valor do número (o que fica como exercício para o leitor). Reparar que eventualmente o código acima examina um caractere além do final do item e precisa "devolvê-lo". Tipicamente um analisador léxico não precisa guardar estados entre uma chamada e outra nem voltar atrás nos seus passos.
Algumas linguagens possuem idiossincrasias que dificultam o analisador léxico. Por exemplo, algumas versões do FORTRAN permitem colocar espaços no meio de identificadores, criando seqüências de difícil análise como:
Somente ao encontrar a vírgula o analisador léxico descobre que os itens léxicos são <DO> <10> <I> <=> (comando DO) ao invés de <DO10I> <=> (o que seria um comando de atribuição).
O analisador léxico é também responsável por desprezar os comentários nos fontes.
No caso de identificadores e palavras reservadas, a máquina de estado apenas isola a seqüência de caracteres. O analisador léxico precisa também identificar o item.
No caso das palavras reservadas, normalmente existe uma tabela ou lista onde a seqüência isolada deve ser procurada. Uma forma simples, mas ineficiente, é fazer uma busca seqüencial. Uma forma mais inteligente é ordenar previamente a lista e fazer uma busca binária.
Uma forma ainda melhor é usar hashing. No hashing, calcula-se um número (hash) a partir da seqüência de caracteres e usa-se este número como índice para a tabela.
O principal problema com o hashing é que várias seqüências podem gerar o mesmo hash (gerando uma colisão). Ao inserir um item numa tabela de hash, se a posição já estiver ocupada é preciso fazer uma lista ligada na posição para colocar o novo item. Ao fazer uma busca, é preciso fazer uma busca seqüencial nesta lista ligada.
Uma opção para diminuir as colisões é aumentar a faixa de valores para o hash, porém isto leva ao desperdício de memória. No caso das palavras reservadas, a lista é constante, o que permite escolher previamente uma função de hash que evite colisões. Por exemplo, pode-se criar uma função parametrizada e deixar um computador procurando exaustivamente os parâmetros que otimizem a função de hash.
Uma vez determinado que uma seqüência não é uma palavra reservada, o analisador léxico deve tentar descobrir o tipo de identificador. Isto é feito procurando a seqüência em tabelas de nomes de variáveis, funções, etc construída pelo analisador semântico. Estas tabelas podem usar o hashing para otimizar a busca. Um truque simples mas eficaz consiste ao encontrar um item na lista ligada da tabela de hash mover este item para o início da lista. Isto faz com que a lista automaticamente se ordene em função do uso dos itens.
Em algumas linguagens é permitido usar um identificador que ainda não foi declarado e portanto tem tipo ignorado. Isto não afeta o analisador léxico porém complica o analisador sintático e pode obrigar o analisador semântico a segurar a geração do código objeto até que o identificador seja declarado.
Na próxima parte vamos ver o coração do compilador, o analisador sintático.
Itens léxicos típicos são identificadores de variáveis e rotinas, palavras reservadas, constantes e símbolos. Cada um destes itens se caracteriza por uma seqüência de caracteres que segue uma regra simples (por exemplo, "um identificador deve começar por uma letra e possuir somente letras e números"). Isto recomenda o uso de máquinas de estado para o reconhecer os itens léxicos. Toda vez que o analisador léxico é chamado para reconhecer o próximo item léxico, ele parte de um estado inicial e vai mudando de estado a cada caractere examinado, até reconhecer o item ou detectar uma seqüência inválida de caracteres (um "erro léxico").
Por exemplo, vamos considerar um caso simples, em que os itens léxicos são números inteiros decimais e as operações + e -. De uma forma livre, teríamos o seguinte analisador léxico na linguagem C:
estado = INICIAL;
while (estado != FINAL)
{
c = ProximoCaracter();
switch (estado)
{
case INICIAL:
if (c == EOF)
{
item = EOF;
estado = FINAL;
}
else if (isdigit(c))
estado = NUMERO;
else if (c == '+')
{
item = MAIS;
estado = FINAL;
}
else if (c == '-')
{
item = MENOS;
estado = FINAL;
}
else if (!isspace(c))
{
item = ERRO;
estado = FINAL;
}
break;
case NUMERO:
if (c == EOF)
{
item = NUMERO;
estado = FINAL;
}
if (!isdigit(c))
{
DevolveCaracter(c);
item = NUMERO;
estado = FINAL;
}
}
}
Para não estender mais o código, não estamos guardando o valor do número (o que fica como exercício para o leitor). Reparar que eventualmente o código acima examina um caractere além do final do item e precisa "devolvê-lo". Tipicamente um analisador léxico não precisa guardar estados entre uma chamada e outra nem voltar atrás nos seus passos.
Algumas linguagens possuem idiossincrasias que dificultam o analisador léxico. Por exemplo, algumas versões do FORTRAN permitem colocar espaços no meio de identificadores, criando seqüências de difícil análise como:
DO 10 I = 1, 10
Somente ao encontrar a vírgula o analisador léxico descobre que os itens léxicos são <DO> <10> <I> <=> (comando DO) ao invés de <DO10I> <=> (o que seria um comando de atribuição).
O analisador léxico é também responsável por desprezar os comentários nos fontes.
No caso de identificadores e palavras reservadas, a máquina de estado apenas isola a seqüência de caracteres. O analisador léxico precisa também identificar o item.
No caso das palavras reservadas, normalmente existe uma tabela ou lista onde a seqüência isolada deve ser procurada. Uma forma simples, mas ineficiente, é fazer uma busca seqüencial. Uma forma mais inteligente é ordenar previamente a lista e fazer uma busca binária.
Uma forma ainda melhor é usar hashing. No hashing, calcula-se um número (hash) a partir da seqüência de caracteres e usa-se este número como índice para a tabela.
O principal problema com o hashing é que várias seqüências podem gerar o mesmo hash (gerando uma colisão). Ao inserir um item numa tabela de hash, se a posição já estiver ocupada é preciso fazer uma lista ligada na posição para colocar o novo item. Ao fazer uma busca, é preciso fazer uma busca seqüencial nesta lista ligada.
Uma opção para diminuir as colisões é aumentar a faixa de valores para o hash, porém isto leva ao desperdício de memória. No caso das palavras reservadas, a lista é constante, o que permite escolher previamente uma função de hash que evite colisões. Por exemplo, pode-se criar uma função parametrizada e deixar um computador procurando exaustivamente os parâmetros que otimizem a função de hash.
Uma vez determinado que uma seqüência não é uma palavra reservada, o analisador léxico deve tentar descobrir o tipo de identificador. Isto é feito procurando a seqüência em tabelas de nomes de variáveis, funções, etc construída pelo analisador semântico. Estas tabelas podem usar o hashing para otimizar a busca. Um truque simples mas eficaz consiste ao encontrar um item na lista ligada da tabela de hash mover este item para o início da lista. Isto faz com que a lista automaticamente se ordene em função do uso dos itens.
Em algumas linguagens é permitido usar um identificador que ainda não foi declarado e portanto tem tipo ignorado. Isto não afeta o analisador léxico porém complica o analisador sintático e pode obrigar o analisador semântico a segurar a geração do código objeto até que o identificador seja declarado.
Na próxima parte vamos ver o coração do compilador, o analisador sintático.
terça-feira, fevereiro 27, 2007
Construindo um Compilador - Parte 1
Esta série de posts foi instigada por uma mensagem no grupo C++ Brasil.
Minha primeira experiência em construir um compilador foi na faculdade. Lembro vagamente que era um compilador que gerava um programa para uma calculadora Texas a partir de uma linguagem parecida com Basic.
Recem formado, tive a oportunidade de participar de uma série de cursos na Scopus, não relacionados diretamente a projetos. Um deles foi A Construção de Um Compilador, lecionado pelo professor Valdemar Setzer. O material para este curso foi uma versão preliminar de um livro do próprio Setzer (em conjunto com Inês S Homem de Melo), que posteriormente viria a ser publicado pela Editora Campus.
Vários anos depois, tive a oportunidade de utilizar na prática estes conhecimentos, ao participar da definição e desenvolvimento de uma linguagem de script para o programa de comunicação Zapt da Humana Informática.
A forma de implementar um compilador que vou apresentar nestes posts se baseia diretamente no livro do Setzer. Obviamente vou ser bastante superficial nestes posts (o livro tem mais de 300 páginas).
O Que é Um Compilador?
Podemos dizer que um compilador é um programa que traduz um programa escrito em uma linguagem (linguagem fonte) para uma outra linguagem (linguagem objeto). Tipicamente a linguagem fonte é uma linguagem de alto nível e a linguagem objeto é o código de máquina.
Um parente próximo do compilador é o interpretador, que ao invés de gerar o programa em linguagem objeto ele o executa.
Um compilador pode não converter diretamente a linguagem fonte na linguagem objeto, ele pode ser composto de vários passos utilizando linguagens intermediárias. Um exemplo típico são compiladores que usam linguagem Assembly como uma linguagem intermediária.
Definindo Uma Linguagem
Tipicamente a definição de uma linguagem começa com os itens básicos para a escrita de programas: palavras reservadas, símbolos especiais, constantes e identificadores. Estes itens são denominados itens léxicos.
A forma como estes itens léxicos são combinados para gerar declarações, expressões e comandos em geral de uma linguagem é definida pela gramática da linguagem. Existem várias formas de se definir uma linguagem, algumas mais formais (como a notação BNF) e outras menso. Nestes posts vou usar os grafos sintáticos para descrever a gramática.
A definição da linguagem pode facilitar ou complicar a sua compilação. O método que será abordado é mais adequado para lingugens "bem comportadas".
Estrutura de Um Compilador
Tradicionalmente se divide o compilador em três grandes partes:
Minha primeira experiência em construir um compilador foi na faculdade. Lembro vagamente que era um compilador que gerava um programa para uma calculadora Texas a partir de uma linguagem parecida com Basic.
Recem formado, tive a oportunidade de participar de uma série de cursos na Scopus, não relacionados diretamente a projetos. Um deles foi A Construção de Um Compilador, lecionado pelo professor Valdemar Setzer. O material para este curso foi uma versão preliminar de um livro do próprio Setzer (em conjunto com Inês S Homem de Melo), que posteriormente viria a ser publicado pela Editora Campus.
Vários anos depois, tive a oportunidade de utilizar na prática estes conhecimentos, ao participar da definição e desenvolvimento de uma linguagem de script para o programa de comunicação Zapt da Humana Informática.A forma de implementar um compilador que vou apresentar nestes posts se baseia diretamente no livro do Setzer. Obviamente vou ser bastante superficial nestes posts (o livro tem mais de 300 páginas).
O Que é Um Compilador?
Podemos dizer que um compilador é um programa que traduz um programa escrito em uma linguagem (linguagem fonte) para uma outra linguagem (linguagem objeto). Tipicamente a linguagem fonte é uma linguagem de alto nível e a linguagem objeto é o código de máquina.
Um parente próximo do compilador é o interpretador, que ao invés de gerar o programa em linguagem objeto ele o executa.
Um compilador pode não converter diretamente a linguagem fonte na linguagem objeto, ele pode ser composto de vários passos utilizando linguagens intermediárias. Um exemplo típico são compiladores que usam linguagem Assembly como uma linguagem intermediária.
Definindo Uma Linguagem
Tipicamente a definição de uma linguagem começa com os itens básicos para a escrita de programas: palavras reservadas, símbolos especiais, constantes e identificadores. Estes itens são denominados itens léxicos.
A forma como estes itens léxicos são combinados para gerar declarações, expressões e comandos em geral de uma linguagem é definida pela gramática da linguagem. Existem várias formas de se definir uma linguagem, algumas mais formais (como a notação BNF) e outras menso. Nestes posts vou usar os grafos sintáticos para descrever a gramática.
A definição da linguagem pode facilitar ou complicar a sua compilação. O método que será abordado é mais adequado para lingugens "bem comportadas".Estrutura de Um Compilador
Tradicionalmente se divide o compilador em três grandes partes:
- Analisador Léxico: reconhece no fonte os itens léxicos
- Analisador Sintático: verifica se a sequência de itens léxicos contida no fonte está de acordo com a gramática da linguagem e reconhece as várias construções.
- Analisador Semântico: Gera o código objeto para as construções reconhecidas pala analisador sintático.
quarta-feira, fevereiro 21, 2007
Programação Assembly no ARM - Parte IV
Nesta parte vamos ver as instruções de acesso à memória. Como vimos na parte anterior, as instruções lógicas e aritméticas do ARM trabalham com operandos nos registradores. As instruções de acesso à memória no ARM são primordialmente a carga de um registrador em uma posição de memória e o armazenamento do conteúdo do registrador em uma posição da memória, conforme dita a filosofia RISC.
Estas instruções, denominadas de Single Data Transfer, são codificadas conforme a figura abaixo:
Note que embora sejam apenas duas instruções assembly, LDR e STR, existem uma grande quantidade de opções. Como sempre, o opcode contém uma condição. O bit L diferencia a instrução de Load (carga do registrador a partir da memória) da instrução de Store (armazenamento na memória do conteudo do registrador). Rd indica o registrador que receberá o valor lido (LDR) ou que contém o valor a ser armazenado (STR). O bit B indica se estamos manipulando um word (32 bits) ou byte (8 bits); existem instruções separadas para manipular valores de 16 bits (half-words). O resto dos campos do opcode determinam o endereço da posição de memória a ser manipulada.
Este endereço é determinado por duas partes: a base (que fica no registrador Rn) e o offset (que, conforme o bit I, pode ser um valor imediato de 12 bits ou o conteúdo de um registrador deslocado). O deslocamento do registrador usado para o offset é determinado de forma semelhante ao usado para o valor imediato nas instruções lógicas e aritméticas. O bit U indica se o offset deve ser somado ou subtraído da base.
O bit P determina se a combinação da base com o offset deve ser feita antes (pré-indexação) ou depois (pós-indexação) do acesso à memória. O bit W permite atualizar o registrador base com o valor final do endereço. Quando se especifica a pós-indexação, o ARM atualiza sempre o registrador base, para não alterá-lo deve-se colocar um offset de zero. Na prática, isto significa:
Onde B indica que é um acesso a byte.
<endereço> pode ser
Reparar que não é possível especificar diretamente um endereço qualquer da memória, pois o offset imediato tem 12 bits e um endereço tem 32 bits. Além disso, já vimos que as instruções lógicas e aritméticas são limitadas quanto aos valores imediatos que podem ser usados. Para carregar em um registrador um endereço ou constante qualquer, é preciso armazená-lo em memória em uma posição que possa ser acessada por um LDR. Isto torna frequente a presença de constantes no meio do código:
Para facilitar isto, o Assembler permite a seguinte construção:
Se possível, o assembler gera uma instrução MOV ou MVN para carregar o valor no registrador. Se isto não for possível, o assembler coloca a constante em um trecho próximo e gera uma instrução LDR usando endereçamento relativo ao PC.
Outras Instruções de Acesso à Memória
As instruções LDRH, LDRSH e STRH permitem carregar e armazenar valores de 16 bits (half word). A instrução LDRSH faz a "extensão do sinal", isto é, preenche os 16 bits mais significativos do registrador com o bit mais significativo do valor de 16 bits, de forma a manter o sinal do valor. O mesmo opcode permite também carregar em um registrador um valor de 8 bits com extensão de sinal (LDRSB). Estas instruções oferecem os mesmos recursos de endereçamento que LDR e STR.
As instruções LDM e STM (Block Data Transfer) permitem carregar ou armazenar um conjunto de registradores em posições contiguas de memória. A codificação destas instruções é apresentada abaixo:
Register list possui 16 bits, um para cada registrador. Os bits com 1 indicam os registradores a serem transferidos. O endereço inicial é obtido a partir de um registrador, que será automaticamente incrementado ou decrementado, antes ou depois de transferir cada registrador. O registrador utilizado pode ou não ser atualizado ao final da transferência.
A codificação em assembly destas instruções é:
Onde
Estas instruções, denominadas de Single Data Transfer, são codificadas conforme a figura abaixo:
Note que embora sejam apenas duas instruções assembly, LDR e STR, existem uma grande quantidade de opções. Como sempre, o opcode contém uma condição. O bit L diferencia a instrução de Load (carga do registrador a partir da memória) da instrução de Store (armazenamento na memória do conteudo do registrador). Rd indica o registrador que receberá o valor lido (LDR) ou que contém o valor a ser armazenado (STR). O bit B indica se estamos manipulando um word (32 bits) ou byte (8 bits); existem instruções separadas para manipular valores de 16 bits (half-words). O resto dos campos do opcode determinam o endereço da posição de memória a ser manipulada.Este endereço é determinado por duas partes: a base (que fica no registrador Rn) e o offset (que, conforme o bit I, pode ser um valor imediato de 12 bits ou o conteúdo de um registrador deslocado). O deslocamento do registrador usado para o offset é determinado de forma semelhante ao usado para o valor imediato nas instruções lógicas e aritméticas. O bit U indica se o offset deve ser somado ou subtraído da base.
O bit P determina se a combinação da base com o offset deve ser feita antes (pré-indexação) ou depois (pós-indexação) do acesso à memória. O bit W permite atualizar o registrador base com o valor final do endereço. Quando se especifica a pós-indexação, o ARM atualiza sempre o registrador base, para não alterá-lo deve-se colocar um offset de zero. Na prática, isto significa:
- P = 0, W = 0: normalmente tratado pelo ARM como P = 0, W = 1. (para ser preciso, no modo privelegiado em um processador com hardware de gerenciamento de memória esta combinação faz com que o endereço seja tratado como um endereço de usuário ao invés de endereço de sistema).
- P = 1, W = 0: combina base e offset para determinar o endereço, o registrador base fica inalterado. Útil, por exemplo, para acessar um item de um vetor (base é o endereço inicial e o offset é o deslocamento em relação ao início).
- P = 0, W = 1: usa somente a base para determinar o endereço, após o acesso à memória a base é atualizada com a combinação da base com o offset. Permite implementar em uma única instrução a construção *p++ do C (acessa a posição apontada pelo registrador base e o avança para o próximo item).
- P = 1, W = 1: combina base e offset para determinar o endereço, o registrador base é atualizado para o endereço usado. Permite implementar em uma única instrução a construção *++p do C (avança o registrador base para o próximo item e o acessa).
LDR{cond}{B} Rd,<endereço>
STR{cond}{B} Rd,<endereço>
Onde B indica que é um acesso a byte.
- uma expressão, que resulta em um endereço. O Assembler tenta montar uma instrução que combine um offset ao PC para obter este endereço, se não conseguir gerará um erro. Esta forma é útil para carregar em registradores constantes que estão armazenadas junto ao código.
- uma especificação de endereçamento pré-indexado (combina base e offset antes de acessar a memória):
- [Rn]
- [Rn,#expressão] {!}
- [Rn,{+/-}Rm{,<shift>}] {!}
- uma especificação de endereçamento pós-indexado (combina base e offset depois de acessar a memória):
- [Rn],#expressão
- [Rn],{+/-}Rm{,
}
nestes casos o registrador base é sempre atualizado.
A presença de ! indica que o registrador base deve ser atualizado (W = 1).
; coloca valores conhecidos em R1 e R2
MOV R1,#0
MOV R2,#4
; coloca em R0 o conteúdo da posição 0 da memória
LDR R0,[R1]
; coloca em R0 o conteúdo da posição 4 da memória
LDR R0,[R1,R2]
; coloca em R0 o conteúdo da posição 32 da memória
LDR R0,[R1,R2,LSL #3]
; idem
LDR R0,[R1+#32]
; coloca em R0 o conteúdo da posição 4 da memória
; R1 passa a ser 4
LDR R0,[R1,R2]!
; coloca em R0 o conteúdo da posição 4 da memória
; R1 passa a ser 8
LDR R0,[R1],R2
Reparar que não é possível especificar diretamente um endereço qualquer da memória, pois o offset imediato tem 12 bits e um endereço tem 32 bits. Além disso, já vimos que as instruções lógicas e aritméticas são limitadas quanto aos valores imediatos que podem ser usados. Para carregar em um registrador um endereço ou constante qualquer, é preciso armazená-lo em memória em uma posição que possa ser acessada por um LDR. Isto torna frequente a presença de constantes no meio do código:
...
LDR Rd,X ; usa endereçamento relativo ao PC
...
X .long valor ; em algum lugar próximo
Para facilitar isto, o Assembler permite a seguinte construção:
LDR Rd,=valor
Se possível, o assembler gera uma instrução MOV ou MVN para carregar o valor no registrador. Se isto não for possível, o assembler coloca a constante em um trecho próximo e gera uma instrução LDR usando endereçamento relativo ao PC.
Outras Instruções de Acesso à Memória
As instruções LDRH, LDRSH e STRH permitem carregar e armazenar valores de 16 bits (half word). A instrução LDRSH faz a "extensão do sinal", isto é, preenche os 16 bits mais significativos do registrador com o bit mais significativo do valor de 16 bits, de forma a manter o sinal do valor. O mesmo opcode permite também carregar em um registrador um valor de 8 bits com extensão de sinal (LDRSB). Estas instruções oferecem os mesmos recursos de endereçamento que LDR e STR.
As instruções LDM e STM (Block Data Transfer) permitem carregar ou armazenar um conjunto de registradores em posições contiguas de memória. A codificação destas instruções é apresentada abaixo:
Register list possui 16 bits, um para cada registrador. Os bits com 1 indicam os registradores a serem transferidos. O endereço inicial é obtido a partir de um registrador, que será automaticamente incrementado ou decrementado, antes ou depois de transferir cada registrador. O registrador utilizado pode ou não ser atualizado ao final da transferência.
A codificação em assembly destas instruções é:
LDM{cond}<fd|ed|fa|ea|ia|ib|da|db> Rn{!},<rlist>
STM{cond}<fd|ed|fa|ea|ia|ib|da|db> Rn{!},<rlist>
Onde
- {cond} é a condição em que a instrução será executada.
- FD, ED,..DB determinam os bits P e U. FD, ED, FA e EA são (respectivamente) idênticos a IA, IB, DA e DB; os primeiros são utilizados para documentar quando os registradores estão sendo transferidos para uma pilha.
- ! indica que o registrador Rn deve ser atualizado ao final
; salva todos os registradores em posições
; consecutivas a partir da apontada por R0
STMIA R0,{R0-R15}
; empilha os registradores (exceto R15/PC)
STMFD SP!,{R0-R15}
; Salva na pilha os registradores R1, R3 e R5
STMFD SP!,{R1, R3, R5}
; desempilha os registradores
LDMED SP!,{R0-R14}
terça-feira, fevereiro 06, 2007
Programação Assembly no ARM - Parte III
Continuando o nosso estudo das instruções, vamos examinar com mais detalhes o grupo de instruções de Data Processing. Este grupo contém as instruções aritméticas, lógicas e de movimentação. Estas instruções realizam uma operação sobre um ou dois operandos (Op1 e Op2) e colocam o resultado em um registrador (Rd) ou nos flags.
A figura abaixo mostra os vários campos do opcode destas instruções:
Na parte II nós já vimos os campos Cond e S. O campo Opcode determina a operação que será executada:
Portanto o campo Rd determina o registrador (R0 a R15) que será o destino do resultado da operação. As instruções TST, TEQ, CMP e CMN ignoram este campo. Como o único resultado destas operações é o posicionamento dos flags, o bit S é sempre forçado pelos assemblers.
Op1 é sempre um registrador e é definido por Rn; as instruções MOV e MVN ignoram o campo Rn.
Existem duas opções para a codificação do campo Operand 2.
1. Se I for 0, o segundo operando é um registrador, cujo conteúdo pode ser deslocado:
Este deslocamento pode de quatro formas:
2. Se I for 1, o segundo operando é um valor imediato (codificado na própria instrução):
O valor de 8 bits (Imm) contido na instrução é expandido para 32 bits colocando-se zeros à esquerda e em seguida rodado para a direita o dobro de vezes do especificado em Rotate. Como Rotate tem 4 bits, isto significa que o valor pode ser rodado 0, 2, 4, 8 .. 30 bits para a direita. Embora esta codificação permita colocar um grande variedade de constantes na instrução, uma quantidade ainda maior não tem como ser codificada. Neste caso o valor precisa ser armazenado em uma posição da memória e carregado para um registrador antes de executar a operação. Por exemplo, as constantes 0, 1, 0x100 e 0x110 podem ser codificadas mas 0x101 não.
Vejamos agora como escrever estas instruções na linguagem Assembly.
MOV e MVN
{cond}{S} Rd,
CMP,CMN,TEQ,TST
{cond} Rn,
AND,EOR,SUB,RSB,ADD,ADC,SBC,RSC,ORR,BIC
{cond}{S} Rd,Rn,
onde
é o mnemônico da instrução
{cond} é a condição (opcional)
{S} indica que pode ser acrescentado S para a instrução afetar os flags
pode ser Rm{,} ou <#expressão>
pode ser Rs ou #expressão
é ASL, LSL, LSR, ASR ou ROR
Rd, Rn, Rm e Rs são os registradores R0 a R15
Quando Op2 for especificado com #expressão, o assembler tentará codificá-lo em um valor imediato. Se não conseguir, acusará erro.
Vejamos se alguns exemplos esclarecem um pouco:
No próximo post da série vamos ver como acessar dados na memória. Até lá!
A figura abaixo mostra os vários campos do opcode destas instruções:
Na parte II nós já vimos os campos Cond e S. O campo Opcode determina a operação que será executada:
Opcode mne ação
0000 AND Rd := Op1 AND Op2
0001 EOR Rd := Op1 XOR Op2
0010 SUB Rd := Op1 - Op2
0011 RSB Rd := Op2 - Op1
0100 ADD Rd := Op1 + Op2
0101 ADC Rd := Op1 + Op2 + C
0110 SBC Rd := Op1 - Op2 + C - 1
0111 RSC Rd := Op2 - Op1 + C - 1
1000 TST posiciona flags conforme Op1 AND Op2
1001 TEQ posiciona flags conforme Op1 XOR Op2
1010 CMP posiciona flags conforme Op1 - Op2
1011 CMN posiciona flags conforme Op1 + Op2
1100 ORR Rd := Op1 OR Op2
1101 MOV Rd := Op2
1110 BIC Rd := Op1 AND NOT Op2
1111 MVN Rd := NOT Op2
Portanto o campo Rd determina o registrador (R0 a R15) que será o destino do resultado da operação. As instruções TST, TEQ, CMP e CMN ignoram este campo. Como o único resultado destas operações é o posicionamento dos flags, o bit S é sempre forçado pelos assemblers.
Op1 é sempre um registrador e é definido por Rn; as instruções MOV e MVN ignoram o campo Rn.
Existem duas opções para a codificação do campo Operand 2.
1. Se I for 0, o segundo operando é um registrador, cujo conteúdo pode ser deslocado:
Este deslocamento pode de quatro formas:- Lógico para a esquerda (LSL): desloca para a esquerda introduzindo zeros à direita
- Lógico para a direita (LSR): desloca para a direita introduzindo zeros à esquerda
- Aritmético para a direita (ASR): desloca para a direita repetindo o bit mais significativo na esquerda
- Rotação para a direita (ROR): desloca para a direita, introduzindo na esquerda os bits que 'saem' à direita
2. Se I for 1, o segundo operando é um valor imediato (codificado na própria instrução):
O valor de 8 bits (Imm) contido na instrução é expandido para 32 bits colocando-se zeros à esquerda e em seguida rodado para a direita o dobro de vezes do especificado em Rotate. Como Rotate tem 4 bits, isto significa que o valor pode ser rodado 0, 2, 4, 8 .. 30 bits para a direita. Embora esta codificação permita colocar um grande variedade de constantes na instrução, uma quantidade ainda maior não tem como ser codificada. Neste caso o valor precisa ser armazenado em uma posição da memória e carregado para um registrador antes de executar a operação. Por exemplo, as constantes 0, 1, 0x100 e 0x110 podem ser codificadas mas 0x101 não.Vejamos agora como escrever estas instruções na linguagem Assembly.
MOV e MVN
CMP,CMN,TEQ,TST
AND,EOR,SUB,RSB,ADD,ADC,SBC,RSC,ORR,BIC
onde
{cond} é a condição (opcional)
{S} indica que pode ser acrescentado S para a instrução afetar os flags
Rd, Rn, Rm e Rs são os registradores R0 a R15
Quando Op2 for especificado com #expressão, o assembler tentará codificá-lo em um valor imediato. Se não conseguir, acusará erro.
Vejamos se alguns exemplos esclarecem um pouco:
MOV R1,#100 ; coloca 100 em R1
MOVS R1,R0 ; coloca o conteúdo de R0 em R1, atualiza os flags
MOV R1,R0 ASL 5 ; coloca R0 * 32 em R1
MOV R1, R0 ROR R2 ; coloca em R1 o valor de R0 rodado para a direita de R2 bits
ADD R2,R1,R0 ; soma R1 a R0 e coloca o resultado em R2
ADD R1,R1,#1 ; incrementa R1
CMP R1,R2 ; compara R1 a R2, flags posicionados cf R1-R2
TST R1,#0x80000000 ; testa o bit mais significativo de R1
BIC R1,R1,#1 ; zera o bit menos significativo de R1
No próximo post da série vamos ver como acessar dados na memória. Até lá!
sexta-feira, fevereiro 02, 2007
Programação Assembly no ARM - Parte II
Nesta segunda parte vamos começar a falar sobre as instruções do ARM. Todas as instruções do ARM ocupam exatamente um word de 32 bits:
O primeiro ponto a reparar é como a codificação é uniforme em todas as instruções. Isto visa simplificar o hardware de decodificação das instruções e faz parte da filosofia RISC.
Um segundo ponto interessante é o campo Cond que aparece em todas as instruções. Este campo determina como devem estar os flags para a instrução ser executada. Na maioria dos processadores apenas as instruções de desvio dependem dos flags, no ARM todas as instruções são condicionais! A tabela abaixo mostra as condições disponíveis:
O sufixo na tabela acima deve ser acrescentado ao mnemônico da instrução a ser afetada; o sufixo AL pode ser omnitido (e normalmente é). Este sufixo fica obvio no caso de uma instrução de desvio: B (ou BAL) é um desvio incondicional, BEQ é um desvio se igual. As coisas ficam um pouco mais confusas com outras instruções, por exemplo LDREQ é uma instrução de Load Register que só é executado quando o flag Z estiver ligado.
Ainda na codificação das instruções, repare no bit S nas três primeiras linhas. Estas linhas codificam as instruções aritméticas, lógicas e de movimentação. O bit S indica se a instrução vai ou não afetar os flags. No Assembly, isto é feito acrescentando o sufixo S no mnemônico quando se deseja afetar os flags. Por exemplo, uma instrução AND não afeta os flags, mas ANDS afeta (é claro de ANDEQS afeta os flags somente quando for executada, o que só ocorre quando o flag Z está ligado).
E quais são as instruções disponíveis? A figura abaixo tem a lista completa:
Para podermos entender estas instruções é necessário conhecer primeiro como são codificados os operandos, o que veremos no próximo post.
O primeiro ponto a reparar é como a codificação é uniforme em todas as instruções. Isto visa simplificar o hardware de decodificação das instruções e faz parte da filosofia RISC.Um segundo ponto interessante é o campo Cond que aparece em todas as instruções. Este campo determina como devem estar os flags para a instrução ser executada. Na maioria dos processadores apenas as instruções de desvio dependem dos flags, no ARM todas as instruções são condicionais! A tabela abaixo mostra as condições disponíveis:
O sufixo na tabela acima deve ser acrescentado ao mnemônico da instrução a ser afetada; o sufixo AL pode ser omnitido (e normalmente é). Este sufixo fica obvio no caso de uma instrução de desvio: B (ou BAL) é um desvio incondicional, BEQ é um desvio se igual. As coisas ficam um pouco mais confusas com outras instruções, por exemplo LDREQ é uma instrução de Load Register que só é executado quando o flag Z estiver ligado.Ainda na codificação das instruções, repare no bit S nas três primeiras linhas. Estas linhas codificam as instruções aritméticas, lógicas e de movimentação. O bit S indica se a instrução vai ou não afetar os flags. No Assembly, isto é feito acrescentando o sufixo S no mnemônico quando se deseja afetar os flags. Por exemplo, uma instrução AND não afeta os flags, mas ANDS afeta (é claro de ANDEQS afeta os flags somente quando for executada, o que só ocorre quando o flag Z está ligado).
E quais são as instruções disponíveis? A figura abaixo tem a lista completa:
Para podermos entender estas instruções é necessário conhecer primeiro como são codificados os operandos, o que veremos no próximo post.
quinta-feira, fevereiro 01, 2007
Programação Assembly no ARM - Parte I
Atualmente é bastante raro eu programar em Assembly. Entretanto, pela segunda vez estou tendo que alterar um módulo de iniciação para um sistema embarcado utilizando um processador com arquitetura ARM. Não sei se é a falta de prática ou as pecularidades do ARM, mas nos dois casos suei muito para fazer as poucas linhas necessárias. Para tentar consolidar o meu aprendizado, resolvi fazer uma pequena serie de posts sobre o assunto.
O que é a arquitetura ARM?
Eu diria que a arquitetura ARM (que já foi chamadado de "Advanced RISC Machine" e "Acorn RISC Machine") é uma especificação dos registradores e instruções de máquina de um processador de 32 bits baseado na filosofia RISC (a Wikipedia tem uma definição mais longa).
Na verdade existem várias versões desta especificação, a que vou tratar aqui é chamada de ARM7TDMI. Esta especificação inclui um modo com instruções de 16 bits (Thumb) que vou ignorar nestes posts. A empresa responsável pelo ARM7TDMI licencia a sua implemantação para inclusão em vários microcontroladores, como os da Atmel e ST Microeletronics.
A descrição do ARM7DMI em formato pdf pode ser encontrada aqui.
São características RISC do ARM:
Existem inúmeros Assemblers disponíveis para o ARM, utilizando diversas sintaxes. A sintaxe que eu uso aqui é compatível com o GNU Arm Toolchain.
Os registradores do ARM
O ARM possui 16 registradores de 32 bits, denominados simplesmente de R0 a R15. O registrador R15 é sempre usado como ponteiro para a próxima instrução a executar e pode ser referenciado no Assembly como PC.
A função de chamada de subrotina salva o endereço de retorno no registrador R14, também chamado de link register (LR no Assembly).
O registrador R13 é normalmente usado como ponteiro de pilha (SP no Assembly). Entretanto, ao contrário de outros processadores, este uso é apenas convenção.
Por último, existe um registrador de status e flags, o CPSR, que é acessível apenas por instruções especiais.
No próximo post começaremos a ver as instruções.
O que é a arquitetura ARM?
Eu diria que a arquitetura ARM (que já foi chamadado de "Advanced RISC Machine" e "Acorn RISC Machine") é uma especificação dos registradores e instruções de máquina de um processador de 32 bits baseado na filosofia RISC (a Wikipedia tem uma definição mais longa).
Na verdade existem várias versões desta especificação, a que vou tratar aqui é chamada de ARM7TDMI. Esta especificação inclui um modo com instruções de 16 bits (Thumb) que vou ignorar nestes posts. A empresa responsável pelo ARM7TDMI licencia a sua implemantação para inclusão em vários microcontroladores, como os da Atmel e ST Microeletronics.
A descrição do ARM7DMI em formato pdf pode ser encontrada aqui.
São características RISC do ARM:
- As instruções são todas codificadas da mesma forma, ocupando sempre 32 bits
- Existem vários registradores e as instruções aceitam qualquer um deles como operando
- A memória é usada como operando somente para movimentação; operações aritméticas e lógicas usam registradores e constantes como operando
- A maioria das instruções são executadas em um único ciclo
Existem inúmeros Assemblers disponíveis para o ARM, utilizando diversas sintaxes. A sintaxe que eu uso aqui é compatível com o GNU Arm Toolchain.
Os registradores do ARM
O ARM possui 16 registradores de 32 bits, denominados simplesmente de R0 a R15. O registrador R15 é sempre usado como ponteiro para a próxima instrução a executar e pode ser referenciado no Assembly como PC.
A função de chamada de subrotina salva o endereço de retorno no registrador R14, também chamado de link register (LR no Assembly).
O registrador R13 é normalmente usado como ponteiro de pilha (SP no Assembly). Entretanto, ao contrário de outros processadores, este uso é apenas convenção.
Por último, existe um registrador de status e flags, o CPSR, que é acessível apenas por instruções especiais.
No próximo post começaremos a ver as instruções.
Comemoração
Já decidi como vou comemorar o meu aniversário de casamento este ano: lendo o último livro do Harry Potter. Comprei os dois últimos livros na Livraria Cultura, que entregou no dia do lançamento e por preço compatível com o da Amazon. Vamos ver se eles mantem esta tradição.
Agora só falta acertar com a "patroa"...
Agora só falta acertar com a "patroa"...
terça-feira, janeiro 30, 2007
sexta-feira, janeiro 26, 2007
Adventure - Parte III
No post anterior tinhamos parado no sucesso obtido pela Sierra com as suas séries de aventuras. Vamos falar agora sobre o principal concorrente da Sierra, que levou ao que poderíamos chamar de "época de ouro" dos jogos de aventura.
Esta empresa surgiu com o nome de LuscaFilm Games e depois passou a se chamar LucasArts. Para os eventuais desligados, o Lucas no nome se refere a George Lucas famoso pelos filmes Star Wars e Indiana Jones. Ele vislumbrou o surgimento dos computadores como uma nova media para o entretedimento e resolveu fincar o pé neste mercado.
Embora a LucasFilm Games tenha gerado jogos de diversos gêneros, seus principais sucessos na década de 90 foram as aventuras. As aventuras da LucasFilm se destacavam a partir dos seus roteiros, muito bem bolados. A implementação contava com gráficos e sons impecáveis, aproveitando os avanços constantes do hardware (vídeos EGA e VGA, placas de som, drive de CD).
O primeiro sucesso foi provavelmente Indiana Jones e a Última Cruzada, baseada no filme. Embora os gráficos e sons ainda fosse toscos no PC, já apresentava uma interface gráfica característica, dispensando a digitação. A aventura seguinte com Indiana Jones foi uma das mais marcantes para mim. Indiana Jones and the Fate of Atlantis possui um rotiro primoroso e inédito (que chegou a ser considerado para um filme). Os gráficos VGA 256 cores e a trilha sonora propriciam a imersão do jogador no ambiente do jogo. A dificuldade dos problemas estava no ponto certo, pelo menos no meu caso.
Uma outra série bem sucedida foi a da Ilha dos Macacos. Em termos de imaginação e roteiro, considero o primeiro jogo da série (The Secret of Monkey Island) o melhor. Com um humor muito refinado, é baseado em uma das atrações dos parques da Disney (como os filmes Piratas do Caribe). O segundo jogo da série (Le Chuck´s Revenge) possui uma quantidade muito maior de ambientes e se encerra com um final estranho e polêmico. O terceiro jogo da série (The Curse of Monkey Island) saiu muito tempo depois e não contou com o produtor original (Ron Gilbert). O estilo gráfico e a interface de operação foram bastante alterados neste terceiro jogo, mas não tanto como no quarto (e até o momento o último) jogo da série. Escape from Monkey Island apresenta gráficos 3D ('Indispensável o Uso de Placa de Vídeo Aceleradora 3D' está em destaque na caixa). O estilo do jogo também mudou e a sequência de luta no final foi muito criticada pelos fans do jogo.
A LucasArts fez um monte de outras aventuras, entre as quais:
Para quem quiser ver a qualidade dos jogos daquilo que chamei de "época de ouro", o site ScummVM é dedicado a um interpretador para os jogos desta época. Além do interpretador, o site contem alguns jogos comerciais completos; Flight of the Amazon Queen é bem representativo dos jogos VGA.
Esta empresa surgiu com o nome de LuscaFilm Games e depois passou a se chamar LucasArts. Para os eventuais desligados, o Lucas no nome se refere a George Lucas famoso pelos filmes Star Wars e Indiana Jones. Ele vislumbrou o surgimento dos computadores como uma nova media para o entretedimento e resolveu fincar o pé neste mercado.
Embora a LucasFilm Games tenha gerado jogos de diversos gêneros, seus principais sucessos na década de 90 foram as aventuras. As aventuras da LucasFilm se destacavam a partir dos seus roteiros, muito bem bolados. A implementação contava com gráficos e sons impecáveis, aproveitando os avanços constantes do hardware (vídeos EGA e VGA, placas de som, drive de CD).
O primeiro sucesso foi provavelmente Indiana Jones e a Última Cruzada, baseada no filme. Embora os gráficos e sons ainda fosse toscos no PC, já apresentava uma interface gráfica característica, dispensando a digitação. A aventura seguinte com Indiana Jones foi uma das mais marcantes para mim. Indiana Jones and the Fate of Atlantis possui um rotiro primoroso e inédito (que chegou a ser considerado para um filme). Os gráficos VGA 256 cores e a trilha sonora propriciam a imersão do jogador no ambiente do jogo. A dificuldade dos problemas estava no ponto certo, pelo menos no meu caso.
Uma outra série bem sucedida foi a da Ilha dos Macacos. Em termos de imaginação e roteiro, considero o primeiro jogo da série (The Secret of Monkey Island) o melhor. Com um humor muito refinado, é baseado em uma das atrações dos parques da Disney (como os filmes Piratas do Caribe). O segundo jogo da série (Le Chuck´s Revenge) possui uma quantidade muito maior de ambientes e se encerra com um final estranho e polêmico. O terceiro jogo da série (The Curse of Monkey Island) saiu muito tempo depois e não contou com o produtor original (Ron Gilbert). O estilo gráfico e a interface de operação foram bastante alterados neste terceiro jogo, mas não tanto como no quarto (e até o momento o último) jogo da série. Escape from Monkey Island apresenta gráficos 3D ('Indispensável o Uso de Placa de Vídeo Aceleradora 3D' está em destaque na caixa). O estilo do jogo também mudou e a sequência de luta no final foi muito criticada pelos fans do jogo.
A LucasArts fez um monte de outras aventuras, entre as quais:
- Loom - uma aventura inovadora mas que não teve sucesso suficiente para ter continuações
- Manic Mansion e Day of the Tentacle - duas aventuras de Ron Gilbert que não tive a oportunidade de conhecer
- The Dig - uma aventura de ficção científica, baseada em um roteiro de Steven Spielberg. O jogo é um pouco prejudicado pela instabilidade da plataforma (DOS Extender) e por pistas muito estranhas para os problemas.
- Sam e Max Hit The Road - uma aventura muito louca, que teve uma continuação cancelada em 2004 pela LucasArts. Os projetistas estão lançando em capítulos um novo jogo com os personagens.
- Grim Fandango - a primeira aventura da LucasArts em 3D, apesar de ter sido um sucesso com a crítica suas vendas foram consideradas baixas pela LucasArts.
Para quem quiser ver a qualidade dos jogos daquilo que chamei de "época de ouro", o site ScummVM é dedicado a um interpretador para os jogos desta época. Além do interpretador, o site contem alguns jogos comerciais completos; Flight of the Amazon Queen é bem representativo dos jogos VGA.
quinta-feira, janeiro 18, 2007
Livros de Dezembro
Embora o tempo estivesse curto para postar, deu para ler alguns livros.
O primeiro foi Fifth Planet, um livro obscuro de Fred e Geoffrey Hoyle. Fred Hoyle foi um astrônomo famoso e autor de um clássico da ficção científica - The Black Cloud. Em Fifth Planet, escrito em conjunto com o filho Geoffrey, aparecem alguns pontos em comum com The Black Cloud: cientistas ganhando espaço no governo, a Inglaterra em destaque no mundo e o contato com uma inteligência extra-terrestre. O livro foi escrito no começo dos anos 60 e a guerra fria tem um certo destaque que hoje soa estranho. No final das contas, uma leitura bem agradável.
Em seguida reli The Dain Curse, de Dashiell Hammett. Hammett é famoso por ser um dos "pais" das histórias de detetive americanas, seu livro mais famoso é o Falcão Maltes. Em The Dain Curse, o detetive (chamado apenas de The Continenal Op), se envolve com uma série de mortes em torno da enigmática Gabrielle Leggett. Uma boa história, com um ótimo final.
Aproveitando o embalo, reli The Thin Man (em português, O Homem Magro), também de Dashiell Hammet. É um livro estranho, a começar pelo Thin Man do título. Embora exista uma semelhança física com o autor e em uma série de televisão baseada no livro tenha associado este nome ao detetive, na história ele é o principal suspeito de um crime e só surge no final (não vou entrar em mais detalhes para não revelar a trama). O detetive é um investigador aposentado, casado com uma mulher muito mais nova. Ambos passam a maior parte do tempo bebendo. A maioria dos personagens são bastante complexos, com comportamentos excêntricos. O livro contem algumas páginas reproduzindo o relato de uma história real de canibalismo que nada tem a ver com mistério.
O primeiro foi Fifth Planet, um livro obscuro de Fred e Geoffrey Hoyle. Fred Hoyle foi um astrônomo famoso e autor de um clássico da ficção científica - The Black Cloud. Em Fifth Planet, escrito em conjunto com o filho Geoffrey, aparecem alguns pontos em comum com The Black Cloud: cientistas ganhando espaço no governo, a Inglaterra em destaque no mundo e o contato com uma inteligência extra-terrestre. O livro foi escrito no começo dos anos 60 e a guerra fria tem um certo destaque que hoje soa estranho. No final das contas, uma leitura bem agradável.
Em seguida reli The Dain Curse, de Dashiell Hammett. Hammett é famoso por ser um dos "pais" das histórias de detetive americanas, seu livro mais famoso é o Falcão Maltes. Em The Dain Curse, o detetive (chamado apenas de The Continenal Op), se envolve com uma série de mortes em torno da enigmática Gabrielle Leggett. Uma boa história, com um ótimo final.
Aproveitando o embalo, reli The Thin Man (em português, O Homem Magro), também de Dashiell Hammet. É um livro estranho, a começar pelo Thin Man do título. Embora exista uma semelhança física com o autor e em uma série de televisão baseada no livro tenha associado este nome ao detetive, na história ele é o principal suspeito de um crime e só surge no final (não vou entrar em mais detalhes para não revelar a trama). O detetive é um investigador aposentado, casado com uma mulher muito mais nova. Ambos passam a maior parte do tempo bebendo. A maioria dos personagens são bastante complexos, com comportamentos excêntricos. O livro contem algumas páginas reproduzindo o relato de uma história real de canibalismo que nada tem a ver com mistério.
terça-feira, janeiro 16, 2007
Resoluções de Ano Novo
Até me assustei quando vi a data do post anterior; os motivos para a ausência são os de sempre: trabalho e família.
Para começar um ano, nada como um conjunto de resoluções. Acho que muitos desenvolvedores se identificaram com elas:
Para começar um ano, nada como um conjunto de resoluções. Acho que muitos desenvolvedores se identificaram com elas:
- Instalar e usar um sistema de controle de versão
- Fazer até o fim pelo menos um dos "programas maravilhosos" que eu invento quando estou longe do micro
- Aprender direito e usar Python
- Continuar ignorando Perl e PHP
- Não trabalhar mais que 60 horas por semana
- Não ficar 30 dias sem colocar um post no blog
sexta-feira, dezembro 08, 2006
TechEd 2006 - Dia 3
Seguem as impressões sobre as apresentações que eu assisti no terceiro e último dia (30/11/2006) do TechEd 2006.
Smart Client - Composite UI Application Block
Outra palestra bem distante do que eu faço no dia a dia, mas muito boa. O Composite UI Application Block é um dos design patterns implementados pela Microsoft e pode ser baixado gratuitamente daqui. Tirando um pouco do glamour, podemos dizer que é um conjunto de classes para facilitar o desenvolvimento de aplicações de desktop nas quais a janela principal é composta de várias partes relativamente independentes. As classes permitem dinamicamente acrescentar as partes e atualizar o menu e o toolbar. É algo apropriado principalmente para grandes projetos desenvolvidos por times.
A chuva complicou a chegada de muita gente e até um pouco antes da hora prevista só estavam na sala eu e o apresentador (Marcelo Hideaki Azuma). A palestra foi começada com apenas três ouvintes, mas foi rapidamente enchendo (para ajudar uma das palestras ao lado foi cancelada porque o apresentador não chegou a tempo).
Windows Mobile e SQL Mobile - Aumentando a Performance da sua aplicação
Esta foi a palestra que eu menos gostei. Começou com o mal sinal, com o Marcio Boaro desdenhando outras plataformas, e foi morro abaixo. Parecia existir uma divergência entre o que estava escrito no PowerPoint e o que o apresentador tinha entendido. Para tornar um pouco mais divertida a apresentação, estava na platéia o Renato Haddad e pudemos assistir algumas discussões não conclusivas.
Windows Communication Foundation: Integrando aplicações
Uma palestra razoável, mas sem grandes novidades. Uma das poucas em que estourou o tempo.
Segundo o guia do evento, esta palestra ia falar também sobre como usar a solução "pear-to-pear", mas o tempo foi insuficiente. Será que estavam se referindo a isto?
Windows Communication Foundation: Segurança e Gerenciamento com WCF
Uma palestra muito boa, mas sobre a qual estranhamento lembro pouco. Devo confessar que estava meio sonolento... O apresentador foi o Mauro Santana, cuja voz é bem conhecida de quem fez os treinamentos do Programa Cinco Estrelas do MSDN.
Compatibilidade de Aplicações com o Windows Vista
Francamente, não esperava muito desta palestra, mas foi a que mais me marcou.
É inegável que a Microsoft faz um grande esforço para manter compatibilidade entre as versões do Windows, fazendo uma grande quantidade de testes e criando uma série de "adptações técnicas" para contornar programas mal comportados. Por outro lado, algumas decisões, notadamente as relativas a segurança, criam problemas tanto para programas como para usuários.
Uma das novidades do Windows Vista é deixar acessível ao administrador a base de dados de "adaptações técnicas". Este base de dados contém dezenas (centenas?) de aplicações (identificadas por nome do executável e/ou hashes e/ou outras coisas). Para cada aplicação pode ser indicada quais "adaptações técnicas" devem ser aplicadas.
A mais simples destas adaptações é mentir a versão. O Windows Vista é o Windows 6.0; o Windows 2000 é o 5.0 e o Windows XP é o 5.1. Algumas aplicações podem se atrapalhar com isto, seja por paranóia ("Versão de Windows Desconhecida!") ou por erro de programação ("se a versão é 5.1 é XP senão é Windows 2000...").
Uma mudança radical no Windows Vista é o tratamento dado ao Administrador. Na minha opinião, a encrenca toda é consequência da origem do Windows. O Windows surgiu no PC - Personal Computer. Normalmente, quem opera o Windows se considera (com razão ou não) o dono da máquina e espera poder fazer operações que em outros ambientes são de uso restrito, como instalar programas, mudar configurações, etc. O resultado é que quando foram introduzidas proteções, os usuários passaram a trabalhar sempre como administradores. A proliferação dos virus e a retomada do controle da TI sobre os computadores nas empresas grandes e médias criou uma grande encrenca.
A solução proposta pelo Windows Vista é o User Account Control. Basicamente ele tende a rodar as aplicações sob um usuário comum, mesmo se você estiver logado como Administrador. Para rodar uma aplicação realmente como Administrador com o UAC ligado, você precisa clicar com o botão direito e escolher "Run As Administrator". Se você não fizer isto, Coisas Inesperadas poderão acontecer quanto a aplicação tentar fazer uma operação que requer direito de administrador. O Windows poderá pedir uma confirmação, recusar com erro, recusar sem erro ou fazer uma "virtualização". A "virtualização" transforma uma ação que seria global (como escrever em determinados locais do Registry ou salvar uma configuração no Windows.ini) em uma ação restrita ao usuário. É de se esperar muita encrenca e choradeira por conta disto.
Uma coisa ainda mais radical é o Windows Resource Protection. A Microsoft resolveu restringir a atualização dos "recursos protegidos do sistema operacional" (praticamente tudo que está sob o diretório Windows) aos instaladores oficiais (marcados com o certificado digital da Microsoft). Não é mais permitido a um operador ou instalador substituir, modificar ou remover um módulo do sistema. É esperado que isto quebre um monte de instaladores.
Detalhes sobre a compatibilidade de aplicações com o Windows Vista podem ser encontrados aqui.
Concluindo
Valeu a pena? Eu diria que sim, não pelo conteúdo em si (que alguma hora vai estar disponível para download), mas por obrigar a parar por dois dias e meio e olhar outras coisas (ou coisas antigas de forma diferente).
Smart Client - Composite UI Application Block
Outra palestra bem distante do que eu faço no dia a dia, mas muito boa. O Composite UI Application Block é um dos design patterns implementados pela Microsoft e pode ser baixado gratuitamente daqui. Tirando um pouco do glamour, podemos dizer que é um conjunto de classes para facilitar o desenvolvimento de aplicações de desktop nas quais a janela principal é composta de várias partes relativamente independentes. As classes permitem dinamicamente acrescentar as partes e atualizar o menu e o toolbar. É algo apropriado principalmente para grandes projetos desenvolvidos por times.
A chuva complicou a chegada de muita gente e até um pouco antes da hora prevista só estavam na sala eu e o apresentador (Marcelo Hideaki Azuma). A palestra foi começada com apenas três ouvintes, mas foi rapidamente enchendo (para ajudar uma das palestras ao lado foi cancelada porque o apresentador não chegou a tempo).
Windows Mobile e SQL Mobile - Aumentando a Performance da sua aplicação
Esta foi a palestra que eu menos gostei. Começou com o mal sinal, com o Marcio Boaro desdenhando outras plataformas, e foi morro abaixo. Parecia existir uma divergência entre o que estava escrito no PowerPoint e o que o apresentador tinha entendido. Para tornar um pouco mais divertida a apresentação, estava na platéia o Renato Haddad e pudemos assistir algumas discussões não conclusivas.
Windows Communication Foundation: Integrando aplicações
Uma palestra razoável, mas sem grandes novidades. Uma das poucas em que estourou o tempo.
Segundo o guia do evento, esta palestra ia falar também sobre como usar a solução "pear-to-pear", mas o tempo foi insuficiente. Será que estavam se referindo a isto?
Windows Communication Foundation: Segurança e Gerenciamento com WCF
Uma palestra muito boa, mas sobre a qual estranhamento lembro pouco. Devo confessar que estava meio sonolento... O apresentador foi o Mauro Santana, cuja voz é bem conhecida de quem fez os treinamentos do Programa Cinco Estrelas do MSDN.
Compatibilidade de Aplicações com o Windows Vista
Francamente, não esperava muito desta palestra, mas foi a que mais me marcou.
É inegável que a Microsoft faz um grande esforço para manter compatibilidade entre as versões do Windows, fazendo uma grande quantidade de testes e criando uma série de "adptações técnicas" para contornar programas mal comportados. Por outro lado, algumas decisões, notadamente as relativas a segurança, criam problemas tanto para programas como para usuários.
Uma das novidades do Windows Vista é deixar acessível ao administrador a base de dados de "adaptações técnicas". Este base de dados contém dezenas (centenas?) de aplicações (identificadas por nome do executável e/ou hashes e/ou outras coisas). Para cada aplicação pode ser indicada quais "adaptações técnicas" devem ser aplicadas.
A mais simples destas adaptações é mentir a versão. O Windows Vista é o Windows 6.0; o Windows 2000 é o 5.0 e o Windows XP é o 5.1. Algumas aplicações podem se atrapalhar com isto, seja por paranóia ("Versão de Windows Desconhecida!") ou por erro de programação ("se a versão é 5.1 é XP senão é Windows 2000...").
Uma mudança radical no Windows Vista é o tratamento dado ao Administrador. Na minha opinião, a encrenca toda é consequência da origem do Windows. O Windows surgiu no PC - Personal Computer. Normalmente, quem opera o Windows se considera (com razão ou não) o dono da máquina e espera poder fazer operações que em outros ambientes são de uso restrito, como instalar programas, mudar configurações, etc. O resultado é que quando foram introduzidas proteções, os usuários passaram a trabalhar sempre como administradores. A proliferação dos virus e a retomada do controle da TI sobre os computadores nas empresas grandes e médias criou uma grande encrenca.
A solução proposta pelo Windows Vista é o User Account Control. Basicamente ele tende a rodar as aplicações sob um usuário comum, mesmo se você estiver logado como Administrador. Para rodar uma aplicação realmente como Administrador com o UAC ligado, você precisa clicar com o botão direito e escolher "Run As Administrator". Se você não fizer isto, Coisas Inesperadas poderão acontecer quanto a aplicação tentar fazer uma operação que requer direito de administrador. O Windows poderá pedir uma confirmação, recusar com erro, recusar sem erro ou fazer uma "virtualização". A "virtualização" transforma uma ação que seria global (como escrever em determinados locais do Registry ou salvar uma configuração no Windows.ini) em uma ação restrita ao usuário. É de se esperar muita encrenca e choradeira por conta disto.
Uma coisa ainda mais radical é o Windows Resource Protection. A Microsoft resolveu restringir a atualização dos "recursos protegidos do sistema operacional" (praticamente tudo que está sob o diretório Windows) aos instaladores oficiais (marcados com o certificado digital da Microsoft). Não é mais permitido a um operador ou instalador substituir, modificar ou remover um módulo do sistema. É esperado que isto quebre um monte de instaladores.
Detalhes sobre a compatibilidade de aplicações com o Windows Vista podem ser encontrados aqui.
Concluindo
Valeu a pena? Eu diria que sim, não pelo conteúdo em si (que alguma hora vai estar disponível para download), mas por obrigar a parar por dois dias e meio e olhar outras coisas (ou coisas antigas de forma diferente).
quarta-feira, dezembro 06, 2006
TechEd 2006 - Dia 2
O segundo dia do TechEd 2006 (29/11/2006) começou com uma falha imperdoável que se repetiu no dia seguinte: não foi servido café antes da primeira palestra! O coffee break entre as palestras foi muito bom (principalmente entre a primeira e a segunda do terceiro dia), mas faltou um café para dar ânimo no início do dia (principalmente para quem ainda estava de ressaca do show do dia anterior).
Nesta edição do TechEd existia um número imenso de palestras. No processo de inscrição on-line você selecionava as que pretendia ver. Embora as recepcionistas na porta das salas tivessem um computador de mão (nada menos que o meu amigo SPT-1500, que não usa sistema Windows), ele era usado apenas para registrar as presenças. O controle da inscrição era feito visualmente, conferindo a lista impressa no verso do crachá. Uma vez começada a palestra e sobrando espaço na sala, a entrada ficava livre.
Seguem as minhas impressões sobre as palestras que vi neste dia.
Windows Vista para Desenvolvedores
Apresentou uma visão geral daquilo que um dia foi chamado de WinFx e acabou batizado com o infeliz nome .NET Framework 3.0 (o que merece um comentário mais longo o dia em que eu entender direito).
Desconfio que o marketeiro que definiu o nome dos "pilares" do .NET Framework 3.0 trabalhava antes fazendo press-releases para a Bill & Melinda Gates Foundation, já que todos tem o nome Windows * Foundation, exceto pelo Windows Cardspace, escalado às pressas para substituir o WinFS que não conseguiu ser feito.
Uma palestra boa mas não notável.
Soluções para os mais comuns desafios do Desenvolvimento de Windows Forms
Um segredo não muito oculto é que a Microsoft entregou aos apresentadores as palestras prontas (título, descrição, PowerPoint, exemplos, etc) do evento internacional. Fica difícil quem viu esta palesta do Alfred Myers acreditar isto, já que ele fez um trabalho excelente de adaptação. Cada parte da apresentação era precedida por um post falso do fórum MSDN, que imitava perfeitamente os posts reais (dos nicks estranhos ao estilo do texto).
A palestra em si girou em como contornar alguns "desafios" (bugs e limitações) do Windows Forms. Embora "mais comuns" seja discutível, várias pessoas (inclusive o próprio Alfred) já os tinham enfrentado na vida real. As "soluções" variaram entre derivar uma classe do .NET Framework e substiuir pequenos detalhes a fazer um complexo hook de mensagens para conseguir descobrir quando a visibilidade de um controle muda.
Windows Presentation Foundation: Construindo aplicações ricas e conectadas
O WPF (antigo Avalon) é a parte mais visível do Windows Vista. Esta palestra pode ser resumida ao Times Reader, que é um client para apresentar offline, via WPF, conteúdo do New York Times.
Uma coisa que ficou clara nesta palestra e na próxima, é a dificuldade de integração do WPF ao que já existe (Visual Studio, Windows Forms e mesmo ao SideBar do Vista). Algo que também merece um post mais longo quando eu entender!
Windows Presentation Foundation: Como fazer gráficos 3D na minha aplicação
O Fábio Galuppo seguiu um caminho diferente do Alfred: usou o PowerPoint original, em inglês. O resultado também foi bom, principalmente com a enfase sendo dado ao código.
Quem quiser ter uma idéia de como se programa em 3D com o WPF pode dar uma olhada neste capítulo extra do livro do Petzold sobre WPF.
Melhores Práticas para Criar Web Sites Escaláveis e com Amplo Acesso a Dados
Até hoje fiz muito pouca programação para Web e certamente nada que precisasse atender a número de grande de usuários, mas o título da palestra me interessou. Eurico Brás apresentou uma palestra muito boa sobre os fatores principais para criar sites escaláveis.
Uma curiosidade foi ver a importância prática de algo que mencionei quando falei do gerenciamento de memória no Windows 32 bits. O Windows cria um espaço virtual de 4GBytes para cada processo (o máximo que pode ser endereçado com 32 bits). Deste espaço, normalmente 2G são reservados para o sistema operacional, restando 2G para a aplicação. Normalmente as várias instâncias de um site rodam dentro de um único processo. Uma forma de melhorar o desempenho e eliminar alguns gargálos é usar chaches, o que aumenta o consumo de memória. Devido ao limite de 2GBytes, normalmente não adiante colocar mais que 3GBytes de Ram em um servidor web. No Windows Server 2003 existe uma opção para reduzir o espaço reservado ao sistema para 1GByte, neste caso faz sentido aumentar a memória do servidor até 4GBytes. Mais provavelmente não vai adiantar, pelo menos enquanto não tivermos a infraestrutura ampliada para 64bits (como já foi feito no SQL Server e no Exchange).
Nesta edição do TechEd existia um número imenso de palestras. No processo de inscrição on-line você selecionava as que pretendia ver. Embora as recepcionistas na porta das salas tivessem um computador de mão (nada menos que o meu amigo SPT-1500, que não usa sistema Windows), ele era usado apenas para registrar as presenças. O controle da inscrição era feito visualmente, conferindo a lista impressa no verso do crachá. Uma vez começada a palestra e sobrando espaço na sala, a entrada ficava livre.
Seguem as minhas impressões sobre as palestras que vi neste dia.
Windows Vista para Desenvolvedores
Apresentou uma visão geral daquilo que um dia foi chamado de WinFx e acabou batizado com o infeliz nome .NET Framework 3.0 (o que merece um comentário mais longo o dia em que eu entender direito).
Desconfio que o marketeiro que definiu o nome dos "pilares" do .NET Framework 3.0 trabalhava antes fazendo press-releases para a Bill & Melinda Gates Foundation, já que todos tem o nome Windows * Foundation, exceto pelo Windows Cardspace, escalado às pressas para substituir o WinFS que não conseguiu ser feito.
Uma palestra boa mas não notável.
Soluções para os mais comuns desafios do Desenvolvimento de Windows Forms
Um segredo não muito oculto é que a Microsoft entregou aos apresentadores as palestras prontas (título, descrição, PowerPoint, exemplos, etc) do evento internacional. Fica difícil quem viu esta palesta do Alfred Myers acreditar isto, já que ele fez um trabalho excelente de adaptação. Cada parte da apresentação era precedida por um post falso do fórum MSDN, que imitava perfeitamente os posts reais (dos nicks estranhos ao estilo do texto).
A palestra em si girou em como contornar alguns "desafios" (bugs e limitações) do Windows Forms. Embora "mais comuns" seja discutível, várias pessoas (inclusive o próprio Alfred) já os tinham enfrentado na vida real. As "soluções" variaram entre derivar uma classe do .NET Framework e substiuir pequenos detalhes a fazer um complexo hook de mensagens para conseguir descobrir quando a visibilidade de um controle muda.
Windows Presentation Foundation: Construindo aplicações ricas e conectadas
O WPF (antigo Avalon) é a parte mais visível do Windows Vista. Esta palestra pode ser resumida ao Times Reader, que é um client para apresentar offline, via WPF, conteúdo do New York Times.
Uma coisa que ficou clara nesta palestra e na próxima, é a dificuldade de integração do WPF ao que já existe (Visual Studio, Windows Forms e mesmo ao SideBar do Vista). Algo que também merece um post mais longo quando eu entender!
Windows Presentation Foundation: Como fazer gráficos 3D na minha aplicação
O Fábio Galuppo seguiu um caminho diferente do Alfred: usou o PowerPoint original, em inglês. O resultado também foi bom, principalmente com a enfase sendo dado ao código.
Quem quiser ter uma idéia de como se programa em 3D com o WPF pode dar uma olhada neste capítulo extra do livro do Petzold sobre WPF.
Melhores Práticas para Criar Web Sites Escaláveis e com Amplo Acesso a Dados
Até hoje fiz muito pouca programação para Web e certamente nada que precisasse atender a número de grande de usuários, mas o título da palestra me interessou. Eurico Brás apresentou uma palestra muito boa sobre os fatores principais para criar sites escaláveis.
Uma curiosidade foi ver a importância prática de algo que mencionei quando falei do gerenciamento de memória no Windows 32 bits. O Windows cria um espaço virtual de 4GBytes para cada processo (o máximo que pode ser endereçado com 32 bits). Deste espaço, normalmente 2G são reservados para o sistema operacional, restando 2G para a aplicação. Normalmente as várias instâncias de um site rodam dentro de um único processo. Uma forma de melhorar o desempenho e eliminar alguns gargálos é usar chaches, o que aumenta o consumo de memória. Devido ao limite de 2GBytes, normalmente não adiante colocar mais que 3GBytes de Ram em um servidor web. No Windows Server 2003 existe uma opção para reduzir o espaço reservado ao sistema para 1GByte, neste caso faz sentido aumentar a memória do servidor até 4GBytes. Mais provavelmente não vai adiantar, pelo menos enquanto não tivermos a infraestrutura ampliada para 64bits (como já foi feito no SQL Server e no Exchange).
terça-feira, dezembro 05, 2006
TechEd 2006 - Dia 1
Segundo a versão oficial, este foi o maior TechEd até agora e incluiu o lançamento da década: Microsoft Windows Vista, 2007 Microsoft Office System e Microsoft Exchange Server 2007.
O processo de inscrição não foi muito suave, como mostram os comentários abaixo:
http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=722381&SiteID=21
http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=767777&SiteID=21
O primeiro dia do evento (28/11/2006) foi dedicado às sessões gerais (com algo entre 1700 e 3000 pessoas, dependendo da fonte). Todas estas pessoas ficaram amontoadas no pequeno espaço fora da sala, já que ela só foi aberta no horário de início (ao som de Beautiful Day do U2 repetida seguidamente umas cinco vezes).
Assim que todos se acomodaram, teve o longo lançamento dos três produtos, com Gabriel o Pensador como mestre de cerimônias e um grupo de músicos/dançarinos fazendo performances entre as apresentações. Como parece ser regra nestes casos, o evento estava atrasado uma hora quando veio o coffee-break (que eu não vi, quando eu saí da sala parecia que uma nuvem de gafanhotos tinha passado por ali).
Depois teve uma mais curta (e mais enfadonha) apresentação sobre as comunidades MSDN e TechNet.
Por último, uma apresentação de Hans Donner do seu gadget para o SideBar do Vista, desenvolvido em conjunto com o Fábio Galuppo.
Depois foi só curtir o cocktail do lnçamento e o show do Skank.
O processo de inscrição não foi muito suave, como mostram os comentários abaixo:
http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=722381&SiteID=21
http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=767777&SiteID=21
O primeiro dia do evento (28/11/2006) foi dedicado às sessões gerais (com algo entre 1700 e 3000 pessoas, dependendo da fonte). Todas estas pessoas ficaram amontoadas no pequeno espaço fora da sala, já que ela só foi aberta no horário de início (ao som de Beautiful Day do U2 repetida seguidamente umas cinco vezes).
Assim que todos se acomodaram, teve o longo lançamento dos três produtos, com Gabriel o Pensador como mestre de cerimônias e um grupo de músicos/dançarinos fazendo performances entre as apresentações. Como parece ser regra nestes casos, o evento estava atrasado uma hora quando veio o coffee-break (que eu não vi, quando eu saí da sala parecia que uma nuvem de gafanhotos tinha passado por ali).
Depois teve uma mais curta (e mais enfadonha) apresentação sobre as comunidades MSDN e TechNet.
Por último, uma apresentação de Hans Donner do seu gadget para o SideBar do Vista, desenvolvido em conjunto com o Fábio Galuppo.
Depois foi só curtir o cocktail do lnçamento e o show do Skank.
segunda-feira, dezembro 04, 2006
Adventure - Parte II
Ao final da primeira parte, o estado-da-arte eram as aventuras ilustradas. Em 1983, a Sierra lançou o que ela chamava de "3-D Animated Adventures".
A tela ao lado mostra o primeiro jogo lançado, o King Quest, em todo o esplendor da CGA com monitor RGB.
Olhando com atenção, é possível ver o nosso personagem, que pode ser movimentado através do teclado. Para realçar o aspecto 3D, o personagem pode passar tanto na frente como atrás de alguns elementos do cenário (como a árvore à esquerda). Os cenários possuiam algumas pequenas animações (como as bandeiras do castelo) .
Os comandos para interagir com o cenário continuavam sendo digitados, porém o parser era mais simples que o usado pela Infocom, a enfase claramente era na parte gráfica.
Estas aventuras tiveram grande sucesso e acabaram criando várias séries, como King Quest, Space Quest e Leisure Suit Larry. Para quem quiser ver como era um jogo da época, existe um jogo da série Space Quest feito por um fã: The Lost Chapter. Os primeiros jogos da série King Quest foram refeitos por fãs, com gráficos e sons atuais: King Quest I, King Quest II e King Quest III.
Como as demais aventuras, estas se baseavam em um interpretador, o AGI. Posteriormente a Sierra criou um aegundo interpretador, o SCI. À medida em que a resolução e o número de cores ia aumentando, a interface foi se afastando da digitação de texto e se limitando ao point-and-click. Nos links acima existem tanto interpretadores como editores de jogos.
A tela ao lado mostra o primeiro jogo lançado, o King Quest, em todo o esplendor da CGA com monitor RGB.Olhando com atenção, é possível ver o nosso personagem, que pode ser movimentado através do teclado. Para realçar o aspecto 3D, o personagem pode passar tanto na frente como atrás de alguns elementos do cenário (como a árvore à esquerda). Os cenários possuiam algumas pequenas animações (como as bandeiras do castelo) .
Os comandos para interagir com o cenário continuavam sendo digitados, porém o parser era mais simples que o usado pela Infocom, a enfase claramente era na parte gráfica.
Estas aventuras tiveram grande sucesso e acabaram criando várias séries, como King Quest, Space Quest e Leisure Suit Larry. Para quem quiser ver como era um jogo da época, existe um jogo da série Space Quest feito por um fã: The Lost Chapter. Os primeiros jogos da série King Quest foram refeitos por fãs, com gráficos e sons atuais: King Quest I, King Quest II e King Quest III.
Como as demais aventuras, estas se baseavam em um interpretador, o AGI. Posteriormente a Sierra criou um aegundo interpretador, o SCI. À medida em que a resolução e o número de cores ia aumentando, a interface foi se afastando da digitação de texto e se limitando ao point-and-click. Nos links acima existem tanto interpretadores como editores de jogos.
Assinar:
Postagens (Atom)