Tag Archives: c++

Sistema Operacional miniOS-0.02: Configuração do Ambiente

Ola terráqueos. Voltei.

Estou continuando a serie de posts sobre como fazer um sistema operacional, fazendo o meu proprio sistema.

Agora vou tratar da configuração do ambiente, ou em outras palavras, deixar as ferramentas que não são de desenvolvimento ajustadas para facilitar. Basicamente vamos falar do diretório /tools do nosso projeto.

Quando essa parte do tutorial estiver publicada no meu blog, você já poderão conferir no repositório os fontes dos arquivos.


/tools/boot_qemu.sh

Primeiramente, vamos falar sobre esse arquivo, que vai ser o script que vai ajudar a inicializar o nosso kernel.

Para testar o kernel, eu optei por usar o qemu, que é um emulador de maquinas bem completo e com suporte a virtualização, ou seja, podemos também usar o kernel um uma maquina virtualizada com pouco esforço.

Não vou explicar o script, acho que isso não é necessário, mas a função básica é verificar se o qemu de 32 bits esta disponível no sistema, se não estiver, usar o comando padrão. Depois, se a variável de ambiente estiver sem nenhum valor, ele procurar a imagem do kernel com o nome padrão(“miniOS”) e inicializa o sistema. Como vamos precisar por questões de debug saber o conteúdo dos registradores, esse script vai esperar um tempo para que a maquina levante o sistema e vai mostrar o conteúdo dos registradores.

O objetivo vai se rodar esse comando depois de construir o “executável” do sistema, dentro do diretório central do código fonte.

Originalmente, no tutorial do Bran e em outros, se usa um “emulador” antigo mas que funcionava bem legal, que era o bochs. O bochs é funcional e foi muito usado durante muito tempo, mas ele sempre foi mais difícil de usar, além de ter alguns “bugs” que não me pareciam muito fáceis de lidar… Por isso resolvi usar uma ferramenta mais fácil e moderna, por isso o qemu ;).

Para quem quer usar uma interface, eu recomendo o aqemu. Ele tem a opção de colocar um kernel para dar boot, e fica mais pratico. Não vou abordar isso, tanto porque acho o script mais fácil ^^.

Como sempre, o código agora já esta no repositório.


LibreSSL e porque o openssl ainda é perigoso

Certo, em épocas de heartbleed e coisas do tipo, começamos a perceber que existem alguns problemas com algumas implementações não tão modernas

Mais especificamente com o OpenSSL, recentemente na tentativa de evitar outros erros futuros, pessoas começaram a olhar e relatar problemas adicionais com o openSSL. Devido a vários problemas, foi resolvido criar um fork do projeto chamado “libreSSL“.

Realmente não gosto muito da ideia de se fazer um fork de forma desnecessária, mas procurando sobre o assunto, encontrei esses slides que justificam o clone:

http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html

Recentemente soltei um twett sobre um post falando sobre a baixa qualidade em códigos científicos. Acho que esse é um caso de grande parte das coisas que são motivos do clone até.

Ah, também acho interessante que o projeto é vinculado ao openBSD, mas ainda assim ele é portável. Quer dizer, acho que a maior parte das coisas feitas no openBSD são portáveis mesmo.

UPDATE:

Um link muito útil que o Dielson colocou para entender o Heartbleed:

http://www.dwheeler.com/essays/heartbleed.html


Sistema Operacional miniOS-0.01: Estrutura de diretórios

Voltei! Dessa vez, para começar e por enquanto, um post mais fácil, pelo menos. Vamos falar sobre a estrutura de diretórios do projeto de um sistema operacional, e o que temos que ter e onde, além de algumas dificuldades que já começou a aparecer.

Certo, vamos mostrar a estrutura de diretórios no geral, e depois eu vou explicar o porque de cada pasta é importante e para que serve, além de levantar umas ideias gerais sobre o futuro do que vai conter em cada uma das pastas.


/src/
/src/compiler/CC
/src/kernel/boot/
/src/kernel/kpp/
/src/kernel/fs/
/src/kernel/arch/
/src/kernel/arch/ISA/
/src/kernel/arch/ISA/PLATFORM
/src/libc/
/tools/

