5 ms·
Thank you for your insightful comment. Do you mind going a bit more into the decode advantage?
by deadmutex 6y ago
Thank you for your insightful comment. Do you mind going a bit more into the decode advantage?
- my123 6y ago32-bit fixed size instructions, that are aligned. That allows you to have 8-wide decoders for example. On x86, you can't really do this/didn't happen because the instructions are 1 to 15 bytes long, and you'll need to decode the prior instruction at least in part to determine where your current instr starts. (currently 4-wide decoders are available for x86 uArches)
- mhh__ 6y agoFixed width instructions are much easier to decode at the same time as their neighbours. The density is a tradeoff you have to think about, but X86 is not a clean ISA. For a more alien example, the mill cpu has very long variable length instructions for density reasons but because it's specifically designed around that and not needing any implicit parallelism they can use tricks to find instruction boundaries much more easily.
- Dylan16807 6y agoThe biggest thing for quickly finding instruction boundaries is probably not having prefixes, which is pretty straightforward.
- cesarb 6y agoNot having suffixes helps too. AFAIK, on x86 to find the length of an instruction, first you have to decode the instruction itself (the decoding can vary depending on the prefixes) to know if it is followed by a modRM byte, then decode the modRM byte to know whether it is followed by an immediate or not and how big that immediate is, and only then can you know where the next instruction is. The modRM byte (and the SIB byte) can be thought of as a "suffix" of sorts to the instruction. Contrast for instance with RISC-V, where the first byte of every instruction has everything necessary to know the instruction length (and you only need 2 bits of that byte unless your core supports instructions longer than 4 bytes).