Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #105743 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-03-10 11:57 -0800 |
| Last post | 2017-03-15 13:39 -0700 |
| Articles | 20 on this page of 107 — 23 participants |
Back to article view | Back to comp.lang.c
va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 11:57 -0800
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 12:04 -0800
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-10 12:32 -0800
Re: va_start without the first argument? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-10 15:51 -0500
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 14:36 -0800
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 14:53 -0800
Re: va_start without the first argument? Robert Wessel <robertwessel2@yahoo.com> - 2017-03-10 17:14 -0600
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 15:37 -0800
Re: va_start without the first argument? Robert Wessel <robertwessel2@yahoo.com> - 2017-03-10 23:12 -0600
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 10:29 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 11:31 -0700
Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-13 18:40 +0000
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 12:31 -0700
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 19:53 +0100
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-11 19:05 +0000
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-11 11:56 -0800
Re: va_start without the first argument? antispam@math.uni.wroc.pl - 2017-03-12 05:41 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 13:52 +0100
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-12 14:40 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 18:13 +0100
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-12 18:04 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 21:04 +0100
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-12 21:02 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-12 22:40 +0100
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-12 15:51 -0700
Re: va_start without the first argument? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-12 16:52 -0700
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-13 00:56 +0100
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-13 09:17 -0700
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 17:54 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-13 22:12 +0100
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 22:48 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 13:46 +0100
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-14 13:37 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 15:24 +0100
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 08:25 -0700
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 17:02 +0100
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 09:45 -0700
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 09:15 -0700
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 10:02 -0700
Re: va_start without the first argument? jt@toerring.de (Jens Thoms Toerring) - 2017-03-14 20:32 +0000
Re: va_start without the first argument? raltbos@xs4all.nl (Richard Bos) - 2017-03-14 07:44 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 13:38 +0100
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 08:57 -0700
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-13 11:21 -0700
Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-13 18:33 +0000
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-13 22:08 +0100
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-13 15:23 -0700
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 13:58 +0100
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 09:18 -0700
Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 16:52 +0000
Re: va_start without the first argument? Keith Thompson <kst-u@mib.org> - 2017-03-14 11:34 -0700
Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 18:54 +0000
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 13:30 -0700
Re: va_start without the first argument? Ike Naar <ike@iceland.freeshell.org> - 2017-03-15 21:55 +0000
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-15 15:16 -0700
Re: va_start without the first argument? Philip Lantz <prl@canterey.us> - 2017-03-23 21:04 -0700
Re: va_start without the first argument? David Brown <david.brown@hesbynett.no> - 2017-03-14 21:48 +0100
Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 14:01 +0000
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-14 07:42 -0700
Re: va_start without the first argument? scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 12:38 +0000
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-13 01:11 +0100
Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-13 15:43 +1300
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 10:36 +0000
Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-14 07:33 +1300
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 19:00 +0000
Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-14 08:05 +1300
Re: va_start without the first argument? BartC <bc@freeuk.com> - 2017-03-13 23:10 +0000
Re: va_start without the first argument? Ian Collins <ian-news@hotmail.com> - 2017-03-14 17:38 +1300
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-14 05:48 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 12:12 -0700
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-12 19:39 +0100
Re: va_start without the first argument? jt@toerring.de (Jens Thoms Toerring) - 2017-03-10 20:49 +0000
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-10 14:41 -0800
Re: va_start without the first argument? John Bode <jfbode1029@gmail.com> - 2017-03-10 16:05 -0800
Re: va_start without the first argument? jacob navia <jacob@jacob.remcomp.fr> - 2017-03-11 21:47 +0100
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-11 13:07 -0800
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 22:24 +0100
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 05:44 -0700
Re: va_start without the first argument? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-13 08:59 -0400
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 06:17 -0700
Re: va_start without the first argument? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-13 13:27 -0400
Re: va_start without the first argument? Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-13 13:30 -0400
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 11:00 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 10:34 -0700
Re: va_start without the first argument? antispam@math.uni.wroc.pl - 2017-03-12 06:00 +0000
Re: va_start without the first argument? gordonb.gas5o@burditt.org (Gordon Burditt) - 2017-03-17 09:46 -0500
Re: va_start without the first argument? supercat@casperkitty.com - 2017-03-17 09:07 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 05:39 -0700
Re: va_start without the first argument? John Bode <jfbode1029@gmail.com> - 2017-03-13 11:40 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 12:01 -0700
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-13 23:17 +0100
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 16:15 -0700
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 00:26 +0100
Re: va_start without the first argument? kikiins@gmail.com - 2017-03-13 16:51 -0700
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 01:12 +0100
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 18:24 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-13 18:57 -0700
Re: va_start without the first argument? raltbos@xs4all.nl (Richard Bos) - 2017-03-14 07:59 +0000
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-14 06:45 -0700
Re: va_start without the first argument? Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 18:20 -0500
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 00:31 +0100
Re: va_start without the first argument? raltbos@xs4all.nl (Richard Bos) - 2017-03-13 16:51 +0000
Re: va_start without the first argument? jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-11 19:29 +0100
Re: va_start without the first argument? Siri Cruise <chine.bleu@yahoo.com> - 2017-03-11 12:12 -0800
Re: va_start without the first argument? luser droog <luser.droog@gmail.com> - 2017-03-13 05:37 -0700
Re: va_start without the first argument? luser droog <luser.droog@gmail.com> - 2017-03-15 11:45 -0700
Re: va_start without the first argument? Thiago Adams <thiago.adams@gmail.com> - 2017-03-15 13:39 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-03-14 07:44 +0000 |
| Message-ID | <58c79f35.356562@news.xs4all.nl> |
| In reply to | #105937 |
David Brown <david.brown@hesbynett.no> wrote: > On 13/03/17 18:54, BartC wrote: > > > (Just yesterday, I had to need to wait a second or so before proceeding > > in a bit of code. I couldn't just use a loop counting to a billion, as > > this was gcc on Linux (so no alternatives), and it would just disregard > > the loop. Things such as sleep() were not practical, I ended up using > > getchar() then waiting for someone to press Enter. > > > > It gets silly when you have to fight the compiler to stop it ignoring > > your intentions.) > > <http://en.cppreference.com/w/c/language/volatile> Never mind volatile, which is a, ahem, non-stable resource - whatever happened to <time.h>!? Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 13:38 +0100 |
| Message-ID | <oa8o2a$hkd$1@dont-email.me> |
| In reply to | #105994 |
On 14/03/17 08:44, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 13/03/17 18:54, BartC wrote: >> >>> (Just yesterday, I had to need to wait a second or so before proceeding >>> in a bit of code. I couldn't just use a loop counting to a billion, as >>> this was gcc on Linux (so no alternatives), and it would just disregard >>> the loop. Things such as sleep() were not practical, I ended up using >>> getchar() then waiting for someone to press Enter. >>> >>> It gets silly when you have to fight the compiler to stop it ignoring >>> your intentions.) >> >> <http://en.cppreference.com/w/c/language/volatile> > > Never mind volatile, which is a, ahem, non-stable resource - whatever > happened to <time.h>!? > Apparently things like "sleep" were not practical. I don't know what the problem might have been, but I assume it also applies to the functions in <time.h> and and OS-specific functions for timing.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-14 08:57 -0700 |
| Message-ID | <lnpohjkg02.fsf@kst-u.example.com> |
| In reply to | #105994 |
raltbos@xs4all.nl (Richard Bos) writes:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 13/03/17 18:54, BartC wrote:
>> > (Just yesterday, I had to need to wait a second or so before proceeding
>> > in a bit of code. I couldn't just use a loop counting to a billion, as
>> > this was gcc on Linux (so no alternatives), and it would just disregard
>> > the loop. Things such as sleep() were not practical, I ended up using
>> > getchar() then waiting for someone to press Enter.
>> >
>> > It gets silly when you have to fight the compiler to stop it ignoring
>> > your intentions.)
>>
>> <http://en.cppreference.com/w/c/language/volatile>
>
> Never mind volatile, which is a, ahem, non-stable resource - whatever
> happened to <time.h>!?
<time.h> has no sleep function. The POSIX sleep() function is declared
in <unistd.h>. (I have no idea why sleep() would not be practical for
BartC's requirements.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-13 11:21 -0700 |
| Message-ID | <lnd1dlf364.fsf@kst-u.example.com> |
| In reply to | #105913 |
supercat@casperkitty.com writes:
[...]
> The main compiler I use supports an extension which I think debuted in gcc,
> which doesn't actually execute anything but returns 1 if an expression can
> be evaluated as a compile-time constant and zero if it cannot. This makes
> it practical to have a macro which does an action one of two ways depending
> upon which is more efficient. Being able to express such concepts more
> elegantly than via preprocessor macros would be nice, but the macros do work
> and the code is readable on the incocation side at least.
[...]
What compiler? What is the name of the extension?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-13 18:33 +0000 |
| Message-ID | <zBBxA.61776$Bp6.33909@fx36.iad> |
| In reply to | #105925 |
Keith Thompson <kst-u@mib.org> writes:
>supercat@casperkitty.com writes:
>[...]
>> The main compiler I use supports an extension which I think debuted in gcc,
>> which doesn't actually execute anything but returns 1 if an expression can
>> be evaluated as a compile-time constant and zero if it cannot. This makes
>> it practical to have a macro which does an action one of two ways depending
>> upon which is more efficient. Being able to express such concepts more
>> elegantly than via preprocessor macros would be nice, but the macros do work
>> and the code is readable on the incocation side at least.
>[...]
>
>What compiler? What is the name of the extension?
perhaps the cat is referring to this feature of the Gnu Compiler Collection:
-- Built-in Function: int __builtin_constant_p (EXP)
You can use the built-in function '__builtin_constant_p' to
determine if a value is known to be constant at compile time and
hence that GCC can perform constant-folding on expressions
involving that value. The argument of the function is the value to
test. The function returns the integer 1 if the argument is known
to be a compile-time constant and 0 if it is not known to be a
compile-time constant. A return of 0 does not indicate that the
value is _not_ a constant, but merely that GCC cannot prove it is a
constant with the specified value of the '-O' option.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-13 22:08 +0100 |
| Message-ID | <oa71j7$rrb$1@dont-email.me> |
| In reply to | #105927 |
On 13/03/17 19:33, Scott Lurndal wrote: > Keith Thompson <kst-u@mib.org> writes: >> supercat@casperkitty.com writes: >> [...] >>> The main compiler I use supports an extension which I think debuted in gcc, >>> which doesn't actually execute anything but returns 1 if an expression can >>> be evaluated as a compile-time constant and zero if it cannot. This makes >>> it practical to have a macro which does an action one of two ways depending >>> upon which is more efficient. Being able to express such concepts more >>> elegantly than via preprocessor macros would be nice, but the macros do work >>> and the code is readable on the incocation side at least. >> [...] >> >> What compiler? What is the name of the extension? > > perhaps the cat is referring to this feature of the Gnu Compiler Collection: > > -- Built-in Function: int __builtin_constant_p (EXP) > You can use the built-in function '__builtin_constant_p' to > determine if a value is known to be constant at compile time and > hence that GCC can perform constant-folding on expressions > involving that value. The argument of the function is the value to > test. The function returns the integer 1 if the argument is known > to be a compile-time constant and 0 if it is not known to be a > compile-time constant. A return of 0 does not indicate that the > value is _not_ a constant, but merely that GCC cannot prove it is a > constant with the specified value of the '-O' option. > I assume that is what he is talking about. I don't know why he thinks it is a macro or handled by the preprocessor, however. It can be a useful extension sometimes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-13 15:23 -0700 |
| Message-ID | <7dc37a16-7135-4e50-accf-591c923908c4@googlegroups.com> |
| In reply to | #105936 |
On Monday, March 13, 2017 at 4:08:48 PM UTC-5, David Brown wrote: > I assume that is what he is talking about. I don't know why he thinks > it is a macro or handled by the preprocessor, however. It can be a > useful extension sometimes. The __builtin_constant_p intrinsic isn't a macro, of course, but at least on the Keil-ARM compiler it is primarily useful *within* function-like macros. If numbering I/O ports 0-255 on some system would mean that turning on a particular I/O port bit b would require storing (1u<<(b & 31)) to an address (0x12340000 + (b & 0xE0) << 1), then when b is constant such a task would be most effectively handled by simply doing a store, but when it's not constant having the compiler generate a function call would be faster than having it generate the shifting and masking code call-side. Using __builtin_constant_p makes it possible to generate direct stores when using constant port numbers, and function calls when using port numbers that are not constants. Some quick tests with gcc suggest that its __builtin_constant_p doesn't always imply that something is actually a constant in the usual sense, which allows the directive to be used on parameters of functions that may be inline. On the other hand, Keil's behavior abides by the principle that const-ness is a static property of an expression while gcc only tests whether something seems to be constant at a particular spot in the code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 13:58 +0100 |
| Message-ID | <oa8p90$n6q$1@dont-email.me> |
| In reply to | #105950 |
On 13/03/17 23:23, supercat@casperkitty.com wrote: > On Monday, March 13, 2017 at 4:08:48 PM UTC-5, David Brown wrote: >> I assume that is what he is talking about. I don't know why he thinks >> it is a macro or handled by the preprocessor, however. It can be a >> useful extension sometimes. > > The __builtin_constant_p intrinsic isn't a macro, of course, but at least on > the Keil-ARM compiler it is primarily useful *within* function-like macros. That happens to be true in my code too. It will also be true in code designed to be portable - you might have: #ifdef __GNUC__ #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p(x) #else #define IS_COMPILE_TIME_CONSTANT(x) (0) #endif But code that uses such builtins a lot, and relies on gcc compatible extensions, could use it freely in code. It is certainly not reliant on macros or the pre-processor in any way. > If numbering I/O ports 0-255 on some system would mean that turning on a > particular I/O port bit b would require storing (1u<<(b & 31)) to an address > (0x12340000 + (b & 0xE0) << 1), then when b is constant such a task would be > most effectively handled by simply doing a store, but when it's not constant > having the compiler generate a function call would be faster than having it > generate the shifting and masking code call-side. Using __builtin_constant_p > makes it possible to generate direct stores when using constant port numbers, > and function calls when using port numbers that are not constants. > Yes, that's the kind of thing that __builtin_constant_p is useful for. > Some quick tests with gcc suggest that its __builtin_constant_p doesn't always > imply that something is actually a constant in the usual sense, which allows > the directive to be used on parameters of functions that may be inline. From the manual: "You can use the built-in function __builtin_constant_p to determine if a value is known to be constant at compile time and hence that GCC can perform constant-folding on expressions involving that value" Here, "constant" is an adjective - it is not related to the specific term in the C standards. It just means that the compiler can figure out the value when compiling the code. > On > the other hand, Keil's behavior abides by the principle that const-ness is a > static property of an expression while gcc only tests whether something seems > to be constant at a particular spot in the code. > I haven't looked at Keil's manual to see what it says for it's extension here, but it seems to be a limited subset of the functionality of gcc's extension.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-14 09:18 -0700 |
| Message-ID | <lnh92vkf22.fsf@kst-u.example.com> |
| In reply to | #106010 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> #ifdef __GNUC__
> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p(x)
I'd parenthesize this:
#define IS_COMPILE_TIME_CONSTANT(x) (__builtin_constant_p(x))
I'm not sure whether it can make a difference, but it's easier to add
the parentheses than to prove that they're not needed.
> #else
> #define IS_COMPILE_TIME_CONSTANT(x) (0)
I wouldn't bother with the parentheses here; there are no precedence
issues with a single constant.
> #endif
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-14 16:52 +0000 |
| Message-ID | <UcVxA.62280$Bp6.51791@fx36.iad> |
| In reply to | #106049 |
Keith Thompson <kst-u@mib.org> writes: >David Brown <david.brown@hesbynett.no> writes: >[...] >> #ifdef __GNUC__ >> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p(x) > >I'd parenthesize this: > >#define IS_COMPILE_TIME_CONSTANT(x) (__builtin_constant_p(x)) > >I'm not sure whether it can make a difference, but it's easier to add >the parentheses than to prove that they're not needed. I think if you are adding additional parenthesis, I'd be tempted to write it: #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p((x))
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-14 11:34 -0700 |
| Message-ID | <ln4lyvk8ql.fsf@kst-u.example.com> |
| In reply to | #106055 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>>[...]
>>> #ifdef __GNUC__
>>> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p(x)
>>
>>I'd parenthesize this:
>>
>>#define IS_COMPILE_TIME_CONSTANT(x) (__builtin_constant_p(x))
>>
>>I'm not sure whether it can make a difference, but it's easier to add
>>the parentheses than to prove that they're not needed.
>
> I think if you are adding additional parenthesis, I'd be tempted to write it:
>
> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p((x))
Why? In both David's version and mine, the reference to x in
the macro definition is already parenthesized. The fact that the
parentheses are for a function call (or macro invocation?) rather
than grouping doesn't matter as far as operator precedence is
concerned. Similarly, if a macro definition uses an argument as
an array index, it's already surrounded by [] so it doesn't need
additional ().
In general, for a macro whose arguments are expressions and
that expands to an expression, each reference to each argument
should be parenthesized, and the entire definition should also
be parenthesized. Thus:
#define ADD(x, y) ((x) + (y))
But:
#define INDEX(a, i) ((a)[i]) // no need for additional parentheses on i
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-14 18:54 +0000 |
| Message-ID | <%%WxA.32384$Hf3.29484@fx37.iad> |
| In reply to | #106067 |
Keith Thompson <kst-u@mib.org> writes: >scott@slp53.sl.home (Scott Lurndal) writes: >> Keith Thompson <kst-u@mib.org> writes: >>>David Brown <david.brown@hesbynett.no> writes: >>>[...] >>>> #ifdef __GNUC__ >>>> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p(x) >>> >>>I'd parenthesize this: >>> >>>#define IS_COMPILE_TIME_CONSTANT(x) (__builtin_constant_p(x)) >>> >>>I'm not sure whether it can make a difference, but it's easier to add >>>the parentheses than to prove that they're not needed. >> >> I think if you are adding additional parenthesis, I'd be tempted to write it: >> >> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p((x)) > >Why? In both David's version and mine, the reference to x in >the macro definition is already parenthesized. The fact that the >parentheses are for a function call (or macro invocation?) rather >than grouping doesn't matter as far as operator precedence is >concerned. Similarly, if a macro definition uses an argument as >an array index, it's already surrounded by [] so it doesn't need >additional (). I had considered passing the expression "z++,y" as 'x' to the macro, but that can't be done without first enclosing it in parens, so yes, the extra parens around 'x' aren't necessary.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-14 13:30 -0700 |
| Message-ID | <931c4a06-8f14-4c60-8a41-f34b36d07563@googlegroups.com> |
| In reply to | #106067 |
On Tuesday, March 14, 2017 at 1:34:55 PM UTC-5, Keith Thompson wrote:
> Why? In both David's version and mine, the reference to x in
> the macro definition is already parenthesized. The fact that the
> parentheses are for a function call (or macro invocation?) rather
> than grouping doesn't matter as far as operator precedence is
> concerned. Similarly, if a macro definition uses an argument as
> an array index, it's already surrounded by [] so it doesn't need
> additional ().
If bar is a function-like macro which is supposed to accept a single value,
there are corner cases in which
#define foo(x) bar(x)
may fail but adding extra parentheses around x would make it work. One
might question whether any sane person would write client-side code that
would break the above definition of foo(x), or whether one should try
to defend against client-side programmers that are crazy enough to do so,
but adding parentheses will guard against such things.
BTW, a sample corner case where the parentheses are necessary:
#define triangles(x) (int const[]){1,3,6,10}[x]
#define mac1(x) x
#define mac2(x) mac1(x)
int test99()
{
return mac2(triangles(3));
}
The above will fail compilation, but changing the mac2 definition to
#define mac2(x) mac1(x)
will fix it.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-03-15 21:55 +0000 |
| Message-ID | <slrn3vfsocje8a.ffd.ike@iceland.freeshell.org> |
| In reply to | #106082 |
On 2017-03-14, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> On Tuesday, March 14, 2017 at 1:34:55 PM UTC-5, Keith Thompson wrote:
>> Why? In both David's version and mine, the reference to x in
>> the macro definition is already parenthesized. The fact that the
>> parentheses are for a function call (or macro invocation?) rather
>> than grouping doesn't matter as far as operator precedence is
>> concerned. Similarly, if a macro definition uses an argument as
>> an array index, it's already surrounded by [] so it doesn't need
>> additional ().
>
> If bar is a function-like macro which is supposed to accept a single value,
> there are corner cases in which
>
> #define foo(x) bar(x)
>
> may fail but adding extra parentheses around x would make it work. One
> might question whether any sane person would write client-side code that
> would break the above definition of foo(x), or whether one should try
> to defend against client-side programmers that are crazy enough to do so,
> but adding parentheses will guard against such things.
>
> BTW, a sample corner case where the parentheses are necessary:
>
> #define triangles(x) (int const[]){1,3,6,10}[x]
>
> #define mac1(x) x
> #define mac2(x) mac1(x)
>
> int test99()
> {
> return mac2(triangles(3));
> }
>
> The above will fail compilation, but changing the mac2 definition to
>
> #define mac2(x) mac1(x)
>
> will fix it.
What's the difference between
#define mac2(x) mac1(x)
and
#define mac2(x) mac1(x)
?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-15 15:16 -0700 |
| Message-ID | <1486f63d-baaf-4656-b264-0ff123eedeae@googlegroups.com> |
| In reply to | #106182 |
On Wednesday, March 15, 2017 at 4:59:04 PM UTC-5, Ike Naar wrote:
> On 2017-03-14, supercat wrote:
> > The above will fail compilation, but changing the mac2 definition to
> >
> > #define mac2(x) mac1(x)
> >
> > will fix it.
>
> What's the difference between
>
> #define mac2(x) mac1(x)
>
> and
>
> #define mac2(x) mac1(x)
>
> ?
For the latter, I meant
#define mac2(x) mac1((x))
For situations where mac1 is supposed to behave like a function that accepts
a single value, the corner cases where the macro would fail are pretty rare,
but the extra parentheses will take care of them, albeit at the cost of
masking some problems that probably should be errors (e.g. if mac2 is passed
a macro that expands to two comma-separated items, the parentheses would turn
the comma from a separator into an operator, but I know of no other way to
add punctuation around a macro argument that will prevent an expression that
contains a comma which is enclosed in {} or [] but not () from being treated
as two arguments.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-03-23 21:04 -0700 |
| Message-ID | <MPG.333dc3f0c9c3f0fc132@news.eternal-september.org> |
| In reply to | #106182 |
Ike Naar wrote:
>
> On 2017-03-14, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> > On Tuesday, March 14, 2017 at 1:34:55 PM UTC-5, Keith Thompson wrote:
> >> Why? In both David's version and mine, the reference to x in
> >> the macro definition is already parenthesized. The fact that the
> >> parentheses are for a function call (or macro invocation?) rather
> >> than grouping doesn't matter as far as operator precedence is
> >> concerned. Similarly, if a macro definition uses an argument as
> >> an array index, it's already surrounded by [] so it doesn't need
> >> additional ().
> >
> > If bar is a function-like macro which is supposed to accept a single value,
> > there are corner cases in which
> >
> > #define foo(x) bar(x)
> >
> > may fail but adding extra parentheses around x would make it work. One
> > might question whether any sane person would write client-side code that
> > would break the above definition of foo(x), or whether one should try
> > to defend against client-side programmers that are crazy enough to do so,
> > but adding parentheses will guard against such things.
> >
> > BTW, a sample corner case where the parentheses are necessary:
> >
> > #define triangles(x) (int const[]){1,3,6,10}[x]
> >
> > #define mac1(x) x
> > #define mac2(x) mac1(x)
> >
> > int test99()
> > {
> > return mac2(triangles(3));
> > }
> >
> > The above will fail compilation, but changing the mac2 definition to
> >
> > #define mac2(x) mac1((x))
[Note: I applied the obviously intended correction here.]
> >
> > will fix it.
The parentheses that are missing in this example are in the definition of
triangles. Adding unnecessary parentheses in the definition of mac1 or
mac2 is pointless.
Philip
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-14 21:48 +0100 |
| Message-ID | <oa9kpj$t9p$1@dont-email.me> |
| In reply to | #106049 |
On 14/03/17 17:18, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> #ifdef __GNUC__ >> #define IS_COMPILE_TIME_CONSTANT(x) __builtin_constant_p(x) > > I'd parenthesize this: > > #define IS_COMPILE_TIME_CONSTANT(x) (__builtin_constant_p(x)) > > I'm not sure whether it can make a difference, but it's easier to add > the parentheses than to prove that they're not needed. I'm fairly sure they would not be needed, but I agree that it is best to have parentheses to be on the safe side of any possible doubts. > >> #else >> #define IS_COMPILE_TIME_CONSTANT(x) (0) > > I wouldn't bother with the parentheses here; there are no precedence > issues with a single constant. > See above :-) I can't think off-hand of any cases there the parenthesis might make a difference, but maybe there are ones that I didn't think of - and they don't do any harm. >> #endif >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-14 14:01 +0000 |
| Message-ID | <YISxA.35153$ff2.15678@fx41.iad> |
| In reply to | #105950 |
>On 13/03/17 23:23, supercat@casperkitty.com wrote: >> If numbering I/O ports 0-255 on some system would mean that turning on a >> particular I/O port bit b would require storing (1u<<(b & 31)) to an address >> (0x12340000 + (b & 0xE0) << 1), then when b is constant such a task would be >> most effectively handled by simply doing a store, but when it's not constant >> having the compiler generate a function call would be faster than having it >> generate the shifting and masking code call-side. Actually, I'd disagree with the "would be faster" part. On any modern processor architecture, the shift/mask code would be implemented as a pair of single-cycle instructions (generally executed in parallel on an out-of-order processor with multiple ALU's) whereas the function call would be more expensive just to execute the same two instructions (particularly on x86 where the call stack will be used - arm64 doesn't need to touch the stack for small leaf functions, but there is still the possibility of a icache miss on the function call).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-14 07:42 -0700 |
| Message-ID | <f9189221-c73d-4bc0-99c6-76e816c24462@googlegroups.com> |
| In reply to | #106018 |
On Tuesday, March 14, 2017 at 9:01:34 AM UTC-5, Scott Lurndal wrote:
> >On 13/03/17 23:23, supercat wrote
> >> ... but when it's not constant
> >> having the compiler generate a function call would be faster than having it
> >> generate the shifting and masking code call-side.
>
> Actually, I'd disagree with the "would be faster" part.
I meant to say the function call would be more compact but not much slower.
On something like an ARM Cortex-M0, if the bit number starts in a register
(e.g. R4) it would be necessary to do something like:
ldr r0,=port0base
add r0,r0,r4
shr r0,r0,5
shl r0,r0,8
mov r1,#1
rol r1,r0,r0
str [r0],r1
which would be 14 bytes (not counting the port0 base constant which the
compiler might be able to reuse); if memory serves, that would be about
10 cycles; a call/return pair would be another six. By contrast, for
the constant case, using a byte store:
ldr r0,=portNbase
mov r1,#byte
strb [r0],r1
six bytes, and an the execution time of six cycles; repeated actions with
the same port or nearby ports may shave 2-4 bytes and 3-4 cycles.
> On any modern
> processor architecture, the shift/mask code would be implemented as a pair
> of single-cycle instructions (generally executed in parallel on an
> out-of-order processor with multiple ALU's) whereas the function call would
> be more expensive just to execute the same two instructions
> (particularly on x86 where the call stack will be used - arm64 doesn't
> need to touch the stack for small leaf functions, but there is still
> the possibility of a icache miss on the function call).
Some people write programs for devices that use orders of magnitude less
current than the processors on a typical desktop machine, and thus have
very optimization requirements.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-14 12:38 +0000 |
| Message-ID | <jvRxA.14895$zC6.3967@fx29.iad> |
| In reply to | #105936 |
David Brown <david.brown@hesbynett.no> writes: >On 13/03/17 19:33, Scott Lurndal wrote: >> Keith Thompson <kst-u@mib.org> writes: >>> supercat@casperkitty.com writes: >>> [...] >>>> The main compiler I use supports an extension which I think debuted in gcc, >>>> which doesn't actually execute anything but returns 1 if an expression can >>>> be evaluated as a compile-time constant and zero if it cannot. This makes >>>> it practical to have a macro which does an action one of two ways depending >>>> upon which is more efficient. Being able to express such concepts more >>>> elegantly than via preprocessor macros would be nice, but the macros do work >>>> and the code is readable on the incocation side at least. >>> [...] >>> >>> What compiler? What is the name of the extension? >> >> perhaps the cat is referring to this feature of the Gnu Compiler Collection: >> >> -- Built-in Function: int __builtin_constant_p (EXP) >> You can use the built-in function '__builtin_constant_p' to >> determine if a value is known to be constant at compile time and >> hence that GCC can perform constant-folding on expressions >> involving that value. The argument of the function is the value to >> test. The function returns the integer 1 if the argument is known >> to be a compile-time constant and 0 if it is not known to be a >> compile-time constant. A return of 0 does not indicate that the >> value is _not_ a constant, but merely that GCC cannot prove it is a >> constant with the specified value of the '-O' option. >> > >I assume that is what he is talking about. I don't know why he thinks >it is a macro or handled by the preprocessor, however. It can be a >useful extension sometimes. > The example which follows the above text in the gcc info page shows _builtin_constant_p being used in a preprocessor macro. That's likely why the OP referred to processors macros.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web