Re: Misc: Ongoing status...

On Thu, 30 Jan 2025 20:00:22 +0000, BGB wrote:

So, recent features added to my core ISA: None.
Reason: Not a whole lot that brings much benefit.
>
>
Have ended up recently more working on the RISC-V side of things,
because there are still gains to be made there (stuff is still more
buggy, less complete, and slower than XG2).
>
>
On the RISC-V side, did experiment with Branch-compare-Immediate
instructions, but unclear if I will carry them over:
   Adds a non-zero cost to the decoder;
     Cost primarily associated with dealing with a second immed.
   Effect on performance is very small (< 1%).

I find this a little odd--My 66000 has a lot of CPM #immed-BC
a) so I am sensitive as this is break even wrt RISC-V
b) But perhaps the small gains is due to something about
.. how the pair runs down the pipe as opposed to how the
.. single runs down the pipe.

In my case, I added them as jumbo-prefixed forms, so:
   BEQI Imm17s, Rs, Disp12s

IMM17 should be big enough.

Also added Store-with-Immediate, with a similar mechanism:
   MOV.L  Imm17s, (Rm, Disp12s*1)
As, it basically dropped out for free.
>
Also unclear if it will be carried over. Also gains little, as in most
of the store-with-immediate scenarios, the immediate is 0.

Most of my ST w/immediate is floating point data--imme17 is not
going to cut it there.

Instructions with a less than 1% gain and no compelling edge case, are
essentially clutter.
>
I can note that some of the niche ops I did add, like special-case
RGB555 to Index8 or RGBI, were because at least they had a significant
effect in one use-case (such as, speeding up how quickly the GUI can do
redraw operations).
>
My usual preference in these cases is to assign 64-bit encodings, as the
instructions might only be used in a few edge cases, so it becomes a
waste to assign them spots in the more valuable 32-bit encoding space.
>
>
The more popular option was seemingly another person's option, to define
them as 32-bit encodings.
   Their proposal was effectively:
     Bcc Imm5, Rs1', Disp12
       (IOW: a 3-bit register field, in a 32-bit instruction)
   I don't like this, this is very off-balance.
     Better IMO: Bcc Imm6s, Rs1, Disp9s (+/- 512B)

This is the case were fusing of CMP #imm16-BC into one op is
better, unless you can use a 64-bit encoding to directly
encode that.

The 3-bit register field also makes it nearly useless with my compiler,
as my compiler (in its RV mode) primarily uses X18..X27 for variables
(IOW: the callee save registers). But, maybe moot, as either way it
would still save less than 1%.
>
Also, as for any ops with 3-bit registers:
   Would make superscalar harder and more expensive;
   Would add ugly edge cases and cost to the instruction decoder;
   ...

3-bit register specifier is not much better than dedicated registers
{like x86 DIV}.

I would prefer it if people not went that route (and tried to keep
things at least mostly consistent, trying to avoid making a dog chewed
mess of the

     already dog chewed

            32-bit ISA).

If you really feel the need for 3-bit register fields... Maybe, go to a
larger encoding?...

I suggest a psychiatrist.

When I defined my own version of BccI (with a 64-bit encoding), how many
new instructions did I need to define in the 32-bit base ISA: Zero.

How many 64-bit encodings did My 66000 need:: zero.
{Hint the words following the instruction specifier have no internal
format}
<snip>

But, my overall goal still being:
   Try to make it not suck.
But, it still kinda sucks.
   And, people don't want to admit that it kinda sucks;
   Or, that going some directions will make things worse.

On the other hand, I remain upbeat on the ISA I have created.

Seems like a mostly pointless uphill battle trying to convince anyone of
things that (at least to me) seem kinda obvious.

Do not waste you time teaching pigs to put on lipstick. ...