There used to be very good reasons for keeping instruction / register names short. Those reasons no longer apply, but short cryptic names are still very common in low-level programming.
Why is this? Is it just because old habits are hard to break, or are there better reasons?
For example:
- Atmel ATMEGA32U2 (2010?):
TIFR1(instead ofTimerCounter1InterruptFlag),ICR1H(instead ofInputCapture1High),DDRB(instead ofDataDirectionPortB), etc. - .NET CLR instruction set (2002):
bge.s(instead ofbranch-if-greater-or-equal.short), etc.
Aren't the longer, non-cryptic names easier to work with?
When answering and voting, please consider the following. Many of the possible explanations suggested here apply equally to high-level programming, and yet the consensus, by and large, is to use non-cryptic names consisting of a word or two (commonly understood acronyms excluded).
Also, if your main argument is about physical space on a paper diagram, please consider that this absolutely does not apply to assembly language or CIL, plus I would appreciate if you show me a diagram where terse names fit but readable ones make the diagram worse. From personal experience at a fabless semiconductor company, readable names fit just fine, and result in more readable diagrams.
What is the core thing that is different about low-level programming as opposed to high-level languages that makes the terse cryptic names desirable in low-level but not high-level programming?
Best Answer
The reason the software uses those names is because the datasheets use those names. Since code at that level is very difficult to understand without the datasheet anyway, making variable names you can't search is extremely unhelpful.
That brings up the question of why datasheets use short names. That's probably because you often need to present the names in tables like this where you don't have room for 25-character identifiers:
Also, things like schematics, pin diagrams, and PCB silkscreens often are very cramped for space.