Question about platform independent code and ANSI C compliant code
in [General Programming]
|
Prev: احصل على ماستر كارد MasterCard مجانا هديه
Next: Free Live Voice and Video Chat!Connect with Over 4 Million Members download now
From: Peter Nilsson on 3 Jun 2010 18:36 "bart.c" <ba...(a)freeuk.com> wrote: > "Peter Nilsson" <ai...(a)acay.com.au> wrote in message > > "Joe" <J...(a)NoSpammers.Com> wrote: > > > No reason to have 16-bit signed values suddenly being > > > stored in 32-bit variables. Actually there is. > > Why bother writing 'ANSI C' code if you're going to > > exclude the plethora of implementations that don't offer > > precise 16-bit wide integers? > > In: > > unsigned short a; > int b=123456; > a=b; > > 'a' may end up as 57920 on some machines, and likely 123456 > on others. It seems reasonable to be able to request 'a' to > be exactly 16-bits on any machine, whether that is natural > for the architecture on not. a = b & 0xFFFFu; Decent compilers will optimise out the bitwise-and. More importantly, you can easily and often delay the mask. Which brings me to the point that even on platforms that do support 16-bit types, it can actually be _more_ efficient to perform intermediary calculations with wider _natural_ types. Twenty years ago, smaller types were faster. That isn't always true today. In fact, it's the opposite on many platforms. -- Peter
From: bart.c on 3 Jun 2010 19:47 "Peter Nilsson" <airia(a)acay.com.au> wrote in message news:bc840f02-f7f3-4bfd-8119-da40cfe0d7a9(a)y18g2000prn.googlegroups.com... > "bart.c" <ba...(a)freeuk.com> wrote: >> "Peter Nilsson" <ai...(a)acay.com.au> wrote in message >> > "Joe" <J...(a)NoSpammers.Com> wrote: >> > > No reason to have 16-bit signed values suddenly being >> > > stored in 32-bit variables. > > Actually there is. >> unsigned short a; >> int b=123456; >> a=b; >> >> 'a' may end up as 57920 on some machines, and likely 123456 >> on others. > a = b & 0xFFFFu; > > Decent compilers will optimise out the bitwise-and. > > More importantly, you can easily and often delay the mask. > Which brings me to the point that even on platforms that > do support 16-bit types, it can actually be _more_ efficient > to perform intermediary calculations with wider _natural_ > types. Another example: unsigned short a,b; b=0xffff; a=(b<<1)>>1; 'a' has a result that depends on whether the intermediate calculations are done with the same number of bits as short, or more, resulting in subtle differences between implementations. Masks can fix this too, but now it starts to get untidy. But this is a consequence of the way C works; one of my old language projects does this properly and gives the expected result for 'a' (ie. 0x7fff when using 16-bits). > Twenty years ago, smaller types were faster. That isn't > always true today. In fact, it's the opposite on many > platforms. Whether smaller types are always slower is debatable; you need to look at memory accesses too. (Otherwise, yes my newer projects use 32-bit calculations; shorter types are mainly there to save space; any extra speed is a bonus. However I now also have the same problem as C has above; my excuse is that my 16-bit type is not an proper type, only a narrow version of 32-bits...) -- Bartc
From: Peter Nilsson on 7 Jun 2010 23:00 "bart.c" <ba...(a)freeuk.com> wrote: > "Peter Nilsson" <ai...(a)acay.com.au> wrote: > > "bart.c" <ba...(a)freeuk.com> wrote: > > > unsigned short a; > > > int b=123456; > > > a=b; > > > > > > 'a' may end up as 57920 on some machines, and likely 123456 > > > on others. > > > > a = b & 0xFFFFu; > > > > Decent compilers will optimise out the bitwise-and. > > Another example: > > unsigned short a,b; > > b=0xffff; > a=(b<<1)>>1; > > 'a' has a result that depends on whether the intermediate > calculations are done with the same number of bits as short, > or more, resulting in subtle differences between > implementations. That's because you've coded it that way. > Masks can fix this too, but now it starts to get untidy. What is 'untidy' about...? a = b & 0x7FFFu; -- Peter
From: bart.c on 8 Jun 2010 05:49
Peter Nilsson wrote: > "bart.c" <ba...(a)freeuk.com> wrote: >> "Peter Nilsson" <ai...(a)acay.com.au> wrote: >>> "bart.c" <ba...(a)freeuk.com> wrote: >>>> unsigned short a; >>>> int b=123456; >>>> a=b; >>>> >>>> 'a' may end up as 57920 on some machines, and likely 123456 >>>> on others. >>> >>> a = b & 0xFFFFu; >>> >>> Decent compilers will optimise out the bitwise-and. >> >> Another example: >> >> unsigned short a,b; >> >> b=0xffff; >> a=(b<<1)>>1; >> >> 'a' has a result that depends on whether the intermediate >> calculations are done with the same number of bits as short, >> or more, resulting in subtle differences between >> implementations. > > That's because you've coded it that way. > >> Masks can fix this too, but now it starts to get untidy. > > What is 'untidy' about...? > > a = b & 0x7FFFu; It was supposed to be an example of the widths of intermediate values being significant. Try this then: a=(b<<c)>>c; Or any calculation where high-order bits can affect the result (>>, / and % for example). -- Bartc |