5
$\begingroup$

So what happens if we're transfering lots of 8 bit words in a 32 bit bus? Does each bus cycle only transfers 8 bit at the time, wasting the other 24 lines of the bus? Or does it transfer 4 words in each bus cycle?

$\endgroup$
4
$\begingroup$

I would say "it depends":

  • most likely you ask for 8 bits to be retrieved and you get 8 bits and ignore the other 24 lines;
  • if you know you're dealing with sequential data, that you want to consider bytewise, you could retrieve 4 bytes at a time, but you'll have to split or handle the retrieved 4 bytes in code.

On specific architectures you have alignment considerations.

Specifically addressing your question, no, it is very unlikely a system would retrieve 4 words in each cycle only to then "split" them into single words to process, without a program catering for that itself.

$\endgroup$
1
$\begingroup$

It transfers 4 8-bit words on each bus cycle. I would not say the other 24 lines are wasted; the data on them is unused and may have no valid values. Writing code and trying to put 3 8-bit words on those lines would waste time; each cycle (either reading or writing the bus) has 32 bits of data or instruction on it. Therefore, it is more efficient (and easier) to just send the 8 bits as part of the 32 and ignore the (useless) data on the other 24 lines.

This is really a conceptual question and not a question about the workings of the bus. The processor's job is to faithfully transfer 32 bits on each cycle. It does not know which of those bits are important to you, the programmer. It does not know or care whether it contains 2 BCD digits, 8-bit ASCII, 8-bit unsigned integer, 16-bit signed integer, 32-bit floating point, or a 32-bit instruction. The processor's state machine guided by your program must work together to use only those parts of the data which are important to the task at hand. If you only want to transfer 8-bit words, the receiving process (your program) must make sure it only uses the proper 8 bits of the 32 bits sent to it.

$\endgroup$
  • 1
    $\begingroup$ I find this answer confusing. Your first sentence makes it sound like you are saying it transfers 4 8-bit words in each cycle, but the rest of your answer sounds like you are saying it transfers 1 8-bit word in each cycle. So which is it? I suggest editing to pick one, clarify what you are trying to say and to explain more clearly. $\endgroup$ – D.W. May 28 '15 at 4:51
  • $\begingroup$ Yes, that was the feeling I got from reading it. I'll mark it as an answer after clarification. Thanks! $\endgroup$ – Pedro Gordo May 28 '15 at 9:19
  • $\begingroup$ The answer is quite clear. It transfers always 4 8-bit words, and it is up to the program to decide what is useful. I guess, the extra unneeded 8-bit words can come from many sources depending on what the bus is used for, including random information left over in a register, or whather bytes followed the interesting one in memory. Can you confirm? $\endgroup$ – babou May 29 '15 at 10:55
  • 1
    $\begingroup$ @babou I would not use the word 'random' since a properly operating digital computer cannot do anything random. That is why I used the word 'invalid'. But, the data is invalid only from the point of view of the user--not from the point of view of the computer. So, yes, the invalid data can come from previous register use or other bytes in memory other than the one intended byte. $\endgroup$ – Emmett Redd May 29 '15 at 15:27
  • $\begingroup$ @babou D.W.'s comment was on the answer before I edited it. Your first comment came after. $\endgroup$ – Emmett Redd May 29 '15 at 17:41
1
$\begingroup$

There are 4 common hardware approaches (that I know of) for reading and writing octets (8-bit bytes).

The bus controller inside the CPU can be divided into 2 types, which I will here call "simple" or "caching". Both of these types can be combined with either one of 2 major types of hardware bus.

The vast majority of hardware buses are either:

  • Some hardware buses are only support full-width reads and writes -- they are word-oriented. For example, the program memory of the Microchip PIC16 series only supports full-width 14-bit reads; the PDP-8 only supports full-width 12-bit reads and writes; many DSPs with 32-bit or 24-bit data buses; many internal buses in floating-point units only support reading or writing complete 64-bit floating point numbers; etc.

  • Some hardware buses have individual octet-select lines -- they are byte-oriented. For example, the conventional PCI bus; the 68000 series; the ZipCPU; etc.

byte-oriented hardware buses and simple bus controller

In this one specific case, then when transferring lots of octets (8-bit bytes), each memory cycle transfers only 8 bits, wasting the remaining lines of the data bus.

With a simple bus controller, then with either kind of hardware bus, when the CPU executes a "LOAD BYTE" instruction, that instruction takes a full memory cycle for each LOAD instruction, and all the data lines except for the 8 bits of interest are ignored.

With a simple bus controller, and a bus with byte-select lines, when the CPU executes a "STORE BYTE" instruction, that instruction takes a full memory cycle, the bus interface activates only a single byte-select line, and all the data lines except for the 8 bits corresponding to that byte-select line are ignored -- only the selected byte of memory changes.

word-oriented hardware buses and simple bus controller STORE

In this specific case, when transferring lots of octets (8-bit bytes), 2 full memory cycles transfer only 8 bits, wasting the remaining lines of the data bus.

With a word-oriented bus, there's no way to simply change one byte of memory with a single memory cycle. So when the CPU executes a "STORE BYTE" instruction, a simple bus controller -- in order to ensure only one byte of memory is changed -- reads the entire word, modifies the appropriate byte, and then writes out the entire (modified) word.

caching bus controller

When transferring lots of 8-bit words, a caching bus controller can often (but not always) transfer a full word in each memory cycle (with 32-bit data bus, a full 4 octets each memory cycle).

When the CPU executes a "LOAD BYTE" instruction, often that octet is already in the cache, and so it doesn't use up any DRAM memory cycles.

However, when CPU executes a "LOAD BYTE" instruction, sometimes that octet is not already in cache. So the CPU reads the entire cache line into cache. (Many popular processors have a cache line size of 64 bytes = 512 bits; with a 32-bit data bus, reading a cache line requires 16 memory cycles).

Similarly when the CPU executes a "STORE BYTE" instruction, often that octet is already in the cache, so it doesn't use up any DRAM memory cycles -- it just updates that octet in cache. Later, that entire cache line will be written out.

However, when the CPU executes a "STORE BYTE", sometimes that octet is not already in cache. Some systems use the byte-select lines in combination with a write-around cache policy to immediately write that byte to DRAM, transferring only 8 bits, wasting the remaining lines of the data bus. Other systems use a fetch-on-write cache policy to read the entire cache line into cache, then update just that one byte in the cache. Later, that entire cache line is written out.

A lot of software deals with long UTF-8 strings or long ASCII strings that are always read or written from beginning to end. Starting to read such a string with a caching bus controller causes it to start to pre-load the rest of the string in the cache, so (except at the very beginning and very end of the string) each 32-bit memory cycle reads a full 4 octets of the string. After writing such a string from beginning to end with a caching bus controller, when that string is later flushed from the cache (except at the very beginning and very end of the string) each 32-bit memory cycle writes a full 4 octets of the string.

One popular desktop processor has a cache line size of 64 octets = 512 bits; with a 32-bit data bus, writing out that cache line requires 16 memory cycles. If we are lucky, a lot of "write combining" has occurred and 64 (or more !) of our octet writes have hit this cache line, so each 32-bit write memory cycle is in response to a full 4 octets (or more!) of updated data. In the worst case of random byte writes (which fortunately doesn't happen with typical software), this can theoretically cause "write amplification" where each byte written expands to 16 read memory cycles and 16 write memory cycles.

related: "Transferring < 4 byte data on a 32-bit system"

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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