0% encontró este documento útil (0 votos)
6 vistas5 páginas

Segmentación y Paralelismo en Procesadores

El documento aborda el concepto de segmentación y paralelismo interno en arquitecturas de procesamiento, destacando la diferencia entre pipelining y paralelismo, así como los tipos de procesadores. Se describen los riesgos en el cauce, incluyendo riesgos estructurales, de datos y de control, junto con sus soluciones. Además, se discuten las excepciones en procesadores segmentados y el tratamiento de estas por parte del hardware y el sistema operativo.

Cargado por

AMINE BOUTITAH
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
6 vistas5 páginas

Segmentación y Paralelismo en Procesadores

El documento aborda el concepto de segmentación y paralelismo interno en arquitecturas de procesamiento, destacando la diferencia entre pipelining y paralelismo, así como los tipos de procesadores. Se describen los riesgos en el cauce, incluyendo riesgos estructurales, de datos y de control, junto con sus soluciones. Además, se discuten las excepciones en procesadores segmentados y el tratamiento de estas por parte del hardware y el sistema operativo.

Cargado por

AMINE BOUTITAH
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

4.

Segmentación Paralelismo interno

1) Idea general: por qué aparece la segmentación

• En Von Neumann hay limitaciones técnicas a la velocidad → se buscan arquitecturas alternativas


con varias unidades de procesamiento.

• Tipos de paralelismo:

o Paralelismo interno (una sola CPU): segmentación/pipelining (sin hardware replicado).

o Paralelismo explícito (varias CPUs): SIMD, MISD, MIMD.

2) Pipelining vs Paralelismo (diferencia clásica de test)

• Ambos buscan mejorar rendimiento (instrucciones por unidad de tiempo) haciendo que más
hardware opere simultáneamente.

• Pipelining: el hardware NO se replica, se divide en etapas especializadas.

• Paralelismo (arquitecturas paralelas): el hardware SÍ se replica, se ejecutan varias operaciones a la


vez.

• Comparación típica:

o Secuencial pura: 1 resultado cada N ciclos.

o Paralela pura: N resultados cada N ciclos.

o Pipeline: 1 resultado por ciclo (una vez lleno el cauce).

3) Tipos de procesadores (definiciones cortas)

• Secuencial: no empieza una instrucción hasta terminar la anterior.

• Monociclo: el ciclo lo fija la instrucción más lenta.

• Multiciclo: el periodo lo fija la etapa más larga.

• Segmentado: permite solapar varias instrucciones en el tiempo (paralelismo a nivel de


instrucción).

4) Conceptos básicos de segmentación (ideal)

• Objetivo deseable: CPI = 1 (una instrucción completada por ciclo en régimen).

• El periodo de reloj queda limitado por la etapa más lenta.

• Motivación: ejecutando una sola instrucción, el hardware está infrautilizado gran parte del
tiempo.

• Para segmentar un multiciclo: arrancar una nueva instrucción cada ciclo.

• Condición clave: en cada etapa, las instrucciones deben usar recursos distintos para evitar
conflictos.
5) Cauce de 5 etapas (RISC-V segmentado)

1. IF: búsqueda de instrucción en memoria de instrucciones

2. ID: decodificación + lectura de operandos

3. EX: ALU / cálculo de dirección

4. MEM: acceso a memoria de datos

5. WB: escritura del resultado en banco de registros

6) Rendimiento del procesador segmentado (ideas clave)

• Pipeline ideal:

o Throughput mejora → idealmente 1 instrucción/ciclo → CPI ≈ 1.

• Ojo: la latencia de una instrucción individual puede empeorar por registros de segmentación, etc.

• Speedup máximo ideal con k etapas ≈ k (5 etapas → 5).

• Fórmula típica:

7) Problemas en la ruta de datos (colisiones típicas)

• Colisión en el acceso a memoria: IF y MEM (si fuese una sola memoria).

• Colisión en banco de registros: ID (lectura) y WB (escritura).

• Riesgo de PC: IF actualiza PC, pero saltos lo pueden cambiar más tarde (riesgo de control).

8) Soluciones estructurales (evitar colisiones)

• Separar memoria de instrucciones y memoria de datos.

• Banco de registros: escritura en 1ª mitad del ciclo y lectura en 2ª mitad.

• Uso de multiplexores cuando hay varias fuentes posibles.

• Para BEQ: se añade hardware para no estorbar a la ALU principal ([Link]. restador para
comparación/cálculo).

• Registros de segmentación: guardan resultados al final de cada etapa/ciclo (tamaño depende de


qué transportan).

