On 24.2.2017 г. 01:20, Dimiter_Popoff wrote:
> 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] <source0>,[source1],<destination> (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             http://www.tgi-sci.com
> ------------------------------------------------------
> http://www.flickr.com/photos/didi_tgi/
>
>
>


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             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Fri, 24 Feb 2017 01:20:19 +0200, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>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] <source0>,[source1],<destination> (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.


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)

Hi Dimiter,

[Hope things are improved with L and you're both faring well!]

On 2/23/2017 4:20 PM, Dimiter_Popoff wrote:
> 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] <source0>,[source1],<destination> (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).

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

> 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.

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:
    <operator>(<address>, <bitnumber>)

The NS32k dealt with bit numbering lsb0 in a small endian address space.
So, TBIT, SBIT and CBIT (test, set, clear, respectively) expect:
    <operator><size>  <offset>,<base>
[<size> 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 <base> 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.

On 2/23/2017 6:20 PM, Dimiter_Popoff wrote:
> 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] <source0>,[source1],<destination> (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.

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

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] <source0>,[source1],<destination> (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             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/