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