Posted on 04/07/2010 1:22:51 AM PDT by Yosemitest
Summary
(Excerpt) Read more at microsoft.com ...
save
That’s really the problem here, because the last time I looked at this sort of thing (ie, moving Bliss source to a new platform), a LOT of the details of the internals of Bliss aren’t documented outside DEC, and they probably were not documented inside of DEC much either. They were carried around in a few people’s heads, much like the details of some of their PDP-11 OS’s.
“The complications with Linux running Windows applications...” ? The only Windows application it would need to run for this purpose would be Visual Studio. ndiswrapper would be out of the picture.
Ping
The target back in that day was RISC architectures. The days of CISC architectures was drawing to a close - and we can now say that CISC effectively lost the architecture race.
I’ll see just how many people tell me otherwise before I educate them as to why this is.
You are mixing up two different replies I made to two different problems.
Somebody had mentioned using wine to run windows apps on linux.
I mentioned that the best way to do this was with a legitimate windows guest.
The historic roots and the “grand architecture” ideas behind VMS are also from the 70’s. Much of the IO device architecture of VMS (and now Windows) actually goes back to RSX-11, not VMS.
The most popular CPU of today is a CISC (Intel x86 line and its AMD clones) but it hasn’t really been expanded much in logical architecture for a couple of decades, nor is there a rush to develop more CISCs. RISCs are easier to pipeline, but what ever happened to the Sparcs that looked for a while like they were going to take over the world?
Actually it was I who mentioned wine in the context of trying to cobble up a development environment on Linux to create a VMS environment. It would be just for the sake of Visual Studio.
Ah!
Ok.
The current x86 products today aren’t CISC any more. They have so many transistors available that what is really happening is that the chip is translating the x86 instructions in your software into what Intel calls “micro-ops” before issuing them further - effectively converting CISC to RISC. Much of the internal P6 (and later) architecture is about the RISC portion of the execution engine(s) in the chip. At the internal micro-architecture level, the current Intel products are much more RISC than they are CISC, but they pulled a very smart move in putting a translation engine on top of their micro-architecture to preserve the customer’s software-for-CISC investment. This is the one reason why Intel now dominates the CPU market, and the “true RISC” vendors now have to look to embedded markets for their survival.
A true CISC processor would be like the original Pentiums. Today, I can’t think of any true CISC-on-a-chip platform left out there - every chip architecture out there is a tantamount admission that RISC won the architecture fight, with large caches (or “register files” in original RISC lingo) operating at CPU clock speeds 1:1, speculative execution, one (or more) instructions issuing per clock, deep pipelines, branch prediction, speculative execution, etc.
Out-of-order execution isn’t a RISC concept, so we can’t claim that’s an admission of RISC wins, but it also sure as heck isn’t a CISC feature either.
In the end, CISC architectures are no more. Things like the S/370, VAX, DG’s Eclipse, National’s 32xxx, etc - all done and gone.
But then looking at the market, we have to ask “What happened to ‘true RISC’ architectures like SPARC (and MIPS, and, and, and...) ?”
Simple. Unix (and all its variants) became wildly popular on x86 chips. Once you’re talking of one Unix vs. the next one (eg, Solaris vs. Linux, BSD, OS X, etc), are you willing to pay a premium for the SPARC architecture vs. the latest commodity x86 platform? Nope. What does SPARC give you that the latest commodity x86 chipset doesn’t? Maybe better virtual memory support - but nothing that the user will see. SGI used to be able to flog their graphics performance over the “Unix on a x86 box” alternative - and they lost. Today, SGI has pretty much given up on the MIPS, and SGI is pretty much done in workstations as well.
Microcoding is a very old idea which was inherently RISC. I guess you’re really talking about the amount of chip real estate dedicated to RISCesque architecture (as we know it in the latter day). Big buffers, big pipe lines, etc.
C Cleaner gets rid of more junk than any other utility, but as is right now, I'm leaving it alone.
VAX/VMS file systems did need periodic defragging. My team found out the hard way when a startup procedure that allocated a large contiguous file for the sake of a later application failed to do so, resulting in the entire system refusing to come up.
Wow - your post has a ton of good info. Thanks.
I’m also talking about what is responsible for the performance delivered to your application. Without the new micro-architecture, Intel’s “pentium” line of CPU’s would have hit a wall years ago for no other reason than heat dissipation. There are limits on how fast you can clock a CISC CPU and be able to remove the heat, and CISC CPU’s (which used multiple clocks per instruction) needed ever-faster clocking to achieve throughput.
With the RISC approach, sure, clock speed mattered, but performance gain was had by getting instructions down to one clock per issue and going deep in a pipeline to “pre-execute” instructions with functional units of the CPU that weren’t being used on the current instruction, in effect getting more work out of the CPU per clock cycle.
There were few applications that needed a contiguous file, so in most practical applications, the tendency of ODS-2 to fragment wasn’t a “full stop” problem, merely a performance annoyance.
The big annoyance in the VMS community used to be DEC’s unwillingness to DEAL with the ODS-2 frag problem tho, necessitating companies like Executive Software to put out Diskeeper.
If there is one weak point to VMS, it was the file system. RMS was never truly competitive in the business application world with IBM’s filesystem offerings, and ODS-2 wasn’t as robust as it needed to be in disaster recovery either. DEC should have gone to a built-in database system on top of a log-based filesystem. If there was one blind spot DEC had, it was filesystems in general. DEC just never seemed to “get” the importance of filesystems to scalability and reliability in “big computing” shops. They needed better filesystems, a better directory structure, better backup infrastructure and handling, as well as better backup media. The TK-50 was a steaming pile of poop as far as I was concerned, and we needed something with higher density than a 6250 bpi 9-track.
That’s where IBM always excelled, IMO. IBM did (and always has done) “Big Storage” better than most all other computing vendors.
That said, even DEC’s lackluster offerings are a huge step up from the nonsense on WinNT. Cripes, FAT32? What a flaming pile of crap that was. NTFS is a nice start in the right direction, but Microsoft has yet to deal with the issue of backups competently. That’s one place where OS X has done a masterful job with “Time Machine” - it is conceptually easy for the user to deal with, it is foolishly easy to set up, and it “just works” most of the time.
No desktop OS has a real filesystem any more, tho, and now the assumption is that for structured storage, you’re going to use a RDBMS.
God, that is great. I haven’t seen that bit of trivia in forever.
Kind of like HAL. A 1 letter shift off of IBM.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.