Slashdot Mirror
IBM joins Trillian project
IBM will be
joining the Trillian project to port Linux to Merced. The other
members of Trillian are Intel, VA Linux Systems, SGI, Hewlett-Packard,
and Cygnus Solutions. Linux will be shown
running on a
simulated Merced today at the Linuxworld conference.
To do what, specifically?
To switch between two separate instruction sets, I'll believe. You need more decoding logic, but it can be done fairly easily.
To allow programs to be written in microcode, I doubt - microcode has a very low code density, which leads to many, many problems. RISC is just as easy to optimize, so you don't gain much for your pains.
Ok... Their marketing department calls these RISC instructions, and I call them microcode bit vectors. The article you cited points out itself the differences between this and conventional RISC instructions - RISC instructions don't contain as much internal control state information. They also are usually one machine word in size (32 bits on most PCs, 64 bits on most workstations). These bit vectors are much longer, which leads into the main problem with this approach, which I mentioned in other responses - very low code density.
By writing in microcode, you skip any decoding latency that might exist, but you end up having to transfer several times more information than you otherwise would. This means it takes several machine words to specify each instruction, and several bus cycles to load each instruction (full bus speed != one instruction per bus clock). You could put in a wider memory bus, but the same problem applies - your instruction stream bandwidth just went down a lot. As memory bandwidth is one of the main limiting factors for system performance, this will hurt, a lot. Additionally, the instruction cache can suddenly hold far fewer instructions - you either need a bigger cache to compensate, or suffer through many cache misses.
I am very surprised that NextGen actually built a chip using this approach. It's an interesting idea, but as I state in other messages, conventional RISC is almost as easy to decode and doesn't suffer from the code density problems described above.
The question is, does the K7 bus do what the Nx586 bus did and what the Socket 7 motherboard bus did not -- can it bypass the 80x86 decoder?
I strongly doubt it. No mention of this was made in any of AMD's releases, there is no pressing market demand for it, and it would probably _worsen_ performance, as described above. What they _could_ do is allow an additional RISC instruction set, which would accomplish much the same thing, but it is open to question whether the (very substantial) additional design effort would be worth it for their target market.
Intel is doing something similar to this with the Merced, with x86 and VLIW modes, but that design has its own problems.
Anonymous Coward complains:
The Alpha is an established 64-bit standard, and I can understand its manuals.
Yes, the Alpha is very good.
I cannot understand the manuals for the Merced.
You don't have to. It's the kernel, gcc and glib people who do. Write in C, it's safer.
It is possible, though usually inefficient, to hand-code for the Alpha. It is impossible for the Merced.
Hand coding is never impossible. A big pain in the burro, but not impossible.
Alpha already is running Linux. Not so Merced.
As the article indicates, Merced is already running Linux, to the extent where Merced exists. We're already ahead of the NT and Monterrey projects for Merced.
Why are we wasting time with the Merced? It is nothing but welfare for Intel.
Two reasons. First, we want to support everything, that would include Merced by definition. Second, Merced will have lots of marketting bucks behind it, that will make it popular. We certainly should support the more popular platforms, even if they have deficiencies.
Alpha has been around for years, and it has demonstrated its worth again and again. It is the architecture of the future.
I agree.
Who needs Merced?
Intel does, to survive the future. The rest of us do, because Merced will make 64 bit platforms popular, and in the computer world, popular becomes inexpensive very quickly.
----
----
Open mind, insert foot.
From the Athlon info at Tom's Hardware it looks like the processor has fewer pipeline quirks than the Pentium line, so K7-specific compiler tricks would be less important. Of course anything big on 3D graphics (or any other FP or Integer matrix applications) should check if it's a K7 and make use of the new, improved 3DNow instructions.
----
----
Open mind, insert foot.
I'm going into my fourth year of Computer Engineering, focusing on chip design. The short answer is that it isn't possible to bypass the instruction translators. They aren't translators per se, but something closer to macro expanders.
A CISC instruction (or to a lesser extent, even a RISC instruction) is a concise way of saying that you want the chip to do something fairly complex. For both RISC and CISC processors, these instructions have to be expanded out into a series of truly elementary hardware operations for the chip to perform. RISC instructions tend to be a lot simpler, and are a lot closer to the final "microcode" that controls the various parts of the chip, but they still need _some_ decoding to be processed.
The statement that the K7 (or Pentium-whatever) has a "RISC core" is a bit of a misnomer. What they actually do is allow different tasks required by a CISC instruction to be executed independently. This could be thought of as breaking it into a series of equivalent RISC instructions, but no such instructions actually exist (though you could argue that "micro-ops" and "macro-ops" are close).
Short answer, as above: You can't bypass translation and write in native RISC, because there isn't really a native RISC to write in and analogous translation would still be required no matter what sets of opcodes you were using.
Hopefully this was interesting for anyone that read this far
It's there to provide an Intel-brand x86-compatible chip after Intel switches to IA64. Current users who want to upgrade and still want to buy Intel will buy it, which gets them "hooked" on the new architecture. If Intel broke compatibility, they would lose their market. x86 clones would be chosen by the masses, and people who wanted a high-performing non-x86 system would choose other processors.
If, on the other hand, people can upgrade their x86 "workstations" to Merced "workstations", they can still run their old software, while software written with the Merced in mind gets a speed boost.
Think about it: the entire point of the Merced is to place the burden of optimizing a processor's operation on the compiler rather than the processor itself. Merced's performance is totatly reliant of the quality of the compiler.
For the VLIW instructions, yes. However, it wouldn't cost them much space to put in x86 optimizations. Heck, most of them are already present in the Merced hardware - pipelining, superscaling, and branch prediction are still there. x86 emulation would just require a second instruction decoder and a bit of extra glue logic.
The reason that the compiler is a bugger is that it's difficult to use _VLIW_ properly outside of hand-coded assembly.
IMO, the Merced will either take a 1.5x speed hit over straight x86 clones, or will require 1.5x as much silicon. I'm betting that Intel will throw extra silicon at it and wind up with a chip that runs x86 code at reasonable speed but that costs twice as much as a Pentium-III to fabricate.
Did I mention that it will also cost a freakin fortune?
I strongly suspect that they'll release a cheaper low-end version with smaller cache, just as with the Celeron/Pentium/Xeon spectrum. They need something to offer in the x86 regime, and they need consumers to upgrade to something Merced-compatible if they want to keep their market share while moving on with the Merced. If they don't do this immediately, they'll do it reasonably soon afterwards.
GCC is a fairly good compiler for x86, even when compaired to commercial compilers. GCC is really getting better every day for x86, literally.
But if you compare Alphas with True64-UNIX (formarly DEC-UNIX) and commercial compilers to Alphas running Linux using GCC, there is a HUGE gap in preformance. There is a simple solution though... Get the GCC guys some 21264's ASAP ;-)
BTW, IBM is seems to putting faith into other people's CPU's for Linux ports is a popular idea now, check MU for a story on IBM porting Linux to PowerPC 405.
I am using "microcode" to refer to the final signal patterns on the control lines during each clock, which may not be the standard usage. Re. MUX vs. table lookup, both take a significant amount of time, which is what I am getting at. By making your instruction opcode a huge bit vector specifying the state of all control lines for the current clock and possibly the next few clocks, you could eliminate the decoding, but at the expense of a silly amount of code bloat, which IMO is impractical (among other things you'd need several memory reads to read each opcode).
I readily agree that complicated CISC translation takes longer than RISC translation, but IMO going any farther than RISC gets impractical very quickly.
I've heard plenty about the effort to port Linux to IA-64, but I don't think I've come across a single article on MS's efforts. Surely they are working on it as well.
Now, I know that their development model is in no way open, but I'm still surprised that I haven't heard reports about the transition to Win64 (or whatever it will be called). Perhaps they are so bogged down trying to get W2K to a beta stage so they can finally ship the thing that they aren't focusing on IA-64 yet.
anyone know?
--Lenny
My understanding is that the Merced is x86-compatible. They added a new processing mode in which the Merced's new instruction set and new register structure are accessible, I think.