9) Registros de segmentación (qué son)

• Obligatorios entre etapas.

• Propagan datos y también señales de control a la siguiente etapa.


10) Unidad de control en pipeline (muy preguntable)

• Decodificación multinivel: unidad global + ALU-control.

• En ID, el opcode permite generar todas las señales necesarias.

• Las señales se propagan por los registros de segmentación.

• Bloques típicos de señales:

o Para EX: ALUSrcA, ALUSrcB, ALUOp, RegDst

o Para MEM: Branch, MemRead, MemWrite

o Para WB: MemToReg, RegWrite

11) Por qué RISC-V facilita el pipelining (lista típica)

1. Instrucciones de misma longitud → IF/ID simples.

2. Pocos formatos y campos consistentes → leer registros mientras se decodifica.

3. Memoria solo en load/store → EX calcula dirección.

4. Datos alineados → basta un acceso a memoria.


→ ISA diseñada para reducir riesgos del cauce.

Riesgos en el cauce (Hazards) — LO QUE MÁS CAE

12) Definición general de hazard

• Situaciones que impiden ejecutar la siguiente instrucción en el siguiente ciclo.

Tipos: Estructurales, De datos, De control

13) Riesgos estructurales

• Aparecen cuando 2+ instrucciones requieren el mismo recurso a la vez.

• Ejemplos:

o IF y MEM compiten por memoria.

o ID y WB compiten por banco de registros.

• Soluciones:

o Duplicar/segmentar recursos o turnos.

o Separar memoria de instrucciones/datos.

o BR: escribir 1ª mitad, leer 2ª mitad.

14) Riesgos de datos (dependencias) — nombres


• Tipos:

o RAW (Read After Write) → riesgo real.

o WAR (Write After Read)

o WAW (Write After Write)

15) Soluciones a RAW (3 familias)

A) Software (compilador)

• Reordenación de instrucciones (manteniendo semántica).

• Si no se puede, insertar NOPs.

• Coste: menos rendimiento; compilador más complejo.

B) Hardware: stall

• Detecta dependencia y detiene el pipeline hasta que desaparece.

• Efecto: aumenta CPI.

C) Hardware: forwarding / bypassing

• Pasa resultados cuando están disponibles sin esperar a escribir en BR.

• Requiere conexiones extra; reduce stalls, pero no elimina todos.

16) Riesgos de control (branches)

• Problema: el PC correcto puede no conocerse al arrancar la siguiente instrucción.

• En BEQ, si no se hace nada, aparecen parones.

Soluciones típicas

• Stall

• Resolver antes (adelantar condición/destino)

• Predicción estática: tomado / no tomado

17) Adelantamiento de control (qué significa)

• Mover lógica a ID para:

o evaluar condición (restador + Zero),

o calcular destino (sumador).

• Aun así, pueden quedar paradas; como los saltos son frecuentes, impactan mucho.

18) Predicción de salto estática (lo preguntable)


• Predice “tomado” o “no tomado” antes de saber el resultado.

• Si falla → se vacía el cauce y cargar camino correcto.

• En este modelo, se destaca que tiene sentido usar predicción estática de salto no tomado.

Excepciones en procesador segmentado (también cae)

19) Excepciones en pipeline: problema clave

• Puede haber excepciones simultáneas porque hay varias instrucciones en vuelo.

• Conceptos:

o Excepciones precisas: respetan el orden arquitectónico.

o Imprecisas: respetan el orden en que aparecen, que puede diferir.

20) Excepciones como “riesgo de control” + acciones

• Se tratan como riesgo de control:

1. Vaciar instrucciones posteriores.

2. Se debe comenzar la carga de instrucciones de la nueva dirección

• Soporte típico: seleccionar nuevo PC, SCAUSE (causa), SEPC (PC de la instrucción)

21) Hardware vs Sistema Operativo (reparto típico)

Hardware

• Detener instrucción fallida, completar anteriores, vaciar posteriores,

• guardar causa, salvar PC, saltar a dirección fija.

Sistema Operativo

• Analiza causa y actúa:

o ilegal/overflow/hardware → termina proceso y reporta

o syscall/E/S → salva estado (context switch), atiende, restaura

• Uso frecuente: fallos de página y excepciones de TLB.

22) Tratamiento básico (RISC-V)

• Guardar PC en SEPC.

• Guardar causa en SCAUSE.

• Saltar a la RTE (handler) en dirección fija.

23) Vector de interrupciones

• La dirección del handler depende de la causa (vector).

También podría gustarte