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,287 of 4,255   
   mutazilah@gmail.com to s_dubrovich@yahoo.com   
   Re: segmentation   
   04 Oct 22 15:01:41   
   
   From: muta...@gmail.com   
      
   On Wednesday, October 5, 2022 at 1:31:00 AM UTC+8, s_dubrovich@yahoo.com wrote:   
      
   > > No, I do not wish to be involved on the hardware side,   
   > > except for some basic questions like what's the extra   
   > > cost of the 8086 if variable shifts are added? Which   
   > > has already been answered, which is 5%.   
   > >   
   > > It is the software side I am interested in.   
      
   > You say that, yet all this talk of changing microprocessor functionality for   
   > 'variable shift' -and other things.   
      
   Yes, that is the interface between the hardware and   
   software. As a software person, I should be able to tell   
   the hardware engineers what I would like. I already   
   know that it is possible for minor cost.   
      
   > Please change your nomenclature in regards to 'shift 5'.   
   > It is confusing and irksome to assembly programmers who know that there are   
   > bit shifting instructions for doing shifting of values in registers and   
   memory.   
   > You are discussing changing how address decoding should optionally work   
   > regarding segment registers in real mode address decoding.   
      
   5-bit, or variable segment shifts, seems clear to me.   
   But I'm happy to switch to your terminology. Which   
   is what? Hopefully not copy and paste the above   
   paragraph every time?   
      
   > When I said segment register value is translated 'AS IF' the segment value is   
   > shifted left 4 bits and the IP offset is added to it for the purpose of   
   > address translation to a linear address, I didn't mean that shift 4 is some   
   > sort of variable, or available to be changed, just to be clear.   
      
   I want it to be variable and available to be changed.   
   It's unclear to me where though. Perhaps the shift   
   can be set in the BIOS and then the BIOS executes   
   an 8086+ instruction to set the shift value.   
      
   Making a CPU with a hard-coded shift of 5 would be   
   a last resort.   
      
   > > > Computer scientists wanted separate Code and Data, CS & DS, as mentioned   
   before.   
   > > There's no sensible alternative for the segmentation   
   > > model, is there?   
   > Long mode with paging??   
      
   Sorry for my sloppy English.   
      
   Once a decision is made to use segmentation   
   to exceed 64k, there is no real alternative to   
   what Intel did, is there?   
      
   > How did you go about setting up Bochs?   
      
   It is available from the Google Play store.   
      
   > > > A data register - DE DX   
   > > > A data register - BC CX   
   > > > So, there is some synergy there.   
   > > But can you answer the question - can that   
   > > synergy be total, so that the 8080-replacement   
   > > can be a subset of the 8086, or would both   
   > > processors need some adjustment?   
   > No, the synergy has its limits.   
   > In your yard there are two items: a bicycle (8080) and   
   > a motorcycle (8086). Pick one. You want to motorize   
   > your bicycle?? -- but you have a motorcycle already.   
      
   No, I want to remove the engine from the motorcycle,   
   but keep the frame.   
      
   > The byte codes of the two processors are different.   
   > A RET is a RET but the byte code for each cpu are different.   
      
   And why can't the 8080-replacement use the same   
   byte code as the 8086?   
      
   > The 8086 really is a step up in address capability from   
   > the 8080.   
   > The 8086 can mimic the 8080 addressing map by setting CS=DS=SS,   
   > but it offers more. The addressing mapping can offer more; a   
   > CS of 64k, a DS of 64k, a SS of 64k, for larger programs than   
   > those on an 8080.   
   >   
   > The addressing modes are different. With segmentation, many modes   
   > of addressing are designed into the 8086 address decoding. The   
   > 8080 has one mode. (tiny model).   
      
   Right, and what is preventing an 8086 tiny model program   
   from running on an 8080-replacement?   
      
   > I'm beginning to get a mental picture of what you want, I think:   
   > You require a 2mb addressing range, that is a 21 bits of addressing.   
   > So, the 'shift 5' sets up the upper-most 16 address lines --   
   > bits {21..5} and the lower-most 16 address lines {15..0}.   
      
   And then added together, correct.   
      
   > You want this 8086+ versus moving up to, say 32-bits, a 486 in   
   > protected mode, because of the complexity of the hardware and software.   
   > Because a dystopian senario won't support that level of technology.   
      
   Exactly.   
      
   And not just a dystopian scenario, but acknowledgement   
   that with the benefit of hindsight, this would have solved   
   real world problems with RM16, for basically no cost.   
      
   > Because of the possibility of a carry, the resulting linear address   
   > may have as many as 21 significant bits. An 8086 program may   
   > generate linear addresses anywhere in the range of 0 to 10FFEFh   
   > (1 megabyte plus approximately 64k) of the linear address space.   
   > Because paging is not available in real-address mode, the linear   
   > address is used as the physical address.   
   > "   
   > [Deducing from the above, an 8086 which does not have an A20 address line,   
   > the value in CF is used instead in address translation exceeding 20 bits.]   
      
   The carry flag is for the result of operations, completely   
   unrelated to addressing, as far as I'm aware.   
      
   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