Re: the RISC penalty
30 Dec 1995 14:11:00 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: The RISC penalty (1995-12-19)
Re: The RISC penalty jbuck@Synopsys.COM (1995-12-20)
Re: The RISC penalty (1995-12-21)
Re: The RISC penalty (1995-12-28)
Re: The RISC penalty (1995-12-28)
Re: The RISC penalty (1995-12-30)
Re: the RISC penalty (1995-12-30)
Re: the RISC penalty (1995-12-31)
| List of all articles for this month |

Newsgroups: comp.compilers
Date: 30 Dec 1995 14:11:00 -0500
Organization: Compilers Central
References: 95-12-063 95-12-132 95-12-154
Keywords: architecture

Michael Meissner wrote:
>Well it depends on how you view the instruction stream. True variable
>sized nstructions are a pain, but did it in terms of 60-bit words (ie,
>instructions would not cross a word boundary, so if you wanted to use a
>30-bit instruction, and there are only 15 bits left in the word, you have
>to put a NOP, and start on the next word).

This was true of the lower-end machines, but was NOT true of the 6600 and
higher machines. They had the 8-word instruction stack (a microscopic
instruction fetch cache), and could handle 30-bit instructions that spanned
word boundaries.

One of the significant optimization opportunities on the 6600 was writing
your loop kernels so that they stayed completely inside the stack (6600
terminology) and did not use any instructions that flushed the stack. When
you did this, your program stopped fetching instructions and just worked
out of the stack, which made a SIGNIFICANT difference in the running speed
of the loop. The corollary to this was that self-modifying code was a
SERIOUS Bozo no-no, because the copies in the instruction stack didn't get
[The 360/91 had a similar instruction buffer with loop mode. There was even a
light on the console to tell you when loop mode was active. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.