Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> Your extension [for extracting contiguous bits from a word] is not
>> commonly used, because it only exists in your tool. People who need
>> to do a lot of bit slicing and don't like masking and shifting (or
>> struct bit-fields) should not have trouble defining:
>>
>> #define BIT(x, top, bottom) \
>> (((x) >> (bottom)) & ((1llu << ((top) - (bottom) + 1)) - 1))
>>
>> Yes, the parenthesis you need for macros are ugly, but you only need to
>> get it right once, and now you can read your bit-fields.
>
> That's undefined when all the bits are wanted. (The left shift of 1llu
> could be equal to the width.) Maybe you wrote it for a compiler that
> documents an extension.
>
> I usually right shift -1llu by the width minus the number of bits
> wanted, but you can also just do two left shifts.

Another way, assuming the mask width desired is greater
than zero, is this

((1LLU << width-1) -1) *2 +1

which works great if 'width' is a compile-time constant.

Kaz Kylheku <563-365-8930@kylheku.com> writes:

> On 2021-07-08, Robert Finch <robfi680@gmail.com> wrote:
>
>>> You wrote that you "have been working on a C/C++ like compiler" - do you
>>> mean you have been /using/ such a compiler, or you have been /writing/
>>> such a compiler?
>>
>> I have been using it for simple demos, actually running the compiled
>> code sometime. It has been revamped for several different custom
>> processors, but is still a work in progress.
>>
>>> As I mentioned earlier, I think a "naked switch" like this is a terrible
>>> idea. It is not something I have seen on other compilers, and I've used
>>> quite a large number over the years for far smaller and slower devices
>>> than you are describing here.
>>
>> It is a bad idea in terms of allowing program crashes. But then
>> there are naked functions.
>>
>> CC64 supports a number of ?features? not found in standard C. But I
>> call it a ?C? like compiler because it can compile most C code
>> without changes. I used it to compile the standard C library.
>> Stills lots of bugs in the compiler though.
>>
>> One feature I like is the ability to manipulate bit slices.
>>
>> int a, b;
>>
>> a = b[10:1];
>>
>> Sets a equal to bits 1 to 10 of b. A bit slice can be distinguished
>> from an array index by the colon. Compiles painlessly directly to
>> field manipulation instructions and gets rid of code like: a = (b >>
>> 1) & 0x3ff;
>
> A macro can do this:
>
> a = BIT(b,10,1);
>
> and works everywhere. What you need is a typeof extension to make it
> work with different integer types while retaining efficiency, otherwise
> you're looking at making it assume 64 bit, or saddling it with a type
> name argument. [... and later _Generic is mentioned.]

No typeof is needed, nor _Generic, nor type name argument, nor
forcing a width of 64 bits, to define a macro that produces an
"and" of the appropriate size with a compile-time constant (as
evidenced by both gcc and clang with -O0). Just straight C90.

(I'll try to post a followup in a day or two, if necessary, to
show how. But I expect someone here will get it before then.)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> Your extension [for extracting contiguous bits from a word] is not
>>> commonly used, because it only exists in your tool. People who need
>>> to do a lot of bit slicing and don't like masking and shifting (or
>>> struct bit-fields) should not have trouble defining:
>>>
>>> #define BIT(x, top, bottom) \
>>> (((x) >> (bottom)) & ((1llu << ((top) - (bottom) + 1)) - 1))
>>>
>>> Yes, the parenthesis you need for macros are ugly, but you only need to
>>> get it right once, and now you can read your bit-fields.
>>
>> That's undefined when all the bits are wanted. (The left shift of 1llu
>> could be equal to the width.) Maybe you wrote it for a compiler that
>> documents an extension.
>>
>> I usually right shift -1llu by the width minus the number of bits
>> wanted, but you can also just do two left shifts.
>
>Another way, assuming the mask width desired is greater
>than zero, is this
>
> ((1LLU << width-1) -1) *2 +1
>
>which works great if 'width' is a compile-time constant.

In the C++ world, we use this:

namespace bit
{ template <class T> static inline T maskT(size_t bits)
{
if (bits >= sizeof(T)*8)
return -1;
else
return ~(static_cast<T>(-1)<<bits);
}

template<class T> static inline T extract(T input, size_t stop_bit, size_t start_bit)
{
input >>= start_bit;
input &= maskT<T>(stop_bit - start_bit + 1);
return input;
}

static inline int64_t extracts(uint64_t input, size_t stop_bit, size_t start_bit)
{
int64_t imm = extract(input, stop_bit, start_bit);
int shift = 63-stop_bit+start_bit;
imm <<= shift;
imm >>= shift;
return imm;
}

template<class T> static inline T insert(T original, uint64_t insert, size_t start_bit, size_t width_bits)
{
T mask = bit::maskT<T>(width_bits);
T newdata = mask & insert;
mask <<= start_bit;
newdata <<= start_bit;
original &= ~mask;
original |= newdata;
return original;
}
};

uint64_t registervalue, field;
int64_t field1;

field = bit::extract(registervalue, 15, 0); /* Extract <15:0> and zero-extend */
field1 = bit::extracts((int64_t)registervalue, 20, 16); /* Extract and sign-extend */

registervalue = bit::insert(registervalue, 0xff, 16, 4); /* Set bits<19:16> == 0xff */

On Sunday, July 11, 2021 at 10:07:09 AM UTC-4, Scott Lurndal wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
> >Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >
> >> David Brown <david...@hesbynett.no> writes:
> >>
> >>> Your extension [for extracting contiguous bits from a word] is not
> >>> commonly used, because it only exists in your tool. People who need
> >>> to do a lot of bit slicing and don't like masking and shifting (or
> >>> struct bit-fields) should not have trouble defining:
> >>>
> >>> #define BIT(x, top, bottom) \
> >>> (((x) >> (bottom)) & ((1llu << ((top) - (bottom) + 1)) - 1))
> >>>
> >>> Yes, the parenthesis you need for macros are ugly, but you only need to
> >>> get it right once, and now you can read your bit-fields.
> >>
> >> That's undefined when all the bits are wanted. (The left shift of 1llu
> >> could be equal to the width.) Maybe you wrote it for a compiler that
> >> documents an extension.
> >>
> >> I usually right shift -1llu by the width minus the number of bits
> >> wanted, but you can also just do two left shifts.
> >
> >Another way, assuming the mask width desired is greater
> >than zero, is this
> >
> > ((1LLU << width-1) -1) *2 +1
> >
> >which works great if 'width' is a compile-time constant.
> In the C++ world, we use this:
>
> namespace bit
> {
> template <class T> static inline T maskT(size_t bits)
> {
> if (bits >= sizeof(T)*8)
> return -1;
> else
> return ~(static_cast<T>(-1)<<bits);
> }
>
> template<class T> static inline T extract(T input, size_t stop_bit, size_t start_bit)
> {
> input >>= start_bit;
> input &= maskT<T>(stop_bit - start_bit + 1);
> return input;
> }
>
> static inline int64_t extracts(uint64_t input, size_t stop_bit, size_t start_bit)
> {
> int64_t imm = extract(input, stop_bit, start_bit);
> int shift = 63-stop_bit+start_bit;
> imm <<= shift;
> imm >>= shift;
> return imm;
> }
>
> template<class T> static inline T insert(T original, uint64_t insert, size_t start_bit, size_t width_bits)
> {
> T mask = bit::maskT<T>(width_bits);
> T newdata = mask & insert;
> mask <<= start_bit;
> newdata <<= start_bit;
> original &= ~mask;
> original |= newdata;
> return original;
> }
> };
>
> uint64_t registervalue, field;
> int64_t field1;
>
> field = bit::extract(registervalue, 15, 0); /* Extract <15:0> and zero-extend */
> field1 = bit::extracts((int64_t)registervalue, 20, 16); /* Extract and sign-extend */
>
> registervalue = bit::insert(registervalue, 0xff, 16, 4); /* Set bits<19:16> == 0xff */

