diydsp linked to https://launchpad.net/gcc-arm-embedded which covers Cortex-M and Cortex-R cores, but importantly doesn't mention ARM11 and Cortex-A cores used on the Raspberry Pi and BeagleBoard Black.
I suppose the latter aren't considered "embedded" in the sense that, hell, they run Linux, and so aren't covered by ARM's compiler support effort but by the community?
In the shorter-lived sense, "embedded" referred to low-power, limited functionality processors such as the ARM7/ARM9 CPUs in TFA. These setups often didn't have MMUs, would typically run a very bare-bones RTOS with soft- or hard- realtime support. Remember no MMU means no process isolation. If a task has a stack overrun, it just keeps going into an adjacent task's stack. If a pointer gets corrupted and the software starts writing who-knows-where in RAM, pray it dies early, hard, and reproducibly. The code size, ability to use third-party libraries, etc. were all greatly limited. Very much more the aesthetic of engineering a one-off custom mechanism, albeit in software vs. in the machine shop.
These days, the envelope of "embedded" CPUs has embraced vastly more powerful hardware, while still remaining low power. They have MMUs, they run real Linux (vs. ucLinux or a traditional RTOS) and are much easier to develop for. Think Arduino, Rasberry Pi, and on and on. This has been a huge access revolution for hackers, makers, and anyone who wants to just get down and prototype some ideas.
Embedded systems typically run on a microcontroller. It almost literally means something that reads an input from the physical world (EXTI, logic level or adc) and uses it to control something. Microprocessors typically implement a bus system and additional units like an MMU. We used to have uC with basic busses, but that was for different reasons (EPROM, LCD, ...)
These days the word embedded seems to mean "fits in a small box".