请教三个frontend代码问题

[ddxoxpp]

第一个问题是为什么brSlot的target优先级总是比TailSlot要高，如果TailSlot的idx offset比brSlot低，不是应该选择TailSlot的target吗？

XiangShan/src/main/scala/xiangshan/frontend/FrontendBundle.scala

Lines 413 to 417 in 0bbc9ca

	def target(): UInt = {
	val targetVec = preds.targets :+ fallThroughAddr :+ (pc + (FetchWidth*4).U)
	val selVec = real_slot_taken_mask() :+ (preds.hit && !real_slot_taken_mask().asUInt.orR) :+ true.B
	PriorityMux(selVec zip targetVec)
	}

第二个问题时FallThruAddr的具体含义是什么，为什么在commit update产生ftb entry时要等于br指令的起始地址？

XiangShan/src/main/scala/xiangshan/frontend/NewFtq.scala

Lines 370 to 389 in 0bbc9ca

	val may_have_to_replace = oe.noEmptySlotForNewBr
	val pft_need_to_change = is_new_br && may_have_to_replace
	// it should either be the given last br or the new br
	when (pft_need_to_change) {
	val new_pft_offset =
	Mux(!new_br_insert_onehot.asUInt.orR,
	new_br_offset, oe.allSlotsForBr.last.offset)
	// set jmp to invalid
	if (!shareTailSlot) {
	old_entry_modified.tailSlot.valid := false.B
	}
	old_entry_modified.pftAddr := getLower(io.start_addr) + new_pft_offset
	old_entry_modified.last_is_rvc := pd.rvcMask(new_pft_offset - 1.U) // TODO: fix this
	old_entry_modified.carry := (getLower(io.start_addr) +& new_pft_offset).head(1).asBool
	old_entry_modified.oversize := false.B
	old_entry_modified.isCall := false.B
	old_entry_modified.isRet := false.B
	old_entry_modified.isJalr := false.B
	}

第三个问题时ftq entry为啥要保存预测target，直接在ifu f2流水级读取下一条ftq entry的起始地址，下一个周期返回读数据用于f3 predecode可以不？然后我觉得一项ftq entry保存的信息太多了，感觉占用太多存储，是否考虑压缩压缩？

[Lingrui98]

1. 我们在生成entry的时候保证offset一定按slot递增
2. fallThruAddr的意思就是这个ftbEntry没有预测跳转的指令的情况下，下一个预测块的起始地址；这里是ftbEntry的生成逻辑中分支指令溢出的处理，当以startAddr开始的FetchWidth*4 Byte中存在超过规定条数的转移指令时，我们把offset最大的放到下一个块，同时让这个块的fallThruAddr是它
3. target不仅给ifu读，也给后端判断jalr预测地址读，按你说的实现方式，如果在ifu或后端读的时候，下一个ftqEntry还没入队，那就读不到预测目标地址，不过也许这种情况不常见
4. 目前ftq entry存储的信息都是有用的（除了几个计划移除的记录cycle数的64位UInt），您说的压缩指什么形式呢？

[ddxoxpp]

首先感谢解答。
压缩的话我暂时想到的就是上面提的target的实现方式，不去存target地址。其实在ifu f2流水级读下一条ftq entry的话，下一条ftq entry最迟此周期正在入队，那req进入ifu f3 流水级时 ftq一定能够返回target；然后ifu f3 predecode后产生ifu redirect到下一条 ftq entry重新入队也只需要两个周期，从ifu f3 到后端执行单元肯定不只两个周期了，jalr也应该能读的到？

[Lingrui98]

首先感谢解答。 压缩的话我暂时想到的就是上面提的target的实现方式，不去存target地址。其实在ifu f2流水级读下一条ftq entry的话，下一条ftq entry最迟此周期正在入队，那req进入ifu f3 流水级时 ftq一定能够返回target；然后ifu f3 predecode后产生ifu redirect到下一条 ftq entry重新入队也只需要两个周期，从ifu f3 到后端执行单元肯定不只两个周期了，jalr也应该能读的到？

现在的BPU是基本不阻塞的，之前没有考虑到这一点，这样的话后端和ifu读target的问题应该都不大。
还有一点就是target还会被后端的真实执行结果更新，在更新BPU时使用，也许redirect后马上就提交，触发BPU更新，也许会来不及，这一点可能通过让误预测的分支等几拍提交解决。

如果target用下一个pc的方式来读，那么存pc的那个mem会多三个读口，而它现在已经有11个读口了，这可能是更大的问题。

感谢提问！同时也期待您更多的建议 : )

[ddxoxpp]

向大佬们学习！