Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!wiley!rob
From: rob@wiley.UUCP (Robert Heiss)
Newsgroups: comp.arch
Subject: Re: i860 registers/chip in general
Message-ID: <10117@wiley.UUCP>
Date: 12 Jun 90 20:16:32 GMT
References: <495@tau.megatek.uucp> <8744@brazos.Rice.edu> <1635@charon.cwi.nl> <39315@mips.mips.COM>
Organization: TRW System Integration Group
Lines: 27

In article <1635@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
[SPARC is missing ...]
>a.  A direct datapath from the general registers to the floating point
>    registers.
>b.  A calling sequence that allows passing parameters in floating point
>    registers.
>c.  Conversion from integer to floating point vice-versa should go from
>    integer registers to floating point registers, and the other way around.

In article <39315@mips.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
>Has there ever been an architecture developed which [1] had/has separate
>registers for FP and for integers; [2] obeyed Winter's  property (c.) above?

The CLIPPER architecture has properties a, b, and c.  With floating point
integrated on the same chip as the integer unit, one would expect f.p.
conversions to be fast.  But the C100 implementation has such inefficiently
microcoded conversion instructions that the equivalent SPARC sequence is
faster.

I would like to see an experimental compiler/library for SPARC which avoids
the register windows.  Code as if there were 31 general registers and pass
parameters in registers like MIPS or i860.  Pass f.p. parameters in f.p.
registers.  Do interprocedural optimization too.  If the register windows
aren't a speed advantage, consider defining a SPARC2 architecture without
the window hardware.  As of 1990, transistors still aren't free.

	-Robert Heiss    rob@wilbur.coyote.trw.com