From what I have read, instructions under x86 can be as long as 15 bytes. Since x86 is a 32-bit architecture (64-bit for x86-64 obviously) how does it handle these long instructions? How are they stored in memory, and how are they fetched?


closed as off-topic by David Richerby, Evil, fade2black, quicksort, Anton Trunov Nov 22 '17 at 21:22

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about computer science, within the scope defined in the help center." – David Richerby, Evil, fade2black, quicksort, Anton Trunov
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ @Raphael To me this question is more about "how can instructions longer than the word size be handled at all" (classic misunderstanding of what the word size applies to) with x86 as an example, than about x86 peculiarities specifically $\endgroup$ – harold Nov 14 '17 at 13:12

In general there is not relation between the processor register size (32-bit for x86, 64-bit for x86_64) and the instruction size. Instructions are fetched by a dedicated hardware unit and the current instruction is stored the instruction register, but this register does not need to (and usually does not) have the same size as the data registers. On x86, this register must be able to hold 15 bytes. Instructions are fetched like everything else by issuing read commands to the memory. In general to speed up things, the CPU has an instruction cache so it will not just fetch one instruction at a time but rather an entire cache line at once.


Amaury Pouly's answer covers most of it: modern instruction fetch units work on cache lines, not words. A cache line might be 64 or 128 bytes.

However, that isn't the whole story. You still need to deal with the fact that the instruction fetch operation is uneven (in the sense that some cache lines may have a lot of instructions and some may have few), and that instructions may cross a cache line boundary.

Modern L1 instruction cache doesn't necessarily need to store only instructions. It's common practice to make the L1 instruction cache line slightly wider and store additional information which is computed when the cache line is inserted in the cache. This is called predecoding. A simple example might be to add a bit to each byte which marks where each instruction starts.

Because there are a lot fewer cache line loads than there are instructions executed, this can save time during instruction fetch.

As for cache line boundaries (or, indeed, implementing predecode), one way to model decoding an instruction stream is as a finite state machine of some kind. Modelling the problem this way lets you handle cache line boundaries in a straightforward manner: all you need to "know" between cache line fetches is what state you were in. The implementation may be more complex than this (e.g. to allow for more hardware parallelism), but this can all be handled from the finite state model.


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