| Liste des Groupes | Revenir à c arch |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:RISCV has an extension state register. Qupls/StarkCPU has one as well. But there's no trap on the first floating point use (yet) for Stark. Scratching my head now on how to add this. Should be not too bad to add.On 4/16/2025 8:42 PM, Robert Finch wrote:Many modern CPUs including intel/amd have mechanisms that the OSWorking on the Qupls3/StarkCPU core it looks like there will be enough>
resources to support two sets of registers. The extra set of registers
comes for free for the register file as the BRAMs can support them. The
only increase is in the RAT. The issue I have to trade-off on now is
which of the four operating modes gets its own set of registers while
the other three share a set. However, the first eight registers will be
shared between all modes so that arguments can be passed between them.
The ARM does this. My thought is that the application / user mode gets
its own register set, and the rest of the system shares the other set.
That way there is no need to save and restore the app registers when
calling the system.
>
Another thought is to not include float registers for anything other
than apps. It would save 32 regs per mode, possibly allowing three
register sets to be provided.
>
Not to mention speeding up context switches as you don't need to
save/restore the FP registers for those levels that don't have them, and
if only one level does have them, no need to save them if the switch is
to a level that doesn't have them, as they then can't be clobbered.
can use to determine if floating point registers have been used
since the user process was dispatched, including a trap to the
OS on the first floating point use. This allows them to avoid
saving and restoring the FP registers during context switches.
Les messages affichés proviennent d'usenet.