Re: Green Compiler ?

glen herrmannsfeldt <>
Wed, 2 Jan 2013 18:29:30 +0000 (UTC)

          From comp.compilers

Related articles
[15 earlier articles]
Re: Green Compiler ? (Hans-Peter Diettrich) (2012-12-30)
Re: Green Compiler ? (Dmitry A. Kazakov) (2012-12-30)
Re: Green Compiler ? (George Neuner) (2012-12-31)
Re: Green Compiler ? (Jonathan Thornburg) (2013-01-02)
Re: Green Compiler ? (glen herrmannsfeldt) (2013-01-02)
Re: Green Compiler ? (Hans-Peter Diettrich) (2013-01-02)
Re: Green Compiler ? (glen herrmannsfeldt) (2013-01-02)
Re: Green Compiler ? (glen herrmannsfeldt) (2013-01-02)
Re: Green Compiler ? (Charles Richmond) (2013-01-04)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: Wed, 2 Jan 2013 18:29:30 +0000 (UTC)
Organization: NNTP Server
References: 12-12-010 12-12-012 12-12-022 12-12-028 12-12-034 12-12-037 13-01-002 13-01-003
Keywords: architecture, performance, comment
Posted-Date: 03 Jan 2013 15:14:39 EST

Jonathan Thornburg <> wrote:
> George Neuner <> wrote:

>> My opinions are colored by experience with DSPs, but I have long
>> thought that it would be helpful to have a few K-words of non-cache
>> scratchpad memory very close (1..2 cycles) to the CPU.

> The Cray-2 and Cray-3 had this (I think they called it "local memory").
> Alas, compilers had a lot of trouble making good use of it. As John
> McCalpin put it in 1998 (at the time he was at SGI):

I previously suggested the Cray-1 vector registers, maybe not quite
the same. Still, the being able to move around multiple words in one
operation, especially to get them through a pipelined ALU, seems
a good one.

> # Local memories work fine if an experience performance person gets
> # to rewrite the code. It gets a lot more difficult if you have
> # to educate a compiler to do the right thing....

I do remember, I believe from the Cray-1 days, suggestions of having
the linker allocate registers. That is, similar to the way memory
relocation is done at link time, vector registers would be assigned
to minimize (as well as can be done statically) register spill.

Now, that was before Fortran had dynamic allocation. (And Fortran
was the popular language for Cray programming.)

> I don't know if compilers have improved significantly in this area.

Compiler technology (and size) has change much over the years.

One ongoing question is how well compilers are doing with Fortran
array expressions. It would seem easier for compilers to generate
code using vector registers for array operations.

> And on the hardware side, you'd have to figure out what to do on
> context switch...

Seems to me that the idea behind batch programming (as contrasted
to time-sharing) is keeping context switch low. With a little luck
you don't have to save the vector registers (or local store) for
every interrupt.

(snip, our moderator wrote)
> [It sounds like if we keep working, we might reinvent register windows. -John]

Is SPARC dead now? I was never sure how well the SPARC register windows,
with in and out registers, actually worked for real code.
That is, if they made the best use of chip resources.

I presume they help more for procedure call register saving than for
contect switch, though.

-- glen
[SPARC is still around, mostly seems to be Sun selling servers to run parent
Oracle's software. Register windows are awful for context switch, since you
have to dump and restore the whole register stack on each switch if you don't
have some hack like multiple stacks for active processes. It is also my
impression that SPARC has register windows because it was designed to run code
from PCC, a compiler that did very naive register allocation. The IBM 801
project was at the same time, and its chip had an ordinary register file because
they found that the compiler could generate code to do the saves and restores
at least as well as the implicit ones that windows do. -John]

Post a followup to this message

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