Divulgação Xmega

Software e Hardware para ATMEL

Moderadores: 51, guest2003, brasilma

Mensagempor msamsoniuk » 19 Nov 2009 18:59

nao tem documentacao nao... eu fiz soh por diversao, mas eu gravei a evolucao dele por nove versoes, no arquivo HISTORY que esta em cada diretorio aqui:

http://framework.sourceforge.net/pics/h ... nches/0/0/

seguindo esse HISTORY e lendo o codigo fonte acho q eh possivel compreender como foi evoluindo... eu parei exatamente quando a flash do mcu encheu... daih eu comprei uma versao compativel pino a pino com 8KB, mas nunca mais voltei a mexer. enfim, eh soh experimental mesmo, nem sei se vale a pena documentar.

RobL escreveu:Marcelo

Onde tem um resumo do funcionamento como um todo desse microkernel. Está em algum head ? Procurando não encontrei.
Se houver um site, fico grato pela informação.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor RobL » 19 Nov 2009 19:32

Legal.
Dá pra ir seguindo.
Valeu.
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Mensagempor Jozias del Rios » 20 Nov 2009 05:52

brasilma escreveu:Não cheguei a montar esta CPU discreta, pois nesta época já tinha muitos Z80 a disposição, porem foi uma "viagem" muito interessante.

Alguém daqui possue este nível de compreenção didática?


Ao menos aqui no ITA é feito uma "viagem' desse jeito na arquitetura do 68000.
Programamos muito micro-código para adicionar instruções específicas à CPU.

Imagina alguém querer descer ainda mais e largar o ASM para programar em micro-código!? :O
Os vencedores são aqueles que sabem o que fazer se perderem.
Os perdedores são aqueles que não sabem o que fazer se ganharem.
Avatar do usuário
Jozias del Rios
Byte
 
Mensagens: 279
Registrado em: 31 Out 2009 03:36
Localização: SJCampos-SP

Mensagempor Jozias del Rios » 20 Nov 2009 06:01

Marcelo Samsoniuk escreveu:Quanto ao uso de flags em operacoes, veja o caso em C, onde uma variavel simula o carry necessario para um rotate:

Código: Selecionar todos
unsigned char carry;
unsigned char data = 0x12;

