terça-feira, setembro 26, 2006

Gerenciamento de Memória - 8080 e CPM/80


Assistindo a palestra do Rodrigo Strauss sobre Gerenciamento de Memória no Windows, surgiu a idéia de fazer alguns posts sobre o gerenciamento no nível do microprocessador, começando lá no tempo dos 8 bits.

Como vocês provavelmente sabem, o primeiro microprocessador disponível comercialmente foi o 4004 da Intel, de 4 bits. Posteriormente a Intel criou o 8008 de 8 bits, que rapidamente evoluiu para o 8080, cujas influências estão presentes até hoje nos processadores Intel.

Quando dizemos que o 8080 é um processador de 8 bits, isto se deve principalmente a duas características:
  • a unidade lógica aritmética (ALU) faz diretamente operações com valores de 8 bits
  • a ligação com a memória utiliza 8 bits de dados
O endereçamento da memória utiliza 16 bits, permitindo endereçar diretamente até 64 Kbytes. Ao ser re-iniciado, o 8080 começa a execução sempre pelo endereço zero de memória.

A figura acima mostra os registradores do 8080. O programa counter (PC) e o stack pointer (SP) são registradores de 16 bits. Em quase todos os casos, o acumulador contém um dos operandos e recebe o resultado das operações aritméticas e lógicas.Os registradores B, C, D, E, H e L podem ser usados como registradores de uso geral de 8 bits. Entretanto, algumas instruções permitem tratar estes registradores aos pares (BC, DE e HL) para manipular valores de 16 bits. Como a ALU só consegue manipular 8 bits de cada vez, estas instruções precisam dar duas passadas pela ALU, sendo mais lentas.

Como dito, nas operações aritméticas e lógicas um dos operandos é normalmente o acumulador. O outro é um dos registradores gerais ou a posição de memória apontada pelo par HL. Em outras palavras, o registrador HL é usado principalmente como um ponteiro para a memória (endereçamento indireto).

As instruções que permitem manipular par de registradores como valores de 16 bits são:
  • LXI carrega um valor imediado num par de registradores
  • XCHG, XTHL trocam o conteúdo de HL respectivamente por DE e pelos dois bytes no topo da pilha
  • SPHL carrega SP com o valor em HL
  • LHLD carrega HL com o valor em duas posições consecutivas da memória
  • SHLD guarda em duas posições consecutivas da memória p valor em HL
  • INX e DCX respectivamente incrementam e decrementam um valor em um par de registradores
  • DAD soma BC, DE, HL ou SP a HL
O objetivo principal destas instruções é permitir manipular endereços, para implementar ponteiros, arrays e tabelas de desvios.

A rigor podemos dizer que o 8080 não possui nenhum recurso de gerenciamento de memória. O endereço determinado pelas instruções é colocado diretamente nos pinos que endereçam a memória. Não existe nenhum recurso de mapeamento, proteção ou memória virtual.

O CPM/80

O CPM/80 foi o principal sistema operacional para os computadores "sérios" de 8 bits e influenciou diretamente o MSDOS e indiretamente o Windows. (Talvez mereça um post específico no futuro).

Do ponto de vista de gerenciamente de memória, o CP/M80 era muito simples. Os primeiros 256 bytes de memória possuíam uma estrutura fixa, contendo o endereço de chamada ao sistema operacional e a linha de comando usada para executar os aplicativos (no MSDOS, esta estrutura virou o PSP - prefixo de segmento de programa). Os aplicativos em si eram sempre carregados logo em seguida (endereço 0x100); o sistema operacional em si residia no final da memória. Obviamente, o CP/M 80 suporta a execução de apenas um aplicativo de cada vez.

A chamada ao sistema era feito através de uma instrução CALL para o endereço 5. Nesta posição existia um desvio (JMP) para a primeira posição ocupada pelo CP/M, fazendo com que os endereços 6 e 7 indicassem o fim da memória disponível para o programa. Isto permitia criar um primeiro tipo de TSR (terminate and stay resident - programa que fica na memória após ter terminado do ponto de vista do sistema operacional). O programa se copiava para o fim da memória, antes do sistema operacional, colocava um JMP para o SO no seu inicio e alterava o JMP no endereço 5.

