Duvida subrotinas MikroC

[Djalma Toledo Rodrigues]

veja o codigo, DJ ...
o compilador que trocou "call" por "jump" na verdade fez pouca coisa

Não creio que seja pouca coisa.

Isso apareceu porque o Marcelo colocou o ASM, de tivesse gravado o µC direto ?

E se o Autor publica o Fluxograma ?
Então no Fluxograma consta Subrotinas que na real não existem.

Não posso concordar que isso seja pouca coisa.

DJ

[Jozias del Rios]

Dj, as subrotinas continuam existindo. Tome o exemplo que eu dei de print_clock lá... é uma subrotina que inclusive faz uso de outras subrotinas, e trocou um call por jump, mas sua funcionalidade e organização continua 100%.

Sobre o fato de ocorrer ou nao stack-overflow, temos que lembrar que o compilador que é o dono do stack...

[Jozias del Rios]

Se um autor publicou o fluxograma e programou em C, vale os .c, e não os .hex / .bin / .lst

Mais um exemplo, agora não de call-forwarding, mas de fall-through, que é mais "pesado" ainda...
Um codigo em C hipotético que brinca com BCD do tipo:

Código: Selecionar todos

void main()
{
   while (1)
   {
       print_clock();
       delay();
   }
}


void print_clock()
{
    print_byte( hours );
    print_byte( minutes );
    print_byte( seconds );
}


void print_byte( byte x )
{
    print_nibble( HighNibbleMacro(x) );
    print_nibble( LowNibbleMacro(x) );
}


void print_nibble( nibble x )
{
    output( LCD,Nibble2AsciiMACRO( x ) );
}   


que fosse compilado em:

Código: Selecionar todos

main:
  call print_clock
  call delay
  jump main

print_clock:
   mov al, hours
   call print_byte_al
   
   mov al, minutes
   call print_byte_al

   mov al, seconds

print_byte_al:
    mov bl, high_nibble(al)
    call print_nibble_bl
   
    mov bl, low_nibble(al)

print_nibble_bl:
   call convert_bl_to_ascii_in_cl
   out Display, cl
   return


também não perde seu aspecto de rotina em nenhum momento, pois todas as sub-rotinas, sub-sub-rotinas, sub-sub-sub-rotinas são chamáveis individualmente e retornarão normalmente, obedecido os register and stack conventions adotados.

Perceba que agora não há nem jump nem call, um código simplesmente "cai" no outro. Maravilhas do "omit stack frames" rsrs..

[Jozias del Rios]

Se o tal compilador sdcc fosse aproveitar fall through, ele iria compilar o código do criador do tópico simplesmente como:

Código: Selecionar todos

primeiro:
 ;;;;; call segundo (fall through!!!)

segundo:
 jump primeiro


que seria mais perturbador para ti ainda rsrs... Mas ainda totalmente válido em organização de subrotinas.

[Djalma Toledo Rodrigues]

"Quando um Programador é bom ele é muito, muito bom.
Mas, quando ele é ruim, ele é horrível." (*)

E qual é em essencia a diferença ?

A Lógica -- O Raciocínio Lógico.

Programar µP ou µC , agora ja se confundem, não é 'bolar um programa' mas selecionar,
escolher, as Instruções disponíveis, de cada µP ou µC que satisfaça, com lógica,
ao objetivo proposto.

E para isso é necessário antes ter disponível o Set de Instruçõe do Componente.
É necessário conhecer o µP ou µC e o Hardwire.

É evidente que uma linguagem de Alto Nível não pode chegar a tanto.

Se diferentes compiladores C produzem resultados tão dispares como esses que
o Marcelo colocou, só podemos chegar a seguinte conclusão :

O Compilador C "bola um programa" ao compilar, ou melhor dito apresenta
o Compilado de quem o "bolou" .

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

(*) Depois Edito e coloco o nome do Autor, com a mudaça não consigo localizar agora o Livro.

DJ

[msamsoniuk]

