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: <38055f09c5d32ab77b9e3f1c7b979fb4@www.novabbs.org> <2024Aug11.163333@mips.complang.tuwien.ac.at> <1bf2c13fc41cf8aeca4a746052c03ce3@www.novabbs.org> 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 wrote: >> On Sat, 17 Aug 2024 0:24:24 +0000, Brett wrote: >> >>> MitchAlsup1 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.