为何MIPS架构不使用$v0、$v1传递额外的函数参数

根据MIPS官方文档规定，函数返回值存储在$v0-$v1中（最多支持64位返回值），函数入参通过$a0-$a3传递，超出4个的额外参数需要写入栈中。
既然函数本身允许覆盖$v0-$v1的存储值，那么将函数的第5个参数（若存在）通过$v0传递难道不是更优的方案吗？
这种场景下选择使用栈传递额外参数的设计动机是什么？

核心原因是调用约定要求寄存器职责边界清晰，统一栈传参的方案整体收益远高于用返回值寄存器传参的方案，具体可以从几个层面解释： #

• 避免寄存器职责冲突
  $v0/$v1的明确定位是被调用方输出返回值的专用寄存器，调用约定中默认被调用方不需要保留这两个寄存器的入站值，只要有需要可以直接覆盖。如果把第5个参数塞到$v0里，被调用方一上来写返回值逻辑就可能直接把传入的参数冲掉，要避免这个问题就只能要求被调用方先把$v0的值存到栈里再用，反而多了额外的内存操作，比直接把参数放栈里更麻烦。
• 降低调用方的上下文维护成本
  调用方在触发函数调用之前，$v0里极有可能存着上一次函数调用的返回值，如果要挪用$v0传参，调用方必须先把$v0里的有效数据存栈、写入参数、调用结束后如果还要用之前的返回值再从栈里读回来，反而多了两次栈读写开销。
• 兼容可变参数函数的实现
  对于printf这类参数数量不固定的可变参数函数，现有约定下前4个参数存寄存器、剩余参数按顺序连续存在栈上的设计，让函数可以直接通过栈偏移量读取所有额外参数，逻辑非常统一。如果第五个参数存在$v0里，可变参数函数根本无法预判是否有第五个参数、也不知道要去$v0读取，完全无法兼容这类场景。
• 降低实现复杂度
  MIPS调用约定设计的核心目标就是简单、易实现，额外参数统一放栈的设计，不管是编译器生成汇编还是开发者手写汇编，处理逻辑都是高度一致的，不需要额外判断参数数量对应不同的传参位置，大幅降低了出错概率和实现成本。

内容的提问来源于stack exchange，提问作者M A