md89mch@cc.brunel.ac.uk (Martin Howe) (05/25/90)
In article <1990May22.203656.1091@xavax.com> alvitar@xavax.com (Phillip Harbison) writes: >Binary compatibility might be a worthwhile goal, since it would allow >the software from the previous generation to run on the new machine. >However, none of the 16-bit processors maintained binary compatibility, >so what is gained by propagating an 8080-like architecture? >Nothing, in my opinion. ^^^^^^^^^^^^^^^^^^^^^^ I agree; the problems it brought are worse than the benefits which, it is apocryphally held, are that it made code conversion easier (8080/5 -> 8086). There were automatic translators for this. YUKK ! In article <54810@microsoft.UUCP> markha@microsoft.UUCP (Mark HAHN) writes: >segmentation: >it's a problem because: (1) loading a segment register takes ~10 times >as long as a 'normal' register load, even across all family members. Granted, but with 2**32 byte segments it should not be as necessary to change segments. It's a problem on the 286 and below, though, and it doesn't help with supervisor calls (change of CS and maybe everything else). >the 286: it also seems just plain perverse to stick the ring number >(and a tag bit) in the low bits of each selector; maybe Intel was waging a war >against data larger than 64K. Descriptors are 8-byte objects. Hence address within [LG]DT of descriptor associated with segment register value nnnn is (nnnn & $FFF8) - no shifting or adding ! The "tag bit", officially called Ti selects GDT or LDT - table index. >part of me mourns the passing of segments, because it's obvious that >they are a big part of the influence the 432 exerted. (of course, >this only applies to the chips that have protection, the 286 and sucessors. >I wonder if anyone will ever attempt to do an object/capability system >with the heaps of old 286's out there. if someone finds a niche, the >hardware is incredibly cheap. the thought of hundreds of AT motherboards >wired together brings tears to my eyes, though, both ways! I would like to have seen some sort of capability based x86 (x > 4) chip using segmentation as a basis. However, you'd probably need 32-bit segment names and it would clutter up the 86-chips even more. Hence the i960XA, which seems to have died. Oh well. -- - /| . . JCXZ ! MOVSB ! SGDT ! iAPX ! | There are many kinds of revenge,but \`O.O' . Martin Howe, Microelectronics| none so sweet as Cats revenge ! ={___}= System Design MSc, Brunel U. | - Hodge ` U ' Any unattributed opinions are mine -- Brunel U. can't afford them.
gerry@zds-ux.UUCP (Gerry Gleason) (05/30/90)
In article <1527@Terra.cc.brunel.ac.uk> md89mch@cc.brunel.ac.uk (Martin Howe) writes: >In article <1990May22.203656.1091@xavax.com> alvitar@xavax.com >(Phillip Harbison) writes: >>so what is gained by propagating an 8080-like architecture? >>Nothing, in my opinion. ^^^^^^^^^^^^^^^^^^^^^^ >I agree; the problems it brought are worse than the benefits which, it is >apocryphally held, are that it made code conversion easier (8080/5 -> 8086). >There were automatic translators for this. YUKK ! As much as I don't like all the architectural oddities that have developed through this process, but I disagree with your assessment of automatic translators. Sure they produce that typically runs slower than the original on last generation's processor, but they are an important way to get programs up and running quickly without a lot of re-engineering, thus gaining time for compilers, tools, applications to be written for the new architecture. Of course, today we use C almost like a universal asselbly language, making this type of compatibility much less important. >I would like to have seen some sort of capability based x86 (x > 4) chip >using segmentation as a basis. However, you'd probably need 32-bit segment What I'd like to see is for somebody to add support for type objects to their RISC design ala the SOAR idea. With more tools, languages, and systems build with object oriented concepts, I'm certain the market is ready for this type of processor. From a software perspective, you can build robust software much more easily with all the run-time bounds and type checking these environments provide, but without some hardware support, it is very expensive in performance. Any RISC architects care to comment on this, or should we take you silence to mean it's a hot project, and no one can talk ;-). Gerry Gleason