TMR clock source -> cortex M3.

[msamsoniuk]

rum, rummmmmm;;
FREQUENCIA MÁXIMA PARA OTÁRIOS

hahaha vai voltar para o PIC eh fabim? :D

[B-EAGLE]

por que raios ARM não tem instrução de incremento e decremento? tem algum motivo em especial? pq se usa abessa!

[fabim]

rum, rummmmmm;;
FREQUENCIA MÁXIMA PARA OTÁRIOS

hahaha vai voltar para o PIC eh fabim?

C viu que os DSpic estão despencando de preço ?

C viu que os PIC32, tem ADD, SUB, INC, DEC, tudo por ciclo de instrução ? isso mesmo!! 1 ciclo igual os piquim de 8 bits..
O mult 32 * 32 em hw,
moff reg, muxh
moff reg, muxl
bsf realg,3
movf muxx, regresul
e pronto..
é mais ou menos isso.

[fabim]

vou falar com a keil, pra ver a possibilidade de ADD os PIC32 lá.. ai depois eu vejo.. hehehe

[msamsoniuk]

o ARM nao tem INC e DEC primeiro pq eh um processador RISC, entao a ideia eh justamente minimizar o numero de instrucoes para conseguir compactar a arquitetura e reduzir custos.

segundo pq eh um processador orientado a registros, ou seja, vc tem que tentar se doutrinar a fazer load no comeco da rotina, processar o maximo possivel em registros e soh no final descarregar com store. e nesse caso nem tem a ver com ser RISC, mas por ser uma arquitetura orientada a registros, em oposicao as tipicas arquiteturas orientadas a acumulador e memoria dos processadores de 8 bits. as vantagens sao obvias, por exemplo, compare a sequencia de incrementar uma variavel e multiplicar por dois fazendo um shift. na memoria seria algo como:

inc memoria
rshift memoria

soh que incrementar na memoria implica em 1 clock para leitura, 1 clock para incrementar e mais 1 clock para escrever, perfazendo assim 3 clocks. o rshift vai consumir recursos identicos, o que resulta em 6 clocks.

fazendo a mesma coisa em uma arquitetura orientada a registros:

load r0, memoria
inc r0
rshift r0
store r0, memoria

nessa caso vc vai gastar 1 clock para a leitura, 1 clock para incrementar, 1 clock para shiftar e 1 clock para escrever, totalizando 4 clocks. de fato, se fosse apenas incrementar a variavel diretamente, o resultado seria identico:

inc memoria

consome 3 clocks pq vc precisa de 1 para ler, 1 para incrementar e 1 para gravar... exatamente o mesmo do codigo para o processador orientado a registros:

load r0, memoria
inc r0
store r0, memoria

entao no minimo vc empata e, se precisar de mais operacoes, vc jah tem vantagens de performance, as custas do numero de instrucoes.

porem, tem algo importante no set de instrucoes... quando falamos inc memoria, que tipo de instrucao realmente eh codificado?

no caso de um hc908 usando enderecamento curto (primeiros 256 bytes de memoria), um inc implica em dois bytes. se for usar enderecamento longo (toda faixa de 64KB de memoria), um inc implica em 3 bytes. como o bus de instrucoes eh de um byte, vc teria apenas para a busca da instrucao 2 ou 3 clocks, somando entao com uma sequencia de leitura-modificacao-escrita de provavelmente mais 3 clocks, totalizando assim 5 a 6 clocks para um mero inc!

comparativamente, um inc no acumulador consome apenas 1 clock, como varias outras instrucoes... entao teria que pesar na balanca: vale a pena mexer na memoria ou no acumulador?

como ele nao tem muitos registros, nao tem como pensar muito... mas em um arm ou 68000, que possuem 16 registros de 32 bits, eh muito mais economico carregar tudo para os registros e processar diretamente. compare por exemplo um strcpy() em um processador orientado a acumulador (HC908) e um processador orientado a registros (68040):

loop:
ldhx @src // 3 bytes de instrucao, 2 bytes de leitura = 5 clocks
lda @hx) // 1 byte de instrucao, 1 byte de leitura = 2 clocks
inc hx // 1 byte de instrucao = 1 clock
sthx @src // 3 bytes de instrucao, 2 bytes de escrita = 5 clocks
ldhx @dst // 3 bytes de instrucao, 2 bytes de leitura = 5 clocks
sta @hx) // 1 byte de instrucao, 1 byte de escrita = 2 clocks
inc hx // 1 byte de instrucao = 1 clock
sthx @dst // 3 bytes de instrucao, 2 bytes de escrita = 5 clocks
tsta // 1 byte de instrucao = 1 clock
jnz @loop // 2 bytes de instrucao = 2 clocks

