mas pense bem, ele soh vai fazer mais de uma instrucao por clock em quatro casos:
a) se for superescalar e tiver duas unidades de inteiros, porem, se fosse esse o caso, ele deveria estar picotando 2 instrucoes/clock, do contrario ele seria um superescalar muito ruim.
b) se for vetorial, ele vai puxar uma instrucao e executar a mesma para todas as unidades vetoriais, mas nesse caso ele deveria estar picotando 4 instrucoes/clock, do contrario ele seria um processador vetorial muito ruim.
c) se ele otimizar o dhrystone, somar um valor alto em loops/segundo e na hora de comparar com o VAX dar um valor de DMIPS alto, que nao corresponde a performance real em MIPS.
d) se ele tiver uma cache com bus interno de 64 bits, ele pode transferir 2 instrucoes, de modo a pre-decodificar uma segunda instrucao enquanto decodifica a primeira. porem eu acho um desperdicio um bus tao largo para um ganho tao pequeno.
eu francamente acho que eh o terceiro caso.
veja q a otimizacao de branches soh melhora a questao de descartar ou nao os pipelines, aproximando melhor do pico de 1 instrucao por clock. mas na pratica nao faz vc rodar 2 instrucoes por clock, pq a instrucao do branch continua lah no fluxo de instrucoes q vem da cache uma a uma.
a unica forma dele rodar 2 instrucoes por clock seria o caso do coldfire, onde o bus da cache eh 32 bits e a largura das instrucoes 16 bits. isso permite efetivamente que o processador faca a pre-decodificacao de uma segunda instrucao enquanto esta decodificando a primeira. como ele soh tem uma unidade de inteiros, nao vai rodar 2 instrucoes por clock, mas ele pode rotear a segunda instrucao para uma unidade diferente, como a unidade de branch ou unidade mac, resultando em "pouco mais de" 1 instrucao por clock com a mesma largura de bus do arm que nao pode passar de 1 instrucao por clock.
jah o powerpc nao tem essa facilidade pq as instrucoes sao largas como no caso do arm, mas eles resolvem usando barramentos de 64 e 128 bits, efetivamente permitindo transferir 2 ou 4 instrucoes no mesmo clock, mas com o custo indo lah em cima.
polesapart escreveu:Comparado ao armv4 (arm7tdmi por ex), o cortex-m3 tem branch speculation e arquitetura harvard, sem falar que algumas instruções executam em 1 ciclo de clock, isto ajuda a explicar a diferença. Quanto ao fato dos dmips serem positivos (maior que o clock), o branch speculation ajuda a "enganar" o cálculo, pq o processador de referência sofre a penalidade dos branches (todo branch toma N ciclos de clock), enquanto que no m3, se o branch speculator fizer a escolha certa, o custo é um ciclo de clock. Estatisticamente ele nunca consegue 100% de acertos. Os cortex-A"x" tem branch prediction, que consegue um acerto melhor ao analisar o fluxo de instruções e condicionais. No caso destes últimos, os pipelines tem um nível profundo, então o custo de um branch é muito alto, por isto ele tenta evitar a penalidade o máximo possível. No cortex m3 e no arm7tdmi, o custo de um branch "tomado" é de 3 ciclos de clock.