Quando armazenados em disco (em arquivos com extensão COM), os programas já estavam com os endereços reais de execução, nenhum tipo de relocação era necessária.

Ultrapassando a barreira dos 64K

De uma forma geral os aplicativos e o CP/M 80 não tinham suporte para nenhum esquema que aumentasse a capacidade de endereçamento do 8080. Este aumento exigia um hardware adicional externo ao processador para selecionar entre diversas regiões de memória que compartilham o mesmo endereço do processador. Esta técnica é chamada de chaveamento de memória.

O chaveamento de memória no CP/M 80 era usado na parte específica do equipamento, já então chamada de BIOS. No mínimo precisa ser usada para a carga do sistema operacional, mapeando uma memória não volátil no endereço zero (onde inicia a execução do 8080 e onde posteriormente é preciso ter RAM). Outra opção comum era "esconder" as rotinas de manipulação do hardware, reduzindo o BIOS e liberando mais memória para o aplicativo.

Outros processadores de 8 bits

Alguns funcionários da Intel saíram para fundar uma nova empresa, a Zilog, que lançou uma versão muito aprimorada do 8080, o Z80. Além de ser mais rápido, o Z80 possuiu várias instruções adicionais, principalmente fornecendo formas mais flexíveis de endereçamento da memória. Entretanto, os recursos de gerenciamento de memória continuaram inexistentes. O CP/M 80 e os aplicativos que rodavam sob ele não usavam as instruções adicionais, tratando o Z80 da mesma forma que um 8080.

Posteriormente a Intel lançou o 8085 que tinha apenas pequenos avanços em relação ao 8080.

Outro processador de 8 bits popular na época era o 6502 (usado no Apple I e Apple II). O conjunto de registradores e instruções do 6502 era completamente diferente, valorizando o acesso indireto à memória. O Apple II usava extensamente a técnica de chaveamento de memória, inicialmente para as rotinas de tratamento das placas nos slots e posteriormente para aumento da capacidade gráfica e da memória disponível.

Pacotes

Uma das tarefas dos protocolos do nível de transporte, como o TCP, é garantir a entrega dos pacotes na ordem em que forem enviados. À primeira vista, isto parece desnecessário. Afinal, como os pacotes podem chegar no destino em ordem diferente da em que foram enviados? A resposta é que numa rede complexa existem vários caminhos entre a origem e o destino e nada obriga pacotes consecutivos a seguir o mesmo caminho.

Embora não tenha chegado ao extremo de chegar fora de ordem, meu último pedido na Amazom mostrou como pacotes consecutivos podem experimentar condições bem diferentes. Como mencionei antes, um dos livros foi enviando em um dia e o resto do pedido no dia seguinte. O livro que veio isolado estabeleceu um novo record, chegando em sete dias corridos. Já o resto do pedido chegou somente ontem (26 dias corridos, o que ainda é um prazo bom para o standard shipping).

segunda-feira, setembro 25, 2006

Mudança do feed

Aviso aos assinantes (se é que tem algum): o Blogger mudou o endereço do feed para

http://dqsoft.blogspot.com/feeds/posts/full

quinta-feira, setembro 14, 2006

Programando em C#

Embora eu já tenho obtido a certificação Microsoft em C#, não faz parte do meu dia-a-dia programar em C#. Normalmente programo em C, usando diretamente a API do Windows.

Surgiu agora uma "oportunidade" de mexer numa aplicação Windows em C# (na verdade, a necessidade de fazer os acertos finais em um projeto que eu estava coordenando e outro pessoa estava executando). Seguem algumas observações desta experiência.

Desempenho da IDE e da Aplicação

Um dos receios quanto ao Visual Studio e aplicações gerenciadas é quanto ao desempenho. A minha experiência até o momento foi boa, consigo desenvolver bem em um Pentium 4 2.8 HT, com 512M de Ram, mesmo com o Sql Server rodando na mesma máquina.

A Qualidade do Help

Minha impressão é que ao mesmo tempo que o Help do Visual Studio (MSDN Library) vem aumentado em tamanho (veio em DVD) a qualidade vem caindo. Eu fico lembrando toda hora da velha piada do piloto do helicoptero perdido que recebe a informação de que está... num helicóptero (informação tecnicamente correta e praticamente inútil).

