Three-operand instructions are a blessing. You don't kill a value just because it was an operand to an instruction, which is incredibly useful. Also, it makes "virtual" register lifetimes shorter, which makes it easier to shove your algorithm into the register file.
The Sparc weirdness with sethi, etc. (that constant generation stuff you alluded to) is a necessary evil to keep the opcodes a fixed length. Believe me, having fixed length opcodes is the way to go there. So you end up needing a sethi followed by an or to generate a 32-bit constant. Big deal. It's codesize neutral, and once you understand the idiom, it's not that confusing.
As for performance between a 300MHz UltraSparc and the K6/300, I doubt your K6 would come close on double-precision floating point. Server applications with a large working set (memory footprint) will also fare better on the UltraSparc. For integer applications that are bottlenecked on display bandwidth, though, you're not going to see much, if any difference between the two, and in fact the K6 will feel alot faster since it probably has highly accelerated display hardware attached to it. (Workstations seem to always have sluggish displays hooked to them, as compared to their PC cousins.) Also, if you're running Solaris on the Sparc, remember that it wasn't tuned for interactive responsiveness as much as it was tunes for batch processing. It'll feel slower, but it's cranking numbers faster.
At any rate, I'd say that Sparc is probably not a good example of clean RISC architecture these days. I don't think any architecture that claims the RISC title actually is. If you want to understand the purity that RISC originally achieved, go grab a MIPS R1000 book.
Well, that's annoying; any idea what the rationale for not including the -W warnings in the list of "all" (not-too-hard-to-eliminate) warnings was?
Yes, it is annoying, and no, I have no idea what the rationale was. I wish there was a single flag which said "Sock it to me. Give me every possible error and warning you possibly can. Make lint cower in shame at your glitch finding prowess." Alas, no single flag seems to do that.
If it were a single flag, perhaps more people would use it. Unfortunately, alot of the people who need it most are the ones least likely to use it.
EPIC adds an awful lot to the VLIW base. It encodes explicit parallelism, much like VLIW does, but it breaks away from some VLIW principles in order to make it easier to get initial compilers targeted to the platform and easier for Intel to change the pipeline later.
Traditional VLIW machines sport a "fully exposed pipeline", which means that if an instruction takes more than 1 cycle, the program doesn't see the result until it's actually written back, and the machine lets the user read the old value in the meantime. (For those of you who are familiar with the MIPS or SPARC architectures, you might recognize this concept as "delay slots". VLIW takes this to the extreme such that all delay slots are always fully exposed.) The benefit of this is that you eliminate pipeline interlocks, thereby simplifying the hardware greatly. The pipeline always knows it can issue the next instruction and never has to compare notes between packets. Very clean, and quite simple compared to the heavy voodoo modern CPUs currently perform.
EPIC, in contrast, offers a protected pipeline. From what I've read, it sounds like it's using a simple scoreboard approach to keep track of in-flight values, so it's not nearly as complex as the many register-renaming approaches that are out there; however, it's still quite a bit more complex than the traditional VLIW approach. The protected pipeline makes it easier for Intel to change the pipeline depth later. VLIW doesn't have that luxury for its native code, since changing the pipeline changes the delay slots and breaks all existing code. (Incidentally, that's probably the real reason Transmeta doesn't want anyone targeting its VLIW engine directly. It can't change the pipeline very much if anyone actually does. It's not the instruction set that matters as much as it is the pipeline!)
Traditional VLIW also encodes the exact functional unit that each instruction will be issued on. It does this either positionally (by having a slot in the VLIW opcode for each functional unit and using a fixed-length opcode), or, in the case of C6000, by assigning each unit a different portion of the opcode space and stringing together independent instructions through some bundling mechanism. The main point here is that traditional VLIW encodes the mix of functional units in the code stream. This makes it difficult to change the number or mix of functional units, but it can greatly simplify dispatch, as the dispatcher only needs to look at the instruction word -- it doesn't need to know if the functional units are busy or whatever.*
EPIC, on the other hand, relies on superscalar issue techniques to identify functional units that are available an to issue instructions to them. Again, this costs alot of hardware, but since the parallelism is encoded for the CPU, the hardest part (determining if two instructions have a dependency) is taken care of. There still needs to be a fair amount of logic in the pipeline, though, for pulling instructions out of bundles and finding units for them.
That said, there are many ways in which EPIC and VLIW are the same. EPIC features such as predication, speculative loads, rotating register files, and so on are also available in the VLIW world. (Not all VLIWs implement these though. The C6000, for instance, only implements predication, but arguably it's the feature with the greatest bang/buck ratio.) Also, explicitly coded parallelism is another unique feature of both EPIC and VLIW.
But please, don't confuse the issue by insisting they are the same. A true VLIW core has very spartan decode and dispatch hardware compared to what will be necessary to fully support an EPIC machine. The VLIW will be much more finnicky to support, but as long as you have a compiler of some sort in-between your codebase and the core (eg. the Transmeta Code Morphing software as one example), you're safe.
--Joe
[*Actually, it does need to know, if the architecture has some instructions that aren't fully pipelined. However, it only needs to know enough so that it doesn't blow up the chip. Code which issues an instruction to a unit that's busy is incorrect code in the VLIW world, and the hardware won't save you. Period.]
The Haifa scheduler and other "interesting" pieces in the backend should really help alot. From what I recall, Haifa includes a software pipeliner as well as some other block-scheduling pieces which will be very necessary to get parallelism out of this beast.
One thing I wonder is whether they're actually generating bundles, or if they're just issuing a serial code stream. For the uninitiated, a bundle is Intel's term for a group of instructions that have been marked for parallel execution. An early compiler port that's striving for correctness need not know about bundles by simply issuing bundles which contain a single instruction each. The peephole optimizer might do trivial pairing of instructions after-the-fact, but you really don't get alot of parallelism that way, trust me.
The compiler won't truly shine until the full IA-64 pipeline model, complete with instruction latencies, numbers and mixes of functional units, etc. is described in minute detail to the compiler, and the compiler has the infrastructure for stitching together tightly packed bundles. There are many techniques and optimizations that will need to be implemented in order to stitch those bundles together.
It'll be even more interesting if the compiler can tune for different EPIC iterations, since different chips will have different numbers of functional units. Although the EPIC encoding is scalable, the best performance will be reached if the code provides parallelism which matches the available hardware, rather than exceeding it, since overly parallel code may tie up more registers than is necessary and will trash the instruction cache if it's unrolled too much.
I'm willing to wager that this early GNU C port is available now because the IA64 offers a protected pipeline. IMHO, the single biggest difference between EPIC and VLIW is that EPIC provides pipeline interlocks, whereas traditional VLIW exposes all delay slots and requires the programmer to get it right. While the protected pipeline allows early compilers to ramp up quickly, it also lowers the performance ceiling for a given transistor count.
If anyone here wants to see really hairy VLIW code, go check out TI's C6000 benchmarks page. The C6000 can issue 8 instructions every cycle, and has a fully exposed pipeline. (For those of you crazy enough to click the link, the '||' are used to denote parallel instructions, and branches occur 5 cycles after they're issued.) It's an absolute blast to program by hand (it's my day job), but you don't want to program anything larger than a function in scope. You get a very strong appreciation for compiler technology too. :-) Let me tell you, I've seen some of these "interesting" optimizations coming from the C6000 compiler, and they're pretty mind-bending. I wonder how long they'll take to get these into the IA64 compilers...
I seem to recall seeing something on the 'egcs' site which said -W and -Wall together enabled a few more warnings than -Wall alone.
In fact, on this page, about 2/3rds of the way down, it says:
-Wall no longer implies -W. The new warning flag, -Wsign-compare, included in -Wall, warns about dangerous comparisons of signed and unsigned values. Only the flag is new; it was previously part of -W.
So there you have it. (Incidentally, these were the release notes from EGCS 1.1).
Using -Wall with -On, where n is >= 2 seems to enable a very large number of warnings. I actually use the following warning set with the more recent GCC's:
That catches alot of stuff, including statement-not-reached, unused function arguments, 'foo' used before assignment, mismatches between printf format and arguments. There are a few things it doesn't catch though that TI's compiler does, though. (And there's a couple things TI's compiler doesn't catch that GNU C does.)
(Yes, I used TI's C compiler, since I work for TI. Duh.:-)
XFS might be pretty cool. I could really use the GRIO (Guaranteed Rate I/O) whenever I trying to explain things to people. No more stuttering while I'm trying to remember what I wanted to say.;-)
Go grab the PDF file, and read for yourself how loaded these questions are. Here's a quick sample:
QUESTION: If you knew that the Department of Justice was proposing a regulation that would end up slowing the pace of technological innovation, would you support or oppose the regulation? Would you stringly (support/oppose) it or (support/oppose) it somewhat?
<RANT> Most regulations are not designed to specifically slow down technical innovation. How do we know a priori that a given regulation will slow down innovation? Sure, a regulation could be designed to do that specifically, but in most cases, regulations are meant to stimulate and guide industry, while curtailing harmful practices that hurt everyone in the long run. This question begs the person being asked to oppose this particular form of regulation (regulate to slow down innovation), and then tacitly extends the answer to cover all possible forms of regulation.</RANT>
*sigh*
Alot of the questions are of this form. Go read it.
Trillian is the Linux Port Project and Itanium is the Processor Formerly Known As Merced
I can't comment on win32 vs. win64.
--Joe --
Re:GNU Free Documentation License
on
GPL for Books?
·
· Score: 2
I guess it follows that one can't license the entries in the Obfuscated C contest under GPL, because even if you do get the source you have to go through such contortions to figure out how it works.
In the case of IOCCC entries, a large amount of the "intellectual content" is the obfuscation. In other words, the obfuscation is an important part of the source that cannot be done without. In contrast, the gibberish nature of the HTML that Word generates is not part of the intellectual content of the document.
Actually, that'd be 'she' rather than 'he'. Hedy was an actress. And no, I doubt she has much to do with the amount of power output a cell phone has and what that does to your noggin' as you jabber endlessly while driving down the freeway....
Seriously, I doubt people who use cell phones moderately (eg. for emergency calls, etc), rather than as a primary contact medium or as a way to 'chat with the {boys|girls|etc}' while driving down the road, will have few cancer issues.
On a different note, Blazing Saddles won't be quite the same for me now.
What's sad is I saw a blurb on CNN about a new device someone invented which automatically finds redundant frames, etc. to time-skew a program to fit more advertisements in there...
Methinks you misseth the point. The downward-travelling bubbles in Guinness are less dense than the surrounding liquid, but are still travelling downwards. The reason they travel downward is that the beer surrounding the bubble is travelling downward and is dragging the bubble with it.
Whatever. Mike Abrash went from Microsoft to idSoftware for a single game, and then went back to Microsoft. The last time I spoke with Mike Abrash (over email), he said he was working on Natural Language Processing, anyway.
This could be an interesting opportunity for some daring developer. How about this for an idea: The ADSL modems characterize the link and determine what frequencies they're receiving interference on. They use this information to control a separate AM tuner to discover if the interference is due to an AM station. If it is, they use the demodulated AM signal as an input to a noise filter to reduce the AM signal's power in the data transmission, and voila! You've nearly perfectly cancelled out at least one source of heartache.
I'm no lawyer, but I imagine it would be the user's responsibility to ensure that they've read the supporting documentation.
Generally, licenses need to be rather obvious and presented up-front. The GPL is just such a license. A small leaflet with a copy of the GPL on it and a URL inserted with the documentation would probably be sufficient.
This probably feels a little odd for a consumer appliance, but I expect to see this sort of thing come up more and more. How many of you have an EULA or other License agreement for the software in your cell phone, pager, VCR, coffee maker, telephone, washing machine, etc.? To quote the tired, old AT&T commercial: You will.
Yes, I do believe Kaa's Law applies here. How can people keep forgetting that there was no year 0? After all, everyone seems comfortable with the fact that we're in the 20th Century, even though 1901 through 1999 all start with "19". (Of course, the year 2000 will be the only year in the 20th Century to start with "20".)
Also, I note that NBC misspells millennium by forgetting the second 'n'.... *sigh* Crazy thought: Maybe the millenium (with one 'n') starts in 2000? *snicker*
Slashdot Mirror
[ears perk up] Did you say programming contest? Which one?
...and on the RISC vs. CISC debate, there isn't much difference between the two anymore. :-) Hence, VLIW and EPIC.
--Joe--
Three-operand instructions are a blessing. You don't kill a value just because it was an operand to an instruction, which is incredibly useful. Also, it makes "virtual" register lifetimes shorter, which makes it easier to shove your algorithm into the register file.
The Sparc weirdness with sethi, etc. (that constant generation stuff you alluded to) is a necessary evil to keep the opcodes a fixed length. Believe me, having fixed length opcodes is the way to go there. So you end up needing a sethi followed by an or to generate a 32-bit constant. Big deal. It's codesize neutral, and once you understand the idiom, it's not that confusing.
As for performance between a 300MHz UltraSparc and the K6/300, I doubt your K6 would come close on double-precision floating point. Server applications with a large working set (memory footprint) will also fare better on the UltraSparc. For integer applications that are bottlenecked on display bandwidth, though, you're not going to see much, if any difference between the two, and in fact the K6 will feel alot faster since it probably has highly accelerated display hardware attached to it. (Workstations seem to always have sluggish displays hooked to them, as compared to their PC cousins.) Also, if you're running Solaris on the Sparc, remember that it wasn't tuned for interactive responsiveness as much as it was tunes for batch processing. It'll feel slower, but it's cranking numbers faster.
At any rate, I'd say that Sparc is probably not a good example of clean RISC architecture these days. I don't think any architecture that claims the RISC title actually is. If you want to understand the purity that RISC originally achieved, go grab a MIPS R1000 book.
--Joe--
Yes, it is annoying, and no, I have no idea what the rationale was. I wish there was a single flag which said "Sock it to me. Give me every possible error and warning you possibly can. Make lint cower in shame at your glitch finding prowess." Alas, no single flag seems to do that.
If it were a single flag, perhaps more people would use it. Unfortunately, alot of the people who need it most are the ones least likely to use it.
--Joe--
EPIC adds an awful lot to the VLIW base. It encodes explicit parallelism, much like VLIW does, but it breaks away from some VLIW principles in order to make it easier to get initial compilers targeted to the platform and easier for Intel to change the pipeline later.
Traditional VLIW machines sport a "fully exposed pipeline", which means that if an instruction takes more than 1 cycle, the program doesn't see the result until it's actually written back, and the machine lets the user read the old value in the meantime. (For those of you who are familiar with the MIPS or SPARC architectures, you might recognize this concept as "delay slots". VLIW takes this to the extreme such that all delay slots are always fully exposed.) The benefit of this is that you eliminate pipeline interlocks, thereby simplifying the hardware greatly. The pipeline always knows it can issue the next instruction and never has to compare notes between packets. Very clean, and quite simple compared to the heavy voodoo modern CPUs currently perform.
EPIC, in contrast, offers a protected pipeline. From what I've read, it sounds like it's using a simple scoreboard approach to keep track of in-flight values, so it's not nearly as complex as the many register-renaming approaches that are out there; however, it's still quite a bit more complex than the traditional VLIW approach. The protected pipeline makes it easier for Intel to change the pipeline depth later. VLIW doesn't have that luxury for its native code, since changing the pipeline changes the delay slots and breaks all existing code. (Incidentally, that's probably the real reason Transmeta doesn't want anyone targeting its VLIW engine directly. It can't change the pipeline very much if anyone actually does. It's not the instruction set that matters as much as it is the pipeline!)
Traditional VLIW also encodes the exact functional unit that each instruction will be issued on. It does this either positionally (by having a slot in the VLIW opcode for each functional unit and using a fixed-length opcode), or, in the case of C6000, by assigning each unit a different portion of the opcode space and stringing together independent instructions through some bundling mechanism. The main point here is that traditional VLIW encodes the mix of functional units in the code stream. This makes it difficult to change the number or mix of functional units, but it can greatly simplify dispatch, as the dispatcher only needs to look at the instruction word -- it doesn't need to know if the functional units are busy or whatever.*
EPIC, on the other hand, relies on superscalar issue techniques to identify functional units that are available an to issue instructions to them. Again, this costs alot of hardware, but since the parallelism is encoded for the CPU, the hardest part (determining if two instructions have a dependency) is taken care of. There still needs to be a fair amount of logic in the pipeline, though, for pulling instructions out of bundles and finding units for them.
That said, there are many ways in which EPIC and VLIW are the same. EPIC features such as predication, speculative loads, rotating register files, and so on are also available in the VLIW world. (Not all VLIWs implement these though. The C6000, for instance, only implements predication, but arguably it's the feature with the greatest bang/buck ratio.) Also, explicitly coded parallelism is another unique feature of both EPIC and VLIW.
But please, don't confuse the issue by insisting they are the same. A true VLIW core has very spartan decode and dispatch hardware compared to what will be necessary to fully support an EPIC machine. The VLIW will be much more finnicky to support, but as long as you have a compiler of some sort in-between your codebase and the core (eg. the Transmeta Code Morphing software as one example), you're safe.
--Joe[*Actually, it does need to know, if the architecture has some instructions that aren't fully pipelined. However, it only needs to know enough so that it doesn't blow up the chip. Code which issues an instruction to a unit that's busy is incorrect code in the VLIW world, and the hardware won't save you. Period.]
--
The Haifa scheduler and other "interesting" pieces in the backend should really help alot. From what I recall, Haifa includes a software pipeliner as well as some other block-scheduling pieces which will be very necessary to get parallelism out of this beast.
One thing I wonder is whether they're actually generating bundles, or if they're just issuing a serial code stream. For the uninitiated, a bundle is Intel's term for a group of instructions that have been marked for parallel execution. An early compiler port that's striving for correctness need not know about bundles by simply issuing bundles which contain a single instruction each. The peephole optimizer might do trivial pairing of instructions after-the-fact, but you really don't get alot of parallelism that way, trust me.
The compiler won't truly shine until the full IA-64 pipeline model, complete with instruction latencies, numbers and mixes of functional units, etc. is described in minute detail to the compiler, and the compiler has the infrastructure for stitching together tightly packed bundles. There are many techniques and optimizations that will need to be implemented in order to stitch those bundles together.
It'll be even more interesting if the compiler can tune for different EPIC iterations, since different chips will have different numbers of functional units. Although the EPIC encoding is scalable, the best performance will be reached if the code provides parallelism which matches the available hardware, rather than exceeding it, since overly parallel code may tie up more registers than is necessary and will trash the instruction cache if it's unrolled too much.
I'm willing to wager that this early GNU C port is available now because the IA64 offers a protected pipeline. IMHO, the single biggest difference between EPIC and VLIW is that EPIC provides pipeline interlocks, whereas traditional VLIW exposes all delay slots and requires the programmer to get it right. While the protected pipeline allows early compilers to ramp up quickly, it also lowers the performance ceiling for a given transistor count.
If anyone here wants to see really hairy VLIW code, go check out TI's C6000 benchmarks page. The C6000 can issue 8 instructions every cycle, and has a fully exposed pipeline. (For those of you crazy enough to click the link, the '||' are used to denote parallel instructions, and branches occur 5 cycles after they're issued.) It's an absolute blast to program by hand (it's my day job), but you don't want to program anything larger than a function in scope. You get a very strong appreciation for compiler technology too. :-) Let me tell you, I've seen some of these "interesting" optimizations coming from the C6000 compiler, and they're pretty mind-bending. I wonder how long they'll take to get these into the IA64 compilers...
--Joe--
I seem to recall seeing something on the 'egcs' site which said -W and -Wall together enabled a few more warnings than -Wall alone.
In fact, on this page, about 2/3rds of the way down, it says:
So there you have it. (Incidentally, these were the release notes from EGCS 1.1).
--Joe--
Using -Wall with -On, where n is >= 2 seems to enable a very large number of warnings. I actually use the following warning set with the more recent GCC's:
That catches alot of stuff, including statement-not-reached, unused function arguments, 'foo' used before assignment, mismatches between printf format and arguments. There are a few things it doesn't catch though that TI's compiler does, though. (And there's a couple things TI's compiler doesn't catch that GNU C does.)
(Yes, I used TI's C compiler, since I work for TI. Duh. :-)
--Joe--
XFS might be pretty cool. I could really use the GRIO (Guaranteed Rate I/O) whenever I trying to explain things to people. No more stuttering while I'm trying to remember what I wanted to say. ;-)
--Joe--
Do you suppose we can get Stephen Tweedie to port ext3 to neurons once he's done?
--Joe "Journal Neuron Not Found" Z.--
Three easy steps:
- Grab the PDF file.
- Read it.
- Decide for yourself.
--Joe--
Go grab the PDF file, and read for yourself how loaded these questions are. Here's a quick sample:
<RANT> Most regulations are not designed to specifically slow down technical innovation. How do we know a priori that a given regulation will slow down innovation? Sure, a regulation could be designed to do that specifically, but in most cases, regulations are meant to stimulate and guide industry, while curtailing harmful practices that hurt everyone in the long run. This question begs the person being asked to oppose this particular form of regulation (regulate to slow down innovation), and then tacitly extends the answer to cover all possible forms of regulation.</RANT>
*sigh*
Alot of the questions are of this form. Go read it.
--Joe--
Trillian is the Linux Port Project and Itanium is the Processor Formerly Known As Merced
I can't comment on win32 vs. win64.
--Joe--
In the case of IOCCC entries, a large amount of the "intellectual content" is the obfuscation. In other words, the obfuscation is an important part of the source that cannot be done without. In contrast, the gibberish nature of the HTML that Word generates is not part of the intellectual content of the document.
--Joe--
*chuckle*
Probably the only post on the page that made me laugh....
--Joe--
The Egyptians didn't have the Pythagorean Theorem. They only had 3-4-5 triangles made of rope with knots tied in it.
Pythagoras, and his followers, were Greek. They came later.
--Joe--
Actually, that'd be 'she' rather than 'he'. Hedy was an actress. And no, I doubt she has much to do with the amount of power output a cell phone has and what that does to your noggin' as you jabber endlessly while driving down the freeway....
Seriously, I doubt people who use cell phones moderately (eg. for emergency calls, etc), rather than as a primary contact medium or as a way to 'chat with the {boys|girls|etc}' while driving down the road, will have few cancer issues.
On a different note, Blazing Saddles won't be quite the same for me now.
--Joe--
What's sad is I saw a blurb on CNN about a new device someone invented which automatically finds redundant frames, etc. to time-skew a program to fit more advertisements in there...
*sigh*
--Joe--
I just finished my own cheesy Tetris clone for the Intellivision! I guess I've made my rite of passage.
BTW, if anyone's interested, I have an Intellivision-compatible Software Development Kit as well. :-)
--Joe--
If the beer were lighter than nitrogen, it would likely float. (Recall, the atmosphere is ~70% nitrogen.)
--Joe--
Methinks you misseth the point. The downward-travelling bubbles in Guinness are less dense than the surrounding liquid, but are still travelling downwards. The reason they travel downward is that the beer surrounding the bubble is travelling downward and is dragging the bubble with it.
--Joe--
Whatever. Mike Abrash went from Microsoft to idSoftware for a single game, and then went back to Microsoft. The last time I spoke with Mike Abrash (over email), he said he was working on Natural Language Processing, anyway.
--Joe--
This could be an interesting opportunity for some daring developer. How about this for an idea: The ADSL modems characterize the link and determine what frequencies they're receiving interference on. They use this information to control a separate AM tuner to discover if the interference is due to an AM station. If it is, they use the demodulated AM signal as an input to a noise filter to reduce the AM signal's power in the data transmission, and voila! You've nearly perfectly cancelled out at least one source of heartache.
Thoughts from the peanut gallery?
--Joe--
After all, like Linus says, "Release early, release often!"
--Joe--
Generally, licenses need to be rather obvious and presented up-front. The GPL is just such a license. A small leaflet with a copy of the GPL on it and a URL inserted with the documentation would probably be sufficient.
This probably feels a little odd for a consumer appliance, but I expect to see this sort of thing come up more and more. How many of you have an EULA or other License agreement for the software in your cell phone, pager, VCR, coffee maker, telephone, washing machine, etc.? To quote the tired, old AT&T commercial: You will.
--Joe--
Yes, I do believe Kaa's Law applies here. How can people keep forgetting that there was no year 0? After all, everyone seems comfortable with the fact that we're in the 20th Century, even though 1901 through 1999 all start with "19". (Of course, the year 2000 will be the only year in the 20th Century to start with "20".)
Also, I note that NBC misspells millennium by forgetting the second 'n'.... *sigh* Crazy thought: Maybe the millenium (with one 'n') starts in 2000? *snicker*
--Joe--