/tools

Esse diretório é o que temos um carinho especial. Aqui vamos colocar as ferramentas que vão nos ajudar a desenvolver nosso sistema operacional, vão facilitar o desenvolvimento, na verdade.

Também vamos colocar alguns programas não relacionados com o kernel em si, pelo menos porque vão ser códigos tão pequenos que não precisam criar repositórios a parte para eles, sendo mas simples deixar ai mesmo.

/src

Aqui vai ficar os códigos relacionados ao kernel, diretamente ao que vai entrar no kernel. Provavelmente, tudo o que vai ser compilado e construido dentro do kernel vai ficar em alguma pasta por aqui.

Na verdade, os códigos não vão ficar aqui, mas em pastas separadas pelas suas funções, como explicado abaixo.

/src/compiler/

Aqui começamos a entrar em detalhes interessantes. Vamos começar com um pequeno conto, o de como um programa normal funciona.

Quando você inicia um programa, você já começa com a sua função main(), certo? Mas quem iniciou as suas variáveis globais? E quem configurou algumas funções? Quem criou os arquivos stdin, stdout e stderr?

Você pode argumentar que tudo isso é função das variáveis globais(por exemplo, stdin, stdout e por ai vai…), mas, isso ainda tem funções especificas que você tem que saber sobre o ambiente para funcionar. Esse tipo de função é de códigos específicos do compilador! No futuro, esses códigos que vamos precisar, vão estar nesse diretório. A medida que precisarmos, eu vou explicando o porque, para que e como vamos precisar disso, então relaxe por enquanto e aceite que precisamos.

Uma coisa a mais a se considerar é que existem vários compiladores, então para cada compilador eu vou precisar de algum código especifico. Essa parte não tem jeito, muita coisa pode ser reusada, mas infelizmente normalmente os codigos são diferentes um dos outros. Para manter separado, vamos criar um diretório também para cada compilador, como por exemplo:


/src/compiler/gcc

Para cada compilador, um diretório. O como vamos usar assim, mais para frente a gente fala(próximo post?).

/src/kernel/

Vamos colocar aqui os códigos especificamente feitos para o kernel. Aqui vai ficar a lógica do kernel e coisas que tem a ver com arquitetura.

/src/kernel/boot/

Precisamos de alguns códigos para inicializar o kernel. Aqui é que ficam esses códigos, aqui é a cola entre o gerenciador de boot e o seu kernel, digamos que a interface, a passagem.

Não confundir com o gerenciadores de boot, que inicializa e carrega o kernel. Isso não é trabalho de um kernel, e não vamos fazer um, então deixa essa parte quieto.

/src/kernel/kpp/

Não podemos contar com nada, ou com muito pouco pelo menos, no desenvolvimento de um kernel. Isso quer dizer que não podemos usar as bibliotecas padrões que normalmente usamos, e isso quer dizer que vamos precisar reimplementar algumas coisas.

Para todas essas coisas que iremos reimplementar de algoritmos básicos(como vector, lista, etc…), vamos colocar nesse diretório.

Sobre o nome do diretório, é as iniciais de kernel plus plus, meio sem sentido mais com sentido…

/src/kernel/fs/

Nada de novo aqui, apenas vai ser o diretório com códigos relacionados ao sistema de arquivo.

Mais no futuro a gente resolve o que vai colocar aqui, principalmente porque não sabemos ainda como vai ser a cara de como lidar com sistema de arquivos.

/src/kernel/arch/

Com certeza vamos precisar utilizar algum código que seja especifico para alguma plataforma, e nesse diretório é que vamos colocar esses códigos que vão depender de alguma arquitetura.

O objetivo é que todos os códigos que dependam de alguma plataforma fiquem aqui, basicamente como eu quero isolar o código em ASM também, gostaria que todos os códigos ficasse aqui.

Mas não é sempre que podemos isolar o código ASM do código em C/C++. Existem alguns códigos de inicialização e alguns outros códigos que precisam ser escritos em ASM para serem mais portáveis ou funcionarem como você quer.

/src/kernel/arch/ISA

