¿El 8080 siempre maneja correctamente el acceso no alineado?
El 8080 se conoce como una CPU de 8 bits porque tiene un bus de datos de 8 bits, pero hay varios casos en los que debe realizar un acceso a la memoria de 16 bits, por ejemplo, al leer o escribir un par de registros de 16 bits. , o el contador de programa de 16 bits al realizar una llamada o retorno a una subrutina.
Supongo que admite acceso no alineado, es decir, no se requiere que la dirección sea pareja.
¿Admite el acceso totalmente no alineado en todos los casos, es decir, no se requiere que ambos bytes estén en la misma página? Por ejemplo, si intenta escribir un par de registros de 16 bits en la dirección$7fff, will the second byte be written to $8000? O si el puntero de la pila se estableció en$8001 and you perform a subroutine call, will the return address be written to the addresses $8000 y $ 7fff?
Respuestas
TL; DR:
El 8080 no conoce ninguna alineación. Todo acceso es byte y lineal. Tampoco hay lógica de página. Todas las direcciones se manejan como 16 bits directos y todo el acceso a los datos es de 8 bits.
(Para reflexiones adicionales, ver más abajo)
En detalle:
Supongo que admite acceso no alineado, es decir, no se requiere que la dirección sea pareja.
El 8080 no maneja ni sabe nada sobre alineación. Un valor de 16 bits simplemente se almacena en dos ubicaciones de memoria consecutivas (8 bits).
¿Admite el acceso totalmente no alineado en todos los casos?
Sí, la carga / almacenamiento de 16 bits se puede realizar desde cualquier dirección.
¿No hay requisito de que ambos bytes estén en la misma página?
No, el 8080 no tiene el concepto de 'páginas'. todos los punteros de dirección son de 16 bits y los incrementos se manejan como tales.
Por ejemplo, si intenta escribir un par de registros de 16 bits en la dirección $7fff, will the second byte be written to $8000?
Sí (* 1).
O si el puntero de la pila se estableció en $8001 and you perform a subroutine call, will the return address be written to the addresses $8000 y $ 7fff?
Exactamente.
El 8080 como CPU de 16 bits
Sí, en cierto sentido el 8080 (y sus descendientes 8085 y Z80) son CPU de 16 bits, al menos en lo que respecta al conjunto de registros y manejo de direcciones. El archivo de registro está organizado como
- un conjunto de seis registros de 16 bits: BC, DE, HL, SP, IP y WZ (* 2)
- conectado directamente a un incrementador / decrementador de 16 bits
- conectado directamente a un pestillo de dirección de 16 bits
- que a su vez está conectado al bus de direcciones
Así, cada uno de estos registros puede, dentro de un único ciclo de máquina, ser
- bloqueado para colocarlo en el bus de direcciones (externo), y / o
- incrementado o
- decrementado
Tenga en cuenta que no hay ninguna restricción por "páginas" implícitas o la necesidad de obtener una alineación par / impar, ya que la generación de direcciones es simple de 16 bits con una interfaz de memoria del tamaño de un byte.
La estructura interna del 8080 es, con respecto a los registros y el direccionamiento, completamente de 16 bits, mientras que el 6502 aquí también es de 8 bits, operando con unidades separadas de 8 bits para manejar páginas y direcciones dentro de las páginas.
Antecedentes
La pregunta puede surgir de una confusión entre los requisitos de tamaño de los datos y el tamaño del bus de datos. Los problemas de alineación solo pueden surgir con diseños que tienen una granulación de direcciones más fina que el bus de datos externo y que acceden a un elemento de datos del tamaño de varias unidades de dirección, es decir, una CPU con direccionamiento de bytes pero un bus de datos de varios bytes de ancho que accede a datos de más de un byte - como un 68020 (direccionamiento de bytes, bus de datos de 4 bytes de ancho) que accede a una palabra de 16 bits.
El 8080 no entra en esta categoría. La unidad de datos direccionable y el acceso con no difieren.
* 1 - O más correcto será la dirección 7FFFh y 8000h :)) SCNR
* 2 - Tenga en cuenta que AF no es uno de ellos, A es un registro separado, mientras que F no existe.
Aunque el 8080 y el Z80 no se preocupan por la alineación, un compilador que apunte al 8080 podría beneficiarse un poco al saber que los punteros a objetos de 16 y 32 bits estarán alineados. Por ejemplo, considere el código necesario para procesar *p += 1;si pes un int*. Si pse sabe que está alineado, un compilador podría generar [se muestran códigos de operación Z80]
ld hl,(p)
inc (hl)
jnz noHighByte
inc l
inc (hl)
noHighByte:
Si un compilador no sabía que p estará alineado con 16 bits, necesitaría generar una instrucción "inc hl" en lugar de "inc l", lo que tomaría dos ciclos adicionales para ejecutarse. El costo adicional es lo suficientemente pequeño como para que ninguno de los compiladores 8080 / Z80 que he visto hiciera ningún esfuerzo por evitarlo, pero si un lenguaje requería que los objetos se alinearan de esa manera, podría haber ofrecido algunos beneficios.
Curiosamente, los beneficios serían aún mayores si se pudiera garantizar que los arreglos pequeños no se extendieran a ambos lados de los límites de la página, pero los idiomas no ofrecen formas de especificar tales restricciones. Si, por ejemplo, uno tiene un puntero a un char[16];que se sabe que está alineado con 16 bytes, la evaluación de p[i]++podría ser:
ld hl,(p)
ld a,(i)
add a,l
ld l,a
inc (hl)
en lugar de algo como:
ld hl,(p)
ld a,(i)
ld e,a
ld d,0
add de,hl
inc (hl)
o
ld hl,(p)
ld a,(i)
add a,l
ld l,a
jnc noCarry
inc h
noCarry:
inc (hl)
siendo la última versión más grande, pero sin afectar a DE. Tenga en cuenta que la última versión es más grande que la del medio, pero más rápida, ya que "ADD HL, DE" es una instrucción muy lenta.
Para explotar cosas como la última velocidad, un compilador tendría que saber que la indexación ppor ino cruzaría el límite de una página, y ningún idioma que conozca generalmente proporcionaría alguna forma de decirle eso a un compilador.