From: muta...@gmail.com   
      
   On Sunday, July 18, 2021 at 11:06:05 AM UTC+10, muta...@gmail.com wrote:   
      
   > > > The linker does indeed need to ensure that no individual   
   > > > function is split over a 64k boundary.   
   >   
   > > I am not sure if compilers supported this, but single function   
   > > bigger that 64k is valid once you allow more than 64k code.   
   > > Compiler can use any mixture of near and far jumps inside.   
   >   
   > I've been thinking more about this.   
   >   
   > If a single function is more than 64k, then, by design, my   
   > linker would ensure that that function started on a 64k   
   > boundary.   
   >   
   > With such an executable loaded into memory, regardless   
   > of the segment shift value, I don't see how the compiler   
   > could generate any code which mandated a 4-bit shift.   
   >   
   > The far jumps will necessarily have a segment that needs   
   > to be correctly relocated.   
   >   
   > The near jumps will be identically aligned in memory, so   
   > will also work.   
   >   
   > Am I missing something?   
      
   Wait. I've got it.   
      
   If a routine is located at say 2k below the first 64k block,   
   and needs to call a routine at say 3k above the start of   
   the second 64k block, the compiler would say "aha,   
   within range", and generate a near jump.   
      
   That determination of "within range" is where a label   
   would be aware that it will always be invoked with an   
   offset of 0, so everything is being reset, so it has a   
   64k forward address range.   
      
   Whereas I need the compiler to not assume it is possible   
   to mandate a fresh segment so that you get an offset   
   of 0.   
      
   Well, even then - if you wish to demand a fresh segment,   
   the padding bytes from the last segment may be up to   
   64k instead of up to 16. It is those padding bytes where   
   the number 4 is being hardcoded in the compiler.   
      
   So yes, if you have an individual function more than   
   64k in size, the compiler may need to be modified.   
   Bumping the padding bytes to ensure a 64k boundary   
   would likely be a terrible solution, but would work.   
      
   Or else simply deem that those 16-bit executables won't   
   be supported on the 80386 in PM32. At least for now.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)