Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #161777

Re: naked switches

Show all headers | View raw

On 09/07/2021 09:01, David Brown wrote:
> On 08/07/2021 18:51, Bart wrote:
>> On 08/07/2021 16:52, David Brown wrote:
>>> On 08/07/2021 15:58, Robert Finch wrote:
>>>> On Thursday, July 8, 2021 at 6:25:26 AM UTC-4, Malcolm McLean wrote:
>>>>> On Thursday, 8 July 2021 at 09:00:40 UTC+1, Keith Thompson wrote:
>>>>>> Robert Finch <robf...@gmail.com> writes:
>>>>>>> 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?
>>>
>>>
>>>>
>>>> That is basically how it is working. There is still a default
>>>> statement for unimplemented values between the min and max. The table
>>>> entry may as well point somewhere useful. There were two goals with
>>>> this, a) a performance optimization and b) code size optimization. I
>>>> am dealing with small roms in an FPGA so bytes count. The processor
>>>> is also rather slow <40MHz.
>>>>
>>>>
>>>
>>> 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?
>>>
>>> As I mentioned earlier, I think a "naked switch" like this is a terrible
>>> idea.
>>
>> I've considered having something like that. I'd have called it 'uswitch'.
>>
>> It was never done because:
>>
>> * The range check wasn't really much of an overhead on x64 (the indexed
>> jump is)
>>
>> * I could never be sure that the switch index would always be inside the
>> range of the minimum and maximum values of the switch cases
>>
>> * It seemed a bit naff
>>
>> But I wouldn't find it objectionable if it helps out on a slower
>> processor. After all array indices are not checked either as I said in
>> my last post.
>>
> 
> The critical difference is the semantics of the C language - array
> indexes are not checked automatically in C, the range in a switch /is/
> checked because a switch is defined in the language to do nothing if the
> value does not match any of the cases.
> 
> If you are making a different language, you can pick different rules.
> 
> I've seen many compilers that have odd non-standard behaviour "to make C
> simpler" or "to get better code on this little processor".  IME, it is
> /always/ a mistake.  I've seen "const" used to mean "this is in flash",
> changes to the integer promotion rules, and other "improvements".  The
> result is always mixups and misunderstandings, incompatibilities and
> people writing poorer code that is harder to follow, less portable /and/
> gives less efficient results on the smart-arse toolchain.
> 
> If you are making a C compiler, make a /C/ compiler.  If you want to get
> better results, make your optimisation smarter.  If you want to give
> users something extra to squeeze a little more out of the target, give
> them something /useful/, /clear/, and /optional/.  The answer here is
> __builtin_unreachable(), or __assume if you prefer MSVC's solution.
> 
>>    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.
>>>
>>> The way you handle this with gcc has already been covered - you use
>>> __builtin_unreachable() to tell the compiler how to optimise for "this
>>> can't happen" cases.  clang supports __builtin_unreachable() too, and
>>> MSVC has "__assume(false)" that has the same effect.
>>>
>>
>> How would that work in that case? There doesn't appear to be a bit of
>> code to hang that onto, unless you specifically create an empty block
>> for the purpose, guarded by the same sort of range check you want to avoid.
> 
> The normal situation would be :
> 
> 	switch (x) {
> 		case 1 : handle1(); break;
> 		case 2 : handle2(); break;
> 		case 4 : handle4(); break;
> 		default : __builtin_unreachable();	// gcc
> 		default : __assume(0);			// msvc
> 	}

As I said, you may want to reserve default: for x==3.

> 
> 
> 
> If you want to say x == 3 is a "do nothing" situation, but you want to
> tell the compiler it doesn't need to check for x < 1 or x > 4, then you
> do so simply and clearly:
> 
> 	if ((x < 1) || (x > 4)) __builtin_unreachable();	// gcc
> 	__assume((x >= 1) && (x <= 4));				// msvc

This is really ugly and may involve some compilers (eg. mine) adding all 
those extra checks.

But also, how would this work in practice? Case values are usually 
enums, you'd need to go and find which are the minimum and maximum 
enums, and hope they don't change.

However, if you know that x is always going to have a value of one of 
those enums, and all enum cases are checked (no gaps), then uswitch will 
be safe.

Gaps could be allowed, except for the danger that the gaps could be at 
either end (so for enums of 1,2,3,4,5, it may omit 1 and/or 5, but it 
will then assume 2-5 or 1-4).

> 
> 	switch (x) {
> 		case 1 : handle1(); break;
> 		case 2 : handle2(); break;
> 		case 4 : handle4(); break;
> 	}
> 
> 
> Compare that to someone looking at "uswitch" and wondering what that
> might possibly mean,


Unchecked or unsafe. But no worse than scratching their head over 
__builtin_unreachable and wondering what it has to do with that switch 
further down the function.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

naked switches Robert Finch <robfi680@gmail.com> - 2021-07-07 16:39 -0700
  Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 01:26 +0100
  Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 01:57 +0000
    Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-08 09:16 +0200
  Re: naked switches Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-08 01:00 -0700
    Re: naked switches Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-08 03:25 -0700
      Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 06:58 -0700
        Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 15:52 +0100
        Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-08 17:52 +0200
          Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 17:51 +0100
            Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:01 +0200
              Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 11:09 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 13:14 +0200
                Re: naked switches Manfred <noname@add.invalid> - 2021-07-09 15:35 +0200
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 16:51 +0200
                Re: naked switches Manfred <noname@add.invalid> - 2021-07-09 18:23 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 16:07 +0100
                Re: naked switches Manfred <noname@add.invalid> - 2021-07-09 18:41 +0200
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 11:02 +0200
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 19:20 +0200
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-09 10:46 -0700
                Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-09 19:56 +0000
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 22:01 +0100
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-09 15:07 -0700
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 23:30 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 12:17 +0200
          Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 10:18 -0700
            Re: naked switches Bart <bc@freeuk.com> - 2021-07-08 18:43 +0100
              Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 15:32 -0700
            Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 17:47 +0000
              Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-08 15:45 -0700
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:27 +0200
                Re: naked switches Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-09 11:13 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 13:30 +0200
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:39 -0700
                Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-11 14:06 +0000
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-07-11 08:01 -0700
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-16 03:53 -0700
                Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-16 14:47 +0000
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 06:09 -0700
                Re: naked switches Robert Finch <robfi680@gmail.com> - 2021-09-30 07:03 -0700
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-09 13:44 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 13:28 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-10 13:04 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 15:39 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-10 15:08 +0100
                Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-10 17:34 +0200
                Re: naked switches Bart <bc@freeuk.com> - 2021-07-10 17:47 +0100
              Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-11 00:57 -0700
                Re: naked switches Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-16 03:51 -0700
        Re: naked switches Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-08 11:40 -0700
          Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:38 +0200
  Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 17:33 +0000
    Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-08 17:47 +0000
      Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-08 17:58 +0000
        Re: naked switches scott@slp53.sl.home (Scott Lurndal) - 2021-07-08 19:13 +0000
          Re: naked switches Kaz Kylheku <563-365-8930@kylheku.com> - 2021-07-09 02:30 +0000
        Re: naked switches David Brown <david.brown@hesbynett.no> - 2021-07-09 10:41 +0200
  Re: naked switches Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-30 18:04 +0200

csiph-web