Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: naked switches Date: Fri, 16 Jul 2021 03:51:44 -0700 Organization: A noiseless patient Spider Lines: 62 Message-ID: <868s267cqn.fsf@linuxsc.com> References: <06a0049a-2d7d-40f0-899a-fb35c9a15d5fn@googlegroups.com> <8735sp8cbm.fsf@nosuchdomain.example.com> <255c09e7-2365-4983-ad4d-3bfc83cf04e7n@googlegroups.com> <31342574-cb69-4ad6-8576-387dcf9caf70n@googlegroups.com> <7e094b82-01be-4d7f-9793-4eeda725ca0en@googlegroups.com> <20210708103653.702@kylheku.com> <861r858eqz.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="09634a13793bf13421bcf3f217467df0"; logging-data="9110"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bF/ypoOZ4FOBSjC1jHhVnzvRaJ6kxPF4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:XfACfF7tRgjz1J7VYtLlDnCEvys= sha1:2Xh8mdThYIg7mjMySXdPPfj05kI= Xref: csiph.com comp.lang.c:161931 Tim Rentsch writes: > Kaz Kylheku <563-365-8930@kylheku.com> writes: > >> On 2021-07-08, Robert Finch 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).