From: tkoenig@netcologne.de
Robert Finch schrieb:
> On 2025-10-29 2:15 p.m., Thomas Koenig wrote:
>> Robert Finch schrieb:
>>> 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. GPRs may contain either integer or
>>> floating-point values.
>>
>> I understand the temptation to go for more bits :-) What is your
>> instruction alignment? Bytewise so 40 bits fit, or do you have some
>> alignment that the first instruction of a cache line is always aligned?
>
> The 40-bit instructions are byte aligned. This does add more shifting in
> the align stage. Once shifted though instructions are easily peeled off
> from fixed positions. One consequence is jump targets must be byte
> aligned OR routines could be required to be 32-bit aligned for instance.>
That raises an interesting question. If you want to align a branch
target on a 32-bit boundary, or even a cache line, how do you fill
up the rest? If all instructions are 40 bits, you cannot have a
NOP that is not 40 bits, so there would need to be a jump before
a gap that is does not fit 40 bits.
>> If you have that many bits available, do you still go for a load-store
>> architecture, or do you have memory operations? This could offset the
>> larger size of your instructions.
>
> It is load/store with no memory ops excepting possibly atomic memory ops.>
OK. Starting with 40 vs 32 bits, you have a factor of 1.25 disadvantage
in code density to start with. Having memory operations could offset
that by a certain factor, that was why I was asking.
>>> 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 sizes are not really a good fit for constants from programs,
>> where quite a few constants tend to be 32 or 64 bits. Would a
>> 64-bit FP constant leave 26 bits empty?
>>
> I found that 16-bit immediates could be encoded instead of 10-bit.
OK. That should also help for offsets in load/store.
> So, now there are 16,56,96 and 136 bit constants possible. The
> 56-bitconstant likely has enough range for most 64-bit ops.
For addresses, it will take some time for this to overflow :-)
For floating point constants, that will be hard.
I have done some analysis on frequency of floating point constants
in different programs, and what I found was that there are a few
floating point constants that keep coming up, like a few integers
around zero (biased towards the positive side), plus a few more
golden oldies like 0.5, 1.5 and pi. Apart from that, I found that
different programs have wildly different floating point constants,
which is not surprising. (I based that analysis on the grand
total of three packages, namely Perl, gnuplot and GSL, so cover
is not really extensive).
> Otherwise using
> a 96-bit constant for 64-bit ops would leave the upper 32-bit of the
> constant unused.
There are also 32-bit floating point constants, and 32-bit integers
as constants. There are also very many small integer constants, but
of course there also could be others.
>136 bit constants may not be implemented, but a size
> code is reserved for that size.
I'm still hoping for good 128-bit IEEE hardware float support.
POWER has this, but stuck it on their their decimal float
arithmetic, which is not highly performing...
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
