Searched hist:6821 (Results 1 - 8 of 8) sorted by relevance
| /gem5/src/arch/power/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/riscv/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/mips/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/arm/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/alpha/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/x86/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/sparc/ | ||
| H A D | isa_traits.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/cpu/o3/ | ||
| H A D | fetch_impl.hh | diff 12427:b0611f1ad833 Wed Dec 20 02:14:00 EST 2017 Gabe Black <gabeblack@google.com> alpha,arm,mips,power,riscv,sparc,x86,cpu: Get rid of ISA_HAS_DELAY_SLOT. This constant is, first, a #define, and second only used in one place. In that one place, it appears that the code it guards is no longer necessary in general. It was originally written to avoid refetching a block of data that you're still in, even if you've moved slightly farther in it because you're skipping the next instruction due to an annulled branch delay slot. In reality however, in SPARC, the one ISA I'm aware of which has this sort of branching behavior, the PC state object will correctly determine that no branch is happening in these cases. Code lower down in the loop will then recompute where fetching should continue based on the next PC, automatically skipping the annulled branch slot without misinterpretting the gap as a branch. This change therefore also removes this block of code. Change-Id: I820ebc9df10aeb4fcb69c12f6a784e9ec616743c Reviewed-on: https://gem5-review.googlesource.com/6821 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
Completed in 55 milliseconds