Deutsch English Français Italiano |
<v9rlh3$28344$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Brett <ggtgp@yahoo.com> Newsgroups: comp.arch Subject: Re: My 66000 and High word facility Date: Sun, 18 Aug 2024 02:16:04 -0000 (UTC) Organization: A noiseless patient Spider Lines: 94 Message-ID: <v9rlh3$28344$1@dont-email.me> 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> <66569211a570a7db9978ebbab2b073c2@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 18 Aug 2024 04:16:04 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5ba5cb609a09f0936fb582a81e40cbf8"; logging-data="2362500"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MR34BIa7DIbr+O0gHEvFM" User-Agent: NewsTap/5.5 (iPad) Cancel-Lock: sha1:Rq2NWDTYVGL98skwHaCqtuNxcI0= sha1:/hK8QWtpXYvecLP4HtOdBxjhHIE= Bytes: 5044 MitchAlsup1 <mitchalsup@aol.com> wrote: > 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 I don’t remember the PlayStation using all registers in an interrupt, it was only a few lines of code and 8 registers was fine. This would only save you 3 cycles and is probably not worth the potential hassles. I have heard programmers complaining that interrupt response was too slow and so they had to add a second toy CPU just to handle interrupts. Probably people that made the mistake of upgrading to x86. Have wondered if having a scratchpad for interrupt code (and critical data) would solve those problems as memory can be 150 cycles away, plus you can have 40 pending reads queued ahead of you. Makes servicing interrupts in a timely matter difficult, even if you are not touching much memory. >>>> 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. >