¿Por qué la sección de código se llama sección de texto?


14

La sección de un ejecutable que contiene código a veces se denomina .textsección. En arquitecturas de memoria segmentada, un segmento asignado como código a veces se denomina segmento de texto. El mensaje de error de Unix "archivo de texto ocupado" ( ETXTBSY) significa "este archivo es un programa que se está ejecutando".

¿Cómo llegó el texto a significar código ejecutable (máquina) ?

Una respuesta ideal sería: explicar la conexión entre la palabra y su significado; proporcionar una cita para el origen o al menos la historia del término; dar una idea de qué comunidades lo usan.


.textEs una directiva de montaje. Asamblea es texto.
Austin Henley

66
Se hizo una pregunta similar y se respondió en StackOverflow hace 3 años: stackoverflow.com/questions/1282506/…
Stephen C

@StephenC Gracias por el enlace. Fácil de encontrar buscando en Google "segmento de texto", intenté principalmente con "sección de texto" y no apareció. Por lo tanto, se remonta al menos a los días de GE, pero aún no está claro cómo se estableció el significado.
Gilles 'SO- deja de ser malvado'

Respuestas:


5

El término proviene del lenguaje ensamblador. No puedo verificar la etimología, pero supongo que el nombre proviene del otro uso de la sección. Mientras que la .datasección denota variables que pueden cambiar durante el curso de la ejecución, la .textsección contiene datos que no cambian durante la ejecución, lo que permite ponerla en ROM si es necesario. Eso lo hace útil para el código, sí, pero también lo hace útil para cadenas de texto que no cambian. Probablemente de ahí proviene el término.

Para abordar el comentario de Griffin sobre las funciones de primera clase, considere el siguiente código de Python 3:

def counter():
    x = 0
    def increment(y):
        nonlocal x
        x += y
        print(x)
    return increment

El código que realmente ejecuta incrementtermina por verse internamente algo así como:

self.func_dict['x'] += y
print(self.func_dict['x'])

Ese código ejecutable se puede poner en la ROM. Nunca cambia durante la ejecución del programa, sin importar cuántas veces llame counter(). Lo que cambia es el selfpuntero y sus variables miembro. Esos deben ser puestos en .data. Cuando usted return increment, en realidad, está devolviendo una nueva instancia de un objeto de función de incremento. No está creando dinámicamente nuevo código ejecutable cada vez. El código en sí es inmutable a pesar de que el puntero no lo es.

El único código que debe almacenarse en la .datasección es el generado por eval(), porque no lo conoce el compilador o el compilador JIT al inicio del programa. Sin embargo, incluso ese código es inmutable. Si cambia la cadena y eval()vuelve a llamar , no está cambiando el código de la vez anterior que llamó eval(), está creando un conjunto completamente nuevo de código.

Aunque el modelo de programación puede hacer que parezca que el código es mutable, el código de auto-modificación real en el nivel de instrucción del procesador es peligroso y rara vez se encuentra fuera de los temas de vudú del sistema operativo como el cambio de contexto del proceso.


Entonces, ¿qué sucede cuando está usando un lenguaje funcional considerando que el código también es mutable / de primera clase?
Griffin

1
Vea mi edición sobre funciones de primera clase.
Karl Bielefeldt
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.