Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: register sets
Date: Thu, 17 Apr 2025 21:56:24 -0400
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vtsbga$1tu26$1@dont-email.me>
References: <vbgdms$152jq$1@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> <vtq6vh$39sli$1@dont-email.me>
 <Is7MP.2098019$OrR5.521315@fx18.iad>
 <4f65d9544ad95edc8b07c869f9921a35@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Apr 2025 03:56:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9f05e5fbb16ec5a84d3766df57261ea4";
	logging-data="2029638"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+0NeMX7LLNy32bOxOXHxwX0N2nxmSvhqw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JJsDdTCc4pgEQLXkAXlyWRz6AL4=
In-Reply-To: <4f65d9544ad95edc8b07c869f9921a35@www.novabbs.org>
Content-Language: en-US

On 2025-04-17 2:26 p.m., MitchAlsup1 wrote:
> On Thu, 17 Apr 2025 13:35:36 +0000, Scott Lurndal wrote:
> 
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> 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.
>>
>> Many modern CPUs including intel/amd have mechanisms that the OS
>> 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.
> 
> The converse point is that the OS may want to use vector instructions
> to move data around (Disk-cache to User-buffer) and thus have to have
> access to those registers anyway.
> 
> But, yes, if you have 14 different kinds of register files, you need
> something close to 13 of them under flags of control to thin the
> work at context switch time.

I like having the extra register files, it is just a personal 
programming convenience. It reduces the pressure on the general-purpose 
register file. It is also a matter of encoding the register selection in 
a 32-bit instruction. I did not want to waste more than five bits on the 
register selection. It is really a 52?-register machine, but the 
instruction encodings do not allow all registers for all instructions. 
One can use the move instruction to swap any registers.

But it makes the compiler more complex as it has to deal with different 
architectural register files. I suppose one could code the compiler for 
a machine with a flat 96 registers by surrounding operations with move 
instructions. It is code bloat but I do not know if it would affect 
performance.

Thinking of including a register exchange instruction.