Segmentation in real mode
in [ASM]
|
Prev: stricmp
Next: Killing Explorer
From: Beth on 16 Mar 2005 09:16 Randy wrote: > Beth wrote: > > 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. I know; _THAT_ was entirely what I was saying!! Some here suggested the segmentation might be about "8080 compatibility", perhaps...but as the 8080 didn't have "segmentation" but, in fact, use pairs of 8-bit registers to create 16-bit addresses, then changing to the completely different "segmentation" instead of just using two 16-bit registers to create a 32-bit address is _less_ "8080 compatible" than what I'm talking about... Plus, you can't run 8080 software on the 8086...it's not "backward compatible" like that, so it would always require a "re-write", anyway...wouldn't it, thus, make more sense to keep the same _style_ of "scheme" but just "increase the bitage" rather than completely alter the entire nature of the addressing scheme to something completely different and incompatible? > Intel did not invent segmentation. Again, I know; _THAT_ was what I was saying about "mainframes" and such... > 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). Not on microprocessors...but, yes, there was nothing unusual in this on other systems like mainframes...that's what I was saying pointing out that this could have been Intel trying to "move down" segmentation from those chips into their microprocessor range... But that perhaps it was a "jump too early" to do it at this point because, well, as we know, it doesn't work too well...it's too simplistic an implementation to be all that useful...when the '286 and '386 introduced "protected mode" and a _flexible_ "segmentation" scheme - user-defined segments- , then, sure, this was excellent...it came into its own there and made sense...but the earlier 8086 implementation? This was arguably a "jump too early"...fixed "segmentation" is more of a hinderance than a help... > Segment registers never were intended to be "base address" registers. Yes; The problem, in fact, is that in the original fixed 8086 scheme, they _were_ acting somewhat like that...when the '286 and '386, though, "corrected" the "segmentation" scheme to be _flexible_, _THEN_ "segmentation" made perfect and complete sense...as I say, they probably "jumped too early" in trying to get "segmentation" into their microprocessor range before, really, that range was ready for it...if you can't make "segmentation" anything but "fixed", then, truth is, you'd probably be better _without_ it...once made "flexible", though, _THEN_ it makes sense... > Intel used a "cheap" implementation of segmentation in the 8086, which > is quite reasonable given the state of the art at the time. Well, yes; But, in a sense, the argument I'm making is that it was _TOO CHEAP_ an implementation...that the 8086 would have done _better without it_...now, once the _GOOD_ (non-cheap) implementation of segmentation turned up in the '286, _THEN_ it made sense... A case of, as I say, perhaps "jumping too early"...that it wasn't really worth trying to get "segmentation" into the chip _until_ it was "non-cheap" enough to be done _properly_...that the "cheap" fixed implementation in the 8086 was, in fact, so "cheap" as to be more of a hinderance than a help... If you like, Intel were trying to move "segmentation" into their microprocessor range...a good and noble goal and it _worked_ with the '286 and '386...BUT that, at the time of the 8086, I think that it was still "too early"...that they were, in fact, trying to force something onto the microprocessors before they were "ready" for it... That is, I can see why Intel might have wanted to do this...but that I still personally think that they "jumped too early" and made a bad decision...a bit "too excited" to get this "new feature" into the chip that they weren't really considering if it was better to _wait_ before introducing this "feature"... Baseball analogy: They swung their bat too early...strike! ;)... > > 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. No, you disagree with my assessment that Intel were "jumping too early", so you feel no need for this idea...the idea itself is NOT nonsense at all... > Intel's idea was to support segmentation, a popular memory management > scheme (at the time). Yes, I _SAID_ this in reply to wolfgang that "segmentation" was used on mainframe systems and that Intel were probably trying to "bring it down" to their microprocessors with the 8086...I _UNDERSTAND_ that...I'm saying they "jumped too early" and made a _BAD_ decision to do that... > 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). I know... > 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. I also know this...I _SAID_ exactly as much before Annie "freaked out" in response to the assertion...that the 4004 was _different_ to the 8008 which was _different_ to the 8086...that chips were not typically so "backwards compatible" as they later came to be... That Intel basically had no idea and didn't plan that their 8086 design would _still_ be being used - as, in fact, the main CPU out there - nearly _30 years later_! That they had envisaged that this was just a "temporary" scheme... I've said all this...I'm being "disagreed with" using exactly what I myself suggested...how about NOT assuming I'm wrong automatically and _listening_ to what I'm saying, folks, then disagreeing when you actually _DO_ disagree...not just "presuming" you're disagreeing and then "tell me off" with _EXACTLY WHAT I BLOODY SAID MYSELF_!! :) > They *were* planning on the iAPX-432 at the time (which was even less > successful than the Itanium). Yeah; I read up about that, while getting the exact register / addressing details on the 8080... That's really what went "wrong" here...Intel were only expecting the 8086 to have a relatively short "shelf life" (certainly NOT 30 years!! ;)...and the addressing scheme on the 8086 is _HARD-WIRED_ to the specific situation of the 8086 with _no thought_ given to "expansion" because, as you say, they were planning the 432 and were expecting that to take over from the 8086 (just as the 8086 itself had taken over from the 8080 and that from the 4004 and so forth)... And that's what I meant when I was talking about "CPU families" not really being a big thing at the time...not that they didn't not do it at all (the 4040 to the 4004, for example) but that it was not "usual"...certainly not in the way the x86 "family" took off...this was simply NOT EXPECTED because no chip - not even the 8080 - had taken off as the x86 went on to do (I mean, it's _STILL_ right here with us right now, running our PCs for us to be talking here :)... This was, indeed, _exactly_ what I'd suggested was probably the case... But I still say that they "jumped too early"...indeed, in 1976, 64KBb _was_ "gigantic"...hence, it really was _TOO SOON_ to be introducing "segmentation"...it should have been "reserved" until it could be done _properly_ (as with the '286+)...because the "cheap" version of it in the 8086 was so "cheap" as to be, in my personal opinion, _worse_ than not having it and just sticking with "linear" and no "segmentation" at all... A case of it being _TOO_ "cheap" an implementation...so "cheap" that it wasn't really particularly useful...to have _waited_ before introducing it until they could do it in a not-so-cheap way that could do the feature _JUSTICE_... > > 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. Yes, again, I _KNOW_... Which is why, as I was suggesting, then using a 24-bit address (making the CPU's address range more closely match the pin count) would have been better than using a 32-bit address (16:16 _is_ a 32-bit address, after all) and then squandering it on a _fixed_ scheme which doesn't really do "segmentation" any justice because it's just _TOO_ "cheap" an implementation... Okay, a "what if?" is always a debatable topic...but I still believe it was a _bad_ decision to make and, yes, _EVEN FOR THE TIME_, it was a bad decision... After all, _WHY_ rig up the CPU to have 32-bit addresses - and _pay the cost_ of 32-bits - when, indeed, you were so "limited" by the pin count? It's not an economical or logical decision...it's, perhaps, being too "over-eager" to wedge in "segmentation" _BEFORE_ microprocessors were actually ready to take it... > Board space was very expensive. They needed to produce a CPU that > would compete for sockets against the 8-bit CPUs of the time. Yes, I'm sure...but what does that have to do with using a full 32-bits resolution addressing scheme when you're so limited by "pin count" and "address lines"? This is like saying that a car "must" have fluffy dice because it needs to win a "rally"...the two aren't directly related...the fact that the car must win a rally is true, I'm sure...but this does NOT explain or justify why there are fluffy dice in the car... Indeed, basically, what you're saying is that more or less _everything_ was "expensive" at the time...YES, I KNOW...this is why using 32-bits for addressing and then _WASTING_ 12-bits of it seems so illogical...when things are _expensive_, you attempt to "save costs"...you don't go on a "spending spree" because things are expensive (but then "conserve" when everything's cheap)...that's backwards logic... Please, STOP! Let me just show you _ONE_ thing...one simple thing...put your preconceived ideas to one side and just take this point _on merit_ for what it actually is... Right: Real mode address _ARE_ 32-bits...16-bit segment and 16-bit offset...Intel _DID_ use 32-bits of "address resolution"...yes, register bits _WERE_ expensive...yes, "pin count" _WAS_ expensive...board space _WAS_ expensive..._EXACTLY_...so, in a climate of such expense, you'd expect that they'd _CONSERVE_, not go on a wild "spending spree" to introduce things _THEY DON'T NEED_ and blindly _WASTE_ register bits... Okay, let's put it in different terms that make it obvious...let's measure the expense "in address space per bit" units... The real mode addressing uses _32-bits_ to address 1MB of memory...that's 1MB / 32 = 32KB per bit... Right, if they'd used 24-bits as I suggested...then that's 16MB / 24 = 682.667KB per bit... Hence, as register bits are "expensive", as you're pointing out, then a scheme of 32KB/bit versus 683KB/bit? "Real mode addressing" is the _LEAST_ economical method to "save costs" when things are so "expensive"...so pointing out that things are "expensive" is NOT explaining or justifying the scheme at all...it demonstrating just how _INSANE_ a decision it was... It is effectively _THROWING AWAY_ 12-bits out of 16 in the "segment register"...it is _WASTING_ them because the "addition" makes 12-bits of the "segment" and "offset" registes "overlap"... This _COSTS MORE_ to have "real mode addressing"...so, indeed, if things are so "expensive", as you point out, then that is exactly _WHY_ you don't go throwing bits away...this actually proves my point _exactly_... Remember, also, it's not just the "bit cost"..."real mode addressing" also requires an _ADDITION_ operation to be performed on all addresses...so that's going to require _SPACE ON THE CHIP_ to add the logic circuitry to perform that... The 8086 was _TOO EARLY_ for introducing "segmentation"...microprocessors were NOT ready for such a feature...and adding the "cheap" version of "segmentation" as Intel did was an unnecessarily _EXTRA EXPENSE_ that did not "help" but _HINDERED_...because "segmentation" _IS_ good when _FULLY IMPLEMENTED_ but this "cheap" version that they used for the 8086 was _WORSE_ than having NOT introduced it at all... They "jumped too early"...simple as that... > > 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). Look, just because you disagree with my personal opinion is no real to willfully ignore what I'm saying!!! I clearly said that the top 4 bits would be _IGNORED_...they would NOT be "wired up" in the 8086 (it's just a potential "option" to do this later when things aren't "expensive" anymore)...so, I _SAID_...I SAID...I SAID, I SAID, I SAID - getting the fracking message? - I _SAID_ that the top 4 bits would be ignored to keep to a 20-bit address bus... DO YOU FRACKING HEAR ME? I _SAID_ THAT...I SAID THAT...I SAID THAT... What an ignorant, arrogant and rude man you are being here...if you're going to wade in with size ten Nazi boots...and "tell me off" then do me the fudging courtesy of _READING WHAT I SAID_ before criticising it all... All you've done so far in this post is tell me things _I'VE ALREADY SAID_... > > 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. Oh, for pity's sake...kill me now and put me out of my misery... You're "diagonal reading", aren't you? Tip: Trying _reading it in full_ again...and then look at your response... Yes, transistor budget _WAS_ very important...but an "addition" scheme requires _MORE TRANSISTORS_ than the "pair" scheme...are you reading this properly? Do you see the point? Sprechen Sie English? Parlez vous Anglais? "Real mode addressing" would require _MORE TRANSISTORS_ (using up _MORE_ of that all important "budget") to deal with the "address addition" than to use "pairing" where no manipulation or processing of any kind (other than "routing" the bits through the correct locations) was needed... So, Intel were _WASTING REGISTER BITS_ (12 out of 16, to be exact) - which were expensive - and were _WASTING TRANSISTORS_ (on "address addition", to be exact, where the "pairing" scheme would NOT have used up any extra space because it needs NO kind of processing) - which was expensive - to implement a "scheme" for amounts of RAM that were _NOT_ common in 1976 because they were _TOO EXPENSIVE_, that _WASTES BYTES_ - which are expensive - on 16-byte "boundaries" to save the "memory manger" but _ONE_ extra byte per pointer to get _BYTE BOUNDARIES_ (e.g. _NO WASTE_)... Exactly, exactly...really, lay it all out...examine the expense...examine the logic...it's an _INSANE_ design decision...they were _WASTING_ "expensive" things to gain only _disadvantages_...it was a _bad_ decision... > > 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. I absolutely fracking _do_ understand "segmentation"...I'm NOT talking about "address space expansion": READ IT AGAIN (actually, read it for the first time, as nothing you've said demonstrates the slightest hint that you read anything I wrote but scanning over it "diagonally" and completely misunderstanding my points)... Look, I'm NOT...I repeat, NOT...I repeat, NOT...I repeat, NOT...talking about "address space expansion"... The 1MB address space - the 20-bit address lines, the 40 pins - are _FIXED_...I know that...so this is NOT, NOT, NOT, NOT, NOT about "address space expansion"... The point is: You could use 24-bits for that (and "ignore" the top four) or you could use 32-bits for that (and use a bizarre "addition" scheme that wastes _12_ bits, not four bits)...Intel chose to use the MORE EXPENSIVE implementation... Oh, I give up...you've been "brain-washed" or something to deny facts staring you directly in the face... > > 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 b e 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. WHAT PROTECTION? There was no "protection" on the fracking 8086! > The fact that Intel did not include protection (and implement true > segmentation) until the 286, haunted them for 20 years. YES, I KNOW! THAT'S WHAT I'M SAYING!!! It _MADE SENSE_ once "protection" was introduced...without "protection" (and "flexibility" too), it's NOT WORTH THE BOTHER... You see, I understand "segmentation" _PERFECTLY_...you are _EXACTLY_ confirming my point: You explicitly have just said that _PROTECTION_ is the primary purpose of "segmentation"...yes, _exactly_... And then you said "but Intel didn't actually introduce 'protection' until the '286"... THINK ABOUT IT: Put the two together and you're _CONFIRMING_ what I'm saying... If _protection_ is the "primary purpose" and the 8086 did not have "protections" then the 8086 "segmentation" was NOT FULLFILLING ITS PRIMARY PURPOSE... Let me try that another way, just in case you still can't read...these are the points you've just made: 1. the primary purpose of segmentation is _PROTECTION_ 2. the 8086 DID NOT HAVE protection until the '286 Hence, the primary purpose of "segmentation" was NOT achieved until the '286... That is your _OWN_ conclusion, if you only examine your own logic for a second...and that is what I've been saying all along...that Intel "jumped too early" in placing "segmentation" into the 8086 because it was an _EXPENSIVE WASTE_ until the '286, when "protections" were introduced..._THAT_ was when "segmentation" made sense... You're "brain-washed" or "blinkered" or something...because, to disagree with me, you're telling me all the exact same facts I have already said and are, in fact, completely confirming the basis of my opinion to be factually accurate...you're PROVING my case for me but somehow can't see that, thinking you're proving the opposite... > > 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. Oh, is that it? Because Rene says it, you're going to automatically say the opposite, true or not? > 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? Yes, that may be true... Oh, I give up...you're just not listening at all...you've jumped into this thread determined to disagree...it doesn't even matter that all the "facts" you're telling us, _I ALREADY SAID_...and that they are just _PROVING_ my point...you're disagreeing, even if your own words don't even back that up... You're wearing "disagree at all costs" blinkers or something because you can't even see that the "facts" you're providing us (which I _already_ provided) are _EXACTLY CONFIRMING_ what I've said... > > "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. No, I entirely understand "segmentation"...the WHOLE POINT HERE is that I'm advocating that they _SHOULDN'T_ have used "segmentation"...why? For the reasons you've already stated out of your own mouth: 1. The primary reason of "segmentation" is "protection" 2. The 8086's "segmentation" had no "protection" Hence, there was no reason to put "segmentation" into the 8086...thank you for _CONFIRMING_ that point... > > 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. Yeah; And Harold Shipman did an "amazing job" of hiding his serial killling from the authorities too...the Nazis did an "amazing job" of efficient murder in the Holocaust...the Spanish Inquistion did an "amazing job" of torturing and oppressing people... Yeah...an "amazing job" Intel have done holding things back...let's give them a prize! > 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. I know; That's why when it comes to the subject of 32-bits and such, I place the blame firmly on _MICROSOFT_ and absolve Intel because they _DID_ put it in the hardware and it is, indeed, NOT their fault if it was not used properly... "Credit where credit is due" :)... > 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. Yes; I completely agree...100%...in a sense, this is why NT has always been more robust and reliable than the 9x range because it _DID_ make better use (not full use but better use) of these facilities in the hardware... > > 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. Yeah; Again, I did _say_ this myself... Pointing out that AMD realised that once you "break compatibility" to introduce things like "64-bit" then: "in for a penny, in for a pound"...you know, once it's "incompatible", you can't get "more incompatible"...it just is "compatible" or isn't "compatible"...hence, AMD took advantage of the break in "compatibility" that 64-bits introduces to also "fix" a few other things, like adding on extra registers... And, also, it's worth nothing that Intel _DID_ also change the "post byte" stuff to introduce "32-bit addressing" (the "SIB" stuff and such)...hence, in fact, Intel _ALSO_ had an "opportunity" in the move to 32-bits to have done the same as AMD...they did NOT take advantage of that... > 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. Oh, I know; You only have to look at the x86 chip over time (and I _was_ following along from the '286 until today) and also the way Microsoft continually "patch" things all the time to realise that a creative mind can, indeed, work miracles of "extending" while remaining "backwards compatible"... I'm just wondering what those creative minds would have been able to do, if they had been devoted to _PROGRESS_, rather than devoted to work out "hacks" to keep things "compatible" all the time... > > 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. Yes; Basically, the customers "demand" the "compatibility"...I understand that...Intel understands that...but the point is, if the customer is "demanding" this, then the customer clearly _ISN'T_ always right... I mean, the truth is, customers _COULD_ make the "leap" to other systems...but they prefer "familiar"...so "compatibility" wins...but, well, if you think about it, with Microsoft always demanding a new machine to run the next OS version and software on a constant "upgrade cycle", then, in the main, most users _HAVE_ completely changed _ALL_ their software numerous times over...hence, the fact that moving to a new platform requires changing all your software, in fact, is a "false economy"... Nevertheless, as I say, I perfectly understand, though, that it matters NOT what is "true" or what is "false"...in business, all that matters is "supply and demand"...you know, if a customer is convinced that aliens are coming to kill us all then you sell them "alien defence kits"...it matters not whether the aliens really are coming or not...so long as the _customers_ believe that and you can sell them "alien defence kits" then "'tis not our place to question why" in business...you just sell them _ANYTHING_ they are willing to buy... Customers are often fearful of "compatibility"...that it could "all fall apart" and they don't really understand what's involved...or, if things were to change, what they need to do...and so forth...it's all a very "scary" thought for them...so, they all want "compatibility"...in truth, they are asking for "safe", "familiar", "cosy" and such...nevertheless, if they asked for Moon rocks and you can supply them, then supply them Moon rocks...such is the nature of business...it's just about "selling units"...the "why?" is, well, something for other people - philosophers and the like - to ponder...we're just going to make some "profit" while they're thinking it all through... That is why "business" is a double-edged sword; Truth is, people complain about the "power companies" and all the terrible things they do to the environment...but, in the end, they would NOT do those things, if there was not a "profit" in there for them to do it...they aren't "born evil" or anything...they are just more concern with "profit" than anything else, as that's what they see "business" is about... Hence, if everyone _STOPPED_ buying Microsoft or _STOPPED_ driving cars or _STOPPED_ wanting cheap "GM" Monsanto foods then "Crime&Co" would also _STOP_ what it's doing because it is _ONLY_ concern with "profit"...but it is _US_ - the consumers - who _DEFINE_ what is "profitable"...it's _OUR_ money in _OUR_ pockets that they are trying to get... Beth :)
From: Beth on 16 Mar 2005 10:17 Herbert wrote: > Randy wrote: > > 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. THANK YOU, HERBERT! At least _someone_ is not "blinkered" and "blinded" to be able to see that Intel's 8086 "segmentation" is NOT "cheap"... I think it must be some kind of refusing to accept the possibility that what we've got today _ISN'T_ the "best" it could have been...people like to believe that, you know, what we have is "cutting edge technology"...it's NOT really true, though...but it's a "persistent myth" people like to "comfort" themselves with... > In the x86 architecture segmentation was introduced with the 80286. Yes! And, in fact, if you _really_ look at what Randy wrote, he _WAS_ saying as much himself...just, for some reason, he couldn't see it... As Randy did say: 1. "You don't understand segmentation. It's not about address space expansion." 2. "Address space expansion is *not* [ segmentation's ] primary purpose. Protection is." 3. "The fact that Intel did not include protection (and implement true segmentation) until the 286, haunted them for 20 years." Which, in fact, _IS_ confirming what you and I, Herbert, are saying...but, for some reason, Randy can't see that this is what he himself has _ALSO_ implicitly said in these things... If the "primary purpose" for "segmentation" is "protection" (and not "address space expansion")..._AND_ that "protection" did not turn up until the '286... Then, well, logically: This means that the 8086 "segmentation" was NOT fulfilling the "primary purpose" of "segmentation"... That, ironically, _IS_ what Randy himself is implicitly confirming in what he said there... > 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). Yes; And is a _HIGHLY EXPENSIVE_ way to do it in the way the 8086 implemented it... ....and, after such a cost, it turns out that the 8086's "segmentation" is a poor "cheap" version which does NOT even fulfill its "primary purpose"! This is like buying a Ferrari and then never using it for its "primary purpose" - driving it - but, instead, filling it up with soil and planting flowers inside it...using it as a grossly expensive and ill-fitting-its-purpose "flower bed"... I mean, Randy glosses over it...but paying a _HIGH PRICE_ for something that is NOT even used for its "primary purpose"? Yeah, let's buy a highly expensive plasma TV...and then never use it...let's prop up a table leg with it or something... > But segment register and segmentation sound much better than base > address register addressing and Intel always was good at marketing. Yeah; Like I said, if you were following the "scheme" I proposed, they wouldn't really be "segment registers" at all...I was just using that name because that's what Intel called these registers...you know, I have to call them "segment registers" so you know which registers I'm talking about...but, really, they would (should?) have been called something else... You're quite right, the name was NOT "justified" until the '286 added _REAL_ "segmentation"...the 8086 wasn't really doing "segmentation" and they screwed up that chip by trying to "pretend" they had "segmentation" when they had no such thing, with what is - and I will never be shaken from this opinion because the _FACTS_ are right there that it's - a _DISASTER_ of a design... That "addition" thing _COSTS_ expensive bits (for the extra 12-bits which are _wasted_) and transistors (for all the "address addition" stuff required...as _ADDITION_ like this would require an "adder" circuit...while if there was no "overlap" - like my 24-bit idea - then you wouldn't require anything extra...you know, the "segment registers" would just the "upper bits" of the address and would be used to "fill in" the top part of the 20-bit address...nothing more than "routing" it to the correct address lines, no "processing" required)... ....in order to create an _insane_ address space: There are potentially up to 4,096 different ways to address the exact same memory location...and it's _NOT EVEN SYMMETRICAL_ that it _depends where the memory address is_...that is, the first 16 bytes can only be addressed one way...the next 16 two ways...and so on...up to 4,096...where it then comes back down again that the last 16 can only be addressed in one way...the 16 before that two ways... ....and, to top it all off, this actually _EXCEEDS_ 20-bits...so, it's not even doing that job properly either...and later required adding in even more needless "A20 gate" circuitry to "emulate" this _STUPID_ 8086 behaviour that it could actually _exceed_ 20-bits and "wrap around"... ....and, worse, many have stated that it "improves the memory manager"...utter nonsense...using "segments", you have to work to 16-byte "paragraph" boundaries...and this saves you two bytes in not needing to store the "offset" in the memory manager's tables...but, assuming "arbitrary length" on data, the 16-byte boundaries would waste, "on average", 8 bytes..."do the math", as the Americans like to say...waste 8 bytes, save 2...which comes to wasting around 6 bytes on average with this scheme... Alternatively, with the other scheme, the "memory manager" needs to, yes, store an extra two bytes with its "pointers"...on the other hand, for those two bytes, it gets to align data at _any memory location it pleases_ (byte boundaries or, in other words, no "boundaries" at all)...so, this way around, we're "wasting" 2 bytes but saving around 8 on average...which comes to _SAVING_ around 6 bytes on average with this scheme... So, sorry...it's simply not true...the 8086 "segmentation" does NOT make the "memory manager" more efficient...it makes it _LESS_ efficient...you talk of "wasted bytes" because of "aligning to boundaries"...this is _CAUSED_ by "segmentation", not "alleviated" by it...it _CREATES_ it, not "solves" it... [ ...and, as noted, if NOT using 8086 "segmentation" - which is a MISNOMER because it does NOT implement true "segmentation" at all - then you'd only need _8-bit_ "upper address" registers for a 24-bit address...hence, you could save another byte on those memory pointers that way... ] ....and, simply, whatever the "theory", there's one very simple way to _PROVE_ that it's a _DISASTER_...just _USE_ real mode for a while to try to program something non-trivial...then do the same in "flat mode"... I suspect some "rose tinted glasses" may be being worn by some people here that anything and everything from "ye olde days" - as they built up an "empathy" with the disasters put before them at the time - is automatically "great"...no, some things _WERE_ completely _DREADFUL_ and, however "fondly remembered", that does NOT alter that they were _DREADFUL_... I can produce - as I have in part here - a list as long as your arm why "8086 segmentation" is a total nightmare (and _was_ just the same at the time of its creation)...and that list _DOES_ dispell "myths" that it was somehow "8080 compatibility" (untrue; The chips are fundamentally incompatible and the 8080 used "pairing") or "better memory management" (untrue; It creates needless waste to manage memory this way) or "protections" (obviously untrue; There were no "protections" available until the '286...note that, with the '286, Intel _CORRECTED_ the mistake...thereafter, it _IS_ proper "segmentation" and it _IS_ good and it _IS_ fantastic...absolutely NO COMPLAINTS about '286+ "segmentation"...that, if you like, is what they _SHOULD_ have done all along...either that or should NOT have attempted "segmentation" at all, if they could not do it _PROPERLY_)... It's simply a _FACT_...it was a BAD DESIGN DECISION...and you can't get around that because it's simply a _FACT_...it has numerous disadvantages and, thus far, no _real_ advantage has been stated (and, to be honest, you'd require an awful lot of advantages here because the "disadvantages" is NOT a short list)... > Only with the introduction of the protected mode this register became > segment registers, holding a entry into the segment table. Yes; And, at this point, it was _TRUE_ "segmentation"...and Intel looked on it and saw that it was good...and that was the second day and night... It finally made sense and was a _GOOD_ feature with the '286...and, simply, I'm saying they either should have implemented that way from the start...and if that was too expensive (which it would have been) then, simply, they should NOT HAVE EVEN TRIED...because the half-arsed version of "segmentation" in 8086 was a total disaster (and, as Herbert points out, do we really even grace the dignity of calling it "segmentation" when, in fact, the truth is that it was NO SUCH THING...just "pretending" to be "segmentation")... Beth :)
From: Frank Kotler on 16 Mar 2005 10:40 Beth wrote: > Baseball analogy: They swung their bat too early...strike! ;)... So you *don't* release the 8086. IBM *doesn't* pick up your chip for the PC. And... Pity Intel didn't have you around for a batting coach. They might have been more successful. :) Best, Frank
From: Betov on 16 Mar 2005 10:58 Frank Kotler <fbkotler(a)comcast.net> ýcrivait news:42385387.F6EF6217 @comcast.net: > Pity Intel didn't have you around for a batting coach. They > might have been more successful. :) Well, you can console yourself with having her, now, as a batting coach for LustAsm. Happy? :) Betov. < http://rosasm.org/ >
From: Beth on 16 Mar 2005 12:03
Frankie say: > Beth wrote: > > Baseball analogy: They swung their bat too early...strike! ;)... > > So you *don't* release the 8086. Who said that? I was only talking about the "segmentation" feature...that was introduced too early... > IBM *doesn't* pick up your chip for the PC. IBM apparently did not pick the x86 for the PC for those reasons...they spec'd it up with a Motorola chip at first...and, from what I read, the switch was to do with "contractual obligations" and such with Intel...also, no doubt, "doing it on the cheap" as IBM weren't taking the PC particularly seriously...after all, a "personal computer"? No, no...mainframes are the future! Everyone with 640KB who runs the 5 or 6 computers that exist in the world knows this, surely? ;)... > And... > > Pity Intel didn't have you around for a batting coach. They > might have been more successful. :) Well, not really...because, at that time, I wouldn't have exactly been "born yesterday"...but it wouldn't have been all that far off (years rather than days but not that many :)...hence, it would have been illegal under child labour laws to have hired me...also perhaps advisable to wait until I'd learnt to read and write...and speak...and that kind of thing first ;)... Beth :) |