Hi Rohit,
I am currently developing a very similar system based
on Philips 98c51 Rx2 to flash my app via USB connection.

Since I have only 64k codespace I have no idea how to
jump across 64k boundaries.
The following example is based on Keil. INT0 vector and
SIO vector are used by both update and app code the
rest of the vectors are mapped exclusively to the app
Update code is linked at 0x000 app code at 0x2000.

first I created a asm module with the IRQ vectors

extrn DATA (USB_VECT)
extrn DATA (SIO_VECT)

CSEG at 0003h
PUSH USB_VECT+1
PUSH USB_VECT+0
RET

CSEG at 000bh
LJMP 200bh

CSEG at 0013h
LJMP 20013h

CSEG at 001bh
LJMP 201bh

CSEG at 0023h
PUSH SIO_VECT+1
PUSH SIO_VECT+0
RET

CSEG at 002bh
LJMP 202bh
end

The trick is locating SIO_VECT and USB_VECT at exact the same
addresses in update and app code. I have used this scheme also
succsessfully when I have to share different interrupt procs to the
same interrupt.

I am holding the IRQ procs in one c file with #pragma NOINTVECTOR
in the first line so C does not generate a VectorTable. (Keil C)

UINT16 sio_vect _at_ 0x18 // mem for the vectors
UINT16 usb_vect _at_ 0x1A // same loc in both code bases

void InitSio(void)
{
sio_vect = &MidiIrq; // install the Irq Proc
....
ES=1;
}

and in my IRQ.C

void MidiIrq(void) interrupt SIO_VECTOR
{
....
}

In the Main () of my update code I an doing then some tests like
the POF flag and if they are succsessfully I am executing a
CALL (0x2000); to start my app code via

#define CALL(addr) (((void(*)(void))(UINT8 code *)addr)())

The only disadvantages of that scheme is you will need 2 bytes
of DATA space for each Irq you want to share and the response
time is about 4 cycles slower than executing a direct call.

cheers Thomas