A documentação está muitas vezes restrita ao tipo dos parâmetros (informação já apresentada pelo Intelisense). Alguns "exemplos" não fornecem muita coisa mais. Além disso, tem a mesma informação repetida na mesma página para VB.Net, C#, C++, J# e JScript.

Em comparação, a documentação da API do Windows contém muita informação sobre o quando usar, porque usar, etc.

Acessando Embedded Resources

Embedded Resources são informações, como textos e imagens, que são armazenadas dentro do próprio executável (mais precisamente, no Assembly .Net). No C + Windows API, o uso disto é quase sempre explícito. No .Net, a maior parte do tempo você não se preocupa com isto. Entretanto, se você precisar se preocupar, pode ter surpresas.

Basicamente o que eu precisei era acessar um ícone. Vou começar apresentando a solução:
  1. Acrescente o arquivo com o ícone na solução (clique com o botão direito no nome do projeto, selecione Add Existing Item, navegue até o arquivo)
  2. Selecione o arquivo e em Properties mude Build Action para Embedded Resource
  3. No ponto em que você precisar do ícone coloque (supondo que o arquivo foi "Icone.ico")
Icon meuIcone = new Icon (GetType(), "Icone.ico")

Parece óbvio, afinal como eu posso ter errado isto? Bem, o help não tinha muita informação além de

public Icon (Type type, string resource);

e os exemplos que eu vi no livro Programming Microsoft Windows Forms e em alguns sites foram

Icon meuIcone = new Icon (GetType(), "Projeto.Icone.ico")

para confundir um pouco mais, embora a linha acima dê erro durante a execução (não acha o resource), se você examinar o Assembly com o MSIL Disassembler, vai ver que o ícone está lá e com o nome "Projeto.Icone.ico".

O que ocorre (e eu só achei no adendo do post de um blog) é que na hora de procurar o resource o namespace da classe do primeiro parâmetro é colocado automaticamente na frente do nome informado no segundo parâmetro. E o nome do resource no assembly é feito colocando o namespace default na frente do nome do arquivo. No meu caso, os namespaces eram os mesmos, e acabava sendo procurado Projeto.Projeto.Icone.ico ao invés de Projeto.Icone.ico.

Se você criar uma pasta no projeto para os seus ícones, por exemplo Icones, o nome do resource vai ficar Projeto.Icones.Icone.ico e portanto de ser usado

Icon meuIcone = new Icon (GetType(), "Icones.Icone.ico")

Depois que a gente entende, fica fácil...

quarta-feira, setembro 06, 2006

Novo record da Amazon

No dia 30/8 (uma semana atrás) coloquei um pedido na Amazon. Entre os livros, um deles tinha data prevista de publicação 4/9; a minha grande preocupação era a Amazon não quebrar obrigatoriamente o pedido em dois, aumentando o custo do correio. Felizmente ela aceitou automaticamente o pedido de enviar tudo em uma única remessa, inclusive avisando que o despacho seria atrasado pelo livro que ainda não tinha saído.

Para minha surpresa, no dia seguinte (31/8) veio um email avisando que parte do pedido estava sendo mandado na frente (sem custo adicional): o livro ainda não lançado! O resto saiu no dia seguinte.

Hoje, 6/9, sete dias corridos após o pedido, o livro chegou! Não deu nem tempo de ficar com inveja dos fãs americanos que correram para comprar o livro na segunda feira. E olha que eu usei a opção mais barata de correio.

O único porém fica para o carteiro, que simplesmente largou a caixa na entrada; mesmo supondo que não tenhamos ouvido a campainha seria de esperar que ele fizesse questão de entregar em mãos a alguém.

Migração para Blogger Beta

Migrei o blog para o Bloger Beta para poder colocar labels nos post. Vamos torcer para não ter nenhum bug catastrófico!

Turbo Explorer

A Borland lançou ontem a linha Turbo, composta por versões Professional e Explorer do Turbo C++, Turbo Delphi, Turbo Delphi p/ .Net e Turbo C#.

