Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Robert Finch Newsgroups: comp.arch Subject: Re: Tonights Tradeoff - ATOM Date: Sun, 13 Oct 2024 02:46:14 -0400 Organization: A noiseless patient Spider Lines: 54 Message-ID: References: <37067f65c5982e4d03825b997b23c128@www.novabbs.org> <5f8ee3d3b2321ffa7e6c570882686b57@www.novabbs.org> <2024Oct4.081931@mips.complang.tuwien.ac.at> <2024Oct5.114309@mips.complang.tuwien.ac.at> <531204abc9366f7dff2f288acb941f9a@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 13 Oct 2024 08:46:19 +0200 (CEST) Injection-Info: dont-email.me; posting-host="29fc730c4615fe70a51db70f860a30da"; logging-data="626793"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mPGsXYh37N7v8zrEUEHW1/l8BjqpQ8+I=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:5yJr81wOKf6hE77ev989mvqytHc= Content-Language: en-US In-Reply-To: <531204abc9366f7dff2f288acb941f9a@www.novabbs.org> Bytes: 4473 >> BJX2 / XG2 has destroys the value of the one source operand, I noted the >> extra code to preserve the one operand. Is that only for the ADDC >> instruction? >> >> What is the limit on the My66000 CARRY modifier for the number of >> carries? Assuming the sequence is interruptible there must be a few bits >> of state that need to be preserved. > > CARRY casts its modification over 8 subsequent instructions using its > 16-bit immediate. > >> I found incorporating modifiers have a tendency to turn my code into >> spaghetti. Maybe my grasp of implementation is not so great though. > > DECODE has a shift register to attach 2-bits to subsequent instructions > each. However, the Rd provided by CARRY carries 64-bits from instruction > to instruction--which makes 256×64 -bit multiplication straightforward. Q+ has something using a similar approach, the ATOM instruction, which sets the interrupt priority level for the next 11 instructions. It shifts three bits per instruction at a time at the enqueue stage when the instruction group is loaded into the ROB. The shift should maybe be moved back to decode. It is a bit of spaghetti code ATM. I suspect could be implemented better. The idea is ATOM allows temporarily disabling interrupts and automatically restoring the interrupt level to what it was after a certain number of instructions. I found writing code I was disabling then enabling interrupts at various points, which was tricky to do as the original interrupt status needed to be recorded and restored. It took several instructions. Looking for a cleaner solution. atom “77777” ; disable all but non-maskable interrupts < instr. > Currently, all Q+ instructions have only a single write port max. To use two ports means using two ALUs at the same time, which would serialize the machine. I think the CARRY modifier requires two write ports. The quad-float extender prefix (QFEXT) allows 128-bit floats by using an FPU and ALU port at the same time. There were a couple of other modifiers, PRED and ROUND, but they got removed as they were not needed when the instructions were enlarged to 64-bit. PRED is just a predicate register spec in every instruction now. > >> The add, addgc can execute at the same time. So, it is 4 clocks at the >> worst to add two 256-bit numbers. (The first / last instructions may >> execute at the same time as other instructions). >> I wanted to avoid using instruction modifiers and special flags >> registers as much as possible. It is somewhat tricky to have a carry >> flag in flight. Q+ is not very code dense, but the add can be done. It >> is also possible to put the carry bit in a predicate register.