Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #161773
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: naked switches |
| Date | 2021-07-09 10:01 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <sc8von$8fo$1@dont-email.me> (permalink) |
| References | (1 earlier) <8735sp8cbm.fsf@nosuchdomain.example.com> <255c09e7-2365-4983-ad4d-3bfc83cf04e7n@googlegroups.com> <31342574-cb69-4ad6-8576-387dcf9caf70n@googlegroups.com> <sc76v8$8ah$1@dont-email.me> <sc7aeg$10u$1@dont-email.me> |
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
}
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
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, or trying to guess if it is safe to pass 3 as x, or
figuring out if the code is correct and efficient when you have the
cases in a different order.
Once you have __builtin_unreachable() or __assume(), you have a tool
that can be re-used in all sorts of other situations instead of just one
minor use-case with little impact. And this tool is useful for giving
the compiler more information, and for documenting the programmer's
intentions and assumptions.
You can also use a macro or inline function here, along the lines of :
#if DEBUGMODE
#define impossible() send_bug_report_to_programmer()
#else
#define impossible() __builtin_unreachable()
#endif
Now you have a combined debugging tool, documentation tool, and more
efficient code.
>
> If you mean putting it on the default: case of the switch, then that is
> not the same thing: if you know your switch index values are in the
> range 1 to 5 include, you may have case labels for 1, 3 and 5, and want
> default handling for 2 and 4, which /is/ reachable.
>
> You just don't want the unnecessary check for being within 1 to 5.
Put the check where you want the check to happen.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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