Radix Sort speed improvement
I never found a code that was simple and easy to understand yet wasn't any slower  


Note the order. Start readable.
Start with What shall this be good for?: (doc)comment your code.  

No slower than what? A "well known implementation" for reference and as a base-line would be useful.

Things I liked:


"non-obvious" code blocks are commented
(short-circuit set-up, negative numbers sort)
trying to keep the number of passes low
handling of negative numbers via histogram instead of value manipulation


Dislikes (beyond missing doc comments):


not declaring the size parameter const N
this would at least hint that the memory pointed to by A and Temp may be modified
naming
while I like i for index without further significance, I prefer p for a pointer
What is the significance of Z in Z1…4?
case:
assuming capital case OK for arrays: why N, T, Jump1…4?
naked literals (beyond 0±1)
repetition
starting with types: have a value type, a histogram type
with "the rearrangement blocks", I'd prefer benchmark/machine code comparisons between  
zeroing memory with open code - use memset(destination, 0, count)
"empty then" instead of inverting the condition
*(p+e) instead of p[e] (let alone *(e+p)) - without revisiting the standard, I would have denied this was well defined.)
updating a counter using increment/decrement
I think of those operations as next/previous and use += 1(-= 1) for numerical adjustment  
not using an explicit variable (histogram handling, mostly)
re. speed: not special-casing "small" arrays


Things I don't want to presume warranted:


bit operations preferred to ldiv_t ldiv()
bit operations using compile time constants over using parameters (would allow factoring out)  
"walking memory backwards" as fast as "forwards"