Dentro dos códigos mais específicos e em ASM da arquitetura, ainda temos códigos que dependem das informações especificas da ISA da maquina. Essas declarações e códigos vão ficar aqui.

Aqui vai ficar uma parte um pouco chata do trabalho já que também vamos lidar possivelmente com C, que é construir alguns tipos da ISA. pode ser que usemos algumas soluções mais com cara de C++, mas vai ser difícil…

Também temos que ter uma forma de escolher a ISA em que nosso sistema estará compilando. Isso vai fazer parte do sistema de build.

Uma coisa importante a se ressaltar é que o nome “ISA” no nome da pasta vai ser substituído pelo nome da ISA que você esta implementando, porque você pode ter varias implementações. Por exemplo, se você estiver implementando a ISA da arquitetura x86, a pasta seria:


/src/kernel/arch/x86

Isso tudo porque depois vamos usar isso para identificar e configurar a plataforma para onde vamos gerar o nosso kernel.

/src/kernel/arch/ISA/PLATFORM

Aqui ficaram códigos ainda mais específicos das plataformas, como na ISA, só que menos genéricos ainda e mais dependentes do hardware.

É meio difícil de explicar, e fica meio nebulosa a fronteira entre os códigos da ISA e os da plataforma, mas acho que é legal criar essa divisão para aproveitar códigos usados entre plataformas. Talvez seja trabalho demais para pouca coisa também, mas nesse momento não estou ligando para isso.

Assim como no caso da ISA, se estivermos por exemplo implementado a plataforma i386 da ISA x86, faríamos:


/src/kernel/arch/x86/i386

/src/libc/

Uma das piores coisas de se contruir um sistema operacional é que você não tem acesso a praticamente nenhuma ferramente pronta. Isso quer dizer que você mal pode contar com o seu compilador, imagine as bibliotecas basicas de C ou C++.

Para facilitar esse trabalho, de reimplementar todas as bibliotecas, você pode portar algumas bibliotecas. Como a biblioteca basica de C é muito importante, é aqui que teremos os ports de algumas bibliotecas para o nosso sistema.

Porque uma pasta só para isso? Porque o ideal é que possamos trocar a implementação de forma mais fácil, então aqui dentro terremos varias opções que poderão ser escolhidas pelo sistema de build do nosso kernel.

Fim!

Bom, basicamente seria isso ai, essa vai ser a estrutura de diretórios que já adianta alguma coisa para saber o que vamos fazer.

Entrei em vários pontos aqui, mas não falei como eles serão resolvidos, algumas partes porque eu realmente vou explicar melhor isso no futuro, outras porque ainda quero descobrir a melhor forma de resolver.

Mas o mais importante é, se alguem ler isso aqui e alguma duvida surgir, perguntem aqui nos comentários, que eu vou aprimorando cada vez mais o post e também vou tentando responder as duvidas. Tentem não ser tão ansiosos e se concentrar no post de agora!


C++: Parametrizar programa pela linha de comando, arquivo de configurações e/ou variáveis de ambiente

O problema

Olá amiguinhos! Recentemente, tive curiosidade de como fazer uma coisa um pouco mais complexa do que eu já vinha usando.

Todo mundo usa parâmetros para configurar o seu programa e não precisar recompilar ele toda vez para uma alteração nos dados e não na logica. Além de poder tonar o programa mais customizável, temos a vantagem de que desenvolver programas assim também é mais fácil e rápido(por motivos óbvios, use e confirme).

Até ai, eu estava fazendo e vivendo muito bem com isso usando a espetacular biblioteca de opções de programa, isso mesmo, a boost.program_options! Com ela, de forma fácil eu consigo fazer essa trabalho de parametrização do programa.

Só que, para quem já usou programas bem feitos, sabe que essa parametrização é pode ser feita de mais jeitos, e tradicionalmente, as 4 formas mais usadas: Por parâmetros de linha de comando, arquivo de configurações, variáveis de ambiente e/ou combinações dos 3 primeiros.

Eu queria fazer melhor, usar a forma mais completa, que é justamente a 4 forma. Eu ainda não sabia direito como fazer, mas sabia que a boost.program_options dava suporte a todas essas formas e talvez a mais algumas… Recentemente sentei, agrupei tudo o que eu já sabia, pesquisei algumas coisas, fiz uns testes e finalmente consegui chegar a um resultado razoável, que é o que eu lhes apresento agora ;).

