Divulgação Xmega

[brasilma]

São graus de complexibilidade diferentes, qdo se vai ao assembly comanda-se diretamente o hardware do processador dizendo o que se deseja que faça, instrução por instrução, do modo mais elementar possivel.

Porem as coisas precisam evoluir para se poder fazer coisas mais complexas e com maior velocidade, e isso passa pela automatização das tarefas, justamente o que linguagens de nível maior fazem, mesmo que para isso sejam necessários mais recursos do sistema.

Os PCs se tornaram mais atraentes aos leigos, justamente pelos recursos que as interfaces gráficas como o windows ofereceram, imagina o "povo" trabalhando com DOS?!!

E a linguagem de programação tem de acompanhar.

[Djalma Toledo Rodrigues]

Mas, Marcelo você não levou em consideração o seguinte:

Muitas vezes se usa Flags, não os do STATUS, para o Contrôle(*) do Pograma, então o Humano pode colocar agrupar
os 'seus' Flags, por exemplo, em um unico Byte localizado na melhor posição.

Por exemplo no PIC se não uso um determinado periférico posso utilizar sua posição na SFR para isso.
Eu mesmo já usei até aquelas posições vagas que o Datasheet diz não estar implementada (e estava).

Fazendo uma analogia: Como se sabe que o Basic vai percorrer todo o Programa apartir do endereço inicial, para localizar uma Subrotina o Progamador "esperto" colocava as Subrotinas antes do Programa Principal.
Assim:
10 Goto 200
20 Subrotina X

80 Return

90 Subrotina Y

190 Return Fim das Subs

Este procedimento faz o programa rodar mais rápido.

Resumindo: O Humano inteligente pode otimizar.

(*) O GRAFCET por exemplo que só trabalha com BIT --Todas as Variáveis, todos Comandos, todos Sensores etc. 1 Bit
.

[brasilma]

As duas concepções estão corretas, as funções de um bom compilador, são feitas por programadores experientes e com grande conhecimento no hardware para o qual estão desenvolvendo, portanto dificilmente se consegue realisar o procedimento de uma forma mais eficiente.

Porem, como os mesmoe são genéricos, algumas vezes acabam produzindo um código mais complexo dependendo de como se escreve.

Para evitar isso, o programador tem de conhecer a ferramenta com que está trabalhando, eu sempre que posso dou uma olhadinha no compilado, para ver como meus comandos foram implementados, algumas vezes mudando a forma de escrever, o resultado melhora bastante, e assim vamos nos adaptado ao compilador.

[msamsoniuk]

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.

outro caso seria acessar outros flags, por exemplo, em asm para 68000:

Código: Selecionar todos

loop:
  ... codigo ...
  subq.l #1,d0
  bnz loop;


quando vc decrementa o registro d0, ele atualiza os flags no processador. se vc quer contar ateh que d0 seja -1, vc testa o flag N (indicando que d0 contem um numero negativo), se vc quer contar ateh d0 seja 0, vc testa o flag Z (indicando que d0 contem zero). logo depois da operacao matematica vc tem que avaliar os flags e fazer o branch condicional. se deixar para fazer isso adiante, vc perde o estado dos flags, pq qq operacao aritmetica ira sujar os flags.

no caso do processador alpha, a coisa muda de figura, pq ele funciona de uma forma mais C-like:

Código: Selecionar todos

  loop:
    subl r0,#1,r0
    ... codigo ...
    bnz r0,loop


a vantagem da abordagem C-like eh nitida: eu posso acumular 32 resultados em registros e fazer os testes na ordem e na hora que quiser.

no caso de um teste de ponteiros nulos, em asm 68000:

Código: Selecionar todos

  cmp.l #0,a0
  beq out
  cmp.l #0,a1
  beq out
  ...
out:


comparativamente, como seria no alpha:

Código: Selecionar todos

  beq r0,out
  beq r1,out
  ...
out:


o que seria o mesmo que fazer em C:

Código: Selecionar todos

if(p!=0 && q!=0)
{
   ... codigo ...
}


na medida que o codigo em C reflete muito o que vai ser obtido em codigo de maquina, acho que um passo de assembler simbolico eh totalmente desnecessario.

Mas, Marcelo você não levou em consideração o seguinte:

Muitas vezes se usa Flags, não os do STATUS, para o Contrôle(*) do Pograma, então o Humano pode colocar agrupar
os 'seus' Flags, por exemplo, em um unico Byte localizado na melhor posição.

Por exemplo no PIC se não uso um determinado periférico posso utilizar sua posição na SFR para isso.
Eu mesmo já usei até aquelas posições vagas que o Datasheet diz não estar implementada (e estava).

Fazendo uma analogia: Como se sabe que o Basic vai percorrer todo o Programa apartir do endereço inicial, para localizar uma Subrotina o Progamador "esperto" colocava as Subrotinas antes do Programa Principal.
Assim:
10 Goto 200
20 Subrotina X

80 Return

90 Subrotina Y

190 Return Fim das Subs

