68020 Bit Field Instructions

mcgeezer · 06 February 2019, 18:14

Hi All,

I've been looking into the Bit Field 68020 instructions that are available on the A1200 and have been playing with them.

As of yet I haven't really come across many use cases for them over and above what normal AND/OR/NOT/NEG/EOR instructions would do.

It seems they just allow for finer grained control of the normal byte/word/longword sizes but apart from that do they offer anything else?

The BFFFO instruction looks interesting for finding the Most Significant bit set... I could probably use that somewhere but nothing a couple of normal instructions wouldn't solve for me.

Are the BF instructions particularly fast?

Ta,
Geezer

meynaf · 06 February 2019, 18:30

BF instructions aren't fast. But they're single instruction doing the job of several. Thus they're often faster than the unwieldy bit manipulation they replace.

Consider BFINS for example. For doing the same work you need to clear the target field, mask out the data to insert, shift it to the relevant position, and then OR it. This is not only longer in size, it will also require temporaries which you do not necessarily have available because out of data regs.

ross · 06 February 2019, 19:31

Quote:

Originally Posted by mcgeezer

Hi All,

I've been looking into the Bit Field 68020 instructions that are available on the A1200 and have been playing with them.

As of yet I haven't really come across many use cases for them over and above what normal AND/OR/NOT/NEG/EOR instructions would do.

It seems they just allow for finer grained control of the normal byte/word/longword sizes but apart from that do they offer anything else?

The BFFFO instruction looks interesting for finding the Most Significant bit set... I could probably use that somewhere but nothing a couple of normal instructions wouldn't solve for me.

Are the BF instructions particularly fast?

Ta,
Geezer

Heya Geezer, check the Ocean Loader v2 source for an interesting use case.

I've also used it for quarter pixel scroll bit distribution and in a sine scroll

And sure in various 020+ code i've written. I like those instructions.

Yes, all can be done with the usual, but really useful to gain registers and easy of mind.
Even faster in almost all cases (if used appropriately).

mcgeezer · 06 February 2019, 19:48

Quote:

Originally Posted by ross

Heya Geezer, check the Ocean Loader v2 source for an interesting use case.

I've also used it for quarter pixel scroll bit distribution and in a sine scroll

And sure in various 020+ code i've written. I like those instructions.

Yes, all can be done with the usual, but really useful to gain registers and easy of mind.
Even faster in almost all cases (if used appropriately).

Thanks Meynaf and Ross...

When I go through optimisation I'll be sure to look for use cases!

I know there's a few times I've done bit checks like below which could be much improved.... (example)...

Code:

move.w (a0),d0
and.w #$8000,d0
beq.s .go
bra.s .nogo

meynaf · 06 February 2019, 20:05

Quote:

Originally Posted by mcgeezer

Thanks Meynaf and Ross...

When I go through optimisation I'll be sure to look for use cases!

I know there's a few times I've done bit checks like below which could be much improved.... (example)...

For your example, why not using the usual shortcut for the topmost bit :

Code:

 tst.w (a0)
 bpl.s .go
 bra.s .nogo

About bit checks : if you're operating on large bit arrays in memory, you can test/clear/set/reverse a bit in just one instruction...

ross · 06 February 2019, 20:26

Quote:

Originally Posted by mcgeezer

I know there's a few times I've done bit checks like below which could be much improved.... (example)...

Code:

move.w (a0),d0
and.w #$8000,d0
beq.s .go
bra.s .nogo

Well, in this case in fact they would not be adequate instructions, consider that there are those for a single bit (BTST, BCHG, BSET, BCLR), that among other things have the very useful property to set the flags with respect to the source (so a single bit BCHG can be used as a toggle and branch, or BSET/BCLR as a fork with respect to a previous 'atomic' condition).

Those for bit fields should be used for bit fields (with variable sub-index and lengths).
Think for example of the following instruction in a loop that change the components:

bfexts (offset.w,a0,d1.l*8){d2:d3},d0

and try to "emulate" with the regular..

Kalms · 06 February 2019, 20:28

The bit field instructions become even more interesting when the input parameters vary dynamically. That is, imagine that you need to extract a variable-length bit sequence from a varying bit offset (something you might do when reading variable-length data from a bit stream).
Granted, I tended to use them very rarely and instead find ways to accomplish the same thing with simpler operations and amortizing the costs over multiple steps instead.

grond · 07 February 2019, 14:59

BF-instructions are quite handy for some very specific things. Handling planar bitmap graphics, some math functions (mainly BFFFO) and compression and decompression come to my mind. Amiga probably looked at the 020 BFs and thought that they wanted that but found a full 32bit system too expensive. Hence, they invented the blitter...

Unfortunately the BF-instructions are very slow on all 68k processors (except on the AC68080 where most take 1 clock cycle and some 2 clock cycles).

oRBIT · 27 October 2023, 21:51

Is there any human understandable documentation about the bitfield instructions? The docs I've found just results in some kind of trial-and-error for me (and resulting mostly in errors).

Simple example:
Is there a way to copy a few bits from one Dx register to another one? Without using and/or? (Not sure if the BF-way, if there is one, is slower or faster than and and/or-solution).. Imagine this:
#%1100,d0
#%0011,d1
I would like to copy bits 2+3 to d1 so d1 will end up as #%1111

Thomas Richter · 27 October 2023, 23:21

Depends on what you mean by "copy". The bitfield instructions can only extract a sequence of bits from a register or memory array and place them right-aligned into another register, or insert a right-aligned amount of bits into a bit field in a register or in memory. They cannot copy from one field to another.

For that, you need two instructions: One extracting the field first, and a second to re-insert the bits into the destination.

For extracting bit fields, you have two possibilities: bfextu and bfexts. They differ only in the handling of the most significant bit of the field. bfextu takes the all the source bits, copies them right-aligned into the destination register (i.e. the least significant bit of the field goes to bit 0 of the target) and it sets all other bits in the destination to 0.

bfexts instead replicates the most significant bit of the field into all upper bits of the target register, i.e. it sign-extends the target to 32 bits.

To re-insert bits into a bitfield, you use bfins.

Bit fields are denoted by a start bit and a bit count. Unlike all other instructions, bits here count from left to right, i.e. the MSB is bit 0.

06 February 2019, 18:14	#1
mcgeezer Registered User Join Date: Oct 2017 Location: Sunderland, England Posts: 2,702	68020 Bit Field Instructions Hi All, I've been looking into the Bit Field 68020 instructions that are available on the A1200 and have been playing with them. As of yet I haven't really come across many use cases for them over and above what normal AND/OR/NOT/NEG/EOR instructions would do. It seems they just allow for finer grained control of the normal byte/word/longword sizes but apart from that do they offer anything else? The BFFFO instruction looks interesting for finding the Most Significant bit set... I could probably use that somewhere but nothing a couple of normal instructions wouldn't solve for me. Are the BF instructions particularly fast? Ta, Geezer

07 February 2019, 14:59	#8
grond Registered User Join Date: Jun 2015 Location: Germany Posts: 1,918	BF-instructions are quite handy for some very specific things. Handling planar bitmap graphics, some math functions (mainly BFFFO) and compression and decompression come to my mind. Amiga probably looked at the 020 BFs and thought that they wanted that but found a full 32bit system too expensive. Hence, they invented the blitter... Unfortunately the BF-instructions are very slow on all 68k processors (except on the AC68080 where most take 1 clock cycle and some 2 clock cycles). Last edited by grond; 07 February 2019 at 15:38.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
68020 bitfield instructions in winuae	rsn8887	support.WinUAE	14	22 November 2018 20:36
64-bit WinUAE doesn't work on 64-bit Windows XP	mark_k	support.WinUAE	6	24 December 2017 21:17
REQ: 17-Bit Artwork 2 (1988-04)(17-Bit Software)	Sea7	request.Demos	5	13 May 2011 01:07
8 bit to optimized 6 bit palette histogram improvements needed	NovaCoder	Coders. General	0	14 April 2011 02:13
Apollo 1220 - instructions and 68020 to 68030 upgrade	fc.studio	support.Hardware	11	10 January 2008 20:30

06 February 2019, 18:30	#2
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	BF instructions aren't fast. But they're single instruction doing the job of several. Thus they're often faster than the unwieldy bit manipulation they replace. Consider BFINS for example. For doing the same work you need to clear the target field, mask out the data to insert, shift it to the relevant position, and then OR it. This is not only longer in size, it will also require temporaries which you do not necessarily have available because out of data regs.

06 February 2019, 20:28	#7
Kalms Registered User Join Date: Nov 2006 Location: Stockholm, Sweden Posts: 237	The bit field instructions become even more interesting when the input parameters vary dynamically. That is, imagine that you need to extract a variable-length bit sequence from a varying bit offset (something you might do when reading variable-length data from a bit stream). Granted, I tended to use them very rarely and instead find ways to accomplish the same thing with simpler operations and amortizing the costs over multiple steps instead.

27 October 2023, 21:51	#9
oRBIT Zone Friend Join Date: Apr 2006 Location: Gothenburg/Sweden Age: 48 Posts: 339	Is there any human understandable documentation about the bitfield instructions? The docs I've found just results in some kind of trial-and-error for me (and resulting mostly in errors). Simple example: Is there a way to copy a few bits from one Dx register to another one? Without using and/or? (Not sure if the BF-way, if there is one, is slower or faster than and and/or-solution).. Imagine this: #%1100,d0 #%0011,d1 I would like to copy bits 2+3 to d1 so d1 will end up as #%1111

27 October 2023, 23:21	#10
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,215	Depends on what you mean by "copy". The bitfield instructions can only extract a sequence of bits from a register or memory array and place them right-aligned into another register, or insert a right-aligned amount of bits into a bit field in a register or in memory. They cannot copy from one field to another. For that, you need two instructions: One extracting the field first, and a second to re-insert the bits into the destination. For extracting bit fields, you have two possibilities: bfextu and bfexts. They differ only in the handling of the most significant bit of the field. bfextu takes the all the source bits, copies them right-aligned into the destination register (i.e. the least significant bit of the field goes to bit 0 of the target) and it sets all other bits in the destination to 0. bfexts instead replicates the most significant bit of the field into all upper bits of the target register, i.e. it sign-extends the target to 32 bits. To re-insert bits into a bitfield, you use bfins. Bit fields are denoted by a start bit and a bit count. Unlike all other instructions, bits here count from left to right, i.e. the MSB is bit 0.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)