The C standard (AFAIK) uses both terms. I have trouble understanding where the difference between the two is.
If I have any given, syntactically correct C statement, there can be no way that a compiler will not issue some machine instructions. Of course, it could choose to not issue any statement at all, but even that would be "implementation dependant".
A more concrete example: Overflow of integer values. Now we have two types of overflow: arithmetic, and memory-wise. If the overflow of signed integers is UB according to the standard, what does that mean? Could an implementation simply spill an overflowing bit into the adjacent byte to the MSB? (Never seen that, but would it be ok?)
It appears to me that "undefined behaviour" always is implementation dependant. Or, to put it differently, there seems no way a compiler could handle any "undefined behaviour" without introducing "implementation defined" behaviour.
So why even distinguish between the two?
The main difference is that implementation-defined behavior is defined. That is, for every requirement in the Standard that says "implementation-defined", a C implementation is supposed to come with an explanation of what that behavior is.
For example, here is the GCC documentation on implementation-defined behavior for the C language.
Also, in many cases, "implementation-defined" allows for a decision for one of a number of particular possible behaviors. But "undefined behavior" always allows an implementation to do anything at all, either at compile time or at run time.
Read also Lattner's blog What Every Programmer Should Know About Undefined Behavior.