A solução

Considere um programa chamado “sort“.

O programa precisa receber um arquivo de entrada e um de saída, sendo que valores padrões(a entrada padrão e a saída padrão) podem ser assumidos para esses dois caso eles não sejam fornecidos, e eles só devem ser configurados pela linha de comando.

O programa deve receber um numero de pivô, esse numero deve assumir um valor padrão caso não se diga o contrario por algum parâmetro.

O programa também deve exibir uma mensagem de ajuda, mas somente se for requisitado via linha de comando. Essa mensagem de ajuda serve para saber como entrar com todos os parâmetros, via variáveis de ambiente, linha de comando e/ou arquivo de configuração.

Algumas opções devem ser alteradas por variáveis de ambiente começando com “SORT_“. Essas variáveis são as que não são as dadas pela linha de comando exclusivamente.

Finalmente, o código que resolve todos esses requisitos é:

Além do que eu falei, o código tem algumas coisinhas a mais, mas o principal é que cumpre os requisitos.

Fácil de entender, fácil de fazer. Na verdade, eu tive mais dificuldades e demorei mais em escrever os requisitos do que em escrever o código :p.


Sistema Operacional miniOS-0.00: Começando a fazer um do zero, o vai ser preciso?

Construindo um Sistema Operacional

Olá amiguinhos! Recentemente, eu comecei e terminei de construir um sistema operacional. OK, eu me orgulho disso, achei ele muito bem feito, mas ainda tem muitos pontos que eu vi que eu podia melhorar.

Então, agora, eu começo uma serie de posts em que eu pretendo refazer esse sistema, dessa vez muito mais organizado, comentando aqui no blog com posts explicando cada passo, comentando o código de forma realmente legal e inserindo alguns elementos a mais também, tudo isso com a opinião de vocês meus leitores.

Eu pretendo evoluir as ideias que eu já usei e/ou usar algumas ideias melhores que eu tinha pensado na época, mas como eu tinha tempo a cumprir eu não fiz. Além que também eu vou tentar refatorar muito do código que eu já tinha usado.

O plano de release

Como eu já fiz uma vez e tenho alguma noção, eu sei mais ou menos o caminho em ordem do que fazer, e em cada post eu vou tentar abordar cada um desses tópicos. Pelo menos esse é o plano…

Lista do que vou desenvolver em provável ordem:

  1. Estrutura de diretórios
  2. Configuração do Ambiente
  3. Build automatizado
  4. Linker
  5. Código ASM de inicialização
  6. Código “C” de inicialização
  7. Monitor
  8. kprintf
  9. Teste?
  10. Construtores globais
  11. Destrutores globais
  12. Biblioteca padrão “C
  13. Gerencia de memoria no final do kernel
  14. Algumas estruturas de dados
  15. Global Descriptor Table (GDT)
  16. Interrupt Descriptor Table (IDT)
  17. Interrupt Service Routines (ISR)
  18. Interrupt ReQuest (IRQ)
  19. Programmable Interval Timer (PIT)
  20. Teclado
  21. Interface para sistema de arquivo genérica
  22. Gerencia de memoria com paginação
  23. Multiprocesso
  24. Tratamento de Exceções?

Lembrando que provavelmente eu vou alterar esse lista com o tempo, porque eu posso mudar de ideia com relação a ordem ou posso quebrar em mais de um tema esses tópicos, coisas assim.

A parte que eu inicialmente acho mais difícil

Testes, esse é a parte realmente nova e que pode levar tempo. Requer que eu crie mais coisas também.

Testes influenciam o desenvolvimento depois, porque a arquitetura de testes influencia muito no desenvolvimento.

A complexidade é grande, e eu vou abordar melhor o porque no post sobre testes, em que eu devo resolver e propor alguma coisa.

O começo, algo feito

Como eu sempre gosto de deixar algo sempre pronto, com bônus inicial eu já criei o repositório para quem quiser ir acompanhando, no github.

Na verdade, é o repositório antigo que eu tinha feito, mas eu deletei(criei um branch, na verdade…) e recomecei do zero. Mas quem quiser já pode ir acompanhando, mas acho melhor que vocês falem comigo por aqui e vejam os posts aqui também ;).


C/C++: Accessors(getters) e mutators(setters) de forma fácil usando macros

Continuando

Anteriormente, acho que até o ultimo post que eu fiz, falei sobre accessors(getters) e mutators(setters).

Isso foi a algum tempo atrás, e apesar de ser uma maneira muito elegante, ainda é uma maneira um pouco repetitiva, no sentido que você deve se preocupar e repetir algumas partes do processo. Isso é uma parte do processo que pode ser feita de forma automática, com muitas vantagens, com uma ajudinha de macros.

Estava vendo que o Murilo fez algo de forma parecida, e achei muito interessante. Resolvi copiar e alterar para o modo como eu mostrei em meu post passado, e mudei algumas coisas, como o nome de “declare” para “declare_am”, só para fica mais explicito….

Vejam agora que toda vez que eu quiser declarar uma variável data do tipo inteiro com getters e setters, é só usar declare_am(int,data)! Muito fácil.

Segue o código abaixo, usem para facilitar a vida, e qualquer discussão estamos ai :].

#include	<iostream>
#include	<cstdlib>

#define declare_am(type, name) \
private: type _##name; \
public: \
void name(const type& var){\
	_##name = var;\
}\
\
const type & name(){\
	return _##name; \
}\

class Teste_accessor_mutator{
	declare_am(int,data);
	declare_am(int,x);
	declare_am(int,y);
};

int main( int argc, char *argv[] ){
	Teste_accessor_mutator teste;

	teste.data(100);
	teste.x(1);
	teste.y(2);
	std::cout << teste.data() << std::endl ;
	std::cout << teste.x() << std::endl ;
	std::cout << teste.y() << std::endl ;
	return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */


C/C++: Accessors(getters) e mutators(setters) de um jeito diferente

Para que serve mutators e accessors?

Quando temos algum atributo em um objeto, esse atributo pode ser acessado e modificado para descobrir o estado do objeto.

Só que com o tempo, pode se fazer necessário que você tenha um maior controle no acesso a estados do objeto, para ter ou caso você queira um encapsulamento maior(Cache? Controle de acesso? Se que sabe 😉 ).

Com relação aos dados, existem duas operações possíveis para o acesso a um atributo do objeto, você pode acessar ou mudar o atributo. Com isso, você pode inserir uma camada nessas duas operações para poder ter esse encapsulamento a mais.

Já que sabemos o que fazer, então temos uma decisão aqui para tomar: Como iremos fazer isso? Existem algumas formas de se fazer isso, mas existe uma que utiliza polimorfismo em C++ que é mais particularmente interessante.

Ah, para quem ainda não entendeu ainda, os getters e setters servem como um estilo de implementar os accessor e mutators.

Como fazer em C++?

Cenário, dado que temos uma classe chamada Teste_accessor_mutator, que tem um atributo chamado _data. Esse atributo tem que ter um accessor chamado data e um mutator chamado data. Vamos ver isso em código implementado e um exemplo de acesso e mudança de atributo:

#include	<iostream>
#include	<cstdlib>

class Teste_accessor_mutator{
	private:
		int _data;
	public:
		const int &data(){
		return _data;
	}
	void data( const int &data ){
		_data=data;
	}
};

int main( int argc, char *argv[] ){
	Teste_accessor_mutator teste;

	teste.data(100);
	std::cout << teste.data() << std::endl ;
	return EXIT_SUCCESS;
} /* ---------- end of function main ---------- */

Pronto, com isso temos um getter e setter implementado! Perai, calma lá.

Porque eu usei _data como nome do atributo? Porque apesar de de C++ suportar polimorfismo, ele suporta polimorfismo entre métodos e não atributos. Como não vai ser usado o atributo a não ser internamente em raras ocasiões apenas colocar underline(_) na frente do atributo para mudar o nome não causa uma perda de visibilidade muito grande.

Além dessa alternativa, poderia ser qualquer outro nome no dado, como  por exemplo o atributo se chamar m_data. Mas esse estilo tem uma visibilidade boa e não difere do original, então é bem aceitável.

Porque não usar um get_data e um set_data? Não que seja um estilo ruim, mas os nomes dos métodos ficam um pouco poluídos com essa abordagem. Se você tem a vantagem do polimorfismo, fica mais legível o código.


Versão mais nova do gcc para windows

Boas novas

Quem usa a versão oficial para windows do gcc, sabe que a versão oficial suportada pelo windows do gcc e um pouco antiga…. Mais precisamente a versão 3.4. Tá, admito, é muito antiga…. E essa versão não suporta as melhores qualidades do gcc mais novo.
Bom, para aqueles que gostam de novidades e muito poucos riscos, estou avisando aqui que agora vocês pode ter o melhor compilador do mundo em seu computador com o sistema Windows.

Onde baixar

Através desse site http://www.tdragon.net/recentgcc/ você pode baixar a versão mais nova do gcc para o windows!

Que fique claro: Eu só testei via emulação(wine), portanto não vi os detalhes do compilador, só do instalador e de como desinstalar. Mais, segundo o que promete o site que você pode baixar o compilador, ele tem suporte a todas as funcionalidades legais do gcc mais novo. Entre elas:

  • Suporte a arquitetura core2.
  • Suporte a openmp.
  • Suporte a pthreads.

Só esses 3 itens já são suficientes para convencer a qualquer pessoa a pelo menos testar.

Recomendo também a leitura do site, lá ele pode explicar qualquer duvida que venha a existir. Inclusive sobre alguns bugs corrigidos e informações sobre o compilador.

Minhas Impressões

Apesar de não ter usado o compilador, eu baixei e instalei ele só para ter uma noção de como era o instalador  e sua praticidade.

Bom, posso dizer que fiquei impressionado ;). O instalador é melhor do que o do MinGW (o instalador que instala o gcc-3.4 no windows) e ainda é compatível com esse(O instalador é compatível).

Através do instalador você pode remover, alterar e instalar a versão mais nova do gcc no seu computador. Ainda existe a possibilidade de continuar um instalação passada, aproveitando os downloads dos pacotes do site que você já baixou.

Vale a pena mencionar que na instalação ele baixa os pacotes e instala na sua maquina. Ou seja, você tem que estar com acesso a intenet ou fingir uma continuação de instalação se você já tiver os pacotes baixados. O que falta eu acho que é uma versão alternativa completa, com os pacotes já no instalador para não precisar baixar do site os arquivos. Mas talvez já tenha, porque eu não procurei muito, então pode ser que exista e eu não sei ;).

Os detalhes

Vamos aos detalhes do projeto. Esse projeto tem duas versões do compilador, claro que na maioria da vezes você só ira usar uma, mais é sempre bom ter a outra opção. Essas opções são classificadas de acordo de como o binário ira resolver as excessões. Vou mostrar as duas opções abaixo, mais na maior parte das vezes a opção padrão e a melhor e você não deve se preocupar com essa parte.

Calma. Uma pausa antes de prosseguirmos. Se prepare, a partir de agora o nível vai descer. A leitura a partir de agora eu admito que é um pouco mais pesada, mas não se assuste!

Então vamos falar agora sobre como resolver pilhas! Let’s Go Talk About Stacks ;).

SJLJ

A primeira, que é a versão padrão do projeto, é a versão compilada SJLJ.

Desse trecho em diante é especulação, porque não sei direito o porque de usar SJLJ, mas posso especular de forma muito próxima da realidade.

A vantagem de usar a versão padrão com SJLJ é que em vez de usar outro metodo de resolução de exceções, o desenvolvedor desta versão do gcc usa as instruções setjmp(man setjmp) e a longjmp(man longjmp).

Sacou o porque do SJLJ? ;).

Usar essas funções em um binário é mais rápido para o binário a não ser que você use muitas excessões. Se você usar muitas excessões você ira ter um overhead nos try{…}. Isso é a excessão em códigos de computação científica e em geral, por isso, use a versão padrão SJLJ.

Detalhe, não há os try{..} que eu mencionei acima. Para quem programa em c++ é mais fácil dizer assim para que você possa entender, mais imagine que esses blocos são códigos em C que estão ai no começo e no final de uma porção de código para simular os blocos try{…}.

