James Newton wrote: > but, but, but... > > Removing page code from a goto that doesn't need it may cause a goto > after that to move out of range of the target that was in range that > you have already removed paging code from which you would then have to > put back and which could then cause another goto to move out of > range... > > ...I just don't see this one as being solvable this way. > > Somebody please prove me wrong James: If all "long jumps" are the same length -- in other words, if you don't have a 3-word "medium jump" and a 5-word "long jump" -- then it IS solvable... You just start with all jumps set to "short", then go through your code from the lowest address to the highest, adjusting the jumps from 1-word to 5-word as necessary. The process is "mostly" monotonic, so it's guaranteed to complete. I'll buy a beer for anyone who can give an example which won't complete within 10 passes. [Actually, I think it'll always complete within 5, but if you can find an example that'll take 6, you should be able to find one that takes 10]. For the PIC, this is probably the best algorithm; for processors whose "short" and "long" jumps depend on the actual distance between source and destination (e.g., a short jump can traverse 128 bytes while a long jump can traverse 64K), a different algorithm is needed, since the simplistic one described above is neither guaranteed to complete nor guaranteed to produce the most-optimal mix of jump instructions on those processors. For THOSE processors, the very best algorithm is: Start everything at the shortest possible branch, and throw all branches on a worklist. Pull a branch from the worklist; if it's out of range, increase it to the next-larger size, then put all the branches that SPAN the just-increased branch on the worklist. Repeat till stable. This algorithm is guaranteed to complete in linear time and to produce the most-optimal code; the proof (very set-theoretical) was first shown to me by Cliff Click, PhD, who was (and maybe still is) a compiler researcher/designer at Motorola. -Andy === Andrew Warren - fastfwd@ix.netcom.com === Fast Forward Engineering - San Diego, California === http://www.geocities.com/SiliconValley/2499 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics