I wrote:

> > > 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?
> > > ;-)

Simon Burge wrote:

> Err, that 256 MB should be 256 _kB_ for the branch instructions (or
> 65,536 instructions).  That could easily be reached in 20,000 lines of
> code.

Maciej W. Rozycki wrote:

>  Since the program is likely compiled as PIC, a "j label" instruction is
> silently translated to "b label" (or actually "beq $zero, $zero, label",

To clarify, 

As I mentioned, the mips jump range is 256 MB - the jump target is 26
bits, instructions are on 2-bit boundaries, 2^28 = 2^8 * 2^10 * 2^10 = 256
* 1024 * 1024 = 256 MB. [I have often run into this limitation on SGI 
machines running in 64-bit mode. Also note that it's not a relative 
offset, but rather an absolute target in the current code segment - I miss 
the PC-relative jumps and loads of PowerPC, 68K, etc.!]

As Simon mentions, the branch offset is 16 bits, 2^18 = 256*1024 = 256 KB, 
a mere +/- 32K instructions - reminiscent of the bad old days!

Maciej surmises that the assembler sneakily replaces the mighty j
instruction with a wimpy beq instruction (all in the name of relocatable
code) thus significantly reducing the maximum size of a while loop.

This is an annoying problem, in any case, and it should be fixed!! 
Certainly the compiler and assembler are capable of generating non-local 
jumps for large functions (e.g. j somewhere_far_away rather than beq 
somewhere_close) - indeed jal's are all non-local already.

Bob
hmm, I don't actually have a pmax any more.... but the jump issue is 
something I have to deal with all the time....