Segmentation in real mode
in [ASM]
|
Prev: stricmp
Next: Killing Explorer
From: Randall Hyde on 13 Mar 2005 11:09 "Beth" <BethStone21(a)hotmail.NOSPICEDHAM.com> wrote in message news:iiTYd.18434 > > Yes: > But surely the more logical scheme (even at the time...after all, this _IS_ > how the 8080 managed its 16-bit addresses on an 8-bit chip...the same > "problem" just at a lower "bitage" :) would have been to use the exact same > "pairing" scheme yet again...except, simply, the addresses were now two > 16-bit registers in a "pair" (e.g. "DS:BX") rather than two 8-bit registers > (e.g. "HL"), as was the case with the 808x... Segment registers have nothing to do with the 8080. Intel did not invent segmentation. It was actually a relatively popular memory management scheme at the time (paging was taking over, but in 1976 segmentation was quite popular; it was the basis, for example, of OSes like Multics). Segment registers never were intended to be "base address" registers. Intel used a "cheap" implementation of segmentation in the 8086, which is quite reasonable given the state of the art at the time. > > Other points to note is that the "segment registers" were introduced by > Intel _SOLELY_ for the purpose of being the "upper part" of an address (not > "general-purpose" registers)...they could have - if "economics" was a > factor - have, say, used a _byte_ for "segment registers", bringing about a > 24-bit "far" address (which is only an extra byte for the "far" pointer and > would cover their designed 20-bit address space...the extra four bits > possibly "ignored")...8-bit segment registers and 24-bit addresses - if > they were _insisting_ on this 20-bit address space stuff, not to consider > anything else - would have been even better "economics", surely? This idea is nonsense. Intel's idea was to support segmentation, a popular memory management scheme (at the time). Keep in mind that in 1976, 64KB was a *tremendous* amount of memory (PCs, as they existed at the time, had about 4-8K typically). Intel *never* expected people to overlap segments or create "huge" pointers that spanned 64K segments. They figured (incorrectly, as it turned out) that they'd have a new processor out by the time people needed more than 64K. They *were* planning on the iAPX-432 at the time (which was even less successful than the Itanium). > > Though, this "economic" factor does NOT seem at all convincing...after all, > they _DID_ put in full 16-bit registers exactly for this purpose...then > they "crippled" them down to a 1MB address space...that's a pretty > seriously wasteful way to go about things...so, "economics" doesn't ring > true as a factor in this decision... The 1MB address space limitation was actually more a constraint of pin count (40 pins) than anything else at the time. Pins are *very* expensive. Board space was very expensive. They needed to produce a CPU that would compete for sockets against the 8-bit CPUs of the time. > > That is, with my 24-bit "far" address here, that would only really waste 4 > bits when "clamped" to a 20-bit address range (though, the bits could be > "wired up" in future to extend to 24-bits, which is a 16MB range, as time > went on...when "going 32-bit", they could extend it to 16-bits for the > "segment registers")...as "bad" as that might sound, the scheme Intel did > go with is _effectively_ wasting 12-bits (out of 16 total: That's quite a > large chunk of "waste" there) by "duplication"... They could have easily put segments on 256-byte "page" boundaries if having a 24-bit address space was important. Would have increased the pin count to 44, though (which wasn't a standard package at the time, and would have been rejected by engineers). > > Also, thinking about the actual chip implementation itself, "addition" of > addresses would require more "die space", surely, than to simply to > "end-on-end pairing" instead? You know, with the "pairing", you literally > send the first 16 address bus bits from the "offset" and then the remaining > 4 bits from the "segment"...literally just "sending them to the address bus > 'as is'"...the "addition" scheme requires "messing around" with the values > in the registers before you send them onto the address bus...now, they > never did implement this, so I don't know for sure, but could it even be > that this cost us a "performance penalty"? If not in execution (because it > was nicely "optimised" in the hardware) then certainly from the perspective > that "die space" was used up for implementing the "address addition" > circuitry that could have been devoted to something else...another > instruction or more circuitry to improve instructions already > present...something like that...especially because, of course, they were > juggling around less "transistors" at the time...the "die space" a little > more "precious" back then because they couldn't pack as much onto a chip in > those days, as they can today... Yes, the transistor budget had a *lot* to do with it. > > On the contrary, the "economic" argument doesn't ring true at all...because > what Intel did finally go with was a touch "extravagent" (special "segment > registers" rather than just "re-using" the general-purpose registers, as > per what was quite typical prior to this...effectively wasting 12-bits of > these new 16-bit registers they'd introduced...eating up "die space" on the > more complicated "addition" operation)...I mean, in adding _full 16-bit > segment registers_ they _ALREADY PAID THE PRICE_ for a 4GB address space > but, weirdly, "crippled" it down to 1MB...so, it doesn't really sound like > it was an "economic" case because, you know, they _PAID_ for the 16:16 > register pair but then delibrately _under-used_ it and required adding in > more complicated circuitry to deal with that "underuse"...no, no...it seems > Intel were not being at all "economic" here...they were being actually > really rather "extravagently wasteful"... You don't understand segmentation. It's not about address space expansion. > > As I say, if "economics" were a factor then, logically, I'd say that 8-bit > segment registers for a 24-bit "far" address - 8:16 - without the > "addition" nonsense would have been the "cheapest"...yes, there would be a > lack of "symmetry" there...but, then again, if we look to the '386 and > 32-bit, we can see that Intel don't have a problem with that because the > segment registers are _still_ 16-bit, even in "32-bit mode" for a 16:32, > 48-bit "far" address...in fact, if we look at Intel's designs throughout > the x86, then "lack of symmetry" has _NEVER_ been a problem for them... Again, you don't understand segmentation. Address space expansion is *not* its primary purpose. Protection is. The fact that Intel did not include protection (and implement true segmentation) until the 286, haunted them for 20 years. > Hmm, I'm not sure...it doesn't sound particularly "logical" to me at > all...and Rene has replied to you here that he knew someone who was around > at Intel at the time, who didn't think it was particularly "logical" > either...plus, this is _VERY UNUSUAL_...no other common chip out there ever > did implement anything so "weird" as this... Rene says lots of things. And there were a *lot* of people at Intel at the time. Just maybe some of them didn't really have all the insights into the design of the 8086? > > "Economically", you're _PAYING THE PRICE_ for a potential 4GB address > space...but then delibrately _under-use_ it...that's not particularly > "logical" either...you know, it's like buying a Ferrari and then > "modifying" the engine so it's no better than a typical "family car" (buy > 16:16 then "cripple" it to act as a 4:16)...like: Buy a "family car" in the > first place (buy 8:16 and just ignore the top 4 bits...if that sounds > wasteful to "ignore" the 4 bits (though, you don't have to do that...I'm > just assuming the "1MB address space" was a "set in stone" design decision > :), then just remember that the "real mode addressing" is far worse, > effectively wasting 12 out of 16 bits...far more wasteful a scheme)...it's > _cheaper_ for the same performance... Again, you don't understand the purpose of segmentation. > Yes; Ultimately, the true "blame" is with "backwards compatibility", in the > sense that it wouldn't particularly matter what "scheme" they chose for a > particular chip, if it wasn't for the fact that it has to be _RETAINED_ > forever in the x86 line because of "backwards compatibility" philosophy... And Intel did an amazing job of this. The fact that modern OSes, such as Windows and Linux, fail to take advantage of the powerful segmentation facitilities that Intel finally got right in the 80386 design is not Intel's fault. We'd have much more capable (and *safer*) software today if Windows and other OSes actually took advantage of segmentation and allowed applications to use segments. > > Intel daren't "break compatibility" with so important and successful a line > of chips...and, indeed, we can _see_ the various consequences that has > brought about...it's not just the "real mode addressing"...it's the 3-bits > encoding for registers, keeping them "stuck" at 8...it's some of the > "quirks" of protected mode (which you apparently don't particularly like > too much, wolfgang...can't say I blame you ;) because, of course, it had a > 16-bit implementation in the '286 first before it's 32-bit implementation > in the '386... The AMD64 processors demonstrate how they can get around this. Keep in mind, people were saying the same thing about 16-bit offsets until the 386 came along. There are lots of ways to extend the architecture without breaking compatibility. > > Basically, it's "business suicide" to mess around with the x86 line in too > "breaks compatibility" a way...I understand that perfectly...doesn't mean, > though, that I like it or that it isn't true to point out that if we > _didn't_ have "backwards compatibility", we'd actually have almost > certainly a far more superior machine and OS and software than we actually > have got... True, look at the popularity of the Itanium. Intel forgot the lessons of the iAPX-432. OTOH, it seems like the x86 family has just about reached maximum speed. So unless they do something radically different, we're not going to see faster CPUs any time soon. Have to go... Cheers, Randy Hyde
From: Herbert Kleebauer on 13 Mar 2005 15:36 Randall Hyde wrote: > "Beth" <BethStone21(a)hotmail.NOSPICEDHAM.com> wrote in message > Segment registers have nothing to do with the 8080. > Intel did not invent segmentation. It was actually a relatively > popular memory management scheme at the time (paging was taking > over, but in 1976 segmentation was quite popular; it was the basis, > for example, of OSes like Multics). Segment registers never were > intended to be "base address" registers. > > Intel used a "cheap" implementation of segmentation in the 8086, which > is quite reasonable given the state of the art at the time. > This idea is nonsense. > Intel's idea was to support segmentation, a popular memory management > scheme (at the time). > You don't understand segmentation. > It's not about address space expansion. > Again, you don't understand segmentation. > Address space expansion is *not* its primary purpose. Protection is. > Again, you don't understand the purpose of segmentation. If you think Intel used a "cheap" implementation of segmentation in the 8086, then YOU don't understand segmentation. In the x86 architecture segmentation was introduced with the 80286. In the 8086 there are only four 20 bit base address registers (one for code, one for stack, one for data and an extra one) which are implicitly added to any memory address used in the program. To allow a single 16 bit move instruction to load the base registers, the least significant 4 bits are fixed to zero (and therefore need not be stored). Using base address registers to allow shorter program addresses has nothing to with segmentation. This is part of the address calculation and not part of the address translation (segmentation or paging). But segment register and segmentation sound much better than base address register addressing and Intel always was good at marketing. Only with the introduction of the protected mode this register became segment registers, holding a entry into the segment table.
From: NoDot on 13 Mar 2005 20:55 Annie wrote: > On 2005-03-13 BethStone21(a)hotmail.NOSPICEDHAM.com said: > > > Yep. > > Troll. Try spammer. The_Sage is a troll. -- The above was written by NoDot. Visit the Website of NoDot: <www.geocities.com/nodot1989/>
From: Beth on 13 Mar 2005 23:16 Rene wrote: > Tom wrote: > > I'll be fine learning more from you, Mr. Hyde. Thank you very much for > > your kind interest. And thank you for Webster. > > Given the situation, whatever i could say would have > no effect, but, just in case you would not be utterly > stupid... > > Randall Hyde is the individual who actually the most > damages Assembly. Rene Tournois is an individual who also has an assembler - RosAsm - that isn't as popular as Randy's HLA... Enough said, yes? ;) Beth :)
From: /o//annabee on 13 Mar 2005 23:41
Pý Mon, 14 Mar 2005 04:16:42 GMT, skrev Beth <BethStone21(a)hotmail.NOSPICEDHAM.com>: > Rene wrote: >> Tom wrote: >> > I'll be fine learning more from you, Mr. Hyde. Thank you very much for >> > your kind interest. And thank you for Webster. >> >> Given the situation, whatever i could say would have >> no effect, but, just in case you would not be utterly >> stupid... >> >> Randall Hyde is the individual who actually the most >> damages Assembly. > > Rene Tournois is an individual who also has an assembler - RosAsm - that > isn't as popular as Randy's HLA... > > Enough said, yes? ;) I think you fail to see that RosAsm has some users, whereas HLA has *none*. Or maybe you will write LuxAsm in HLA, then we will have NONE + NONE users for HLA :))) Add in Evenbit and we get NONE+NONE+NOP, add in Percival and we get NONE+NONE+NOP+-SQRT(ZILCH) Hehehe. > Beth :) -- I am shy |