If I'm not mistaken, the mips jump range is 256 MB. Your function is 
larger than 256 MB??? How much memory do you have in your pmax, anyway? 
;-)

As people have already basically suggested, the assembler could detect
out-of-range jumps and generate code that would work.  It would be nice if
gcc didn't generate those out-of-range jumps, but I would not be horribly
offended if the assembler printed out a warning and replaced the offending
jump with:

	lui	$at, (target >> 16)
	ori	$at, (target & 0xffff)
	jr	$at

I think ori doesn't sigh-extend. Slow, but better than the assembler dying
on you. The slightly tricky part is determining which forward jumps would
be out of range - depending on how the assembler works, this might require
some additional changes.

Or you could just live with the 256MB function limitation, as Mr.  
Nishimura suggests. Or you could post-process the compiler output with a
line or two of awk/sed/perl/vi...

Bob

On Sat, 29 Jun 2002, Toru Nishimura wrote:

> This is not a compiler bug in strict senses, but the program hits a limitation of
> hardware.  J(ump) instruction takes 28bit target which happens not to cope
> with the program.  The limitation does not matter for most cases as long as
> functions are small enough.   Jumbo functions are very harmful for fast