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