Stretch bit in word into longword
 

Here I am again stuck in very silly problems.

I'm trying to write a piece of code to transform a word into a longword by "stretching" the bits.

For example:

%1010110011010101

should become:

%11001100111100001111001100110011

so every value repeated twice.

But I have no idea how to proceed. Actually it's an exercise to learn manipulate data and I really need some help here.

I tried by copying the data, then LSR by 1 bit and copy it again with a XOR but all I got was a big mess :banghead

Probably an easier way to do it... but a five minute shot.

Your result will be in d1

mcgeezer

This is faster and the number of processor cycles used are a constant:
Result in D2.
Yes, is ugly :)

Probably with a LUT can be made much faster.

makes sense and actually works, thanks!

LOL yes quite ugly but still a trick to learn, thanks :great

A simple trick to make it much faster on bare 68k:

mcgeezer routine: 678 cycles*
my previous one: 396 cycles
this: 272 cycles**

*of course only for this number of 1 bits
**occhio allo swap ;)

LUT version: 82 cycles :D

You're the best :great
:)

Slightly lower cycle count (-4):

:great

Another little gain (-2):
:)

Getting too old for this :(, should've noticed earlier. 2 cycles faster, so the same as yours, but without extra mem accesses.

:cool

Damn, that's why last night I dreamed of a lsr #7, but this morning I forgot it! :p

Anyone shorter? :)

Be satisfied with that, without considering the initial setup in d0 and lut calc these are 68 cycles, I would say not bad at all ;)

Absolute shortest (in some way :D) :
Obviously needs 68020+.

:cheese
Thinks that a 512byte lut already seemed big to me...
It would be interesting to calculate how many cycles it takes to fill the lut ;)

Indeed. :)
This is a rather typical example of code where we need to know what the program does and how badly it needs to be fast...

The non-LUT code can be shortened and sped up quite a bit:


No idea about the actual cycle count.

Another possibility is ye olde c2p merge trick (unverified, but it gives the idea) :
Use of rol/ror is probably killing the timing on 68000, though...