I use the bit-slicing notation in part because the compiler I am using is not very sophisticated.
It cannot determine from a group of shifting and masking operations what bitfield instruction
to use. It does not have very sophisticated pattern matching for instruction sequences. Hence
to get efficient code from the compiler the bit-slicing syntax was added. It is as much to
support the compiler as it is for ease of use by the programmer.
x = a[15:10]
Compiles directly to an extract instruction something like: ext $t0,$a0,#10,#5 – a single
instruction. If shifting and masking macros were used, the compiler would likely generate all
the operations, turning what should be a single cycle op into a multi-cycle multi-instruction op.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Kaz Kylheku <563-365-8930@kylheku.com> writes:
>
>> On 2021-07-08, Robert Finch <robfi680@gmail.com> wrote:
>>
>>>> You wrote that you "have been working on a C/C++ like compiler" - do you
>>>> mean you have been /using/ such a compiler, or you have been /writing/
>>>> such a compiler?
>>>
>>> I have been using it for simple demos, actually running the compiled
>>> code sometime. It has been revamped for several different custom
>>> processors, but is still a work in progress.
>>>
>>>> As I mentioned earlier, I think a "naked switch" like this is a terrible
>>>> idea. It is not something I have seen on other compilers, and I've used
>>>> quite a large number over the years for far smaller and slower devices
>>>> than you are describing here.
>>>
>>> It is a bad idea in terms of allowing program crashes. But then
>>> there are naked functions.
>>>
>>> CC64 supports a number of ?features? not found in standard C. But I
>>> call it a ?C? like compiler because it can compile most C code
>>> without changes. I used it to compile the standard C library.
>>> Stills lots of bugs in the compiler though.
>>>
>>> One feature I like is the ability to manipulate bit slices.
>>>
>>> int a, b;
>>>
>>> a = b[10:1];
>>>
>>> Sets a equal to bits 1 to 10 of b. A bit slice can be distinguished
>>> from an array index by the colon. Compiles painlessly directly to
>>> field manipulation instructions and gets rid of code like: a = (b >>
>>> 1) & 0x3ff;
>>
>> A macro can do this:
>>
>> a = BIT(b,10,1);
>>
>> and works everywhere. What you need is a typeof extension to make it
>> work with different integer types while retaining efficiency, otherwise
>> you're looking at making it assume 64 bit, or saddling it with a type
>> name argument. [... and later _Generic is mentioned.]
>
> No typeof is needed, nor _Generic, nor type name argument, nor
> forcing a width of 64 bits, to define a macro that produces an
> "and" of the appropriate size with a compile-time constant (as
> evidenced by both gcc and clang with -O0). Just straight C90.
>
> (I'll try to post a followup in a day or two, if necessary, to
> show how. But I expect someone here will get it before then.)

To extract a "field" from expression 'e' of width 'w' at position 'p'

#define FIELD(e,w,p) ( (e)>>(p) & ( ( (0?(e):1) << (w)-1 ) -1) *2 +1 )

The idiom (0?(e):1) produces the value 1 in a type wide enough to mask
a field in the expression of 'e' (assuming the field does not include
the sign bit of a signed integer type).

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> Your extension [for extracting contiguous bits from a word] is not
>>>> commonly used, because it only exists in your tool. People who need
>>>> to do a lot of bit slicing and don't like masking and shifting (or
>>>> struct bit-fields) should not have trouble defining:
>>>>
>>>> #define BIT(x, top, bottom) \
>>>> (((x) >> (bottom)) & ((1llu << ((top) - (bottom) + 1)) - 1))
>>>>
>>>> Yes, the parenthesis you need for macros are ugly, but you only need to
>>>> get it right once, and now you can read your bit-fields.
>>>
>>> That's undefined when all the bits are wanted. (The left shift of 1llu
>>> could be equal to the width.) Maybe you wrote it for a compiler that
>>> documents an extension.
>>>
>>> I usually right shift -1llu by the width minus the number of bits
>>> wanted, but you can also just do two left shifts.
>>
>> Another way, assuming the mask width desired is greater
>> than zero, is this
>>
>> ((1LLU << width-1) -1) *2 +1
>>
>> which works great if 'width' is a compile-time constant.
>
> In the C++ world, we use this:
>
> namespace bit
> {
> template <class T> static inline T maskT(size_t bits)
> {
> if (bits >= sizeof(T)*8)
> return -1;
> else
> return ~(static_cast<T>(-1)<<bits);
> }
>
> template<class T> static inline T extract(T input, size_t stop_bit, size_t start_bit)
> {
> input >>= start_bit;
> input &= maskT<T>(stop_bit - start_bit + 1);
> return input;
> }
>
> static inline int64_t extracts(uint64_t input, size_t stop_bit, size_t start_bit)
> {
> int64_t imm = extract(input, stop_bit, start_bit);
> int shift = 63-stop_bit+start_bit;
> imm <<= shift;
> imm >>= shift;
> return imm;
> }
>
> template<class T> static inline T insert(T original, uint64_t insert, size_t start_bit, size_t width_bits)
> {
> T mask = bit::maskT<T>(width_bits);
> T newdata = mask & insert;
> mask <<= start_bit;
> newdata <<= start_bit;
> original &= ~mask;
> original |= newdata;
> return original;
> }
> };
>
> uint64_t registervalue, field;
> int64_t field1;
>
> field = bit::extract(registervalue, 15, 0); /* Extract <15:0> and zero-extend */
> field1 = bit::extracts((int64_t)registervalue, 20, 16); /* Extract and sign-extend */
>
> registervalue = bit::insert(registervalue, 0xff, 16, 4); /* Set bits<19:16> == 0xff */

