为何大端字节序计算机从低到高读内存？高到低内存顺序相关问询

Great question—this dives into some underdiscussed design choices that shaped modern computing. Let’s unpack your two core questions clearly:

1. Which Architectures or Languages Use High-to-Low Memory Access Order? #

First, it’s important to clarify: nearly all mainstream architectures and programming languages stick to a low-to-high memory growth model for static memory, heap allocations, and struct member storage. That said, there are a few niche or historical exceptions:

• Stack Memory in Most Systems: While not a system-wide access model, the call stack on nearly every architecture grows from high addresses to low addresses. For example, when you declare a local variable in C, it sits at a lower address than the previous stack frame. But this is a specific edge case, not the default for general memory access.
• Vintage Mainframes/Minicomputers: A small number of older specialized systems, like the Burroughs B5000 series, used a reverse address space where memory expanded downward. These were built for niche business computing and never gained widespread traction.
• Custom Embedded Setups: In rare memory-constrained embedded projects, developers might manually configure a system to use high-to-low allocation to align with specific hardware peripherals. This is always a custom tweak, not an out-of-the-box standard.

As for languages: no mainstream programming language natively enforces high-to-low memory access. Languages like C, Python, Java, and Rust all defer to the underlying architecture’s memory layout rules.

2. Why Didn’t High-to-Low Memory Access Become the Mainstream? #

Your observation is spot-on—big-endian systems would indeed gain the same "read different value lengths without adjusting addresses" perk if using high-to-low access. But several key factors led the industry to standardize on low-to-high:

• Historical Inertia: Early computers (like the ENIAC and IBM 360) were designed with low-to-high address growth, following the natural flow of binary counting (0, 1, 2, ...). As computing evolved, subsequent architectures adopted this model to maintain compatibility with existing software and hardware ecosystems. Rewriting decades of code and redesigning core hardware to reverse this would have been prohibitively costly.
• Simpler Hardware Design: Low-to-high alignment matches how binary logic circuits handle counting. Address lines increment from least significant to most significant, which simplifies address decoding and memory controller design. A reverse model would require extra logic to invert address signals, adding complexity and manufacturing costs.
• Memory Management Headaches: A system-wide high-to-low model would upend all standard memory allocation logic:
  • malloc() would need to return the highest available address instead of the lowest.
  • Heap allocation would grow downward, conflicting with the stack’s natural downward growth (increasing the risk of heap/stack collisions and fragmentation).
  • Existing memory management algorithms (like buddy allocation or slab allocation) are optimized for low-to-high growth; adapting them to reverse order would require massive overhauls.
• Lack of Compelling Advantage: While high-to-low access would level the playing field for big-endian systems, this benefit didn’t outweigh the costs of switching. Small-endian architectures already had that flexibility, and big-endian systems (like PowerPC or SPARC) developed other workarounds for memory access without reversing address order.

As you noted, Wikipedia’s point about small-endian systems being able to read the same value from different memory lengths without adjusting addresses only holds when reading low-to-high. If systems used high-to-low access, big-endian would gain this same perk—but the industry never had a strong enough reason to make that shift.

内容的提问来源于stack exchange，提问作者Marisha