VIS

VIS

[Sven Grundmann]

Hi !
I am computing RC5DES contest. I had a client on ultrasparc solaris
which was for times as fast as the  sparc
client. I heard it could have to do something with the VIS instruction
set which is implemented in the ultrasparc.

I downloaded a SDK from sun but that requires sun cc 4.x or higher . Is
it Possible to use that VIS instruction
set with gcc  ? ( Do you make use of that already ? ) . Is there a c
library for gcc ?  Does anybody know something about VIS ?


The RC5DES code is nearly as double as fast on a ultrasparc I 167 Mhz
workstation than an 300 MHz Pentium II
( with MMX enhanced client ) .

But it doesn't run on my ultralinux maschine
[grundman@hal7 rc5]$ ./rc5des
ld.so.1: ./rc5des: fatal: libpthread.so.1: can't open file: errno=2
Killed
[grundman@hal7 rc5]$

solaris libpthread is there .
solaris emulation module is loaded.


I know that it is no Ultralinux bug report but i hope somebody of you
knows something about VIS which
can helf me to enhance my Prgramms

Sven Grundmann

ps: The Ultra I are the fastest Prozessors in that DES contest with that
client i have found ( normally only as
fast as a Pentium 200 )
URL is :
http://www.distributed.net

Re: VIS

[David S. Miller]

If the distributed.net people would provide source code to their
clients, we could help you.  But they don't, so on top of not being to
help you, I cannot endorse even running their binaries.

Their VIS rc5 code was done by hand in assembly, no C compiler can
properly take full advantage of the VIS instruction set although the
latest EGCS releases will output VIS instructions for a limited number
of operations if configured properly.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: VIS

[Sven Grundmann]

David S. Miller wrote:

> If the distributed.net people would provide source code to their
> clients, we could help you.  But they don't, so on top of not being to
> help you, I cannot endorse even running their binaries.
>
> Their VIS rc5 code was done by hand in assembly, no C compiler can
> properly take full advantage of the VIS instruction set although the
> latest EGCS releases will output VIS instructions for a limited number
> of operations if configured properly.
>
> Later,
> David S. Miller
> davem@dm.cobaltmicro.com

  Ok I understand that you can't help me with that rc5des client. But i
downloaded the VIS SDK for usage of VIS
in my own computations and read in the documentaion that  i need  a sun
compiler version 4 or higher ! They
have an inline expansion file in their SDK ( vis.il ) .
I am not sure if i can use that with gcc ( cause i don't have that cc 4.x
) and i never used Assembler on a sun.

It looks like that :

! Copyright (C) 1995, 1997, Sun Microsystems, Inc.

