Timeline for Did any CPU ever expose load delays?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 11, 2021 at 23:17 | comment | added | supercat | I think the big difference between the usefulness of load-delay slots and branch-delay slots stems from the fact that a processor core will typically have many registers, but one logical program counter. When performing a delayed branch, the instruction(s) immediately following the branch effectively behave as though they used a program counter separate from the one loaded by the branch, allowing them to be processed usefully even though the program counter being written by the branch will effectively be "busy" for a cycle or two. | |
| Jan 11, 2021 at 22:09 | comment | added | user1937198 | And with regards to use of the old value of register, the concept of a belt means that all mill instructions have the property of not replacing the previous value, but replacing an arbitrary value of whatever is at the end of the belt at the point of retirement. So how do you say which is the 'old' value on the belt? | |
| Jan 11, 2021 at 22:04 | comment | added | user1937198 | @Raffzahn The key difference is that in a register machine other instructions executed during the delay don't have to effect the address register. In the belt design the only way to keep the address in the same place on the belt would be to execute no-ops, and in the case of a delay of more that a couple of cycles actively keeping the value on the belt. And, no its not implemented as a register file, its expected to be implemented as a vector of shift registers, because every value has a maximum lifetime. (Unless you have a source other than millcomputing.com/docs/belt/?) | |
| Jan 11, 2021 at 21:22 | comment | added | Raffzahn | @user1937198 it doesn't matter if one calls it 'belt' or not, when implemented it's a register and fetching content to fill this will take time (BTW, it is not implemented as a belt, but as a register file. The 'movement' is done by constant renaming). | |
| Jan 11, 2021 at 20:37 | vote | accept | rwallace | ||
| Jan 10, 2021 at 21:44 | comment | added | user1937198 | It doesn't really make sense to say that The Mill model allows reuse of the address register or continued use of the old value, as The Mill is not a register machine, so you aren't loading the value into a slot in the same way. It does mean you can allow the address value to fall off the belt, and that the loaded value isn't pushed on for a certain number of cycles, but how that impacts what you can do in the assembly is very different as it impacts everything on the belt, not just two registers. | |
| Jan 10, 2021 at 19:40 | history | edited | Jean-François Fabre | CC BY-SA 4.0 |
fixed small typos
|
| Jan 10, 2021 at 17:42 | comment | added | Peter Cordes | Yeah, RISC philosophical purity taken to extremes. At least MIPS has the excuse that it literally started as an academic project to test the validity of the "RISC = good" hypothesis. Some later machines made engineering decisions while drinking more or less of the kool-aid. (e.g. ARM takes the good ideas but maintains high code density.) | |
| Jan 10, 2021 at 17:17 | comment | added | Raffzahn | @PeterCordes It is really just a set of comperators (or multiple with longer pipelines, but the MIPS I one wasn't such). The special handling of Mult/Div is result of a schizophrenic situation. On one hand, the the goal was to create a true single cycle instruction CPU, but also wanting to include Mult/Div as basic instructions, even though they do not fit that scheme. RISC, and most notably MIPS in its early stages, had more common with a cult preaching its sermon than engineering. The dogma is absolute, they rather shoot themself in the foot than acknowledging that real life is different. | |
| Jan 10, 2021 at 17:04 | comment | added | Raffzahn | @PeterCordes Thank you. I reduced the too specific sidenotes a bit. | |
| Jan 10, 2021 at 17:00 | history | edited | Raffzahn | CC BY-SA 4.0 |
Removed some of the overly detailed remarks.
|
| Jan 10, 2021 at 15:59 | comment | added | Peter Cordes | I made a relatively large edit; you might want to take out some of it if you think it's too much of a tangent, or of course rearrange it. | |
| Jan 10, 2021 at 15:58 | history | edited | Peter Cordes | CC BY-SA 4.0 |
MIPS II (R6000) removed load delay slots. Add some commentary to head off confusion for future readers similar to what popped up in comments. Also mention The Mill, and what actually happened on real R2000.
|
| Jan 10, 2021 at 15:26 | comment | added | Peter Cordes | R3000 was also MIPS I. It was MIPS II that removed the load delay slot (apparently R6000 was the first CPU of that ISA revision: linux-mips.org/wiki/Instruction_Set_Architecture#MIPS_II. R4000 was MIPS III. Out-of-order naming of in-order pipelines... hmm.) | |
| Jan 10, 2021 at 15:20 | comment | added | Peter Cordes |
MIPS originally stood for Microprocessor without Interlocked Pipeline Stages (What is an "interlocked pipeline" as in the MIPS acronym?). It had to be able to stall for cache misses, and in some cases reading lo/hi mult results, but original MIPS I (R2000 / R3000) couldn't stall for "normal" stuff. This may have simplified more than just another comparator? That's partly why mult and div put their results in special registers with restrictive rules about reading them, although that might just have been to reduce comparators. (ping @rwallace)
|
|
| Jan 10, 2021 at 0:15 | comment | added | dave | I think I recall the MIPS 2000 assembler reordering instructions to populate the load-delay slot (it certainly did for branch-delay slots). | |
| Jan 9, 2021 at 23:44 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 721 characters in body
|
| Jan 9, 2021 at 23:33 | comment | added | Raffzahn | @rwallace Not really. Especially in embedded the cost of a load delay slot is even more, as there are many situations were the slot can't be filled with a useful instructions forcing the inclusion of an explicit NOP resulting in bloated code. Not really something embedded developers love to see. | |
| Jan 9, 2021 at 23:27 | comment | added | rwallace | Of course the disadvantage is that as soon as you implement the next CPU of the same architecture – or even a clock speed bump of the same CPU – the number of delay cycles the hardware wants, no longer matches existing code, so you get a mess. Still, it could make sense for some embedded applications, or game consoles. | |
| Jan 9, 2021 at 23:25 | comment | added | rwallace | Right. The advantage of a load delay would be not so much saving the little bit of hardware to implement the interlock, as to improve IPC by making it possible for the CPU to do other things while waiting for the load to complete. (An out of order CPU can also do that, but the out of order hardware is quite expensive, whereas the load delay would have slightly negative cost.) | |
| Jan 9, 2021 at 23:14 | history | answered | Raffzahn | CC BY-SA 4.0 |