pouët.net

evl,
and that's one thing rlwinm does (amongst others).

o yeah, absolute value on the 68k would be nice too.

superplek: exactly, int 21h was the way to call the OS. Most people here are asking for new HW, but I only ask for new SW :(

I frequently miss these on the 65816:
- JSL [$12],Y ;Subroutine Jump, Direct Page Indirect Long Indexed Y
- INC $123456 ;Increment/Decrement, Absolute Long
- PLK ;Pull byte from stack, put into program bank reg (normal long jumps work just as well for that, of course)

But maybe that's just me...

something that enables stackless use of the x86 fpu

though for starters, an FLD from EAX would be good too.

FILD i mean.

Ok here's a longer and more explained one for Z80


As I already said faster index register instructions would be nice
LD A,(IX+5) takes 19 t-states when eg. LD A,(HL) takes 7 t-states.
But 19 t-states is just fine for 3,5 Mhz and can be useful as Optimus already explained! :-)

Faster clear memory instruction would indeed be quite nice since even fastest way by
pushing stack takes 11 t-states. LDIR going 4 t-states would be kickass!

I love the way Gameboys custom Z80 does the load location (HL) with register and increase HL instruction.
##GBZ80
LDI (HL),anyregister ;8 t-states
##Z80
LD (HL),anyregister ; 7 t-states
INC HL ; 6 t-states

I don't see no use for multiplication when you can use tables, but indeed barrel shifts would've been nice.


I personally think all these 'upgrades' just kills the creativity.

I mean by creativity, the coders creativity of searching new ways to code(ofc. not entirely), this is atleast for me(i think).

This post starts with a lie: I need more than one instruction. A famility so to say. I also now had them native on the C64x+ DSP

Here it is:

SHFL RegOut, RegA, RegB

Shuffle: interleaves the lower 16 bits from RegA with RegB and places the result into 32 bit register RegOut:

E.g:

RegA: <abcdefghijklmnop>
RegB: <AbCDEFGHIJKLMNOP>
RegOut: <aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpP>


Of course we need the reverse thing: DEAL:

DEAL RegOut, RegA

Deal: de-interleaves the bits from RegA and sorts them into MSB16 and LSB16 of RegOut:

E.g:
RegA: <aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpP>
RegOut: <ABCDEFGHIJKLMNOPabcdefghijklmnop>


-----------------

Why do I need these:

Well - Interleaving bits this way gives the best cache-hit ratios regardless of the direction you scan through a 2D-Array. The only important thing is cache locality in general and the manhatten difference between subsequent reads. In extreme cases this roxors hard and gives a factor 10 performance gain!

Such an instruction would *rock* 2D matrix mathematics for matrices larger than your first level cache. And for the extra demo-sceener factor: They would totally rock all 2D software texture mappers.


Fun fact: In the x86 world we're about to even see these instructions in the future.. Not like this, but as a side-effect of carry-less multiplication (aka Galois GF2-multiplications).

Now dig this:

RegA: <abcdefghijklmnop>

Result: = RegA (Galois-Multipliy) RegA

Results in: <a0b0c0d0e0f0gh0i0j0k0l0m0n0o0p>

Or in other words: a pow2 as carry-less multiplication spreads the bits out and fills the gap with zeroes. So it takes only two of these multiplies and a humble OR to interleave bits and get all the cache-miss galore that I talked about..

ARM-NEON has this feature for two years now btw. As an intrinsic it is called:

poly8x8_t vmul_p8 (poly8x8_t, poly8x8_t)


Last but not least: Such an instruction has great use in crypto-applications as well.

On my oldskool hobby platform of choice, I like all the instructions I have (the MUL is fucking slow, but it functions). I just wish every single byte didn't take 4 cycles to read. I have nearly 5MHz at my disposal but it's no faster than a C64.

torus: What do you mean, "about to see"? Carryless multiply is there already, starting with Westmere (the 32nm shrink of Nehalem aka Core i7). http://en.wikipedia.org/wiki/CLMUL_instruction_set