Ahh, rather like using an elephant gun to shoot a field mouse.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>

>>
>> uint64_t registervalue, field;
>> int64_t field1;
>>
>> field = bit::extract(registervalue, 15, 0); /* Extract <15:0> and zero-extend */
>> field1 = bit::extracts((int64_t)registervalue, 20, 16); /* Extract and sign-extend */
>>
>> registervalue = bit::insert(registervalue, 0xff, 16, 4); /* Set bits<19:16> == 0xff */
>
>Ahh, rather like using an elephant gun to shoot a field mouse.

The compiler generates optimal code[*]. The source is descriptive
and far more readable (and less subject to error) than manual bit
shifting/masking.

I don't see a problem.

[*] As inline functions, they're translated with the rest of the function.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>
>>>
>>> uint64_t registervalue, field;
>>> int64_t field1;
>>>
>>> field = bit::extract(registervalue, 15, 0); /* Extract <15:0> and zero-extend */
>>> field1 = bit::extracts((int64_t)registervalue, 20, 16); /* Extract and sign-extend */
>>>
>>> registervalue = bit::insert(registervalue, 0xff, 16, 4); /* Set bits<19:16> == 0xff */
>>
>> Ahh, rather like using an elephant gun to shoot a field mouse.
>
> The compiler generates optimal code[*].

Perhaps some compilers do, but it's more likely that fast code
will result from a purely functional expression that computes
the desired result directly. Not that code quality had anything to
do with my earlier comments.

> The source is descriptive and far more readable (and less subject
> to error) than manual bit shifting/masking.

That's funny. Reminds me of things I used to hear 50 years ago when
people would say assembly language is easier to understand than the
high-level languages of the day.

> I don't see a problem.

To me it looks like you're confusing length and verbosity with
comprehensibility.

I have modified my compiler to recognize when switches are one-hot powers of two and it uses the BBS instruction if available. No special syntax required for switches.
I added syntax to enums however to allow using an enum to define one-hot values.

enum (2*) { a, b, c, d, e};

Assigns the values 0,1,2,4,8 to a,b,c,d,e respectively.
The (2*) is the exponential increment spec. (3*, 4*, etc is also possible).

enums in my compiler also allow the increment to vary

enum(3) { a, b, c, d, e}; for instance increments the enum value by 3 for each symbol.

Am 08.07.2021 um 01:39 schrieb Robert Finch:
> I have been working on a C/C++ like compiler. One feature supported in the compiler is naked switches. A naked switch omits the range checking code that is normally associated with the switch statement. Omitting this code can improve performance at the risk of a crash if invalid cases are processed. I am wondering if there is a similar option in other C compilers? Or would this just be an automatic optimization at high levels?
>
> Normal Switch:
>
> ; switch(x) {
> ldo $t0,64[$fp]
> sge $t1,$t0,#1 ; x varies between 1 and 12
> sle $t2,$t0,#12
> and $t1,$t1,$t2
> beq $t1,TestSwitch_89
> sub $t0,$t0,#1
> sll $t0,$t0,#4
> ldo $t0,TestSwitch_116[$t0]
> jmp $t0
>
> Naked Switch
> ; switch(x; naked) {
> ldo $t0,64[$fp]
> sub $t0,$t0,#1
> sll $t0,$t0,#4
> ldo $t0,TestSwitch_144[$t0]
> jmp $t0
>

Don't make such strange C-extensions.
Help the optimizer with sth. like __assume in MSVC++.