! @(#)vis.il    1.4     97/03/30 SMI

! The interface to the VIS instructions as declared below (and in the VIS
! User's Guide) will not change, but the macro implementation might change

! in the future.

!
! Pure edge handling instructions
!
! int vis_edge8(void */*frs1*/, void */*frs2*/);
!
        .inline vis_edge8,2
        edge8   %o0,%o1,%o0
        .end
!
! int vis_edge8l(void */*frs1*/, void */*frs2*/);
!
        .inline vis_edge8l,2
        edge8l  %o0,%o1,%o0
        .end

.......
And so on .

Sven Grundmann

Re: VIS

[David S. Miller]

   Date: Thu, 16 Jul 1998 15:12:05 +0200
   From: Sven Grundmann <grundema@uni-duesseldorf.de>

     Ok I understand that you can't help me with that rc5des
   client. But i downloaded the VIS SDK for usage of VIS in my own
   computations and read in the documentaion that  i need  a sun
   compiler version 4 or higher ! They have an inline expansion file
   in their SDK ( vis.il ) . I am not sure if i can use that with gcc
   ( cause i don't have that cc 4.x ) and i never used Assembler on a
   sun.

(side comment: this *.il inline assembler interface of sunpro is one
of the things I totally think they got wrong and which gcc has a much
superier interface, look at the syntax, it's just gross)

You are right, they will not work "as is" with gcc and would all need
to be rewritten.  It's all trivial, for example the first one you
showed would be something like:

extern __inline__ int vis_edge8(void *frs1, void *frs2)
{
	__asm__ __volatile__("edge8	%0,%2,%0"
			     : "=&r" (frs1)
			     : "0" (frs1), "r" (frs1));
	return (int) frs1;
}

in gcc...

And don't forget to tell gcc to pass -Av9a to the assembler.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: VIS

[Andi Kleen]

"David S. Miller" <davem@dm.cobaltmicro.com> writes:

> (side comment: this *.il inline assembler interface of sunpro is one
> of the things I totally think they got wrong and which gcc has a much
> superier interface, look at the syntax, it's just gross)

The big advantage of the Sun solution is that their templates are schedulable,
while this is just impossible with the gcc inline assembly.

-Andi

Re: VIS

[David S. Miller]

   From: Andi Kleen <ak@muc.de>
   Date: 17 Jul 1998 01:37:07 +0200

   "David S. Miller" <davem@dm.cobaltmicro.com> writes:

   > (side comment: this *.il inline assembler interface of sunpro is one
   > of the things I totally think they got wrong and which gcc has a much
   > superier interface, look at the syntax, it's just gross)

   The big advantage of the Sun solution is that their templates are schedulable,
   while this is just impossible with the gcc inline assembly.

Not true at all, it depends upon how a port was done.  The Sparc
backend creates a situation where all use inline asm's are considered
multi-instruction.  GCC does not require this.  And if this were
changed, inline assembly could be scheduled just like anything else.

(Sun's scheme also seems dangerous, is there a way for me to tell it
 _not_ to schedule what I wrote?)

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: VIS

[Andi Kleen]

"David S. Miller" <davem@dm.cobaltmicro.com> writes:

>    From: Andi Kleen <ak@muc.de>
>    Date: 17 Jul 1998 01:37:07 +0200
> 
>    "David S. Miller" <davem@dm.cobaltmicro.com> writes:
> 
>    > (side comment: this *.il inline assembler interface of sunpro is one
>    > of the things I totally think they got wrong and which gcc has a much
>    > superier interface, look at the syntax, it's just gross)
> 
>    The big advantage of the Sun solution is that their templates are schedulable,
>    while this is just impossible with the gcc inline assembly.
> 
> Not true at all, it depends upon how a port was done.  The Sparc
> backend creates a situation where all use inline asm's are considered
> multi-instruction.  GCC does not require this.  And if this were
> changed, inline assembly could be scheduled just like anything else.

In theory it could be done (by specifying the function units in a fourth
column similar to what is done in the machine descriptions). The problem with
that is that it would add horrible compiler version/CPU revision dependencies
to the code. When I understand it correctly then Sun's approach avoids this
problem - their templates are not pretty, but portable over revisions.

-Andi

Re: VIS

[David S. Miller]

   From: Andi Kleen <ak@muc.de>
   Date: 17 Jul 1998 13:22:47 +0200

   "David S. Miller" <davem@dm.cobaltmicro.com> writes:

   > Not true at all, it depends upon how a port was done.  The Sparc
   > backend creates a situation where all use inline asm's are considered
   > multi-instruction.  GCC does not require this.  And if this were
   > changed, inline assembly could be scheduled just like anything else.

   In theory it could be done (by specifying the function units in a fourth
   column similar to what is done in the machine descriptions).

No, you just need to remove the classification of all asm's as
type attribute "multi", then any single insn asm can be moved around
and scheduled just like any other insn.  In fact, if you wrote your
register constraints like a good little boy gcc will know how to
handle the dependencies right too (to deal with load latencies to an
input register used by your asm) etc.

It's totally trivial.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: VIS

[Andi Kleen]

On Fri, Jul 17, 1998 at 02:34:10PM +0200, David S. Miller wrote:
>    From: Andi Kleen <ak@muc.de>
>    Date: 17 Jul 1998 13:22:47 +0200
> 
>    "David S. Miller" <davem@dm.cobaltmicro.com> writes:
> 
>    > Not true at all, it depends upon how a port was done.  The Sparc
>    > backend creates a situation where all use inline asm's are considered
>    > multi-instruction.  GCC does not require this.  And if this were
>    > changed, inline assembly could be scheduled just like anything else.
> 
>    In theory it could be done (by specifying the function units in a fourth
>    column similar to what is done in the machine descriptions).
> 
> No, you just need to remove the classification of all asm's as
> type attribute "multi", then any single insn asm can be moved around
> and scheduled just like any other insn.  In fact, if you wrote your
> register constraints like a good little boy gcc will know how to
> handle the dependencies right too (to deal with load latencies to an
> input register used by your asm) etc.
> 
> It's totally trivial.

But how does it know what CPU units are used by the inline assembly? It 
does not make much sense to schedule without knowing that. 

-Andi

Re: VIS

[David S. Miller]

   Date: Fri, 17 Jul 1998 14:44:39 +0200
   From: Andi Kleen <ak@muc.de>

   But how does it know what CPU units are used by the inline
   assembly? It does not make much sense to schedule without knowing
   that.

GCC doesn't get perfect scheduling in any event.  And it won't for
some time until real superscalar facilities are added.

What the current gcc scheduler does do very well is seperate memory
references from their first usage, and inter-insn register dependancy
seperation.  With my proposed scheme, you'll get that for inline asm.

It will also fill delay slots in reorg with these asms, which a lot of
the time on Sparc is extremely important.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: VIS

[Andi Kleen]

On Fri, Jul 17, 1998 at 02:46:54PM +0200, David S. Miller wrote:
>    Date: Fri, 17 Jul 1998 14:44:39 +0200
>    From: Andi Kleen <ak@muc.de>
> 
>    But how does it know what CPU units are used by the inline
>    assembly? It does not make much sense to schedule without knowing
>    that.
> 
> GCC doesn't get perfect scheduling in any event.  And it won't for
> some time until real superscalar facilities are added.

This is true for gcc, but Sun's compiler does near perfect scheduling for 
the UltraSparc chips afaik, so they have a bit different requirements. 

Do you see a better design for 100% schedulable inline assembler?

-Andi

Re: VIS

[David S. Miller]

   Date: Fri, 17 Jul 1998 15:29:49 +0200
   From: Andi Kleen <ak@muc.de>

   On Fri, Jul 17, 1998 at 02:46:54PM +0200, David S. Miller wrote:
   > GCC doesn't get perfect scheduling in any event.  And it won't for
   > some time until real superscalar facilities are added.

   This is true for gcc, but Sun's compiler does near perfect scheduling for 
   the UltraSparc chips afaik, so they have a bit different requirements. 

Yes they do get perfect scheduling, and I have to say it is really
nicely done.

   Do you see a better design for 100% schedulable inline assembler?

Of course.  And it retails the beauty of GCCs interface and obtains
the benefit of sunpro's.

Simply keep things as they currently are, then add hooks to the back
end to add minimal parsing of the inline asm.  I say minimal, because
that is all that is necessary, you really only need to determine
the class of each insn (enough to compute the "type" attribute which
gcc uses for scheduling).  The rest is implicit in the constraints and
the register args used by each instruction.

In this way you don't lose any of the generics of the GCC interface.

And in such a scheme "asm volatile" can be extended to mean "don't
schedule me dammit, I coded it this way, don't move shit around".

I may even implement this, I'm in the middle of rewriting the entire
sparc backend for egcs anyways.

Later,
David S. Miller
davem@dm.cobaltmicro.com