Best Way to Convert 32-bit Signed Value to 16 Bit?

[AGS]

Ok, the optimisation is for a func that converts the min/max bounds of a rectangle from 32 bit into 16 bit in order that it can be filled.

Now I have another problem. If I do not have the right and bottom coordinates, but instead a width and a height, what to do then? I want the clipped width and height returned. This time the input and the result of width and height cannot and must not be negative, but input can be larger than $7fff.

[AnimaInCorpore]

Originally Posted by Don_Adan

Perhaps the fastest version is version based on meynaf's trick.

 move.w D0,A0
 cmp.l D0,A0
 beq.b OK
 move.w #$8000,D0
 tst.l D0
 bmi.b OK
 not.w D0
OK

Another idea:

  movea.w d0,a0
  cmpa.l  d0,a0
  beq.s   ok
  add.l   d0,d0
  scc     d0
  ext.w   d0
  roxr.w  #1,d0
ok:

Cheers
Sascha

[Thorham]

Originally Posted by AGS

Ok, the optimisation is for a func that converts the min/max bounds of a rectangle from 32 bit into 16 bit in order that it can be filled.

Why are you using 32 bit values for those rectangles? Even with 16 bit you already have 65536x65536 pixel rectangles, far more than what's needed for anything on Amigas.

Originally Posted by AGS

Now I have another problem. If I do not have the right and bottom coordinates, but instead a width and a height, what to do then? I want the clipped width and height returned.

I don't see how you can clip without knowing the location of the rectangle.

Originally Posted by AGS

This time the input and the result of width and height cannot and must not be negative, but input can be larger than $7fff.

If the input is never negative, 0 is the minimum, and the maxium is $7fff, than that's pretty easy.

[AGS]

In my GUI I habe Listviews for File Directories. These need 32 bit values as they can be very big and also partially outside of the screen. This is how my scrolling works. The location of the Rectangle is given, only width and height are there in difference to right and bottom. It's pretty easy with a compare and this is how i do it, but maybe there is another solution.

[Don_Adan]

Originally Posted by AnimaInCorpore

Another idea:

  movea.w d0,a0
  cmpa.l  d0,a0
  beq.s   ok
  add.l   d0,d0
  scc     d0
  ext.w   d0
  roxr.w  #1,d0
ok:

Cheers
Sascha

Nice.
I checked ADPCM source and full version of meynaf's trick looks next:

  move.w d0,a0
  cmp.l  d0,a0
  beq.s   ok
  add.l   d0,d0
  subx.l    d0,d0
  eor.w #$7FFF,D0
ok

Anyway the shortest version can be next:

  move.w d0,a0
  cmp.l  d0,a0
  beq.s   ok
  add.w   d0,d0
  subx.w   d0
  asr.l  #1,d0
ok

[AGS]

What does "subx.w d0" do? Is this a plain 68000 command or do I need an 680xx?

[Thorham]

To Don_Adan:

You've made a mistake.

Originally Posted by AGS

What does "subx.w d0" do? Is this a plain 68000 command or do I need an 680xx?

Subx is available on all 68000 CPUs. It simply subtracts with carry, just like addx adds with carry. The carry bit is set when an arithmetic operation causes an overflow or underflow, and these instructions can therefore be used to, for example, add two 32 bit numbers together, and get a 33 bit result:

    clr.l   d2
    add.l   d0,d1   ; d1 contains bits 0-31 of the result
    addx.l  d2,d2   ; d2 contains bit 32 of the result

[StingRay]

Originally Posted by Don_Adan

This is not my idea, but meynaf's (french coder, available on EAB too) trick, he used this trick in own productions for fast range check (-32768 to +32767). Moving word into address register works as move.w and ext.l together.

This trick wasn't invented by Meynaf either, it was used for a long time already.

Originally Posted by AGS

What does "subx.w d0" do? Is this a plain 68000 command or do I need an 680xx?

subx.w d0 is illegal, should be subx.w d0,d0, this is a standard 68000 instruction. Subtracts d0 from d0 but takes the value of the carry bit into account as well. if the carry bit was set before, d0 would be -1 after this operation.

[Don_Adan]

Originally Posted by Thorham

To Don_Adan:

You've made a mistake.


Subx is available on all 68000 CPUs. It simply subtracts with carry, just like addx adds with carry. The carry bit is set when an arithmetic operation causes an overflow or underflow, and these instructions can therefore be used to, for example, add two 32 bit numbers together, and get a 33 bit result:

    clr.l   d2
    add.l   d0,d1   ; d1 contains bits 0-31 of the result
    addx.l  d2,d2   ; d2 contains bit 32 of the result

Standard usage of addx/subx commands is not enough sexy for me. Especially subx can be used for many tricks.
And od course it must be subx.w D0,D0.

move.w d0,a0
cmp.l d0,a0
beq.s ok
add.w d0,d0   ; bit x, 0 or 1
subx.w d0,d0  ; d0, $FFFF0000 or $0000FFFF
asr.l #1,d0   ; d0, $FFFF8000 or $00007FFF
ok

[TheDarkCoder]

Originally Posted by Don_Adan

Standard usage of addx/subx commands is not enough sexy for me. Especially subx can be used for many tricks.
And od course it must be subx.w D0,D0.

move.w d0,a0
cmp.l d0,a0
beq.s ok
add.w d0,d0   ; bit x, 0 or 1
subx.w d0,d0  ; d0, $FFFF0000 or $0000FFFF
asr.l #1,d0   ; d0, $FFFF8000 or $00007FFF
ok

this last code seems not working to me..
I tried with D0 = $00200010. The correct result should be (if I understood the problem) D0 = $00007fff. The code instead sets D0 = $00100000 which is wrong even if you consider only D0.w

[AGS]

You understood correctly.

[Don_Adan]

Originally Posted by TheDarkCoder

this last code seems not working to me..
I tried with D0 = $00200010. The correct result should be (if I understood the problem) D0 = $00007fff. The code instead sets D0 = $00100000 which is wrong even if you consider only D0.w

This version fixes only values from $00008000-$0000FFFF and $FFFF7FFF-$FFFF000 range. For other values you must/can use meynaf version with eor. This routine is used mostly (only?) for correction ($7FFF to $8000) range and it works OK (I checked ADPCM player), perhpas can works for JPEG and MPEG decompression routine too. But of course if you need routine for conversion (not for correction only) then meynaf version must be used for this case.