Re: "Mini" tags to reduce the number of op codes

On 4/10/2024 12:12 PM, MitchAlsup1 wrote:

BGB wrote:
 

On 4/9/2024 7:28 PM, MitchAlsup1 wrote:

BGB-Alt wrote:
>

 

Also the blob of constants needed to be within 512 bytes of the load instruction, which was also kind of an evil mess for branch handling (and extra bad if one needed to spill the constants in the middle of a basic block and then branch over it).

 In My 66000 case, the constant is the word following the instruction.
Easy to find, easy to access, no register pollution, no DCache pollution.
 

Yeah.
This was why some of the first things I did when I started extending SH-4 were:
Adding mechanisms to build constants inline;
Adding Load/Store ops with a displacement (albeit with encodings borrowed from SH-2A);
Adding 3R and 3RI encodings (originally Imm8 for 3RI).
Did have a mess when I later extended the ISA to 32 GPRs, as (like with BJX2 Baseline+XGPR) only part of the ISA had access to R16..R31.

Usually they were spilled between basic-blocks, with the basic-block needing to branch to the following basic-block in these cases.

 

Also 8-bit branch displacements are kinda lame, ...

 Why do that to yourself ??
 

I didn't design SuperH, Hitachi did...
All of this stuff was apparently sufficient for the SEGA 32X/Saturn/Dreamcast consoles... (vs the Genesis/MegaDrive using a M68000, and Master System using a Z80).
I guess for a while it was also popular in CD-ROM and HDD controllers.
I guess after SEGA left the game-console market, they had continued using it for a while in arcade machines, before apparently later jumping over to x86 via low-end PC motherboards (I guess it being cheaper since the mid/late 2000s to build an arcade machine with off-the-shelf PC parts).
Saw a video where a guy was messing with one of these, where I guess despite being built with low-end PC parts (and an entry-level graphics card), the parts were balanced well enough that it still gave fairly decent gaming performance.
But, with BJX1, I had added Disp16 branches.
With BJX2, they were replaced with 20 bit branches. These have the merit of being able to branch anywhere within a Doom or Quake sized binary.

And, if one wanted a 16-bit branch:
   MOV.W (PC, 4), R0  //load a 16-bit branch displacement
   BRA/F R0
   .L0:
   NOP    // delay slot
   .WORD $(Label - .L0)

 

Also kinda bad...

 Can you say Yech !!
 

Yeah.
This sort of stuff created strong incentive for ISA redesign...
Granted, it is possible had I instead started with RISC-V instead of SuperH, it is probable BJX2 wouldn't exist.
Though, at the time, the original thinking was that SuperH having smaller instructions meant it would have better code density than RV32I or similar. Turns out not really, as the penalty of the 16 bit ops was needing almost twice as many on average.

Things like memcpy/memmove/memset/etc, are function calls in cases when not directly transformed into register load/store sequences.

>
My 66000 does not convert them into LD-ST sequences, MM is a single inst-
ruction.
>

 

I have no high-level memory move/copy/set instructions.
Only loads/stores...

 You have the power to fix it.........
 

But, at what cost...
I had generally avoided anything that will have required microcode or shoving state-machines into the pipeline or similar.
Things like Load/Store-Multiple or

For small copies, can encode them inline, but past a certain size this becomes too bulky.

 

A copy loop makes more sense for bigger copies, but has a high overhead for small to medium copy.

 

So, there is a size range where doing it inline would be too bulky, but a loop caries an undesirable level of overhead.

 All the more reason to put it (a highly useful unit of work) into an
instruction.
 

This is an area where "slides" work well, the main cost is mostly the bulk that the slide adds to the binary (albeit, it is one-off).
Which is why it is a 512B memcpy slide vs, say, a 4kB memcpy slide...
For looping memcpy, it makes sense to copy 64 or 128 bytes per loop iteration or so to try to limit looping overhead.
Though, leveraging the memcpy slide for the interior part of the copy could be possible in theory as well.
For LZ memcpy, it is typically smaller, as LZ copies tend to be a lot shorter (a big part of LZ decoder performance mostly being in fine-tuning the logic for the match copies).
Though, this is part of why my runtime library had added a "_memlzcpy(dst, src, len)" and "_memlzcpyf(dst, src, len)" functions, which can consolidate this rather than needing to do it one-off for each LZ decoder (as I see it, it is a similar issue to not wanting code to endlessly re-roll stuff for functions like memcpy or malloc/free, *).
*: Though, nevermind that the standard C interface for malloc is annoyingly minimal, and ends up requiring most non-trivial programs to roll their own memory management.

Ended up doing these with "slides", which end up eating roughly several kB of code space, but was more compact than using larger inline copies.

 

Say (IIRC):
   128 bytes or less: Inline Ld/St sequence
   129 bytes to 512B: Slide
   Over 512B: Call "memcpy()" or similar.

 Versus::
     1-infinity: use MM instruction.
 

Yeah, but it makes the CPU logic more expensive.

The slide generally has entry points in multiples of 32 bytes, and operates in reverse order. So, if not a multiple of 32 bytes, the last bytes need to be handled externally prior to branching into the slide.

 Does this remain sequentially consistent ??
 

Within a thread, it is fine.
Main wonk is that it does start copying from the high address first.
Presumably interrupts or similar wont be messing with application memory mid memcpy.
The looping memcpy's generally work from low to high addresses though.

Though, this is only used for fixed-size copies (or "memcpy()" when value is constant).

 

Say:

 

__memcpy64_512_ua:
   MOV.Q        (R5, 480), R20
   MOV.Q        (R5, 488), R21
   MOV.Q        (R5, 496), R22
   MOV.Q        (R5, 504), R23
   MOV.Q        R20, (R4, 480)
   MOV.Q        R21, (R4, 488)
   MOV.Q        R22, (R4, 496)
   MOV.Q        R23, (R4, 504)

 

__memcpy64_480_ua:
   MOV.Q        (R5, 448), R20
   MOV.Q        (R5, 456), R21
   MOV.Q        (R5, 464), R22
   MOV.Q        (R5, 472), R23
   MOV.Q        R20, (R4, 448)
   MOV.Q        R21, (R4, 456)
   MOV.Q        R22, (R4, 464)
   MOV.Q        R23, (R4, 472)

 

....

 

__memcpy64_32_ua:
   MOV.Q        (R5), R20
   MOV.Q        (R5, 8), R21
   MOV.Q        (R5, 16), R22
   MOV.Q        (R5, 24), R23
   MOV.Q        R20, (R4)
   MOV.Q        R21, (R4, 8)
   MOV.Q        R22, (R4, 16)
   MOV.Q        R23, (R4, 24)
   RTS

 Duff's device in any other name.

More or less, though I think the idea of Duff's device is specifically in the way that it abuses the while-loop and switch constructs.
This is basically just an unrolled slide.
So, where one branches into it, determines how much is copied.
For small-to-medium copies, the advantage is mostly that this avoids looping overhead.