Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: My 66000 and High word facility
Date: Sat, 17 Aug 2024 22:15:17 +0000
Organization: Rocksolid Light
Message-ID: <66569211a570a7db9978ebbab2b073c2@www.novabbs.org>
References: <v98asi$rulo$1@dont-email.me> <38055f09c5d32ab77b9e3f1c7b979fb4@www.novabbs.org> <v991kh$vu8g$1@dont-email.me> <2024Aug11.163333@mips.complang.tuwien.ac.at> <v9b57p$2rkrq$1@dont-email.me> <v9brm4$33kmd$1@dont-email.me> <e369e386b23628e5388e95b5a92af62d@www.novabbs.org> <v9jij9$lk6a$1@dont-email.me> <v9jjjn$lofu$1@dont-email.me> <v9k38n$rg2a$1@dont-email.me> <v9mklt$1air0$1@dont-email.me> <1bf2c13fc41cf8aeca4a746052c03ce3@www.novabbs.org> <v9oqjo$1k775$1@dont-email.me> <cfa0a9c4bda9421fee8ce512bdcd58bf@www.novabbs.org> <v9r2s7$21r0k$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2939021"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$RihY8DmiwuhtGXtji66CYeKyS5JdRPoe1vpD5AqCFgyUoWWSvQLga
Bytes: 4045
Lines: 77

On Sat, 17 Aug 2024 20:57:43 +0000, Brett wrote:

> MitchAlsup1 <mitchalsup@aol.com> wrote:
>> On Sat, 17 Aug 2024 0:24:24 +0000, Brett wrote:
>>
>>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>>>
>>>> When HW is doing the saves, it does them in a known order and
>>>> can mark the registers "in use" or "busy" instantaneously and
>>>> clear that status as data arrives. When SW is doing the same,
>>>> SW ahs to wait for the instruction to arrive and then do them
>>>> one-to-small numbers at a time. HW is not so constrained.
>>>
>>> Ok, so the hardware is smart enough.
>>
>> The Instructions and the compiler's use of them were co-developed.
>>
>>> But has anyone told the software guys?
>>
>> Use HLLs and you don't have to.
>
>
> I looked at interrupts in your manual and it did not say how many
> registers
> were full of garbage leaking information because they were not saved or
> restored to make interrupts faster. ;)

When an ISR[13] returns from handling its exception it ahs a register
file
filled with stuff useful to future running's of ISR[13].

When ISR[13] gains control to handle another interrupt it has a file
filled
with what it was filled with the last time it ran--all 30 of them while
registers R0..R1 contain information about the current interrupt to be
serviced.
SP points at its stack
FP points at its frame or is another register containing whatever it
   contained the previous time
R29..R2 contain the value it had the previous time it ran

>
>
>>> Of course convincing programmers to RTFM is futile. ;(
>>
>> Done with Instructions in HW one has to convince exactly two
>> people; GCC code generator and LLVM code generator.
>>>
>>> If so this is the first I have heard that more registers is not bad for
>>> interrupt response time.
>>
>> They are also bad for pipeline stage times.
>>
>>> So we are back to finding any downsides for 64 registers in My 66000.
>>
>> Encoding
>
> Admittedly painful, extremely so.
>
>> pipeline staging
>
> A longer pipeline is slower to start up, but gets work done faster.
> Is this what you mean?

No, I mean the feedback loops take more cycles so apparent latency
is greater.

>> context switch times
>
> Task swapping time is way down in the noise. It’s reloading the L1 and
> L2
> cache that swamps the time. 64 registers is nothing compared to 32k or
> megabytes.

While it is under 1% of all cycles, current x86s take 1,000 cycles
application to application and 10,000 cycles hypervisor to hypervisor.

I want both of these down in the 20-cycle range.