Cross-compilers can produce programs which will run on a different CPU type, something which is often prohibitively slow at run time, though sophisticated implementations which perform efficient once-only conversion either at first execution and saved semi-permanently or once per execution do exist. Such implementations are not as efficient as cross-compilation but they may be the only practical solution where a vendor does't produce a program on the desired CPU.
When an interpreter is used there is in general no separation between compile time and run time. There may instead be a interpretation phase (often into bytecode) followed by execution, but performed by the same software and not exposed to the user. Compile time errors in a program that is normally compiled may instead be detected as runtime errors when interpreted instead and this makes hard to check every single exectution path without extensive debugging.
In computer science, compiletime, as opposed to runtime, is the time when a compilercompiles code written in a programming language into an executable form.
Compiletime errors in a program that is normally compiled may instead be detected as runtime errors when interpreted and this makes it hard to check every single execution path without extensive debugging.
Compilers also exist which translate from one high level language to another, or sometimes to an intermediate language that still needs further processing; these are sometimes known as cascaders.
Building a self-hosting compiler is a bootstrapping problem -- the first such compiler for a language must be compiled either by a compiler written in a different language, or (as in Hart and Levin's Lisp compiler) compiled by running the compiler in an interpreter.
Compilers which are capable of producing both native and foreign binary output may be called either a cross-compiler or a native compiler depending on a specific use, although it would be more correct to classify them as a cross-compilers.