From: nowhere@never.at   
      
   On 13.07.2021 06:13, muta...@gmail.com wrote:   
   > On Tuesday, July 13, 2021 at 1:31:29 PM UTC+10, wolfgang kern wrote:   
   >   
   >>>> 24-bit addressing, and a theoretical x86 processor with   
   >>>> 32-bit addressing. Come to think of it, it might be possible   
   >>>> to use an actual 80386 to do effective 16-bit segment   
   >>>> shifts. Or surely I can at least match the 80286 and do   
   >>>> (effective) 8-bit shifts. That would be a load of fun.   
   >>>> I guess it depends how many selectors I can define on   
   >>>> the 80386. I'll run everything in supervisor mode, so I   
   >>>> can use both GDT and LDT if that helps.   
   >>>   
   >>> I looked up Wikipedia:   
   >>>   
   >>> https://en.wikipedia.org/wiki/Global_Descriptor_Table   
   >>>   
   >>> and there are 8192*2 selectors available, meaning that   
   >>> 16-bit programs can access 1 GiB maximum.   
   >>   
   >>> 4-bit segment shifts make sense when there is 1 MiB of   
   >>> memory available.   
   >   
   >> you totally misunderstood how descriptors work.   
   >> 1. GDT/LDT are only in effect in PM and VM   
   >> 2. a GDT entry can span a 4GB memory range.   
   >> 3. a descriptor can be set for either 16 or 32 bit limit.   
   >> 4. there are several descriptor types [code/data/TSS].   
   >> 5. the count of entries got nothing to do with accessible range.   
   >> 6. segment descriptors ARE NOT extended RM-segment registers,   
   >> they work complete different.   
   >   
   > You misunderstand my intentions.   
   >   
   > I will set up 16384 selectors, each pointing to consecutive   
   > 64k buffers. If the user has 1 GiB of memory, then we are   
   > using EFFECTIVE 16-bit shifts. What that means is that   
   > select 0 points to the first 64k. The second selector points   
   > to address x'10000' for a length of 64k. The third selector   
   > points to address x'20000' for a length of 64k.   
   >   
   > So x'10000' * 16384 will eventually get us up to 1 GiB.   
   >   
   > If we only had 512 MiB installed we would instead use   
   > 15 bit shifts to give better granularity.   
   >   
   > So selector 0 points to address 0. Selector 1 points to   
   > address x'8000' for a length of 64k. Selector 2 points to   
   > address x'10000' for a length of 64k.   
   >   
   > x'8000' * 16384 will eventually get us up to 512 MiB.   
      
   your calculation sucks :)   
      
   and any valid selector can start at any address within 4GB.   
   (but any means aligned to bounds here) the selector number   
   got nothing to do with the address it is pointing to !   
      
   selector 0 is invalid   
   first usable selector number is 8 which is also the offset   
   in the GDTable (numbers 9..15 are same but restricted PL)   
   next usable is 0x10   and so on   
      
   but you may need at least two selectors per 64K block, one   
   for code and one for data (some folks have third for stack)   
      
   So even if you fill the GDT with max possible entries:   
   last will be 0xFFF8, that means (65536-8)/16 = 4095 pairs   
      
   hope you realize that your GDT use a full 64K block by itself.   
   my GDT solution has only 32 entries, including 6 VBIOS selectors.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)