carry = (data&0x80)?1:0;
data = (data << 1; + carry;


eh um caso onde vc nao precisa acessar o flag de carry do processador, pq vc pesca o bit que iria para o carry antes dele ir. vc nao tem como pegar ele depois do shift, mas ele jah esta salvo e vc pode usar novamente.



Marcelo, e como o compilador otimiza isso daí? Porque se deixar ele fazer o que quiser, vc pode esperar um terrível branch condicional...
Os vencedores são aqueles que sabem o que fazer se perderem.
Os perdedores são aqueles que não sabem o que fazer se ganharem.
Avatar do usuário
Jozias del Rios
Byte
 
Mensagens: 279
Registrado em: 31 Out 2009 03:36
Localização: SJCampos-SP

Mensagempor Jozias del Rios » 20 Nov 2009 06:09

Djalma Toledo Rodrigues escreveu:Então o que ocorre ? Cria uma Variável para um único Bit Flag e desperdiça
um Byte da RAM a cada Flag.

por exemplo em Contrôle:

Flag_S Sentido de Rotação
Flag_L Ligar Motor

Pois, é muito mais simples e eficiente, a tomada de decisão Lógica.


Nesse sentido que eu sempre procuro estruturar meus firmwares para terem por volta de 16 bits destes bitflags em uma memória de fácil acesso.

Nas PICs isto é uma vantagem, já que posso deixar esses 16 bits num espaço da RAM que é testado, lido e escrito bitwise com uma única instrução (e independente da página selecionada...)

Nos AVR, que é load-store, é um problema, então eu deixo os registradores r23:r22 para esta função.

São flags globais e detalham a situação do sistema.

Como que eu vou dar este tremendo conselho ao compilador em C ?
Não trata-se mais de uma rotina que precisa ser otimizada, mas sim de uma política de alocação de registradores/variáveis que o C torna rígido.
Os vencedores são aqueles que sabem o que fazer se perderem.
Os perdedores são aqueles que não sabem o que fazer se ganharem.
Avatar do usuário
Jozias del Rios
Byte
 
Mensagens: 279
Registrado em: 31 Out 2009 03:36
Localização: SJCampos-SP

Mensagempor Djalma Toledo Rodrigues » 20 Nov 2009 09:08

Bem colocado Josias

E é por isso que o GRAFCET - a Programação por Etapa e Transição - fica sem sentido
se usado por outro µC que não os da Família 8051 com seu Processador Booleano (De 1 Bit).
.
Avatar do usuário
Djalma Toledo Rodrigues
Dword
 
Mensagens: 2334
Registrado em: 03 Ago 2008 13:22

Mensagempor msamsoniuk » 20 Nov 2009 09:13

voces programam microcodigo em cpus de linha usando os vetores de emulacao de linha A e F ou voces criam um chip novo e adicionam microcodigo?

Jozias del Rios escreveu:
brasilma escreveu:Não cheguei a montar esta CPU discreta, pois nesta época já tinha muitos Z80 a disposição, porem foi uma "viagem" muito interessante.

Alguém daqui possue este nível de compreenção didática?


Ao menos aqui no ITA é feito uma "viagem' desse jeito na arquitetura do 68000.
Programamos muito micro-código para adicionar instruções específicas à CPU.

Imagina alguém querer descer ainda mais e largar o ASM para programar em micro-código!? :O
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor msamsoniuk » 20 Nov 2009 09:27

eu acho que o compilador jah infere o correto a fazer... mas por via das duvidas, para evitar o condicional vc pode fazer dessa forma:

data = (data<<1)+(data>>7);

e ele infere para x86:

shrb $7, %dl

e para 68k:

lsr.b #7,%d0

porem para um 68040 ele muda para uma das instrucoes mais exdruxulas q eu jah vi na vida:

bfextu %d1{#24:#1},%d1

enquanto que no powerpc isso fica mais extenso:

srwi 0,3,7
slwi 3,3,1
add 3,3,0

entao meio que varia de arquitetura para arquitetura e de compilador para compilador.

Jozias del Rios escreveu:
Marcelo Samsoniuk escreveu:Quanto ao uso de flags em operacoes, veja o caso em C, onde uma variavel simula o carry necessario para um rotate:

Código: Selecionar todos
unsigned char carry;
unsigned char data = 0x12;

carry = (data&0x80)?1:0;
data = (data << 1; + carry;


eh um caso onde vc nao precisa acessar o flag de carry do processador, pq vc pesca o bit que iria para o carry antes dele ir. vc nao tem como pegar ele depois do shift, mas ele jah esta salvo e vc pode usar novamente.



Marcelo, e como o compilador otimiza isso daí? Porque se deixar ele fazer o que quiser, vc pode esperar um terrível branch condicional...
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor msamsoniuk » 20 Nov 2009 09:28

se vc quer mandar um hint para o compilador otimizar uma variavel em registrador, use:

register int i;

Jozias del Rios escreveu:
Djalma Toledo Rodrigues escreveu:Então o que ocorre ? Cria uma Variável para um único Bit Flag e desperdiça
um Byte da RAM a cada Flag.

por exemplo em Contrôle:

Flag_S Sentido de Rotação
Flag_L Ligar Motor

Pois, é muito mais simples e eficiente, a tomada de decisão Lógica.


Nesse sentido que eu sempre procuro estruturar meus firmwares para terem por volta de 16 bits destes bitflags em uma memória de fácil acesso.

Nas PICs isto é uma vantagem, já que posso deixar esses 16 bits num espaço da RAM que é testado, lido e escrito bitwise com uma única instrução (e independente da página selecionada...)

Nos AVR, que é load-store, é um problema, então eu deixo os registradores r23:r22 para esta função.

São flags globais e detalham a situação do sistema.

Como que eu vou dar este tremendo conselho ao compilador em C ?
Não trata-se mais de uma rotina que precisa ser otimizada, mas sim de uma política de alocação de registradores/variáveis que o C torna rígido.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor RobL » 20 Nov 2009 10:25

Nos AVR, que é load-store, é um problema, então eu deixo os registradores r23:r22 para esta função.

São flags globais e detalham a situação do sistema.

Como que eu vou dar este tremendo conselho ao compilador em C ?
Não trata-se mais de uma rotina que precisa ser otimizada, mas sim de uma política de alocação de registradores/variáveis que o C torna rígido.


Veja como o GCC AVR resolve isso em C!!! (ou para mim quase C).

Os compiladores não farão isso, terá que ser feito em assembly. Mas aí surge um grande problema, toda ou parte da estratégia do compilador pode ser desativada devido aos registros que foram usados e o compilador não sabe mais o que fazer com o programa até esse ponto, focando eficiência.

Mas no GCC AVR tem uma solução que não é em assembly mas uma forma tão elástica como um assembly mas deixando o COMPILADOR selecionar para você o registro mais adequado. Veja a forma como exemplo:
asm("in %0, %1" : "=r" (value) : "I" (_SFR_IO_ADDR(PORTD)) );

Esta forma de escrever "tem a força do assembler inline" mas no qual toda a estratégia fica a cargo do compilador C, o GCC.
Note que os registros %0 e %1 serão decididos (alocados) pelo compilador. Isto dentro do GCC!!!
Portanto até essa parte já tem solução.

Para leitura:
http://www.nongnu.org/avr-libc/user-man ... e_asm.html
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Mensagempor RobL » 20 Nov 2009 10:43

Outro detalhe.
Dependendo do chip AVR usado não precisa deixar um registro ligado a ALU para flags. Há registros para o usuário dentro dos I/O. No caso do ATmega48, 88, 168 há um de 8 bits e mais 2 logo acima dos I/O mas já não testam bits com as mesmas instruções.
Já nos Xmegas há outros 32 registros(só para flags e outras) para o usuário na parte baixa dos I/O (além dos tradicionais 32 Works register).
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Mensagempor msamsoniuk » 20 Nov 2009 13:13

sem falar, claro, que quando vc liga otimizacoes o compilador eleva todas as variaveis para register automaticamente. se vc tem poucos registros, vc nao precisa nem ficar no dilema de escolher quais vao para register, visto que o compilador faz isso. e compiladores otimizados nao sao novidade: os primeiros compiladores fortran tinham como meta nada menos do que a propria velocidade que se conseguiria atingir com assembler otimizado manualmente!
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor vtrx » 20 Nov 2009 17:51

Fortram lida principalmente com strings....o processador não inetrpreta outra tipo de código a não ser código de máquina.
ASM é um meio de se montar os códigos de máquina,as linguagens de alto nível são um meio de tentar montar esses mesmos códigos,mas não é garantido 100% de otimização,pois é um código portável,isto é ,não é específico para um tipo de processador.
Não sou contra linguagens de alto nível,mesmo para simples µcontroladores,mas no que eu faço eu não posso deixar 'brechas' de programação,minha função é anti-hacker e anti-cracker de software e hardware,não posso usar exclusivamente uma sub-linguagem de programação.Eu mesmo quando programo banco de dados,uso talvez a pior linguagem de programação para OS,o Delphi,que é extremanete popular mais gera códigos muito grande e facilmente crackeado,desde que não se tome alguma precaução.
Avatar do usuário
vtrx
Dword
 
Mensagens: 2239
Registrado em: 20 Abr 2008 21:01

a

Mensagempor RobL » 20 Nov 2009 19:43

as linguagens de alto nível são um meio de tentar montar esses mesmos códigos,mas não é garantido 100% de otimização,pois é um código portável,isto é ,não é específico para um tipo de processador.


O código é portável mas não os compiladores que são específicos para certa cpu (tudo bem cross compiler!!!).
O compilador sempre fará o melhor para cada cpu, pois ele é especialzado para ela.

O fato do C não ser específico para determinada CPU é o que faz dele mais interessante ainda.
Observe que a otimização, sempre ocorrerá da melhor forma possível e dependerá do set de instrução e da quantidade de registros ligados a ALU de determinada cpu dentre um monte de outros fatores.

Obviamente estamos falando de compiladores bem construídos para determinado micro.

Bom, 100% de otimização penso que ninguém saberá se um humano consegue e portanto o compilador também não deve conseguir por ser feito pelo mesmo humano. Mas em um grande programa o humano vai perder a parada para ele mesmo, pois o humano se cansa e comete falhas gritantes!!! Fora o tempo lento do pensamento humano.
Creio que em um pgm de poucas linhas, bem simples, para comparação de teste de otimização, dá para chegar a 100% de otimização. Todos nós já vimos, em forum que quando um cara lança um desfio para o mais eficiente código, aparece sempre mais um, melhor.

A portabilidade do C para microcontroladores só existe 100% no núcleo comum da linguagem C. Obviamente nos periféricos é C-like e "tradução". Vai ter que ser reescrito digitando tudo outra vez.
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Mensagempor vtrx » 20 Nov 2009 20:47

Kizz dizer que voce fica dependendo dos Headers fornecidos.
Veja,quanto mais se sobe o nível da linguagem ,mais recursos são disperdiçados,veja,eu programo em Delphi,C++ e ASM:
Um Form apenas,como uma janela vazia,no Windows em Delphi ocupa 359Kb,em C++ ocupa 20Kb e em ASM ocupa 2Kb.Isto pode não significar nada para um PC com muitos Terabytes,Hds de alta densidade,Os etc,mas para um projeto eletronico pode influir muito.
Lógico que eu escolho a dedo qual linguagem usar dependendo da aplicação,mas a nível de PC.
Avatar do usuário
vtrx
Dword
 
Mensagens: 2239
Registrado em: 20 Abr 2008 21:01

AnteriorPróximo

Voltar para AVR

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron

x