Ah sim, também é mais portável desenvolver algo em SJLJ, porque as funções setjmp e longjmp são funções da biblioteca padrão. E desconfio que seja mais fácil escrever código com SJLJ, apesar de nunca ter escrito com essas funções, eu consigo imaginar como implementar com elas as excessões, consigo ate imagina uma troca de contexto de hardware. Deve ser resultado da minha “forma de pensar em pilhas”.

DWARF-2

A segunda versão do compilador é a a versão não padrão compilada com DWARF-2(dw-2).

Também não sei muito sobre dw-2. Para falar a verdade, sei mais de SJLJ e quase nada de dw-2, e logo vou explicar o porque. Então como acima, o trecho a seguir é mais especulação ainda ;).

Vamos a vantagens do dw-2. Primeiro, não a overhead para as excessões. Ponto. Como ele faz isso? Ai entra a parte estranha do processo e o porque eu não sei quase nada do processo.

Primeiro devemos lembrar de uma vantagem do SJLJ: “portabilidade”. Porque isso é importante? Porque no dw-2 não tem nenhuma. A cada plataforma existe uma forma do compilador fazer o binário resolver a excessão de forma diferente sem overhead para cada maquina. Isso é muito complexo de se implementar pelo que eu posso ver. Envolve sinal em algumas plataformas, pilhas e frames em outras e qualquer outro método em outras plataformas. Isso é o que quer dizer não portável. Pode ser de qualquer forma que resolva o problema em outra plataforma ;).

Além disso, o código fica muito complexo e maior. Há formas de diminuir essa complexidade, mas ela ainda existe.

Fim

Bom, é isso. Baixem o gcc-4,3 para windows! Se eu usasse windows não perderia tempo ;).

Acho que eu acabei me alongando mais na parte de resolução de pilha no binário gerado, mas acho que foi empolgação. Fazia tempos que eu queria escrever algo assim, então acho que falar só do gcc para windows que eu nem uso seria um pouco down. E sempre desejei dar uma esclarecida sobre esse assunto. Bom, fica ai para a geração futura ;).

PS1:. Meu corretor ortográfico esta com defeito no site. Perdão erros ortográficos. ;).

PS2:. Esse post pode ter opiniões pessoais e tendenciosas. Se encontrar alguma, ignore e veja a mensagem geral do texto.


Mais uma dica de blog

Andando por ai, vi e passo a recomendar o blog do Murilo.

O cara é alguem com muito futuro e faz uns posts muito legais.

Antigamente rolou um post no blog do vidageek(nem vou colocar o endereço aqui, ele não merece…) sobre c/c++, basicamente esculhambando a linguagem. No blog do Murilo ele fez um post bem legal defendendo a linguagem. Vale a pena dar uma lida, para você poder se esclarecer melhor caso pense que c/c++ é uma linguagem ruim.

Também tem posts negando mitos, dando destaque a esse aqui.

Recomendo a quem programa em c/c++ que de uma lida nesse blog, porque ate eu quero que o meu blog se torne assim quando eu crescer :p.


Usando C++ com MPI: vector

MPI com vector<>

Bom, todos sabem que eu gosto de c++, e falar o porque seria assunto de outro tópico bem maior. Que eu não estou com saco de fazer ainda :p.

Mas, fazendo programas com MPI, eu acabei me deparando com uma coisa incrível: Ninguém fazia os programas em c++, só c….

Acho que um dos motivos, seria porque o povo não quer mesmo :p. mas, como todos nós sabemos, c++ não é mais lento que C em nenhum aspecto, então, porque não neh?

Nesse topico eu ia explicar como usar o vector com MPI, mas como já tem alguém que faz isso, eu vou só passar o link:

http://www.thinkingparallel.com/2007/02/08/a-smart-way-to-send-a-stdvector-with-mpi-and-why-it-fails/

Veja que na verdade ele não aconselha usar o vector em MPI, mas ensina como usar.

Como os itens do vector são guardados em posições contíguas, então os argumentos dele não valem para desmerecer o vector.


%d bloggers like this: