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,295 of 4,255    |
|    s_dubrovich@yahoo.com to muta...@gmail.com    |
|    Re: segmentation (1/2)    |
|    09 Oct 22 10:59:53    |
   
   On Tuesday, October 4, 2022 at 5:01:43 PM UTC-5, muta...@gmail.com wrote:   
   > On Wednesday, October 5, 2022 at 1:31:00 AM UTC+8, s_dub...@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?   
      
   Well gee, 'segment shift-5' or something quoted, to alert the reader to a   
   'so-called' status.   
      
   > > 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.   
   >   
      
   It would need to be, istm, an unique instruction for each of the 'shift'   
   values in the   
   microcode of the processor.   
      
   > 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.   
      
   I'm sounding out, "Be aware!" -- because I'm quoting the 486 manual.   
   The twenty-first significant bit is the CF.   
      
   Steve   
   >   
   > 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