Article 139 of comp.sys.cdc: Path: matra.meer.net!news.spies.com!news.sgi.com!news.mathworks.com!newsfeed.direct.ca!news.he.net!cnn.nas.nasa.gov!not-for-mail From: Hugh LaMaster Newsgroups: comp.arch,comp.sys.cdc Subject: Merced dual-mode vs. Cyber-180 dual-mode (was Re: Merced a VLIW after all?) Date: Tue, 03 Jun 1997 15:22:52 -0700 Organization: NASA Ames Research Center Lines: 182 Message-ID: <3394993C.2F1C@nas.nasa.gov> References: <5mn7sf$4ei@tooting.netapp.com> <33932D4A.59E2@nas.nasa.gov> <5mvojb$fku@tooting.netapp.com> NNTP-Posting-Host: win144.nas.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (X11; U; IRIX 6.2 IP22) Xref: matra.meer.net comp.arch:76510 comp.sys.cdc:139 Guy Harris wrote: > > Hugh LaMaster wrote: : > >In today's terminology, you would call the 7600 a "superpipelined" > >machine. The 7600 did not do out-of-order issue (although > >IBM tried this at the time), nor did it do superscalar (although > >IBM apparently already had this working at the time, too). > > Does "IBM", in both cases, mean "IBM 360/91 and 3[67]0/195"? Parity error on my part. O-O-O: One, or the other, or both, but I can't remember which. Superscalar: stayed in the lab AFAIK, until rediscovered by- who? Forrest Baskett, maybe - but I don't really know the intellectual property history. And my architectural library is inaccessible right now. Somebody please help me. (Signed, Embarrassed.) > ...and, in any case, the Intel patent to which I was referring had > nothing to do with VLIW or VLIW-like RISCs or scheduling instructions in > software or anything such as that; it had to do with building processors > to run both x86 and some unnamed 64-bit instruction set; it may well be > that none of this *is* subject to a recent patent - it's not, as far as > I know, subject to the Intel patent in question. Looking at the Linley Gwennap's article, it wasn't clear to me what exactly was being patented. Sorry. It still isn't - see below for discussion of dual-mode. I always find these patent discussions very confusing. [It's my problem!! See legal disclaimer below.] > >Since x86 code performance is the key to selling any PC > >processor today, and I doubt if Intel can afford to ignore > >that any more than Intel's competitors, I would assume that > >it would have the fastest possible Pentium-Pro-like hardware > >front-end, but would also have a native RISC/VLIW mode as well. > > That's my suspicion as well, although, as the Merced article in the > 1997-03-10 *Microprocessor Report*, IA64 machines might run only UNIX > and Windows NT, not, say, Windows OT, so they may be able to get away > with having the OS include a binary-to-binary translator to run x86 code > fast, and not try quite so hard to do it all in hardware. > > (Then again, that could mean they'd have a binary-to-binary translator > to make *IA64* code run fast on the particular machine you're using, so > maybe the ability to run legacy IA64 code fast might not be worth > it....) > > >Presumably, the old register set would be a subset of the > >new register set in the new ISA. As is pointed out, the patent apparently allows both separate register sets and x86 -> IA64. > The Intel patent appears to > > 1) mention "x86MT" and "x86MF" instructions to move between > "unnamed 64-bit instruction set" registers and x86 > instruction set registers > > and > > 2) mention a (read-only?) bit in the "extension processor > control register" indicating whether the processor implements > separate x86 registers > > (although it also mentions not only a bit specifying whether the > processor can decode x86 instructions, it also mentions a bit specifying > whether it can decode *64-bit instruction set* instructions, so I'm not > sure whether that means the bits may be read-write, allowing one to shut > off 64-bit mode, or what). > > >Presumably, there would > >be a new mode on the processor which designates the processor > >being in "Merced native" mode. > > They also mention a bit in the "extension processor control register" > specifying the current instruction-set mode, i.e. x86 or 64-bit. > > (For those tuning in late, the *Microprocessor Report* article that > mentioned the Intel patent is available online, at > > http://www.mdronline.com/mpr/merced/merced.html Once again, I'm puzzled when I look at this summary. But then, I'm often puzzled when I look at computer patents, because, apparently, not many people realize that most of this stuff was already done long ago. Really. I wonder if the parties to these disputes have ever read Siewiorek, Bell, and Newell? Somebody, Mark Smotherman I think, started a thread a couple of years ago with all of the provably new architectural inventions of the microprocessor era on the list. The list was pretty short. Machines emulating other machines go way, way back, so that, in general, shouldn't be patentable. And the emphasized point in the article about dual-mode originating with Merced is directly contradicted by the CDC Cyber 180 series, designed by CDC's Canadian subsidiary in the late 70's/early 1980's. This processor series was not a big moneymaker, because it made the mistake of attempting a new mainframe series with a new operating system, network architecture, and microcode-assisted hardware architecture, at a time when the tide was turning towards TCP/IP, Unix, and RISC. However, the systems had good performance, but they were "expensive" "mainframes" in comparison to the emerging Unix/RISC marketplace. Anyway, with respect to the patent: These processors had both a 6600/Cyber70/170 mode and a Cyber 180 mode, and could be hosted either way with guest code of the other type. The idea was to build a generation or two of dual-mode machines, and then drop the 6600/etc. mode, and, they did deliver a series of native-180-only machines, IIRC, before the product line was killed during CDC's downsizing. I don't recall which machines had the dual-mode, but I think it included the 835 and 855. I guess this isn't common knowledge, just because there isn't much left of CDC, but, I'm sure anyone with access to the hardware manuals will discover that it is true. In fact, I bet you could pick up a good, used Cyber 180 and introduce it as evidence in court, along with the manuals. [Just kidding!! And, BTW, once again, I must mention that I am not an attorney, don't pretend to be one, and am not offering legal advice on the DEC Intel patent dispute or any other legal question.] > > >BTW, I wonder if any parties to any lawsuits, or anybody > >divining Intel's new stuff, have looked at whatever IBM's > >patents are for System 38 and AS/400 and compared them > >to the Intel/DEC stuff? Just asking. I have no information > >on this and have no idea if any of them are relevant. > > There are probably a number of patents; I don't know which would be > relevant, though. I suspect many of them might not be relevant to the > Intel/DEC stuff, if by that you mean the Digital patents Intel is > alleged to have infringed, unless some particular implementations of > S/38 or AS/400 used those techniques - but I don't think S/38 or AS/400 > would be any more likely to use them than other ISAs. Well, I was thinking about how the "Future System" evolved into the capabilities-based System 38, and then (System 36 was it?) a different minicomputer architecture was folded again into AS400, which is now apparently built out of special versions of the Power/Power2/PowerPC chipsets (I don't know details). The model is described in Levy's book. Anyway, I'm assuming that a lot of binary translation was done during the transitions, and guessing that there may be some related patents, not to mention the apparently (IIRC) dynamic execution of some flavors of code on some other processors flavors. (I'm obviously no expert). > There may be binary-to-binary translation patents, possibly relevant to > IA64 if B2B translation is intended to be used to get stuff to run fast, > however, given that B2B translation is, as I understand it, a > fundamental technology in S/38 and AS/400 (translating code from the > machine-indepenent code generated by the compiler into what I suspect is > the closest thing to "native machine code" before running it). Yes, it is something like that. Presumably, untrusted "code" is never directly executed, while code from a trusted compiler in the native format might be. I assume that languages like Java always have to run in interpreted mode by a trusted interpreter. -- Hugh LaMaster, M/S 258-5, ASCII Email: hlamaster@mail.arc.nasa.gov NASA Ames Research Center Or: lamaster@nas.nasa.gov Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701 Phone: 415/604-1056 Disclaimer: Unofficial, personal *opinion*. Article 133 of comp.sys.cdc: Path: matra.meer.net!news1.best.com!uninett.no!news.uni-c.dk!news.uni-c.dk!not-for-mail From: peterb@inet.uni-c.dk (Peter Bjoern) Newsgroups: comp.arch,comp.sys.cdc Subject: Re: Merced dual-mode vs. Cyber-180 dual-mode (was Re: Merced a VLIW after all?) Date: Wed, 04 Jun 1997 18:50:04 GMT Organization: None Lines: 60 Message-ID: <3395b50d.1930156@news.uni-c.dk> References: <5mn7sf$4ei@tooting.netapp.com> <33932D4A.59E2@nas.nasa.gov> <5mvojb$fku@tooting.netapp.com> <3394993C.2F1C@nas.nasa.gov> NNTP-Posting-Host: lgb232.ppp.uni-c.dk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent .99g/32.339 Xref: matra.meer.net comp.arch:76332 comp.sys.cdc:133 Hugh LaMaster wrote: >And the emphasized point in the article about dual-mode >originating with Merced is directly contradicted by the >CDC Cyber 180 series, designed by CDC's Canadian subsidiary >in the late 70's/early 1980's. This processor series was not >a big moneymaker, because it made the mistake of attempting a >new mainframe series with a new operating system, network >architecture, and microcode-assisted hardware architecture, >at a time when the tide was turning towards TCP/IP, Unix, >and RISC. However, the systems had good performance, but >they were "expensive" "mainframes" in comparison to the >emerging Unix/RISC marketplace. I agree with your point, but the NOS/VE system and CDCNET ran (run) TCP/IP just fine, including the X-Windows system. At some time, there was a Unix-like sub-system running on top of VE called VX/VE. It was not a great success since real Unix users did not consider it to be 'Kosher' Unix. For a short time, CDC talked about a native Unix for the 180 series, but then they decided to go for the RISC MIPS line with it's modified RiscOS system called EP/IX. I still have a MIPS based EP/IX system running. >Anyway, with respect to the patent: These processors had >both a 6600/Cyber70/170 mode and a Cyber 180 mode, and could >be hosted either way with guest code of the other type. >The idea was to build a generation or two of dual-mode >machines, and then drop the 6600/etc. mode, and, they >did deliver a series of native-180-only machines, IIRC, >before the product line was killed during CDC's downsizing. >I don't recall which machines had the dual-mode, but I >think it included the 835 and 855. From my (pretty good) memory, the machines that would run dual-state (as it was called) were : 810, 815, 825, 830, 835, 840, 845, 850, 855, 860, 865, 870, 875. The models ending on 0 were cpu-wise roughly equivalent to the model just above it ending on a 5, but the '0' models were of a newer and different technology. I don't remember exactly how they were different. Other models that would run dual-state were : 990, 995, 960. The 962, 931, 932 and the Cyber2000 would (will) only run 180-state. Regards Peter =================================================== Spambait : postmaster@127.0.0.1 ===================================================