From: alexfrunews@nospicedham.gmail.com   
      
   On Saturday, November 19, 2022 at 5:19:35 PM UTC-8, Paul Edwards wrote:   
   > On Sunday, November 20, 2022 at 6:08:16 AM UTC+8, Alexei A. Frounze wrote:   
   >   
   > > > Is it:   
   > > >   
   > > > addr0 dd handler0   
   > > >   
   > > > And then do an les of that?   
   >   
   > > I don't recall the a.out format supporting segmentation.   
   > >   
   > > I found my way around the similar problem with the ELF   
   > > format by simply using 32-bit physical addresses,   
   > > which are then decomposed into 16-bit segment and   
   > > 16-bit offset pairs whenever necessary.   
   > How do I use a 32-bit physical address?   
   >   
   > Is it like above?   
      
   Yes.   
      
   I used the assembler (NASM) in the 32-bit non-segmented mode,   
   where all addresses are simply 32-bit offsets.   
      
   The linker, startup code (AKA loader) and generated code then   
   convert these into seg16:ofs16 using 80386 32-bit instructions.   
      
   [This is SmallerC's huge memory model in a nutshell.]   
      
   While said conversion is conceptually trivial, only a few 8086   
   instructions (far call, far jump, lds/les) can consume 32 bits   
   of an address (seg16:ofs16). Everywhere else you have the far   
   address split into two 16-bit portions with some space (code)   
   between the two.   
      
   If you want to be able to use these 16-bit parts independently,   
   you need to produce two special kinds of relocation records,   
   one for the SEG keyword, the other for the OFS/OFFSET.   
   The latter is more or less trivial and already exists, but is   
   probably 32-bit in your assembler, whereas it needs to be 16-bit.   
   The former needs to be introduced.   
      
   The simplest is perhaps to restrict every object file to   
   two segments/sections (code and data), each at most 64KB   
   in size and 16-byte aligned and padded to a multiple of 16 bytes.   
   OFS/OFFSET would then be the subroutine/variable offset   
   from the beginning of its segment/section in the object file.   
   SEG would simply account for the cumulative size of all   
   the linked object files. In essence, you end up relocating   
   only the SEG part as the OFS/OFFSET part is fixed.   
      
   Otherwise you could dump all far pointers into the default   
   data segment and simply do lds/les as needed (naturally,   
   the pointer values must've been relocated by then).   
      
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)