David Weaver
IBM Open-Sourcing AIX or Power?
In a new article (http://www.theregister.co.uk/2006/08/16/ibm_sun_open_source), The Register interviewed IBM about open source projects and strategy. IBM spokespeople offered some intriging comments, containing some amazing (and entertaining) insights. I'm irresistably compelled to have a little fun and share them here ...
When asked if/when IBM would be following Sun's lead and open source its AIX operating system or implementations of its Power processor architecture, IBM replied,
- "Open source is about communities, not releasing ... large pieces of code that nobody is interested in or contributing to"
Good point -- 4,500,000 downloads clearly indicate that no one out there is interested in OpenSolaris. Those 5 million lines of source code sure are sitting on the shelf, getting terribly dusty.
As compared to all the downloads of open-source AIX, of course. Or the open-source Power implementations -- IBM has open-sourced so many (zero) Power implementations, why, nothing else compares.
...but ... but ... wait a minute, what was the original question? I almost forgot. Oh yes, if/when would IBM open-source AIX and Power? IBM's answer, buried in verbal mice-type, somewhere in the midst of providing a new, definitive description of the meaning of open source, was "Um ... well ... NO, IBM isn't open-sourcing either AIX or Power". (Glad I had my reading glasses on, or I might have missed it!)
Then there was another fun nugget in the article:
- OpenSolaris and OpenSPARC are not "great examples of tremendous traction"
Regarding OpenSolaris (the most robust, scalable operating system on the planet) -- "ditto" the earlier comment about 4.5 million downloads. No traction there ... none at all.
Regarding OpenSPARC -- the vast number (zero) of Power processor implementations that IBM has open-sourced, especially current ones (IBM says "no way"), gives it tremendous credibility to comment on open-source hardware projects, so OpenSPARC must not have any traction, despite its tons of downloads. And there have been soooo many open-source hardware projects of this magnitude before, that OpenSPARC must be just a "me-too" project. (including OpenSPARC, the exact number of such projects would be ... yes, that's right: one).
Nowadays, it is so "last century" to open-source your most up-to-date, 32-thread, 8-core, 64-bit processor; it seems like everyone is doing it!
(...but, wait -- everyone who has a 32-thread, 8-core, 64-bit processor has open-sourced it. Notably, that big company who started it all ... the one known for innnovation, the one with the three-letter name [spelled S-u-n])
So check out The Register article -- it's fine (and fun) reading! 
[ T: OpenSPARC ]
Posted at 05:06PM Aug 16, 2006 by dweaver in Sun |
Intro to UltraSPARC Architecture -- #2
Sun's new Niagara ("UltraSPARC T1") processor is not only a new implementation, but the first implementation of a much-enhanced processor architecture, which we've named simply the "UltraSPARC Architecture". To reflect that it's a living architecture, we've named the first version of the architecture spec UltraSPARC Architecture 2005. The date in the name gives an indication of when that revision of the architecture was released.
Note that the full UltraSPARC Architecture 2005 document is posted on the web (at http://opensparc.sunsource.net/nonav/opensparct1.html ). It is available in two "editions" -- Privileged and Hyperprivileged:
- The Privileged edition describes the full Nonprivileged (application software) and Privileged (operating system software) levels of the architecture. It's appropriate for those writing application software, writing a code generator, or writing/porting operating system software to run on top of existing Hypervisor firmware (such as on a SunFire T1000 or T2000 system).
- The Hyperprivileged edition describes the Nonprivileged, Privileged, and Hyperprivileged (hypervisor/virtual machine firmware) levels of the architecture. It adds about 100 pages of low-level details that are invisible to application and O/S software; they're only needed by those writing hyperprivileged firmware ("Hypervisor" code) or designing their own processor based on OpenSPARC.
- UA 2005 lists the specific conditions under which each exception may be raised, for every instruction
- UA 2005 clarifies relative trap priorities
- UA 2005 closes many old implementation dependencies
- Sun's VIS 1 and VIS 2 instructions have been added
- the GSR register has been added
- Hyperprivileged mode has been added (including several hyperprivileged registers, a few hyperprivileged instructions, and effects on the Tcc instruction and the trap model)
- the privileged SIR instruction is now a hyperprivileged instruction
- the privileged VER register is now the hyperprivileged HVER register
- Privileged instructions ALLCLEAN, OTHERW, NORMALW, and INVALW have been added
- An intermediate "zero" state is allowed to be observed by Block Store instructions
- Architectural features are now classified and tagged, to allow smooth architectural evolution (addition and deprecation of features, over the long term)
- There are now two classes of "deferred" traps; SPARC V9 "deferred" traps are now "resumable deferred" traps
[ T: OpenSPARC ]
[ T: UltraSPARC ]
Posted at 01:14PM May 01, 2006 by dweaver in Sun | Comments[3]
Intro to UltraSPARC Architecture -- #1
Sun's new systems based on the Niagara ("UltraSPARC T1") processor seem to be causing quite a stir in the market. Not only is the T1 processor's implementation new, but it is the first processor that adheres to a revised processor architecture specification.
With this posting, I'll embark on a series of posts to introduce this new processor architecture, named UltraSPARC Architecture 2005. We're completing the final touches for external publication of the actual specification; it should be posted on the web (on http://OpenSPARC.net and on the Sun processor web site ) within a month. (to be notified when it's posted, Login to the OpenSPARC site and visit this OpenSPARC page to register for the opensparc-announce mailing list)
The first question many people (even some inside Sun!) ask about the UltraSPARC Architecture is "why is a new architecture specification needed? Can't/shouldn't we just refer to the existing SPARC V9 specification plus a User's Guides for specific processors, like we've done in the past?"
Well, we could have continued down that path. However, it would have required software developers (probably the largest group of readers) to consult not just two, but multiple documents ... primarily SPARC V9 plus various processor implementation documents. With the UltraSPARC Architecture, readers can go to a single document to understand all they need to know about a whole generation of UltraSPARC processors, with all the most up-to-date information. A few may also want to consult implementation-specific architecture supplements.
Other factors motivating the UltraSPARC Architecture document involve the state of the SPARC V9 specification:
- it is now over 10 years old
- its hardcopy version contains ~90 known errata (although the PDF softcopy at SPARC International has been updated with corrections to those bugs)
- doesn't enumerate all exception-causing conditions for each instruction
- contains many ambiguities (one example: trap priorities)
- doesn't contain any of the numerous standard Sun extensions (many of which have been present for over 10 years).
(fortunately, I can say all that about SPARC V9 without fear of insulting its editor
)
- describes processor behavior much more precisely than did SPARC V9
- describes all the Sun architectural extensions (for example, VIS 1 and VIS 2 instructions, GSR register, and global register sets)
- won't be a static document -- if/when documentation bugs are identified, they will be fixed and a revised version will be posted on the web
Ambiguities that were present in SPARC V9 have been cleared up whereever possible in the UltraSPARC Architecture document -- and when not, are spelled out as explicit implementation dependencies. In each instruction description, all exceptions that can be triggered by the instruction are now listed, along with the precise conditions that can cause each exception. Whereever possible, old implementation dependencies were resolved and closed, so there are fewer gratuitous differences between implemenations.
Does this specification replace SPARC V9? Yes and no. SPARC V9 is still the standard by which (64-bit) SPARC implementations are measured; compliance with it is a prerequisite for using the trademarked name "SPARC". And SPARC V9 covers 64-bit SPARC processors from all vendors (primarily Sun and Fujitsu, as I write this), whereas the UltraSPARC Architecture only applies to UltraSPARC processors. But for anyone using a Sun UltraSPARC processor, the UltraSPARC Architecture spec should become the reference of choice.
I mentioned that the UltraSPARC Architecture 2005 describes a whole generation of UltraSPARC processors. Does that mean that an update will be published whenever a new processor "family" is introduced? Yes!
In subsequent postings, I'll assume that the reader has at least passing familiarity with the SPARC instruction set architecture, and will begin describing the new features specified in the UltraSPARC Architecture 2005 -- including Hyperprivileged mode, Chip Multi-Threading (CMT) control, new global registers set organization, new privileged instructions, and how UltraSPARC Architecture is set up to smoothly evolve over the coming years while continuing to maintain compatibility for existing SPARC application binaries.
| David Weaver | |
| UltraSPARC Architecture | |
| Sun Microsystems / Scalable Systems Group (SSG) |
[ T: OpenSPARC ] [ T: UltraSPARC ]
Posted at 05:12PM Jan 11, 2006 by dweaver in Sun | Comments[0]
SWaP in the real world?
As a Sun employee, I'm "supposed" to be saying good things about Sun's products and marketing efforts, right? Last month, I expressed a doubt, and someone from outside the company gave me a quick education on the "real world".
As we were launching the new UltraSPARC T1-based systems in early December, I attended an Sun-internal presentation on the new systems. I heard about a new system metric (Performance / (Space x Watts)) with which competing system configurations could be compared, and a cool on-line tool (http://SimDataCenter.sun.com) that could compare in real-time how various system combinations (both Sun's and competitors') would affect Performance, Space, Watts, Cooling, etc. I wasn't so sure that the full three-variable metric made sense in the real (that is, customers') world. A couple of days later, I commented to a friend who's an outside industry consultant a slight cynicism, that I suspected that most customers only cared about two out of those three measures (with different customers caring about different pairs).
Boy, did I get an earful and a quick education -- customers do care about all three. A client of his had just the day before asked him to help them plan out a refit of a whole datacenter -- which could not add any floor space, power, and cooling for the remainder of 2006, and oh-by-the-way they needed a 1.5x to 2x increase in processing power (throughput) this year. It turned out that Sun's new UltraSPARC T1-based systems were the only way to fulfill those requirements ... and with space, power, and performance to spare.
I'm sold. Bring on "SWaP".
Posted at 03:04PM Jan 11, 2006 by dweaver in Sun |