I'm not sure how to find out what version of ARM compiler(armcc) is required for any given attribute to be supported.
For example __atribute__((noinline))?
See
http://www.keil.com/support/man/docs/armcc/armcc_chr1359124975804.htm
To address the titular question directly, the earliest version of armcc for which __attribute__((noinline)) is supported is version 3.0. I found that out the hard way, though; I don't know of any quick-reference for which versions introduced particular features.
Currently we are using SICStus version :3.12.10 and patch1 (x86-linux-glibc2.3) for 32 bit platform.
My requirement: As per new requirement we have to upgrade SICStus Prolog Version 4.2.3 and x86 platform changed from 32 bit to 64 bit. could you please explain what are the code changes to be modified.
Edit: The predicates atom_codes/2, number_codes/2 are supported both Sicstus prolog version 3 and 4.similarly is there any Commonly accepted basic predicates in SICStus Prolog version 3.12.10 and SICStus Prolog version 4.2.3.could you please share if you have any reference document and link.
Edit: Is there any commonly accepted predicates in prolog version 3 and 4
First, try to run your code in 3.12.10 with the --iso option. This covers many of the changes. I.e., there was a significant change from pre-ISO to ISO. With the help of switch --iso on and off you should be able to get many of the differences.
The release notes might be helpful, too.
Then, consider that to wait until 4.3 which is currently in beta 4.3 has improved ISO conformity even further. Here is the most recent documentation.
I will be working exclusively in C. Ubunutu 10.10 will retrieve version 2.8 of Clang from it's repositories and fully install it. I have compiled Clang v 3.1 from source and have added it to the path (after uninstalling Clang 2.8), but do not have access to it's man pages this way, and have an occasional nagging feeling about not having fully "installed it", though it appears to be fully functional on some testing.
Is there any practical difference between versions 2.8 and 3.1 from a C developer's (student actually) point of view? I am working exclusively in C and will not tap into it's C++ or objective C capabilities. I believe most of the development in Clang recently has been in extending it's C++ abilities.
The noticeable difference I found is that for 2.8 VLA function parameters make the compiler dump core. In 2.9 (and thus in 3.1 I suppose) this bug seems to be fixed.
Also this newer version of clang already implements part of C11, in particular _Generic.
C99 adds several useful features to the language, yet I find it difficult to recommend any practice which depends upon C99. The reason for this is because there are few (any?) actual implementations of the C99 language. Sure, there is limited support in a few compilers, but nobody wants spend the time to write C code only to have it be unportable.
This is frustrating given that the standard was written and finalized over 10 years ago now. Plus I hear discussions of a C1x from time to time, and I wonder why someone would be taking steps to revise the language given that the current version of the language isn't yet implemented.
So my question is, as joe blow C programmer today, what is useful w.r.t. the C99 standard to me (if any)?
C99 brings features that really makes programming in C easier and more error safe:
designated initializers
compound literals
for-scope variables
fixed width integer types
The language is also much more expressive with
variadic macros
inline functions
On my linux machine I have four compilers that support C99 to a satisfying extent that make this usable on a daily base: gcc, clang, opencc and icc.
The first two are open source compilers where clang trying to be code compatible to gcc (meaning C99 support is about the same).
The later two are from the two major CPU producers and are commercial but with generous license policy for non commercial users. Their C99 is a bit less, in particular their support for inline seems not completely consistent with the standard, yet.
MSVC does not, nor will it probably ever, support C99. But Microsoft has little incentive to update their C compiler. It's not like they will lose much business over it.
But there are plenty of compilers that have support for C99.
http://en.wikipedia.org/wiki/C99#Implementations
Regarding gcc:
http://gcc.gnu.org/c99status.html
You are right that perhaps C99 is not useful for library code (and may never be without Microsoft's support), but if you're working on an in-house or personal project where you can pick the compilers and tools, then the portability is not much of an issue.
Regarding C1x, I think it's worth noting that the standards committee is well aware that C99 has not been widely adopted and doesn't want to repeat the same mistakes (or to make the situation worse). From the C1x charter:
Unlike for C9X, the consensus at the London meeting was that there should be no
invention, without exception. Only those features that have a history and are in common
use by a commercial implementation should be considered. Also there must be care to
standardize these features in a way that would make the Standard and the commercial
implementation compatible.
And:
The original standard had a very positive reception from both the user and vendor
communities. However, C99 has been not so widely received.
You should use C99 whenever you are not locked in an environment that doesn't support C99 (embeded systems most notably).
And yes, if you know that your library will be used by people that are using MSVC, you can't use C99 features in the interfaces, but there is no reason not to use C99 in the implementation (apart from library feature dependencies of course).
Original answer: "Uh? What compilers don't support C99? Plus when you move from compilers to tools, C99 is actually more commonly supported then C89."
If you care for performance, there's no way around restrict.
FreeBSD is now using Clang for kernel compiles and that pretty much supports C99.
Does anyone know if the source code for Objective-C is still available from when it was just a pre-processor? Would be curious to see how it was implemented back then.
Thanks.
The Clang LLVM rewriter (rewriter is documented below there) can rewrite Objective-C into C (and is being used by some to compile Objective-C for the Xbox and Windows).
Some discussion here:
http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/32019
The only source-available implementation of Objective-C is GCC. The GCC archive at ftp.gnu.org/pub/gnu/gcc contains versions back to 1.42, while ftp.gnu.org/pub/old-gnu/gcc has some versions slightly older than that. The earliest implementations within GCC were, I believe, preprocessors, so that's probably your best bet.