Why Plan 9 C compilers don't have asm("")
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · you
Quoted 4 lines · Linus Torvalds
On ia64, you probably end up with function calls costing even more than alpha, because not only does the function call end up being a synchronization point for the compiler, it also means that the compiler cannot expose any parallelism, so you get an added hit from there. At
That seems amazingly dumb. You'd think a new processor design would optimize parallel computation over calls, but what do I know?
Register windows do help some, in that sense ia64 is a big step forward ofver x86. As I read what Linus wrote, he talked about a different thing: inside a procedure you do not know whence you are called, therefore you must start scheduling anew from the first instruction of the procedure; before your results hit the writeback stage, a lot of bubbles are in the pipeline meanwhile. Your only hope is that they are used up by unfinished computations in the caller. In this, rational argument passing helps to exploit a possible overlap.
Quoted 8 lines
Quoted 2 lines
Most of these "unconditional branches" are indirect, because rather few 64-bit architectures have a full 64-bit branch. That means that in
This is something I don't get: I never understood why 32bit risc designers were so damn obstinate about "every instruction fits in 32 bits" and refused to have "call 32 bit immediate given in next word" not to mention a "load 32bit immediate given in next word".
Note, the superior x86 instruction set has a 5 byte call immediate.
You must take into account that early riscs had miniscule dies, for example the first Fujitsu made SPARC had 10,000 gates all told. An alignment to the next instruction wastes hardware, and, perhaps, a clock cycle.
-- Pete
Quoted 2 lines · Pete Zaitcev
Register windows do help some, in that sense ia64 is a big step forward ofver x86.
It seems to me that x86 instruction set has lived long enough to become efficient again. Register windows I think are bad. I'd rather see a couple of hundred K of 1 cycle memory that the compiler/programmer could use. But then I don't like the property "test for 1 year and still don't uncover the production case where there is a window spill that comes at just the wrong time when the write cache is full, ... - and timing changes by hundreds of microseconds."
Quoted 4 lines
As I read what Linus wrote, he talked
about a different thing: inside a procedure you do not know whence you are called, therefore you must start scheduling anew from the first instruction of the procedure; before your
This is a hard part for any vliw type machine - if the compiler can't figure it out or if the processor requires a sync point, then performance will be terrible. My understanding is that this is just a merced problem, not a ia64 fundamental, but it seems hard. As Alan points out, the PIV tries to do better with a trace cache so
code;call x; code
is essentially, dynamically inlined by caching
code;code of x; code
if I understand it right and that's pretty cool
- maybe mckinley will use the same technique if
the compiler can't figure it out.
Anyway, any processor that does badly on calls is going to be a disaster, the real question is when it's good to use assembler escapes.
Quoted 4 lines
You must take into account that early riscs had miniscule dies, for example the first Fujitsu made SPARC had 10,000 gates all told. An alignment to the next instruction wastes hardware, and, perhaps, a clock cycle.
PowerPC has no excuse.
Quoted 2 lines
-- Pete