home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,063 of 4,255   
   wolfgang kern to James Harris   
   Re: Format for the OS image   
   08 Feb 22 14:49:56   
   
   From: nowhere@nevernet.at   
      
   On 07/02/2022 14:06, James Harris wrote:   
   > On 09/01/2022 10:44, wolfgang kern wrote:   
   >> On 08/01/2022 23:44, James Harris wrote:   
   >>> On 08/01/2022 20:10, wolfgang kern wrote:   
   >>>   
   >>> ...   
   >>>   
   >>>> Earlier versions of my OS used self-relocation, and they were small   
   >>>> enough to fit into the first 640K. Not more since a while ...   
   >>> What format did you use for relocatable files? AISI there are two   
   >>> choices:   
   >>>   
   >>> 1. Design your own format. Then relocation would be easy but you'd   
   >>> need some way to convert to that form from build tools -   
   >>> compiler/assembler - or to produce your own build tools.   
   >>>   
   >>> 2. Use a predefined format. Then relocation would require parsing the   
   >>> structure but (bugs permitting!) it would be easy to produce.   
   >>>   
   >>>   
   >>> FWIW, I am looking to use option 2 ATM but I have all kinds of   
   >>> interesting ideas for matters related to option 1. :-)   
   >>   
   >> My way of self relocation was just one single variable on the very   
   >> start of the image in RAM (I put all other rd/wr data anyway 512 bytes   
   >> upfront code, similar to a PSP in DOS), so all internal and also   
   >> external access just added this to reference anything within code and   
   >> data by SIB modes.   
   >   
   > I don't get that. If you had instructions like   
   >   
   >    mov ebx, [0x7c00]  ;Get pointer from start of image   
   >   
   > then you would need to know where the image started (0x7c00) ... and if   
   > you knew where the image started you wouldn't need relocation.   
   >   
   >>   
   >> more previous versions used a relative CALL-Null/POP sequence to   
   >> figure where it was loaded, but I soon found the better solution as   
   >> said above.   
   >   
   > I could see value in loading a pointer from a fixed location in memory,   
   > e.g.   
   >   
   >    mov ebx, [0x1004]  ;Get pointer to globals   
   >   
   > but not from the start of a movable image.   
      
   OK, we know that the (old yet) BIOS starts our code at 7C000.   
   So all we have to do is to make sure that all our references   
   either align to (flat) 0:7c00 or (seg:offset) 7c00:0000.   
   My 16 bit MBR starts with a hard coded far jump to 7c00:0040   
   to leave some room for variables and align to cache bound.   
      
   And all the stuff I load after the initial boot, self-relocating   
   is just done by remember the location where I put it and store   
   this (32 bit flat xxxx) value into the image.   
   e.g.: a first local data pointer init   mov esi,xxxx   
   aka: BE xx xx xx xx   
   this is also stored into my MEM-LISTING to be used for external   
   and inter instance referencing.   
   works the same if code modules were moved, what I never did.   
      
   Previous versions used: call 0000 | pop esi   
   E8 00000000   
   5E          must be aware of the five bytes off here.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca