Abishek's suggestion is not so tricky - it does what you think you want it to do, but what happens to the code that was interrupted? How will it ever be able to be resumed as it's state has just been wiped? You can be a little smarter and not destroy the original return address, stack your new return address and do a RETI. The new code that you call must store any registers it alters and when it has finished it can restore the registers and just do a RET. It will then resume from where the interrupt first happened.

It sounds like the OP wants a pre-emptive task change. To do this means a bit more work, like keeping a stack for each task and storing/restoring each task's state. Then you've got to decide which task runs..... soon enough, you've built a RTOS. I would suggest that the OP rethinks what he wants to do. For example, the interrupt could do what it needs to do (keep it lean and mean) and/or set a flag so that at some point later, the required code can be run. For example, I have some code that does MODBUS ASCII format serial communications. I have an interrupt for the serial comms that assembles the received characters into memory - I also check for too many characters etc. When I receive the LF character (which signifies the end of packet in MODBUS ASCII), I set a flag. Because I don't need to respond immediately (I can wait many 10's of milliseconds if I like) I can wait for whatever the main task is performing than regularly test for the comms received flag, if this is set, I can process the received data that is sitting in memory and respond. This is the co-operative method- you must write your code so that the comms received flag is polled at a regular interval so that it can be processed in the required time frame.
You'll find a lot of embedded system code is written this way - it is very simple, does not require much stack space (much less than a pre-emptive OS) and can be very efficient.

You could also use an event driven paradigm like Windows does for its event queue. Requests for processing are entered in a queue and your main code reads the event and calls the code to process it, then it reads the next event and so on. Usually though, an embedded system only has a handful of tasks to process, so the queue can be wasteful, you could just have a number of flags to signify you want something processed.

If you find yourself doing tricks with the stack, you've got to ask yourself if there is an easier way of performing the operation. sometimes, you've just got to do it that way, but be aware of what you're doing - if you're having to ask how to do it then I would suggest you DON'T do it until you fully understand the implications. Ignore this advice and you'll find yourself with potentially buggy code that is highly unreliable and may fail at the most inoportune time.