Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.arch    |    Apparently more than just beeps & boops    |    131,241 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 130,055 of 131,241    |
|    Robert Finch to Robert Finch    |
|    Re: Tonights Tradeoff    |
|    29 Oct 25 08:50:35    |
      From: robfi680@gmail.com              On 2025-10-29 8:41 a.m., Robert Finch wrote:       > On 2025-10-29 3:14 a.m., Stephen Fuld wrote:       >> On 10/28/2025 8:52 PM, Robert Finch wrote:       >>> Started working on yet another CPU – Qupls4. Fixed 40-bit       >>> instructions, 64 GPRs. GPRs may be used in pairs for 128-bit ops.       >>> Registers are named as if there were 32 GPRs, A0 (arg 0 register is       >>> r1) and A0H (arg 0 high is r33). Sameo for other registers.       >>       >> I assume the "high" registers are for handling 128 bit operations       >> without the need to specify another register name. Do you have 5 or 6       >> bit register numbers in the instructions. Five allows you to use the       >> high registers for 128 bit operations without needing another register       >> specifier, but then the high registers can only be used for 128 bit       >> operations, which seems a waste. If you have six bits, you can use       >> all 64 registers for any operation, but how is the "upper" method that       >> better than automatically using r(x+1)?       >>       > Yes, but it is just a suggested usage. The registers are GPRs that can       > be used for anything, specified using a six bit register number. I       > suggested it that way because most of the time register values would be       > passed around as 64-bit quantities and it keeps the same set of       > registers for the same register type (argument, temp, saved). But since       > it should be using mostly compiled code, it does not make much difference.       >       > Also, the high registers could be used as FP registers. Maybe allowing       > for saving only the low order 32 regs during a context switch.>       >>       >>> GPRs may contain either integer or floating-point values.       >>>       >>> Going with a bit result vector in any GPR for compares, then a branch       >>> on bit-set/clear for conditional branches. Might also include branch       >>> true / false.       >>>       >>> Using operand routing for immediate constants and an operation size       >>> for the instruction. Constants and operation size may be specified       >>> independently. With 40-bit instruction words, constants may be       >>> 10,50,90 or 130 bits.       >>       >> Those seem like a call from the My 66000 playbook, which I like.       >>       > Yup.>       >>       >       I should mention that the high registers are available only in user/app       mode. For other modes of operation only the low order 32 registers are       available. I did this to reduce the number of logical registers in the       design. There are about 160 (64+32+32+32) logical registers then. They       are supported by 512 physical registers. My previous design had 224       logical registers which eats up more hardware, probably for little benefit.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca