¿El acceso a la memoria no alineada siempre causa errores de bus?

De acuerdo con la página de Wikipedia Segmentation fault, un error de bus puede deberse a un acceso de memoria no alineado. El artículo ofrece un ejemplo sobre cómo desencadenar un error de bus. En el ejemplo, tenemos que habilitar la verificación de alineación para ver el error de bus. ¿Qué sucede si desactivamos dicha verificación de alineación?¿El acceso a la memoria no alineada siempre causa errores de bus?

Parece que el programa funciona correctamente. Tengo un programa que accede a la memoria desalineada con frecuencia, y es utilizado por un buen número de personas, pero nadie me informa errores de bus u otros resultados extraños. Si deshabilitamos la verificación de alineación, ¿cuál es el efecto secundario de la memoria desalineada?

Plataformas: Estoy trabajando en x86/x86-64. También probé mi programa compilándolo con "gcc -arch ppc" en una Mac y funciona correctamente.

Fuente

2009-09-30 user172818

¿Cuál es la plataforma que se está trabajando ?? –

Pavel Minaev responde en gran medida a mi pregunta. Estoy trabajando en x86/x86_64. Intenté mi programa compilándolo con "gcc -arch ppc" en Mac y funciona correctamente. – user172818

Tenga en cuenta que el acceso de memoria no alineado (en realidad, solo asignación de puntero) es un comportamiento indefinido según el estándar C, por lo que un compilador compatible puede hacer * cualquier cosa * si lo hace (aunque no todos los compiladores se tomarán esa libertad). – sleske

Puede ser mucho más lento acceder a la memoria no alineada (como en, varias veces más lenta).
No todas las plataformas admiten el acceso no alineado - x86 y x64, pero ia64 (Itanium) no, por ejemplo.
Un compilador puede emular acceso no alineados (VC++ hace que para los punteros declarados como __unaligned en IA64, por ejemplo) - mediante la inserción de controles adicionales para detectar el caso no alineada, y la carga/almacenamiento de partes del objeto que se sitúan en el límite de alineación por separado. Sin embargo, eso es incluso más lento que el acceso no alineado en plataformas que lo soportan de forma nativa.

Fuente

2009-09-30 08:54:33

Gracias. Pocos usuarios de mi programa están trabajando en ia64. Tal vez es por eso que no he recibido el informe de errores. – user172818

También puede agregar # 4 que un sistema operativo puede emular el acceso no alineado en funcionamiento de una aplicación detectando la excepción del procesador y corrigiéndolo (algo así como lo que sucede con un error de página). Esto es más lento que el compilador que realiza correcciones no alineadas en el código generado. Windows puede soportar esto en ia64. –

Esta respuesta se mencionó en la publicación del blog * [Alineación de datos para la velocidad: mito o realidad?] (Http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-myth- o-realidad /) *. –

Es muy mucho depende de la arquitectura del chip. x86 y POWER son muy indulgentes, Sparc, Itanium y VAX arrojan diferentes excepciones.

Fuente

2009-09-30 09:05:46

Muchas gracias por la respuesta. – user172818

Es de hecho depende del procesador. Recientemente trabajé en un DSP que felizmente procederá al usar la dirección de memoria alineada más cercana cuando se le solicite operar en un desalineado. *, pervertiste la memoria no alineada accediendo a un individuo. –

De hecho, ¿por qué molestarse siquiera en mirar esos últimos bits en absoluto? Los hombres reales saben lo que están haciendo, de todos modos :) Por otro lado, sería una arquitectura conveniente para utilizar punteros etiquetados, si utiliza los bits ignorados para la etiqueta ... –

Considere el siguiente ejemplo que acabo de probado en ARM9:

//Addresses  0  1  2 3  4  5  6  7  8 9 
U8 u8Temp[10] = {0x11,0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x00}; 

U32 u32Var; 

u32Var = *((U32*)(u16Temp+1)); // Let's read four bytes starting from 0x22 

// You would expect that here u32Var will have a value of 0x55443322 (assuming we have little endian) 
// But in reallity u32Var will be 0x11443322! 
// This is because we are accessing address which %4 is not 0.

Fuente

2013-03-12 23:36:49 Potzon

Creo que tiene un error ortográfico: su tercera declaración hace referencia ' Variable u16Temp', ¿dónde está su declaración? Solo veo 'u8Temp'. – amn

¿El acceso a la memoria no alineada siempre causa errores de bus?

Respuesta

Cuestiones relacionadas