Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The section of an executable that contains code is sometimes called the .text section. In segmented memory architectures, a segment mapped as code is sometimes called a text segment. The unix error message “text file busy” (ETXTBSY) means “this file is a program that is being executed”.

How did text come to mean executable (machine) code?

An ideal answer would: explain the connection between the word and its meaning; provide a citation for the origin or at least the history of the term; give some idea of which communities use it.

share|improve this question
    
.text is an assembly directive. Assembly is text. –  Austin Henley Oct 27 '12 at 0:48
1  
A similar question was asked and answered on StackOverflow 3 years ago: stackoverflow.com/questions/1282506/… –  Stephen C Oct 27 '12 at 2:49
    
@StephenC Thanks for the link. Easy to find by googling “text segment”, I'd tried mostly with “text section” and it didn't turn up. So it dates at least back to the GE days, but it's still not clear how the meaning got established. –  Gilles Oct 27 '12 at 12:54
add comment

1 Answer

The term comes from assembly language. I can't verify the etymology, but my guess is that the name comes from the other use of the section. Whereas the .data section denotes variables that can change during the course of execution, the .text section contains data that doesn't change during execution, allowing it to be put into ROM if needed. That makes it useful for code, yes, but also makes it useful for strings of text that don't change. That's probably where the term came from.

To address Griffin's comment about first class functions, consider the following python 3 code:

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

The code you actually execute for increment ends up looking internally something like:

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

That executable code can be put into ROM. It never changes throughout the execution of the program, no matter how many times you call counter(). What does change is the self pointer and its member variables. Those must be put into .data. When you return increment, you are actually returning a new instance of an increment function object. You are not dynamically creating new executable code every time. The code itself is immutable even though the pointer to it is not.

The only code that must be stored in the .data section is that generated by eval(), because it is not known to the compiler or JIT compiler at the start of the program. However, even that code is immutable. If you change the string and call eval() again, you're not changing the code from the previous time you called eval(), you're creating a whole new set of code.

Although the programming model may make it kind of feel like code is mutable, actual self modifying code at the processor instruction level is dangerous and rarely found outside OS voodoo topics like process context switching.

share|improve this answer
    
So what happens when you're using a functional language considering that the code is mutable / 1st class as well? –  Griffin Oct 27 '12 at 4:32
1  
See my edit about first class functions. –  Karl Bielefeldt Oct 27 '12 at 20:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.