Date: Mon, 30 Aug 2010 00:14:54 -0700 From: perryh@pluto.rain.com To: kc5vdj.freebsd@gmail.com Cc: freebsd-usb@freebsd.org Subject: Re: writing usb drivers under 8.x Message-ID: <4c7b5a6e.QwnmSHqXsgp/7ogB%perryh@pluto.rain.com> In-Reply-To: <4C7B1510.1000601@gmail.com> References: <4C76AB76.4070806@gmail.com> <201008270856.43512.hselasky@c2i.net> <4C777D12.3040900@gmail.com> <201008271053.27731.hselasky@c2i.net> <4C78B0F4.4020002@gmail.com> <4c799393.wU/d2YpTieErDrD7%perryh@pluto.rain.com> <4C7B1139.4050106@gmail.com> <4C7B1510.1000601@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jim Bryant <kc5vdj.freebsd@gmail.com> wrote: > well, i can't speak for K&R 1978, as i can't currently find my copy, > but, for a quick brush up, you might want to read pages 80 and 81 > from K&R 2nd Ed. 1988. > > your idea that the preprocessor will evaluate > > #define thirtytwok (1<<15) > > into 0x8000 > > at compile time is totally incorrect, and in fact wouldn't be in > compliance with standards. i have iso and fips handy, care for > quotes? Who said anything about the preprocessor? The preprocessor is supposed to only do text substitutions, so you're right that _it_ doesn't (or at least, shouldn't) replace (1<<15) with 0x8000. The *compiler* does it. Look up "constant expressions". If you find a C compiler that generates a load and shift to evaluate (1<<15) at runtime, your next move should be to file a bug report with its maintainer -- unless you're dealing with a processor which can do the load and shift in less time or space than a direct load of 0x8000. And BTW, please don't top-post.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4c7b5a6e.QwnmSHqXsgp/7ogB%perryh>