[comp.arch] Bit operations on 68K

alexande@drivax.UUCP (01/22/87)

In article <112@lmi-angel.UUCP> wsr@lmi-angel.UUCP (Wolfgang Rupprecht) writes:
>Look at the BSET, BCLR, BTST (bit set, clear and test) instructions.
>If you do a:
>
>	BSET.L d0, somelocation
>
>with #31 in d0, you have set the MSB (byte 0!) of the long-word.

This is not completely correct.  There is no BSET.L instruction, only BSET.
It works on a destination that is either a 32-bit register, or a byte from
memory. Here is what the Motorola book says about BSET:

	If a data register is the destination, then the bit numbering is
	modulo 32, allowing bit manipulation on all bits in a data register.
	If a memory location is the destination, a byte is read
	from that location, the bit operation is performed using
	the bit number modulo 8, and the byte written back to
	the location with zero referring to the least-significant bit.

I didn't take the manual's word for it.  I tried it on a Motorola VME/10.

>This is *LOW* endian.

Yes, as far as bit numbering goes.  No, as far as byte numbering goes.
That's the inconsistency in the 68K architecture.
-- 
Mark Alexander	...{hplabs,ucbvax!decvax}!decwrl!pyramid!amdahl!drivax!alexande
"This then is my story.  I have reread it.  It has bits of marrow
sticking to it, and blood, and beautiful bright-green flies."  --Nabokov

jimomura@lsuc.UUCP (01/28/87)

In article <816@drivax.UUCP> alexande@drivax.UUCP (Mark Alexander) writes:

...

>This is not completely correct.  There is no BSET.L instruction, only BSET.
>It works on a destination that is either a 32-bit register, or a byte from
>memory. Here is what the Motorola book says about BSET:
>
>	If a data register is the destination, then the bit numbering is
>	modulo 32, allowing bit manipulation on all bits in a data register.
>	If a memory location is the destination, a byte is read
>	from that location, the bit operation is performed using
>	the bit number modulo 8, and the byte written back to
>	the location with zero referring to the least-significant bit.

>I didn't take the manual's word for it.  I tried it on a Motorola VME/10.


     In Kelly-Bootle and Fowler "68000, 68010, 68020 Primer", page 207 they
say that there is a 'bset.l' instruction.  Could it be that this is in the
68020?  (This isn't entirely academic for me since I'll have an '020 fairly
soon.)

Cheers! -- Jim O.
James Omura
2A King George's Drive
Toronto, Ontario (416) 652-3880

guy@gorodish.UUCP (01/30/87)

>     In Kelly-Bootle and Fowler "68000, 68010, 68020 Primer", page 207 they
>say that there is a 'bset.l' instruction.  Could it be that this is in the
>68020?

Nope - not unless they've hidden it really well.  Under BSET in my
"MC68020 32-Bit Microprocessor User's Manual", it describes the same
old BSET as the other 68K chips have.

terryl@tekcrl.UUCP (01/30/87)

In article <1539@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes:
+In article <816@drivax.UUCP> alexande@drivax.UUCP (Mark Alexander) writes:
+
+...
+
+>This is not completely correct.  There is no BSET.L instruction, only BSET.
+>It works on a destination that is either a 32-bit register, or a byte from
+>memory. Here is what the Motorola book says about BSET:
+>
+>	If a data register is the destination, then the bit numbering is
+>	modulo 32, allowing bit manipulation on all bits in a data register.
+>	If a memory location is the destination, a byte is read
+>	from that location, the bit operation is performed using
+>	the bit number modulo 8, and the byte written back to
+>	the location with zero referring to the least-significant bit.
+
+>I didn't take the manual's word for it.  I tried it on a Motorola VME/10.
+
+
+     In Kelly-Bootle and Fowler "68000, 68010, 68020 Primer", page 207 they
+say that there is a 'bset.l' instruction.  Could it be that this is in the
+68020?  (This isn't entirely academic for me since I'll have an '020 fairly
+soon.)

     Well, one could say the Kelly-Bootle book is both right and wrong. No,
the bset instruction on the 68020 is exactly the same as on the 68000 (and the
68010). The .l suffix is redundant, since one can only do long bset's (love
that word!!!) on a data register. My 68020 book(straight from the horse's mouth,
Motorola) has the exact same description of the bset instruction that Mr. Mark
Alexander has quoted.

gnu@hoptoad.UUCP (01/31/87)

The 68020 introduced a new set of 8 instructions that operate on bit
FIELDS rather than BITS.  The old BIT instructions were:

	BTST, BSET, BCLR, BCHG

and they numbered bits in little endian order, modulo 32 in registers
or modulo 8 on a memory address.  The little endian order was to avoid
confusing hardware engineers who knew that pin "D0" was the low order
pin; they could code "BTST #0" and get the same bit.  Unfortunately it
confused the programmers who didn't know anything about pins but they
sure knew that the rest of the machine was big endian.  These instructions
only operate on a single bit at a time.

In the 68020, these BIT FIELD instructions were added:

	BFTST, BFSET, BFCLR, BFCHG, BFINS, BFEXTS, BFEXTU, BFFFO

(the last four are insert, extract signed, extract unsigned, and find
first one).  These number bits big-endian and will accept any bit
number relative to a byte address and figure out where it really
belongs (e.g. you can ask for bit 1005 and it will find it.)  Finally
the bit order is the same as the byte order.  This makes arrays of bit
fields work just fine and is also nice for accessing bitmapped
displays.  These instructions take both a starting bit number and a
width -- they operate on 1 to 32 bits, and are smart about 32 bit
fields lying across multiple words of memory and such.

Probably the guy who mentined "BSET.L" just meant "BFSET".  Various other
instructions got extended with ".L" so this is an easy mistake to make.

Can we stop talking about this?
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   gnu@ingres.berkeley.edu
Love your country but never trust its government.
		     -- from a hand-painted road sign in central Pennsylvania