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: Joe on 1 Jun 2010 17:32 Hi, I am going to implement an algorithm in ANSI C. I also have to provide an API for the algorithm. I am using Bloodsheed's Dev-C++ (ver. 4.9.9.2) IDE and I added the compiler command -ansi in "Compiler Options" and changed "Support all ANSI standard C programs" from "No" to "Yes". Is the above sufficient to ensure that my code complies with the ANSI C standard? If some hardware platform comes with a C-compiler, how do I ensure that my code can be compiled on that platform? Is it enough that my code is ANSI C compliant? How do I ensure that variables which must have a bit width of 16bit, actually compiles into 16bit wide variables (platform independent types!) ? Is there some header file I can include in my project which will give me macros like UINT16 and SINT16 such that SINT16 x; always will compile into a signed, 16bit variable ?
From: Dann Corbit on 1 Jun 2010 18:13 In article <4c057c73$0$279$14726298(a)news.sunsite.dk>, Joe(a)NoSpammers.Com says... > > Hi, > > I am going to implement an algorithm in ANSI C. I also have to > provide an API for the algorithm. > > I am using Bloodsheed's Dev-C++ (ver. 4.9.9.2) IDE and I > added the compiler command -ansi in "Compiler Options" and > changed "Support all ANSI standard C programs" from "No" > to "Yes". > > Is the above sufficient to ensure that my code complies with the ANSI C > standard? Possibly. I guess it is the GCC compiler. If that is the case, then I would recommend: -W -Wall -ansi -pedantic > If some hardware platform comes with a C-compiler, how do I ensure > that my code can be compiled on that platform? Is it enough that my > code is ANSI C compliant? The C compiler for that machine must support the same ANSI/ISO C standard. For instance, C89 or C99. > How do I ensure that variables which must have a bit width of 16bit, > actually compiles into 16bit wide variables (platform independent types!) ? C99 has types for such a guarantee. C89 only has guarantees for "at least". > Is there some header file I can include in my project which will give me > macros like UINT16 and SINT16 such that > > SINT16 x; > > always will compile into a signed, 16bit variable ? Even with C99, exact width types are optional. What is it that you are really trying to accomplish?
From: Pascal J. Bourguignon on 1 Jun 2010 18:34 "Joe" <Joe(a)NoSpammers.Com> writes: > Hi, > > I am going to implement an algorithm in ANSI C. I also have to > provide an API for the algorithm. > > I am using Bloodsheed's Dev-C++ (ver. 4.9.9.2) IDE and I added the > compiler command -ansi in "Compiler Options" and > changed "Support all ANSI standard C programs" from "No" > to "Yes". > > Is the above sufficient to ensure that my code complies with the ANSI C > standard? > > > If some hardware platform comes with a C-compiler, how do I ensure > that my code can be compiled on that platform? Is it enough that my > code is ANSI C compliant? > > How do I ensure that variables which must have a bit width of 16bit, > actually compiles into 16bit wide variables (platform independent types!) ? > > Is there some header file I can include in my project which will give me > macros like UINT16 and SINT16 such that Yes. Have a look at the least types in stdint.h eg. uint_least16_t will allow you to store at least 16 bits, from 0 to UINT_LEAST16_MAX. > SINT16 x; > > always will compile into a signed, 16bit variable ? Into a signed variable yes, but 16-bit, no, not always. Sometimes it will be a 17-bit variable, sometimes a 24-bit variable, sometimes a 29-bit variable, sometimes a 32-bit-variable, etc. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Joe on 1 Jun 2010 18:43 > What is it that you are really trying to accomplish? I just want to be absolutely sure that variables which I want to be N bit wide always will be compiled into N bit wide variables independent of platform. No reason to have 16-bit signed values suddenly being stored in 32-bit variables. I want to implement a fixed-point, digital filter which is portable. The filter must work in the same way no matter which platform it is compiled on as long as the platform comes with an ANSI C compliant compiler. I am using the typedefs in stdint.h.
From: Pascal J. Bourguignon on 1 Jun 2010 19:22
"Joe" <Joe(a)NoSpammers.Com> writes: >> What is it that you are really trying to accomplish? > > I just want to be absolutely sure that variables which I want to > be N bit wide always will be compiled into N bit wide variables > independent of platform. No reason to have 16-bit signed values > suddenly being stored in 32-bit variables. Yes there are very good reason why it might be so. It may be a 21-bit or 24-bit processor (eg a DSP). Or even if it's a 32-bit processor, it may not be a byte-addressing one, perhaps it can only address words, and having a 32-bit wide data bus, it cannot load less than 32-bit at once. If both cases, if you wanted to use only 16-bits to store your data, you would have to pack these bits in the larger word, and accesses to your 16-bit variable would be at least one order of magnitude slower than if you just used the 21-bit, 24-bit, 32-bit or whatever word. Even on computers with byte addressable memory, it is usually NOT slower to load or store 32-bit than 16-bit. (Well, actually to store 16-bit, if the word where they are is not in the cache, it would be slower, since it would have to load the 32-bit first in the cache, before being able to store back the 32-bits). Then, you may have a C compiler targetting a machine that is not even binary-bit-based, (eg. Knuth's MIX). > I want to implement a fixed-point, digital filter which is portable. > The filter must work in the same way no matter which platform it is > compiled on as long > as the platform comes with an ANSI C compliant compiler. > > I am using the typedefs in stdint.h. Mind the fast types too. They often will definitely be bigger than the least types. -- __Pascal Bourguignon__ http://www.informatimago.com/ |