In realtà la portabilità di un linguaggio è un tema parecchio vasto, che dubito riesca a venire liquidato in poche righe
1.
Da quanto ho sempre sentito dire, è il codice scritto in un linguaggio interpretato ad essere più facilmente trasferibile in altre architetture ("write once, run (debug) everywhere" no?). Se è questo che intendi, credo che il motivo sia il minore lavoro che spetta al programmatore nell'ottimizzazione del codice rispetto a una determinata macchina, essendo questo svolto dall'implementazione stessa dell'interprete. Per definizione un linguaggio compilato è legato all'ISA per cui lavora il compilatore.
Se ciò che intendi è invece il linguaggio stesso (il compilatore, la sdk..), tutto ciò che al momento mi viene in mente è la storia di C (non C++ eh): un compilatore relativamente semplice, portato in (riscritto per) una pletora di sistemi differenti ("WOCE"); rimaneggiare il source nel passaggio da un'architettura ad un altra credo sia comunque inevitabile: la somma di due operandi sarà pure tradotta differentemente nell'eseguibile, però nota che ad esempio le operazioni di i/o comunemente gestite dalla libreria standard vanno anch'esse adattate, anche se non direttamente dall'utente del linguaggio. Un interprete deve per sua natura essere legato all'architettura nella quale deve "interpretare" il codice, quindi forse (forse invece sto dicendo una
cazzcosa stupida) è un applicativo più complesso e più legato alla stessa di un compilatore
Altra diramazione è quella tra linguaggio macchina (assembly, anche le sue derivazioni di più alto livello) e linguaggio compilato: mentre il primo
è tutt'uno (più o meno) con l'ISA dove si targetta lo sviluppo, il secondo è per l'astrazione voluta dal compilatore più indipendente da essa, e la disponibilità del compilatore stesso su più macchine permette una maggiore portabilità del prodotto finale.
Comunque attendi risposte più cristiane: non ho a che fare da parecchio con queste cose, né mai le ho approfondite più di tanto