Este procedimento faz o programa rodar mais rápido.

Resumindo: O Humano inteligente pode otimizar.

(*) O GRAFCET por exemplo que só trabalha com BIT --Todas as Variáveis, todos Comandos, todos Sensores etc. 1 Bit
.

[Djalma Toledo Rodrigues]

Sei que se pode Implementar isso em C , Ponteiroo etc. mas, não é da natureza do C .
Para o Programador em C, o µC, ou o µP, é uma coisa abstrata , ele não esta com o Datasheet aberto a sua frente.

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

Nâo estou me referindo aos Flags do Status de Máquina , C . Z . etc. me refiro assim
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.

----------------------------------------------

" To be or not to be, that's the question"
(Shakespeare)

Traduzindo :
C ou não C ...

Abraço Marcelo

[RobL]

Eu mesmo já usei até aquelas posições vagas que o Datasheet diz não estar implementada (e estava).

Cuidado:

Atenção: Há 3 anos, numa consulta à Atmel deram-me uma explicação dizendo que usar bits não implementados pode causar comportamento desconhecido, pois eletricamente o circuito interno pode não estar concluído, podendo acionar ou desligar algo que nem eles fazem previsão.

Quando alguém de lingua inglesa escreve algo que diz: Not recommended "Não recomendamos (recomendado)" a versão em português é: "proibido usar" ou "vai explodir" ou ainda "se fizer vai se danar"!!!

Portanto, coloquei isto aqui para não incentivar a ninguém usar esses bits.
Não confundir com bits reservados. Estes podem ser usados mas seu programa poderá perder portabilidade futura.

[Djalma Toledo Rodrigues]

Concordo Rob_L

Mas, era coisa minha, sem maior compromisso.

De qualquer forma eu deveria ter alertado que não é recomendável.

Abraço e Obrigado.
.

[brasilma]

He, he, disvirtuando um pouco o tópico, tudo é cultura, sou campeão de aproveitar essas coisinhas esquecidas (pura necessidade) num sisteminha certa ocasião... usei toda memória que sobrava do RTC e display, para o processador.

[Djalma Toledo Rodrigues]

... usei toda memória que sobrava do RTC e display, para o processador.

Criativo hein ?

Ou, como dizem: A necessidade é que obriga o Sapo a pular

Sua Vida, sua fome (do sapo) , seu 'amor' indiferente... .
.

[msamsoniuk]

opa, como nao eh da natureza de C?

pega um device driver tipico de um sistema operacional escrito em C:

http://www.sfr-fresh.com/linux/misc/i2c ... algo-8xx.c

a implementacao eh feita integralmente em C usando ponteiros para estruturas que casam com os perifericos mapeados em memoria. e isso nao eh exclusivo deste processador ou deste device driver, isso eh assim para qualquer device driver, pq quanto menos asm existir no sistema operacional, mais portavel ele sera.

isso eh exatamente da natureza de C sim, pq o desenvolvimento de C esta associado ao desenvolvimento do unix. quando ele foi portado para C, obviamente qualquer deficiencia nesse sentido foi suprida, desde que nao afetasse a portabilidade da linguagem.

a vantagem obviamente surge quando vc compara os resultados: antes de ser portado, o unix era um sistema operacional pequeno e limitado, situacao que varios sistemas operacionais mantinham ainda durante a decada de 80. comparativamente, o unix em C era um sistema operacional completo e refinado, com muitas abstracoes de alto nivel. um exemplo bem basico, mas classico, eh que o unix escrito em C suportava um filesystem com diretorios hierarquicos jah na decada de 70, enquando que os sistemas operacionais escritos em asm ainda na decada de 80 nao tinham esse nivel de abstracao. as versoes originais do msdos eram escritas em asm, por questao de performance... ao menos era o que era alegado! pq na verdade ele era tosco, sem features e lerdo quando comparado ao unix

quando a microsoft comprou uma licenca do unix, que vendia com o nome comercial xenix, ela aproveitou para puxar a tecnologia unix escrita em C para o msdos... e a partir daih o msdos ganhou suporte a discos hierarquicos, uma nova api C-like para arquivos, abstracoes para dispositivos mapeados em espaco de arquivos (LPTx, COMx, CON, NUL, etc), pipes e por aih afora.

quanto ao flag, sem problemas criar variaveis empilhadas em C:

Código: Selecionar todos

struct packed_struct {
       unsigned char b0:1;
       unsigned char b1:1;
       unsigned char b2:1;
       unsigned char b3:1;
       unsigned char b4:1;
       unsigned char b5:1;
       unsigned char b6:1;
       unsigned char b7:1;
} flags;


daih vc tem um buffer de 8 flags acessiveis bit a bit. obvio, nao existe enderecamento de bit em C, mas tambem nao existe na maioria dos processadores, entao da forma que vc faria em C:

Código: Selecionar todos

flags.b0 = 1;


vc faria em asm 68k:

Código: Selecionar todos

ori.b #1,(flags)


isso no 68000, mas creio que nao no coldfire, pq eh algo meio cisc demais e vc teria que quebrar em varias instrucoes, pq varias operacoes com operandos imediados foram eliminados.

Sei que se pode Implementar isso em C , Ponteiroo etc. mas, não é da natureza do C .
Para o Programador em C, o µC, ou o µP, é uma coisa abstrata , ele não esta com o Datasheet aberto a sua frente.

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

Nâo estou me referindo aos Flags do Status de Máquina , C . Z . etc. me refiro assim
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.

----------------------------------------------

" To be or not to be, that's the question"
(Shakespeare)

Traduzindo :
C ou não C ...

Abraço Marcelo

[RobL]

Para ser mais econômico em tempo de CO2, pode usar Union envolvendo essa struct. Daí fica tudo em um único byte (8 flags em um byte).

Poderia ser também similar ao assembly, usando a diretiva #define para cada bit de um mesmo byte e setar, resetar por operações lógicas OR e AND. Usaria também um só byte para 8 flags. Gera o mesmo código que em assembly.

[msamsoniuk]

na verdade a struct que eu mostrei jah faz isso que vc falou: empacota 8 bits em um unico byte. o union seria para outra coisa:

Código: Selecionar todos

union
{
   unsigned char BYTE;
   struct
   {                     
      unsigned char  B7:1;
      unsigned char  B6:1;
      unsigned char  B5:1;
      unsigned char  B4:1;
      unsigned char  B3:1;
      unsigned char  B2:1;
      unsigned char  B1:1;
      unsigned char  B0:1; 
   }  BIT;
} DATA;


assim vc pode acessar individualmente tanto os bits quanto byte inteiro q compartilha o mesmo espaco de armazenamento.

e claro, quando vc usa DATA.BIT.B0 = 1, o compilador jah se encarrega de escolher a operacao logica correta mais eficiente para fazer o que vc precisa fazer.

Para ser mais econômico em tempo de CO2, pode usar Union envolvendo essa struct. Daí fica tudo em um único byte (8 flags em um byte).

Poderia ser também similar ao assembly, usando a diretiva #define para cada bit de um mesmo byte e setar, resetar por operações lógicas OR e AND. Usaria também um só byte para 8 flags. Gera o mesmo código que em assembly.

[RobL]

O que quero enfatizar, com Union envolvendo struct, em termos de economia, para os assemblystas( e os chiitas da Assemblyia of god ) que acham que não se pode tratar bits em C (C suporta bit fields), é que através de uma Union envolvendo uma struct, conforme acima, podemos manipular vários bytes de flags (não apenas um byte como acima). usando um mesmo endereço de memória, um só (um byte 8 bits conforme definição acima char), desde que não sendo todos os bytes tratados ao mesmo tempo, é claro.

Cabe lembrar que pode-se manipular, definindo um int (2 bytes), com struct a parte alta e baixa(8 bits cada) com a mesma simplicidade que um byte com 8 bits em assembly, mas em assembly seria uma ginástica danada para fazer o mesmo.

Penso que no tópico. ficaram ricas informações a respeito dos mitos sobre C, especialmente tratamento de bits e outros.

Deixe a inteligência artificial do compilador agir em seu benefício e continue estudando o hardware de seu micro. O uso do compilador não significa encolher seu conhecimento.
Verdadeiramente compiladores são caros. Mas há os livres como o GCC.
Não vai dar para ir à guerra sem eles.

[msamsoniuk]

exatamente robl! nao vou dizer que nao dah para ir a guerra sem conhecer nada de asm, mas certamente vc fica com muito mais liberdade para trabalhar se usar apenas C e minimizar o uso de asm. por exemplo, este microkernel q eu fiz rodar em um HC908 com 4KB de flash:

http://framework.sourceforge.net/pics/hc908rtos/trunk/

tem realmente muito pouco asm inline: apenas 3 instrucoes, das quais apenas uma seria realmente mandatoria.

O que quero enfatizar, com Union envolvendo struct, em termos de economia, para os assemblystas( e os chiitas da Assemblyia of god) que acham que não se pode tratar bits em C (C suporta bit fields), é que através de uma Union envolvendo uma struct, conforme acima, podemos manipular vários bytes de flags (não apenas um byte como acima). usando um mesmo endereço de memória, um só (um byte 8 bits conforme definição acima char), desde que não sendo todos os bytes tratados ao mesmo tempo, é claro.

Cabe lembrar que pode-se manipular, definindo um int (2 bytes), com struct a parte alta e baixa(8 bits cada) com a mesma simplicidade que um byte com 8 bits em assembly, mas em assembly seria uma ginástica danada para fazer o mesmo.

Penso que no tópico. ficaram ricas informações a respeito dos mitos sobre C, especialmente tratamento de bits e outros.

Deixe a inteligência artificial do compilador agir em seu benefício e continue estudando o hardware de seu micro. O uso do compilador não significa encolher seu conhecimento.
Verdadeiramente compiladores são caros. Mas há os livres como o GCC.
Não vai dar para ir à guerra sem eles.

[RobL]

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.