Este grupo especializado despúes de ciertos días de trabajo y de juntar de datos, obtuvimos los datos necesarios, esperamos que te resulte útil para tu proyecto.
Solución:
La razón es reducir el tamaño del programa. Imagine que su programa C se ejecuta en un sistema integrado, donde el código y todas las constantes se guardan en true ROM (memoria flash). En tales sistemas, se debe ejecutar una “copia hacia abajo” inicial para establecer todos static objetos de duración de almacenamiento, antes de llamar a main(). Por lo general, irá como este pseudo:
for(i=0; i
Donde .data y .bss se almacenan en RAM, pero init_value se almacena en ROM. Si hubiera sido un segmento, entonces la ROM tenía que llenarse con muchos ceros, aumentando significativamente el tamaño de la ROM.
Los ejecutables basados en RAM funcionan de manera similar, aunque, por supuesto, no tienen true ROM.
Además, es probable que memset sea un ensamblador en línea muy eficiente, lo que significa que la copia de inicio se puede ejecutar más rápido.
los .bss
segmento es una optimización. La totalidad .bss
El segmento se describe con un solo número, probablemente de 4 u 8 bytes, que indica su tamaño en el proceso en ejecución, mientras que el .data
sección es tan grande como la suma de los tamaños de las variables inicializadas. Por lo tanto, la .bss
hace que los ejecutables sean más pequeños y rápidos de cargar. De lo contrario, las variables podrían estar en el .data
segmento con inicialización explícita a ceros; el programa estaría en apuros para notar la diferencia. (En detalle, la dirección de los objetos en .bss
probablemente sería diferente de la dirección si estuviera en el .data
segmento.)
En el primer programa, a
estaría en el .data
segmento y b
estaría en el .bss
segmento del ejecutable. Una vez que se carga el programa, la distinción se vuelve irrelevante. En tiempo de ejecución, b
ocupa 20 * sizeof(int)
bytes
En el segundo programa, var
se le asigna el espacio y la asignación en main()
modifica ese espacio. Sucede que el espacio para var
fue descrita en el .bss
segmento en lugar del .data
segmento, pero eso no afecta la forma en que el programa se comporta cuando se ejecuta.
Desde Lenguaje ensamblador paso a paso: programación con Linux de Jeff Duntemann, sobre el .datos sección:
los .datos La sección contiene definiciones de datos de elementos de datos inicializados. Los datos inicializados son datos que tienen un valor antes de que el programa comience a ejecutarse. Estos valores son parte del archivo ejecutable. Se cargan en la memoria cuando el archivo ejecutable se carga en la memoria para su ejecución.
Lo importante que debe recordar acerca de la sección .data es que cuantos más elementos de datos inicializados defina, más grande será el archivo ejecutable y más tiempo llevará cargarlo desde el disco a la memoria cuando lo ejecute.
y el .bss sección:
No todos los elementos de datos necesitan tener valores antes de que el programa comience a ejecutarse. Cuando está leyendo datos de un archivo de disco, por ejemplo, necesita tener un lugar para que vayan los datos después de que lleguen del disco. Los búferes de datos como ese están definidos en el .bss sección de su programa. Usted reserva una cierta cantidad de bytes para un búfer y le da un nombre al búfer, pero no dice qué valores deben estar presentes en el búfer.
Hay una diferencia crucial entre los elementos de datos definidos en la sección .data y los elementos de datos definidos en la sección .bss: elementos de datos en la sección .data sección agregue al tamaño de su archivo ejecutable. Los elementos de datos en la sección .bss no. Se puede definir un búfer que ocupa 16.000 bytes (o más, a veces mucho más) en .bss y no agrega casi nada (alrededor de 50 bytes para la descripción) al tamaño del archivo ejecutable.
Sección de Reseñas y Valoraciones
Al final de la post puedes encontrar las aclaraciones de otros sys admins, tú de igual manera eres capaz mostrar el tuyo si lo crees conveniente.