As versões Explorer são gratuitas, download em:
http://www.borland.com/downloads/download_turbo.html

A PC Magazine já publicou um artigo sobre o Turbo Delphi Explorer. Apesar do preço (grátis) e de ser um produto bastante completo e atualizado, já existem algumas pessoas examinando os dentes do cavalo dado:
  • Mesmo os produtos não .Net precisam ter o .Net Framework 1.1 instalado (para a IDE não para o executável gerado)
  • É preciso ter o IE atualizado e o MSXML mais recente
  • Só é possível instalar um produto Turbo Explorer na máquina; também não convive com o produto completo (Borland Developer Studio)
  • Não vai ter versão Linux
  • Os downloads são grandes

terça-feira, setembro 05, 2006

Lista: Nove Séries de Detetives

Para quem não viu ou não lembra, minhas regras para listas estão aqui. Neste caso, preferi listar os personagens e não livros específicos.

  • Perry Mason: pouco conhecido aqui no Brasil, é um ícone nos EUA (pela proximidade geográfica, foi até mencionado no Chaves!). Perry Mason é o advogado detetive, que sempre tira um coelho da cartola nos capítulos finais, para desespero dos promotores e policiais que pensavam ter pegado o culpado. O autor (Erle Stanley Gardner) produziu dezenas de livros, o que complicou bastante o trabalho do meu pai de juntar todos eles (o que só conlcuiu com auxílio da Amazon).
  • Hercule Poirot: o belga de cabeça de ovo criado por Agatha Christie. Embora eu tenha praticamente todos os livros, considero que eles se baseiam demais em truques da autora e não tem a mesma profundidade de outros desta lista. Um leitura divertida, de qualquer forma.
  • Sherlock Holmes: criação de Conan Doyle é provavelmente o detetive mais conhecido do mundo, embora em desconfie que poucos leram os livros. Para quem ainda não leu, recomendo os que tem estórias curtas; os mais longos às vezes tem vários capítulos de romance não detetivesco (e talvez monótono)- vide a segunda parte de "Um Estudo em Vermelho". Nas histórias mais curtas brilham a inteligência do detetive e as situações fantásticas. Como os livros já estão no domínio público é fácil encontrar edições a preços baixos (quem preferir pode baixar do Projeto Gutemberg).
  • Maigret: já escrevi sobre ele antes. Criação de Georges Simenon, as estórias normalmente culminam com a revelação de uma trama sórdida.
  • Nero Wolfe: nas estórias escritas por Rex Stout, o caminho se sobrepõe ao destino. Embora exista um mistério, o que fascina é a interação entre os personagens. Nero Wolfe, nas suas próprias palavras, é apenas um gênio. Sua paixões são as orquídeas e a boa comida (aliás, ele pesa um sexto de tonelada). Para sustentá-las, resolve mistérios por preços altíssimos. Possui várias excentricidades, tornadas ainda mais fortes pelas excessões que ocasionalmente permite. É auxiliado por Archie Goodman, um detetive de porte mais tradicional, que tem entre as suas funções atormentar Wolfe para que ele trabalhe. Completam ainda o "cast" fixo o cozinheiro Fritz Brenner, os detetives free-lance Saul Panzer, Fred Durkin e Orrie Cather, a namorada de Archie (Lily Rowan e o inspetor de polícia Cramer.
  • Philip Marlowe: imortalizado nas telas por Humphrey Bogart, o detetive criado por Raymond Chandler define (juntamente com Sam Spade do Falcão Maltês) e estilo noir. O detetive durão (mas de coração mole) faz piadas o tempo todo enquanto está perdido em meio a tramas complicadas e repletas de reviravoltas. Chandler possui um estilo todo especial de escrever, particularmente nas descrições e adjetivos. Pena que deixou tão poucos livros.
  • Ellery Queen: já houve época em que este nome era sinônimo de mistério. Ellery Queen é ao mesmo tempo personagem (em alguns do dos livros) e autor (na verdade, era pseudônimo de dois primos, segredo este mantido por muito tempo). Suas histórias são bastante intensas e cheias de reviravoltas. Meus prediletos são os que tem Ellery também como personagem.
  • Streeter: alguns anos atrás, procurando algo novo para ler, fui atraído pelas capas destes livros de Michel Stone, imitando os antigos pulps. São estórias no estilo noir porém ambientadas em tempos mais recentes e com techos muito criativos. Infelizmente os livros estão atualmente esgotados e parece que o autor parou após o quarto (eu só tenho dois deles).
  • Inspector West: um detetive criado por John Creasey, com uma visão bem britânica. Destaco o livro A Gun for Inspector West, no qual o inspetor West se indigna com a sugestão de seus superiores de que ele passe a andar armado devido aos ataques de uma gangue violenta.

segunda-feira, setembro 04, 2006

Livro do Mês Passado - Software Estimation

Steve McConnell é autor dos conhecidos livros Code Complete (que ainda não li) e Rapid Develpment (que li e recomendo).

Neste seu mais novo livro Software Estimation: Demystifying the Black Art (lançado agora em 2006) ele aborda a arte de estimar tamanho, esforço e prazo de projetos de software.

É um livro relativamente pequeno, cerca de 300 páginas, dividido em capítulos curtos, ideal para ler aos poucos. O livro é impresso em duas cores (preto e azul), o que é muito bem aproveitado nas tabelas, gráficos e figuras. Espero que a Microsoft Press utilize com mais frequência este tipo de recurso.

Além da experiência própria do autor (que fornece consultoria no assunto e desenvolveu um software para fazer estimativas), o livro utiliza uma quantidade imensa de dados reais coletados por diversos pesquisadores. Embora a maior parte das técnicas seja voltada para projetos de porte médio a grande, muito pode ser também aproveitado para projetos pequenos.

A utilidade deste livro não está limitada às pessoas cuja função é estimar software. O entendimento dos conceitos de estimativa pode reduzir o stress normalmente associado às estimativas e ao próprio desenvolvimento de software.

O livro está dividido em três partes:
  • Conceitos Críticos
  • Técnicas Fundamentais
  • Desafios Específicos
Ao longo do livro são apresentadas 118 "dicas" (eu não contei, elas são reproduzidas em destaque no final do livro). Reproduzo algumas abaixo:
  • Diferencie estimativas, alvos e compromissos. [Uma estimativa é um resultado obtido por uma avaliação, um alvo é um resultado desejado e um compromisso é um resultado acordado entre os envolvidos.]
  • Quando uma estimativa é fornecida como um valor único (ao invés de uma faixa) existe implicitamente uma probabilidade associada.
  • A penalidade para estimar para baixo é normalmente maior que estimar para cima. [Intuitivamente achamos que é o contrário]
  • Existe um "Cone de Incerteza": á medida que um projeto avança, as estimativas podem ser mais precisas (desde que o projeto esteja sendo gerenciado adequadamente). [É tolice querer ser mais preciso que o estágio do projeto permite. Se o projeto não convergir, as estimativas não vão convergir - isto é um problema de gerenciamento e não de estimativa]
  • Não dê estimativas de "bate-pronto". [Pensar um pouco, mesmo que alguns minutos, vai gerar uma estimativa mais precisa]
  • O número de dígitos significativos e a unidade usada da estimativa deve ser compatível com a sua precisão. [Por exemplo, considere a diferença entre dizer 2 dias e dizer 16 horas]
  • O tamanho do software é o fator mais significativo (mas não o único) na determinação do esforço e prazo.
  • O esforço não cresce linearmente com o tamanho.
  • As técnicas de estimativa devem ser escolhidas em função do que você quer estimar, o tamanho do projeto, o estágio do desenvolvimento, o estilo do desenvolvimento (interativo ou sequencial) e a precisão desejada.
  • Contar quando possível. Se não for possível contar, calcular. Somente em último caso opinar. Não usar a opinião de especialistas para ajustar estimativas obtidas por cálculos.
  • Guarde dados históricos dos projetos. A performance passada é o melhor indicador da performance futura. [Como otimistas, achamos sempre que os problemas anteriores não vão se repetir]
  • Não discuta o resultado de uma estimativa [feita com método]. Mude o resultado somente alterando as entradas e recalculando.
Resumindo, altamente recomendado.