Talk:Byte addressing

2007-02-8 Automated pywikipediabot message

--CopyToWiktionaryBot 06:19, 8 February 2007 (UTC)

I wanted to cross link my mention of the IBM 7094 to the Wikipedia article, but I haven't yet figured out how to do that before I ran out of time. It would be great if someone else did that for me, then I would see what you did and would do it for myself next time.

I also wanted to make the point that byte-addressing may not imply 8 bit bytes: this is mainly of historical interest, do other editors agree this is relevant?

Truerivertoo (talk) 16:44, 11 February 2017 (UTC) R~~

Text processing slower without byte addressability?

This article is full of unsubstantiated claims. Why would text processing be slower? It would take up more RAM, but that doesn't mean it would be slower. Also in modern data a lot of text isn't necessarily stored in bytes. — Preceding unsigned comment added by 208.126.206.101 (talk) 05:44, 24 February 2017 (UTC)

Note that, until the introduction of the Byte-Word Extensions, the DEC Alpha processors, which use byte addresses, couldn't load or store 8-bit bytes or 16-bit quantities in a single instruction. Instead, there were instructions to help extract those quantities from and insert those quantities into a wider memory location, and string-processing routines processed multiple characters per instruction whenever possible. See, for example, the internal stxcpy() routine in GNU libc on Alpha, which is used by strcpy, stpcpy, and strcat().

And, for that matter, see the strcpy() routine on GNU libc on x86-64, which also attempts to do copies 64 bits at a time, although it does rely on support for unaligned stores (which Alpha doesn't have).

So, whilst there might be some penalty for not having byte addressing, the penalty for some operations might be reduced if some of the operation could be done a word at a time, even if you pack multiple characters in a word. Guy Harris (talk) 06:37, 3 March 2021 (UTC)

I was just asking myself the same, having come here after looking for unaligned memory access. I haven't found official documents stating it clearly yet (not having now the time and energy to go through long intel manuals), but forums agree that so-called unaligned memory access is very slow. Which happens when you try to address a memory cell whose address is not divisible by 8 in a 64b system or 4 in a 32b system. So if you want to go higher speed for mem access, you'd apparently end up addressing effectively as word-addressing (and only using one byte out of eight if the rest is not needed). See eg. https://stackoverflow.com/questions/12491578/whats-the-actual-effect-of-successful-unaligned-accesses-on-x86 It would be nice to read more about it on wiki. I really want to know why they haven't switched to word addressing - I presume it's due to compatibility reasons. Hoemaco (talk) 13:56, 12 April 2021 (UTC)

I suspect the answer to "what's the penalty for unaligned accesses" is "it depends", where what it depends on is, among other things, the particular processor on which the access is being done - in the sense of "what's its microarchitecture", not "is it an x86 processor or an Alpha processor or...". Even if an instruction set supports unaligned accesses, different implementations might impose different penalties. searching for "unaligned" on Agner Fog's site might show the results of his investigations. Intel's "Intel® 64 and IA-32 Architectures Optimization Reference Manual" also discusses alignment in a number of places. (Hint: don't look for a simple answer, there probably isn't one with modern processors.)

"I really want to know why they haven't switched to word addressing - I presume it's due to compatibility reasons." As the saying goes, THIS. A word-addressed version of x86 would be a completely different, completely incompatible instruction set, capable of running precisely zero existing {Windows,Linux,Solaris,macOS,etc.} binaries without a binary-to-binary translator, and the only benefit it would provide would be a fourfold-to-eightfold increase in the address space size in octets, so such a change would probably be 99 44/100% costs and 66/100% benefits.

"you'd apparently end up addressing effectively as word-addressing" No, because if you're performing arbitrary character-string operations in certain heavily-used programming languages whose names contain a capitalized version of the third letter of the Roman alphabet :-), you're going to need pointers that address single-character items anyway, and you're probably not going to be able to get away with 32-bit or 64-bit characters. Guy Harris (talk) 19:15, 12 April 2021 (UTC)

thanks for the insights. It'd be nice to know how actually non-aligned access is realised in x86 processors (without having to go through hundreds of pages of manual :D ). Hoemaco (talk) 10:58, 22 April 2021 (UTC)

"Realized" in what sense? Architecturally, it's implemented by Intel saying "an address value of n refers to the nth byte within the address space or segment (with the first byte being the 0th byte). In particular x86 processors, the instruction set manual won't help - you'd need at least a block-level description of the chip, and, if those manuals exist, they're probably locked up inside Intel, AMD, etc.. Guy Harris (talk) 21:13, 16 March 2024 (UTC)

Which happens when you try to address a memory cell whose address is not divisible by 8 in a 64b system or 4 in a 32b system. That depends on the processor.

Processors that directly access memory, with no cache in between the processor and memory, would just directly access an 8-bit byte if they have an 8-bit data bus to memory, as the Intel 8088 does, and as the IBM System/360 Model 30 does.. In order to fetch a 16-bit word on the 8088, or a 32-bit word (or 16-bit halfword) on the 360/30, multiple byte accesses would have to be performed.

Processor with no cache, but a wider data bus, might, for example, fetch the word containing the byte, with the low-order bit or bits of the address being forced to zero on the bus (unless the memory just ignores those bits, or those bits aren't present on the bus), and then use a circuit to select the byte from that word. Storing a byte might be done with a "write a byte" bus cycle, with the full address, including the low-order bits, put on the bus, or might be done by reading a word, modifying the byte in the register containing the fetched word, and writing back the word.

Processors with a cache would, at least for cached accesses, fetch an entire cache line if necessary, and then fetch the appropriate byte or multi-byte quantity from the cache. Stores might be done both to the cache, if the data being stored is in the cache, and to memory, in a fashion similar to what's described above (write-through cache), or be done to the cache, with data from the cache later being written back to memory, probably a line at a time (write-back cache). Non-cached references would be done similarly to the way they're done on processors without a cache.

But I'm not a CPU designer, so somebody more familiar with the details of hardware should probably address these details. Guy Harris (talk) 22:03, 16 March 2024 (UTC)

References

Are the terms "byte machine" and "word machine" used in English?

The first paragraph of the article says

Byte addressing in hardware architectures supports accessing individual bytes. Computers with byte addressing are sometimes called byte machines, in contrast to word-addressable architectures, word machines, that access data by word.

However, the references for "byte machines" and "word machines" are both in German; are those terms used in English? If not, then, while mentioning the equivalent German terms might be appropriate in German Wikipedia articles about byte addressing and word addressing (BTW, I'm not convinced that de:8-Bit-Architektur is the appropriate equivalent page to byte addressing - it's about 8-bit processors, not byte-addressed processors with a larger bit width), it wouldn't be appropriate in this article. Guy Harris (talk) 22:12, 16 March 2024 (UTC)

Never heard of a byte machine and I don't speak German. ~Kvng (talk) 22:51, 20 March 2024 (UTC)