Meanwhile in Iceland: http://software.intel.com/en-us/articles/prototype-primitives-guide/. This has the shuffle (bitinterleave11) but no inverse. But it's there in both vector and scalar variants. Halfway there, I guess. :)


The difference is fairly minuscule for anything that has sequential-access inner loops (such as matrix multiplies), because you can efficiently step indices in Z-order.

Take a matrix multiply, A is m x p and B is p x n so C=AB is m x n.



Now, with shuf and the matrix stored in morton order, a first attempt at the inner loop would look something like this:


and realizing that shuf(0, X) = shuf(X,0) << 1, we can get rid of some fat:



One instruction less. But watch what happens when we just step in morton order directly:




Two instructions less and less registers. Short version: If you want morton-order matrices, then just go ahead already, you don't need special instructions to access them quickly. :)

@Gargaj: Never understood why that (and store to EAX) wasn't possible...

rarefluid: Well, Intel stopped extending the x87 instruction set ages ago. Nowadays it's just deprecated, but even pre-SSE, I think the main problem was that the encoding space for x87 is full. Worse, FPU opcodes use ModRM bytes (which are normally used to specify register targets) but then allocate the bits normally used for destination register specification as opcode extension. You do not want to introduce a special destination register encoding that has a different form of ModRM byte, because that and the SIB decoding logic is the one piece of the instruction decoder that's actually used without tons of special cases in the existing x86 instruction set. And you don't want to start allocating FPU opcodes from other ranges, that would royally fuck up instruction decoder design - the kind of fuck-up that makes the critical path longer (i.e. decreases max clock rate).

Outside 4ks where you want the shorter opcodes, the problem for all practical purposes doesn't exist anymore. Since SSE2 (i.e. P4 and after) you can movd between GPRs and the XMM regs.

ryg,

yep. I knew that incremental morton-order trick. That works well and it is fast. But what if you have to jump to a new location often just to iterate three or four elements? You have to interleave the bits of the new location again. This becomes costly.

Think of the SVD's I've calculated last year. If I remember right a big part of it was the diagonal reduction step. The motion through the data was always along a rather thin band around the diagonal of the matrix.

Calling address = interleave (x,y) would be very convenient here..

Nice to see that the instruction made it into the larrabee architecture btw. Any idea what the 2:1 bit interleave pattern is used for?

Cheers,
Nils

Ok. Didn't think about the decoders. The ModR/M econding is seriously fucked up anyway...

i always miss

on 68k (also for .w and .b and all other address regs and also incr or decr or none of those behaviours on the address regs)

instead, i have to trash a reg and use at least 2 instructions. ;(

oh, and this also stands for missing sub support, of course

6502:

SuperH-2:

x86:

The first step in SVD computations is to reduce the matrix to bidiagonal form, in what is basically a variant of the QR decomposition, usually done with either Householder reflections or Givens rotations. Both work by rows/columns, and the matrix is dense at that point.

Nobody stores a bidiagonal matrix in 2D - Morton order or no, that's just asking for piss-poor cache usage. You just store the main diagonal and the super/subdiagonal as vectors.

The final solution step reduces the bidiagonal matrix to a diagonal matrix iteratively, and it needs to apply updates to the basis vectors as it goes along. But that step always goes right along the diagonal (or at most one row/col off it), so just having the increment is fine.


I guess it's for 3D arrays.

On the 68060, I have often missed CVALID - an MMU instruction which forces a cache line to go valid without reading any data from memory. And the instruction should not be privileged, of course.

Proper write merging would mostly do the trick, though.

hm, I guess a nice shuffle instruction would speed up chunky-to-planar routines on the Amiga quite a bit, no?

spike: only on slower cpus (ie less than a decent 040). Otherwise it's all about memory performance.

I tend to miss "djnz a" on the z80. Or whatever isn't orthogonal in the instruction set (why can I add HL,DE but not add DE,HL ?)

None. All instructions are there (I'm sure ;-) - but I would definitely like to have them all executed in a single cycle, so I can split the rasters like hell and push my GTIA to a proper bandwidth on my Atar without changing the rest of the chipsi.