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,353 of 4,255   
   mutazilah@gmail.com to Joe Monk   
   Re: segmentation   
   23 Oct 22 13:43:44   
   
   From: muta...@gmail.com   
      
   On Monday, October 24, 2022 at 4:10:34 AM UTC+8, Joe Monk wrote:   
   > > Crikey. Talk about a misunderstanding.   
   > >   
   > Well as we already know 0x5333 shifted left 5 bits is 0x0A6660   
   >   
   > 0x0A6660 + 0x0A71 = 0x0A70D1   
      
   Ok, I stuffed up the calculation. I can give you another 2   
   arbitrary numbers if necessary.   
      
   > But you still missed the point.   
   >   
   > With 4 bit shifts...   
   >   
   > 0x5555 + 0x0005 = 0x55555   
   > 0x5333 + 0x2225 = 0x55555   
   >   
   > So, mutliple segment:offset pairs point to the same physical address.   
   >   
   > But if I take those same segment:offset pairs and apply 5 bit shifts to   
   them, it breaks segmentation. Thus, none of the existing code base will work.   
      
   Not true.   
      
   The existing code base, some of which includes code I wrote,   
   mainly C code, does not arbitrarily hardcoded addresses like   
   0x5555:0x0005 and then attempt to compare them to other   
   arbitrarily hardcoded addresses.   
      
   The addresses are obtained at runtime, depending on where   
   the OS loaded the program, or as a result of a subsequent   
   malloc() or OS equivalent.   
      
   An immediate switch to 5-bit shifts would not affect most   
   application code one iota, other than given them access to   
   more (because overhead has already been paid for) than   
   double the amount of memory.   
      
   BFN. Paul.   
      
   --- 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