certamente! esse eh o motivo pelo qual compiladores podem eventualmente gerar codigo mais eficiente que codigos otimizados manualmente. quanto maior o nivel da linguagem, mais margem vc dah para o compilador gerar um resultado otimizado, que nao reflete o seu algoritmo de alto nivel, mas sim um conjunto de tecnicas que o compilador utiliza para obter o mesmo resultado.

um exemplo bem classico sao os compiladores para fpgas, onde vc entra com uma descricao comportamental do hardware e o compilador infere uma logica para o que vc escreveu. neste caso, eh comum vc codificar e continuamente olhar o esquematico rtl, para ver se o compilador esta inferindo solucoes logicas de melhor performance. vc pode fazer o mesmo no caso de um compilador C.

"Quando um Programador é bom ele é muito, muito bom.
Mas, quando ele é ruim, ele é horrível." (*)

E qual é em essencia a diferença ?

A Lógica -- O Raciocínio Lógico.

Programar µP ou µC , agora ja se confundem, não é 'bolar um programa' mas selecionar,
escolher, as Instruções disponíveis, de cada µP ou µC que satisfaça, com lógica,
ao objetivo proposto.

E para isso é necessário antes ter disponível o Set de Instruçõe do Componente.
É necessário conhecer o µP ou µC e o Hardwire.

É evidente que uma linguagem de Alto Nível não pode chegar a tanto.

Se diferentes compiladores C produzem resultados tão dispares como esses que
o Marcelo colocou, só podemos chegar a seguinte conclusão :

O Compilador C "bola um programa" ao compilar, ou melhor dito apresenta
o Compilado de quem o "bolou" .

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

(*) Depois Edito e coloco o nome do Autor, com a mudaça não consigo localizar agora o Livro.

DJ

[tcpipchip]

Faltou tambem ver o paradigma se é:

-ORIENTADO A EVENTOS (DELPHI, VB)
-ORIENTADO A OBJETOS (EIFFEL, JAVA, "OBJECT PASCAL")
-ORIENTADO A PROCEDIMENTOS (C, PASCAL)
-ORIENTADO A DECLARAÇÕES (LISP, PROLOG)

[fabim]

hehe, eis o motivo de eu programar em 4 linguagens..
Compila, abre o hex da uma zoiada,
compila, abre o hex da outra zoiada.
Ficou esquisito, uso makros, ou se ja saber o endereço e banco, soco um ASM.rsrs

CHOCOLATI !!!

[Djalma Toledo Rodrigues]

compiladores podem eventualmente gerar codigo mais eficiente que codigos otimizados manualmente. "

Em Assembly raramente se otimiza, não se faz necessário. (*)

um exemplo bem classico sao os compiladores para fpgas, onde vc entra com uma descricao comportamental do hardware e o compilador infere uma logica para o que vc escreveu. neste caso, eh comum vc codificar e continuamente olhar o esquematico rtl, para ver se o compilador esta inferindo solucoes logicas de melhor performance.

Idem. Projeto de Circuito .
Apenas Circuitos de RF geralmente necessitam, já que por sua própria natureza é
sensível a posicionamento de componentes, interacoplamentos, etc.
Em Circuitos de Aúdio, e aqui mi refiro a Audio de Alta Qualidade, também mas, raro

vc pode fazer o mesmo no caso de um compilador C.

Rs uma contradição com a primeira Citação ?

DJ

[msamsoniuk]

opa, se vc nao otimizar manualmente seu codigo asm, com toda certeza o compilador vai acabar batendo ele em performance. veja que os primeiros compiladores fortran na decada de 50 jah tinham performance proxima a codigo asm *otimizado* manualmente.

o que assusta de olhar o codigo gerado pelo compilador eh perceber que no caso de algoritmos complexos, nao adianta nem tentar, o compilador sempre vai conseguir traduzir o algotimo complexo em uma sequencia mais otimizada de instrucoes. o grande problema entao nao eh saber se o compilador vai fazer isso bem ou nao, mas sim se o seu algoritmo de alto nivel esta bom. e nisso eu vejo uma grande falha na maioria dos ambientes de desenvolvimento de software.

tradicionalmente, uma ide para software nao passa de um bom editor de texto. quando muito, ele possui um software extra q te permite debugar (usando o hw real) e nos melhorzinhos simular o hw via software. mas a parte de debug costuma nao passar de uma tela com o codigo asm e C onde vc pode avancar passo a passo e colocar alguns break points.

isso constrasta bastante com uma ide para fpga, onde os editores de texto nem sao tao bons hehehe mas vc comeca escrevendo a descricao comportamental do hardware em verilog, por exemplo. entao a medida que vai descrevendo as interfaces e conectando os modulos, vc vai visualizando a arquitetura hierarquica dos modulos conectados uns aos outros. na medida que vc tem alguma coisa mais palpavel, vc pode sintetizar e conferir o esquematico rtl para ver a situacao do negocio.

ocorre que, conforme a sintaxe que vc escolhe para descrever o comportamento do hw, vc vai obter um ou outro resultado. de olho vc percebe se o resultado eh bom ou ruim. normalmente um resultado ruim eh quando vc tem logica combinacional muito extensa entre registros clockados e muito uso de celulas. o resultado eh bom quando vc tem pouca logica combinacional entre registros e vasto uso de estruturas compactas disponiveis no proprio hw da fpga.

infelizmente nao existe nada parecido em software, entao fica dificil, olhando para um codigo asm, imaginar se o fluxo de dados esta otimizado ou nao. vc pode malemal inferir se o resultado esta bom ou nao pelo tamanho do codigo, mas isso nao eh um indicativo bom para processadores maiores (jah fiz testes de otimizacao manual trocando dezenas de instrucoes simples geradas pelo gcc por instrucoes compactas para operacao de blocos no x86... e no fim obtive ganho zero!). nao sei se realmente valeria a pena inspecionar asm... acho que alguma forma de diagrama seria o mais correto e, de fato, algumas metodologias de zero defeitos apontam justamente para esse caminho.

bom, daih tem a simulacao. normalmente vc pode simular um processador no seu pc, mas comparando com o que se consegue numa ide de fpga dah vontade de chorar. na ide para fpga vc nao simula apenas o componente alvo, como consegue simular todos os outros componentes presentes na mesma placa e mesmo os outros componentes que formam o sistema como um todo.

isso ocorre pq existe o codigo sintetizavel que ira dar origem a fpga em si e o codigo nao sintetizavel, que esta mais para linguagem C do que para hw em si. e exatamente essa parte nao sintetizavel que fornece flexibilidade para gerar impulsos que simulam os componentes em volta da fpga. vc pode tanto monitorar os sinais eletricos em qq ponto do sistema como pode tratar o sistema como uma entidade de alto nivel, por exemplo, com um modulo que simula um processador escrevendo dados na fpga e consultando registros de estado.

eu ateh jah pensei em entrar nesse mercado de ides avancadas para sw, mas eh um negocio complexo demais... e claro, os fabricantes dos processadores tem mais condicoes de produzir ides tao completas, com simuladores e debuggers, mas mesmo assim, acho que meio que falta muita coisa ainda para chegar no mesmo estagio dos fabricantes de fpgas... e dureza eh saber que os caras que suportam o projeto de asics tem metodologias ainda mais avancadas e completas!

compiladores podem eventualmente gerar codigo mais eficiente que codigos otimizados manualmente. "

Em Assembly raramente se otimiza, não se faz necessário. (*)

um exemplo bem classico sao os compiladores para fpgas, onde vc entra com uma descricao comportamental do hardware e o compilador infere uma logica para o que vc escreveu. neste caso, eh comum vc codificar e continuamente olhar o esquematico rtl, para ver se o compilador esta inferindo solucoes logicas de melhor performance.

Idem. Projeto de Circuito .
Apenas Circuitos de RF geralmente necessitam, já que por sua própria natureza é
sensível a posicionamento de componentes, interacoplamentos, etc.
Em Circuitos de Aúdio, e aqui mi refiro a Audio de Alta Qualidade, também mas, raro

vc pode fazer o mesmo no caso de um compilador C.

Rs uma contradição com a primeira Citação ?

DJ