total ae de 29 clocks para mover cada byte entre dois ponteiros de 16 bits... na outra versao, com um bus de 16 bits e orientacao a registros:

move.l @src,a0 // 3 words de instrucao, 2 word read = 5 clocks
move.l @dst,a1 // mesma coisa = 5 clocks
loop:
move.b @a0+,@a1+ // 1 word de instrucao, 1 word read com a0+, 1 word write com a0+ = 5 clocks
bnz loop // branch curto, com 1 word = 1 clock

pequeno massacre com 6 clocks por byte transferido e 10 clocks para setup inicial dos registros que operam como ponteiros src e dst. como o incremento esta embutido no modo de enderecamento ao custo de 1 clock extra por move, nao existe inc/dec no 680x0. e como o move seta o flag Z de acordo com o operando, eh uma instrucao de teste a menos.

opa, tem um pequeno truque aqui... eu consigo fazer move de memoria para memoria no 680x0 e ainda por cima setar os flags de acordo com o valor movido pq 1/4 do set de instrucoes dele eh composto apenas de move... provavelmente eh o processador que dedica mais espaco de microcodigo para move, pq tem todo tipo possivel!

provavelmente em um RISC mais puramente load/store, o move seria quebrado em dois, com um load seguido de um store... de qq forma, a diferenca de performance seria minima e a maioria dos processadores RISC possui auto-incremento de ponteiros.

nas contas eu ainda nao inclui coisas tipo cache, overlap de instrucoes, execucao fora de ordem e outras coisas que o 680x0 faz. por outro lado, o acesso a memoria externa em apenas 1 clock eh algo bastante otimista (embora tenha compensado usando bus de apenas 16 bits).

[fabim]

hehehe.

incfsz var,f //4ciclos incrementa, guarna nele mesmo, testa se zero, skip
call sei_nao_eim.
call acho_que_nao_e_bem_assim

[guest2003]

P**** Fabim...

Voce leu o Datasheet do xipa?

Olha isso:

Eight channel General Purpose DMA controller (GPDMA) on the AHB multilayer matrix that can be used with the SSP, I2S-bus, UART, the Analog-to-Digital and Digital-to-Analog converter peripherals, timer match signals, and for memory-to-memory transfers.


Nao tem que fazer INT a cada 1us ... senão complica ne....

Le o cartao para um buffer... manda a DMA botar pra fora no DA... e assim por diante... e deixa o processador tranquilo... gerando INT só a cada meia hora....

[]'s

[jeanfernandes]

Outro fato interessante fabim

faz um teste basico

declara uma variavel int (32 bits) edecrementa incrementa

declara uma variavel tipo uchar (8 bits) e faz mesma coisa
compara os codigos....

fuiz.

[msamsoniuk]

hehehe.

incfsz var,f //4ciclos incrementa, guarna nele mesmo, testa se zero, skip
call sei_nao_eim.
call acho_que_nao_e_bem_assim

soh tem um detalhe ae: o ARM consegue fazer em 4 clocks tb... no lugar de fazer dois load, inc e depois um load e um store como o compilador mostra:

0x000040A0 4817 LDR r0,[pc,#92] ; @0x00004100
0x000040A2 6800 LDR r0,[r0,#0x00]
0x000040A4 1C40 ADDS r0,r0,#1
0x000040A6 4916 LDR r1,[pc,#88] ; @0x00004100
0x000040A8 6008 STR r0,[r1,#0x00]

vc faz dois loads, inc e um store, pq o terceiro load eh redundante com o primeiro (eh o mesmo endereco):

0x000040A0 4817 LDR r1,[pc,#92] ; @0x00004100
0x000040A2 6800 LDR r0,[r1,#0x00]
0x000040A4 1C40 ADDS r0,r0,#1
0x000040A8 6008 STR r0,[r1,#0x00]

note que o valor do load/store jah fica em r1. e se vc for fazer mais do que apenas incrementar, vc consegue fazer em 1 clock (contra 4 clocks do PIC). quanto ao teste e skip, o ARM possui execucao condicional das instrucoes e vc pode skipar quantas vc quiser.

[polesapart]

Incremento no ARM :

dados++; // 5 ciclos
LDR r0,[pc,#92]
LDR r0,[r0,#0x00]
ADDS r0,r0,#1
LDR r1,[pc,#88]
STR r0,[r1,#0x00]

Incremento no PIC:

dado++; // 1 ciclo
INCF dado,f

Ai que saudade que dá !!!!

.

aham, mas o pic fazia 1 instrução pra 4 ciclos de clock, o arm faz 1/1 ... né? alêm disso, o pic só tinha 1 registro. vc pode fazer inc/dec com 1 ciclo, se vc ñ fizer o memory load/store


mas pow, foi mal, eu não vi q o samsoniuk já tinha defendindo o arm. isso é tão raro que até postei um vídeo do pink floyd em agradecimento a ele, lá no boteco.

[msamsoniuk]

o clock unico de 4MHz do PIC na verdade deriva em 4 clocks de 1MHz com 4 atrasos de fase diferentes, o que significa que a execucao pode rodar em 4 passos sequenciais com 1us entre eles para acomodar logica combinacional. suficiente para executar 4 passos separados, que no caso dessa instrucao suponho que sejam load, add, store, skip.

normalmente eh dito que o PIC possui um pipeline de 2 estagios, sendo um deles fetch e outro execucao. no fundo isso poderia ser visualizado como um pipeline de 8 estagios, sendo os 4 primeiros de fetch e decodificacao, os 4 ultimos com a execucao propriamente dita. na medida que o PIC enderaca quase nada de memoria ram, eh possivel embutir o offset para essa memoria na propria instrucao e eliminar a necessidade de fazer fetch de palavras adicionais.

assim, ele dispensa load/store para operacoes com um operando pq o load/store esta embutido no ciclo de execucao, funcionando, na verdade como um processador CISC.

comparativamente, um processador moderno faz todo o trabalho com apenas uma fase de clock! o truque eh montar um register file com tres barramentos independentes, de modo a conseguir fazer duas leituras e uma escrita em "paralelo"... note que a ram do PIC eh um register file tambem, porem com um unico barramento compartilhado. o que difere o register file do acumulador, no caso do PIC, eh o fato do acumulador ter barramentos separados, nao requerendo ciclos adicionais para load/store e deixando mais ciclos para a logica da instrucao.

em relacao ao ARM, a diferenca eh que o PIC esta preso as 4 fases de clock e possui apenas um registro com barramento duplo, enquanto o ARM eh desenhado para trabalhar com apenas uma fase de clock em um banco de registros capaz de fazer 2 load e 1 store em paralelo, por barramentos independentes.

em essencia, qualquer RISC pode fazer uma operacao por clock utilizando uma logica RTL basica:



isso para uma operacao NOT, que requer 1 operando. se requerer 2 operandos, basta incluir dois barramentos de entrada (por exemplo, um AND ou mesmo uma ALU inteira). e para ter um register file, incluir um par de mux nos dois barramentos de entrada e um demux na saida.

fica bem eficiente, porem para uma seleta quantidade de registros que possuem capacidade de operar com 3 barramentos. para a memoria, que soh possui um barramento, vc fica com instrucoes load e store separadas.

Incremento no ARM :

dados++; // 5 ciclos
LDR r0,[pc,#92]
LDR r0,[r0,#0x00]
ADDS r0,r0,#1
LDR r1,[pc,#88]
STR r0,[r1,#0x00]

Incremento no PIC:

dado++; // 1 ciclo
INCF dado,f

Ai que saudade que dá !!!!

.

aham, mas o pic fazia 1 instrução pra 4 ciclos de clock, o arm faz 1/1 ... né? :P alêm disso, o pic só tinha 1 registro. vc pode fazer inc/dec com 1 ciclo, se vc ñ fizer o memory load/store :P

mas pow, foi mal, eu não vi q o samsoniuk já tinha defendindo o arm. isso é tão raro que até postei um vídeo do pink floyd em agradecimento a ele, lá no boteco.

[fabim]

só sei que estou chateado, de conseguir clock´ar um pino via software apenas em 25mhz. muito triste isto..

hehehehehehehe..
Bom, sei lá tipo.

Pra pic num volto mais, nem a purreta.