Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: register sets
Date: Wed, 16 Apr 2025 23:26:57 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <vtq6vh$39sli$1@dont-email.me>
References: <vbgdms$152jq$1@dont-email.me> <vbog6d$2p2rc$1@dont-email.me>
 <f2d99c60ba76af28c8b63b9628fb56fa@www.novabbs.org>
 <vc61e6$21skv$1@dont-email.me> <vc8gl4$2m5tp$1@dont-email.me>
 <vcv5uj$3arh6$1@dont-email.me>
 <37067f65c5982e4d03825b997b23c128@www.novabbs.org>
 <vd352q$3s1e$1@dont-email.me>
 <5f8ee3d3b2321ffa7e6c570882686b57@www.novabbs.org>
 <vd6a5e$o0aj$2@dont-email.me> <vdnpg4$3c9e$2@dont-email.me>
 <2024Oct4.081931@mips.complang.tuwien.ac.at> <vdp343$9d38$1@dont-email.me>
 <2024Oct5.114309@mips.complang.tuwien.ac.at> <ve5mpq$2jt5k$1@dont-email.me>
 <vedg1s$43mp$1@dont-email.me>
 <ebe5b174d1e95801af623a450c464504@www.novabbs.org>
 <veelbd$9gnd$2@dont-email.me> <veeso3$aq72$1@dont-email.me>
 <vfvi1f$2kp4s$1@dont-email.me> <vgerdr$1v4nd$1@dont-email.me>
 <vtptau$3p73s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Apr 2025 08:26:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="068c5f18bb5141d3d994305ca4e59204";
	logging-data="3470002"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+fOBKQCY66HKZ4i52DUzgn86/79HUbXBE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FQIcRwxR/l6zhgOCKdqLi6jXTeI=
Content-Language: en-US
In-Reply-To: <vtptau$3p73s$1@dont-email.me>
Bytes: 3133

On 4/16/2025 8:42 PM, Robert Finch wrote:
> Working 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.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)