Mnemonic suggestion please

After over 15 years of vpa use I want to put a new mnemonic for bit set, bit clear, bit change, and for bit test.

The old ones are CPU32 legacy - with extended source/destination addressing capabilities. So they are (let's do just bit set): bset[.size] ,[source1], (or sort of). For example:

bset.l #0,(address) will read the longword (32 bits) at address, test its least significant bit (bit 0 here), set it to 1 and write back to address (or bset.l- if test is not wanted).

Now I want to add a mnemonic doing the same but in big endian form; meaning bit 0 will be the most significant bit at (address).

I did "bebset" (big endian bit set) after a few seconds of thought, I had to implement it digging in 15+ years old code, took me hours to recall things so naming was not high on my radar at the moment.

I am not sure I like it, please come up with suggestions. I spent may be 5 minutes thinking and thought of nothing better so I wrote this. I don't like "bebset" because it is somewhat lengthy, and it does not feel nice enough I suppose... Then making it too similar (say something like "bits") will be a source of errors, confusing the big for the little endian one etc. May be bbset? Can look like a keybounce error....

Thought I'd sleep over it (going to bed now) as I'll probably live with it for a while once I adopt it.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

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

formatting link

Reply to
Dimiter_Popoff
Loading thread data ...

I was taught that to avoid typing errors no to variable names should differ by only one character. I'd think this would apply in spades to instruction mnemonics. So toss bbset. I would have no problem with bebset. You say that is too long, but we are talking about a difference of ONE CHARACTER! How about bsetbe? Or maybe make the size identifiers different? bset.lbe

It looks like the size is optional. What does it do if the size is not specified?

--

Rick C
Reply to
rickman

Hi Dimiter,

[H> After over 15 years of vpa use I want to put a new mnemonic

Is this just an efficiency hack to let the assembler do the lsb0 msb0 translation?

The M68k (a big Endian machine/CPU32) nominally uses "lsb0" numbering. But, Apple provided a set of bit-manipulation routines for MacOS named BitTst, BitSet and BitClr that number bits in msb0 style. E.g., syntactically: (, )

The NS32k dealt with bit numbering lsb0 in a small endian address space. So, TBIT, SBIT and CBIT (test, set, clear, respectively) expect: , [ is unimportant for this discussion] TBITx 0,foo would test the lsb of the object at "foo" whereas: TBITx 8,foo would test the lsb of foo+1.

[An offset could be 32b so "TBITx 2147483647,foo" is a valid opceration. Likewise, offsets could be negative so "TBITx -2147483648,foo" is also valid. Bit "-1" is the msb of the address preceding the specified. Of course, the real value lies in using something other than a constant for the offset -- or the base!]

I think you have to decide who your target audience is likely to be to gauge the effectiveness of any particular mnemonic.

Reply to
Don Y

I'm going to agree with Rick - this seems like the ideal use for a modifier. First, I see little object to a bit of extra length, a few extra characters typed matter not at all, but improved clarity can matter a lot. I also dislike the prefix approach, since it puts the cart before the horse, so to speak. So I'd go for bset as a base, with the endianess modifier either attached to that, or as a modifier to the length suffix, or a separate suffix. So one of the following:

bsetbe.l bset.lbe bset.l.be

The middle one could just as well be .lbe, and I'd leave the order for the third option unspecified.

An alternate approach, especially if this is only on a few instructions where then only thing that's impacted by the endianess is a constant, you might consider putting the modifier on that operand. IOW, something like:

bset.l be:#0,(address)

Reply to
Robert Wessel

Thanks for all the suggestions. I went for Rick's "bsetbe", feels just like what my "bebset" needed to sound OK to me.

I would not move this to the size designator, I want to keep that as strictly as possible to specifying just size (which it is not anyway but... .s means FP single precision, same size as .l but loads directly to an FP reg converting to the FP reg size, .d - dual, 64 bit in the case of power/PPC; .l specifies the same size but loading a .l into an FP reg loads the integer value converted to an FP). Being pushed this way by your posts I started thinking even of specifying size as a number - first I thought of the power of 2, then I went to the more generic and anyway better simply bit count, e.g. .32 is 32 bits, 47 is 47 bits etc. Not likely to implement that next few days though (although the vpa/linker do have a bitfield interface between them).

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

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

formatting link

Reply to
Dimiter_Popoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.