Divulgação Xmega

[msamsoniuk]

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.

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.

[RobL]

Legal.
Dá pra ir seguindo.
Valeu.

[Jozias del Rios]

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

[Jozias del Rios]

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...

[Jozias del Rios]

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.

[Djalma Toledo Rodrigues]

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).
.

[msamsoniuk]

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?

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

[msamsoniuk]

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.

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...

[msamsoniuk]

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

register int i;

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.

[RobL]

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]

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).

[msamsoniuk]

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!

[vtrx]

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.

[RobL]

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.

[vtrx]

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.