altivec

altivec

[Sacha Varma]

Has any progress been made on LinuxPPC Altivec support? I posted a while back
and there was some discussion, I wondered if anyone was taking it further. I
suppose the arrival of G4 Macs in a few weeks' time will help kickstart things.
It would be great if AIM took the lead in this sort of work...

The issues as I remember them:

.. saving/restoring altivec registers (there's sample machine
  code for one of the ABIs in the Altivec documentation)

.. support in egcs for the Altivec C language extensions, 
  hopefully C++ also (someone said they had patches supplied
  by Motorola, but I've not found mention of these on the
  Motorola SPS site so I assume they're not for general
  consumption)


There was some talk of trapping an illegal instruction interrupt in
Altivec-compiled code on non-Altivec processors and then emulating it in
software, but as I recall this was thought to be maybe impossible (due to
limited information about the illegal instruction and limits on what you can do
in the trap) or more effort than it's worth.


In the meantime to learn more about Altivec I've been working on a library to
emulate the instructions in software (with appropriate #defines for the language
extensions in a header). If anyone's interested e-mail me and I'll let you know
if/when I'm done; I'm hoping to get the bulk of it done this weekend. (It'll be
C++ I'm afraid - the vector types lend themselves nicely to a template class,
and a lot of the vec_* instructions are overloaded).


--
sacha varma : system simulation ltd : sacha@ssl.co.uk

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[Benjamin Herrenschmidt]

On Fri, Sep 10, 1999, Sacha Varma <sacha@ssl.co.uk> wrote:

>There was some talk of trapping an illegal instruction interrupt in
>Altivec-compiled code on non-Altivec processors and then emulating it in
>software, but as I recall this was thought to be maybe impossible (due to
>limited information about the illegal instruction and limits on what you can
>do
>in the trap) or more effort than it's worth.

This is possible since Apple provides an emulator for developers (it's an
extension that you drop in your MacOS system folder and which traps the
illegal instruction interrupt).

>In the meantime to learn more about Altivec I've been working on a library to
>emulate the instructions in software (with appropriate #defines for the
>language
>extensions in a header). If anyone's interested e-mail me and I'll let you
>know
>if/when I'm done; I'm hoping to get the bulk of it done this weekend. (It'll
>be
>C++ I'm afraid - the vector types lend themselves nicely to a template class,
>and a lot of the vec_* instructions are overloaded).

If your library can be turned into plain C, then we should be able to
implement the same emulation mecanism in Linux, but is it really
interesting ? It will be way too slow to be useful for anything but
developers prototyping Altivec code on G3s.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[Sacha Varma]

Benjamin Herrenschmidt wrote:
> 
> On Fri, Sep 10, 1999, Sacha Varma <sacha@ssl.co.uk> wrote:
> 
> >In the meantime to learn more about Altivec I've been working on a 
> >library to emulate the instructions [...] (It'll
> >be C++ I'm afraid - the vector types lend themselves nicely to a
> >template class, and a lot of the vec_* instructions are
> >overloaded).
> 
> If your library can be turned into plain C, then we should be able 
> to implement the same emulation mecanism in Linux, but is it really
> interesting ? It will be way too slow to be useful for anything but
> developers prototyping Altivec code on G3s.

The main reason I'm doing it is to learn about what's available in Altivec. But
I guess it would also be useful (some of these are pretty far-fetched but hey)
for:

1. (as you say) People who don't yet have a G4
We outside the US are subject to its export laws. Who knows when we'll see them
here in the UK.

2. Those who don't yet have an Altivec compiler
I don't want to develop under MacOS (MPW, MrC) and, as a hobbyist, can't justify
$375 for CodeWarrior, and I don't have the knowledge to patch up gcc and the
Linux kernel.

3. People who want code that's optimised for G4 but also builds on G3
You could use the altivec API when coding and then have a header (as I do) with:

  #ifndef __VEC__
    /* software emulation */
  #else
    /* use native instructions */
  #endif

Granted, maybe my library - which isn't written with performance considerations
in mind - will be much slower than ditching the altivec API and re-writing your
code, but the principle seems sound: portability with virtually no code changes.

4. People who like the Altivec API
Maybe you dig the Altivec API but code for another platform. You could even dive
in and replace the core of the library with MMX or whatever where possible.

5. People who want to know what a particular instruction does
They could browse the library source code. I'm not saying that my library will
be correct (I admit I don't fully understand what some of the instructions do,
e.g. the saturated ones) but hopefully it would eventually be. And the code
might be clearer than the sometimes terse descriptions in the Altivec
documentation.

6. If Altivec is extended in the a future incarnation
Ok I'm clutching at straws here, but maybe new instructions will be added down
the line; if a library exists which is easily extended, people would be able to
get start using them pretty much right away.


--
sacha varma : system simulation ltd : sacha@ssl.co.uk

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[Brad Midgley]

urlich drepper put a lot of work into glibc2.1 and processor capabilities 
for exactly this problem.

so the RIGHT way to do this is by having two dynamic libraries, one for g4
and one for processors without altivec. the libraries just have to be put
in different places; glibc's search path is defined dynamically based on
processor capabilities so the appropriate shared library is linked in.

also, we can avoid the problem of binaries that blow up because they were
compiled for a different powerpc.

the assembler needs to know the new opcodes.

the kernel needs to know how & when to stack and unstack the altivec
registers.

for capabilities, i suspect we just need a little kernel work so the
kernel identifies altivec capability and makes that info available; then
glibc will need to know the symbolic name to look for.

the tough part will be designing a shared library and abstracting its
entry points with an eye on performance both with and without simd
capability. this is a problem that transcends altivec--it is relevant to
simd processor extensions on other architectures too.

> 3. People who want code that's optimised for G4 but also builds on G3
> You could use the altivec API when coding and then have a header (as I
>  #ifndef __VEC__
>    /* software emulation */
>  #else
>    /* use native instructions */
>  #endif


Brad
brad@pht.com | http://www.pht.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[Brad Midgley]

i should have explained this more. the library can't be abstracted at the
level of "multiply these numbers..." it would have to be abstracted at a
much higher level, such as "perform a single-precision fft up to frequency
q" with a mathematician devising what high-level operations are useful.

> the tough part will be designing a shared library and abstracting its
> entry points with an eye on performance both with and without simd
> capability. this is a problem that transcends altivec--it is relevant
> to simd processor extensions on other architectures too.

Brad
brad@pht.com | http://www.pht.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[Vitaly Oratovsky]

Brad Midgley wrote:

> the kernel needs to know how & when to stack and unstack the altivec
> registers.

To really do Altivec vector regs save/restore efficiently will require
cooperation between kernel and compiler.  Altivec architecture defines
a VRSAVE register, which is just a general purpose 32-bit wide bitmask.
The intention is for compiler to record usage of altivec registers in
the prologue of every function which uses them.  Likewise, the epilogue
is supposed to restore VRSAVE to the caller's state.  Of course, hand-
written assembly routines have to play by the same rules.

This approach permits saving/restoring the absolute minimum number of
vector unit regs, and [perhaps more importantly] only when the
interrupted
thread was truly using them.

A less ambitious approach which doesn't require the compiler to mock
with
VRSAVE would be to allow the kernel to discover whether a particular
process
uses the vector unit by "faulting" in the vector unit enable bit in MSR
for
each process individually.

Cheers, Vitaly.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[David Edelsohn]

>>>>> Sacha Varma writes:

Sacha> Has any progress been made on LinuxPPC Altivec support? I posted a while back
Sacha> and there was some discussion, I wondered if anyone was taking it further. I
Sacha> suppose the arrival of G4 Macs in a few weeks' time will help kickstart things.
Sacha> It would be great if AIM took the lead in this sort of work...

Sacha> The issues as I remember them:

Sacha> .. support in egcs for the Altivec C language extensions, 
Sacha> hopefully C++ also (someone said they had patches supplied
Sacha> by Motorola, but I've not found mention of these on the
Sacha> Motorola SPS site so I assume they're not for general
Sacha> consumption)

	Apple apparently has a version of egcs-1.1.2 with an improved
version of Motorola's AltiVec support merged in.  I still have not seen
any offer of these patches to the GCC maintainers (and accompanying
assignment to the FSF) for inclusion in the public sources.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: altivec

[David DeHaven]

>Good lord!  Going the implement-your-own-of route sounds like the best 
>(only) way to go for something like this.

What? You think $500,000 is a lot of money? 'tis a pittance!

-DrD-

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[David DeHaven]

>Motorola or IBM will be happy to sell you a "non-apple non-MacOS PPC"
>machine for Linux, it's just nobody wants to pay the price. :)  A startup
>with a very low overhead could probably provide a reasonably priced mobo
>with an MPC107 and MPC750@400+mhz.  They would want to then sell them to a
>system manufacturer which already has volume discount commodity parts in
>their facility to build a consumer priced machine.  Selling 1-2 boards to
>each homebrew person isn't a business plan that will attract any
>investment, a decent volume distribution deal is needed.  Hrm, I wonder
>what the licensing cost of OF is or would it be better to do an open
>implementation of the standard...

The problem is, there's not enough demand right now to drive a non-PPC 
Linux box market. It's one of those things where we all sit around and 
say "Gosh, that would be cool if all of Intels plants just blew up 
suddenly and PowerPC would dominate the world!!!" It just aint gonna 
happen, at least not in the near future. (very much like the story of 
BeOS...)

As for OF, last I heard IBM will gladly license you to use and modify 
their OF implementation to your own needs. In the short term, it's 
cheaper and easier than trying to brew something up yourself.

-DrD-

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[David DeHaven]

>I would love to work with Altivec, does anyone have any idea where to get
>the hardware preferably cheap =)?

Bwah hah hah hah hah!!! That's a good one! :)

Seriously, you won't see G4's on the market until early next year, unless 
some serious strings are pulled.

-DrD-

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Matt Porter]

On Thu, 15 Jul 1999 puetzk6715@uni.edu wrote:

> 
> On Thu, 15 Jul 1999, Justin Vallon wrote:
> 
> > > Matt Porter writes:
> > > > 
> > > > The MAX processor hasn't even been released yet.  When it is, Apple is
> > > > always the cheapest supplier of PowerPC systems.
> > >              ^^^^^^^^^^^^^^^^^
> > > Something needs to be done about this :)
> > 
> > Maybe you'd like them to raise the price?
> 
> No, I think he wants non-apple non-MacOS PPC machines for Linux. They're
> getting hard to find...

Motorola or IBM will be happy to sell you a "non-apple non-MacOS PPC"
machine for Linux, it's just nobody wants to pay the price. :)  A startup
with a very low overhead could probably provide a reasonably priced mobo
with an MPC107 and MPC750@400+mhz.  They would want to then sell them to a
system manufacturer which already has volume discount commodity parts in
their facility to build a consumer priced machine.  Selling 1-2 boards to
each homebrew person isn't a business plan that will attract any
investment, a decent volume distribution deal is needed.  Hrm, I wonder
what the licensing cost of OF is or would it be better to do an open
implementation of the standard...
 
--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Jason Haas]

Matt Porter wrote:

> Hrm, I wonder
> what the licensing cost of OF is or would it be better to do an open
> implementation of the standard...

I think it's about $0.5M.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Josh Huber]

Jason Haas writes:
> 
> Matt Porter wrote:
> 
> > Hrm, I wonder
> > what the licensing cost of OF is or would it be better to do an open
> > implementation of the standard...
> 
> I think it's about $0.5M.
Good lord!  Going the implement-your-own-of route sounds like the best (only) way to go for something like this.

Do you know of any current projects to do something like this?

Josh

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[sean o'malley]

>Jason Haas writes:
>>
>> Matt Porter wrote:
>>
>> > Hrm, I wonder
>> > what the licensing cost of OF is or would it be better to do an open
>> > implementation of the standard...
>>
>> I think it's about $0.5M.
>Good lord!  Going the implement-your-own-of route sounds like the best
>(only) way to go for something like this.
>
>Do you know of any current projects to do something like this?
>

OF (not necessarily Apples ..) is based on the IEEE 1275 standard and I was
under the impression that they had  newer standard or were close to hacking
one together.

did you try http://www.openfirmware.org/  ??





[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Matt Porter]

On Thu, 15 Jul 1999, Jason Haas wrote:

> Matt Porter wrote:
> 
> > Hrm, I wonder
> > what the licensing cost of OF is or would it be better to do an open
> > implementation of the standard...
> 
> I think it's about $0.5M.

That's in the neighborhood of the figure I've heard around Moto. when
asking some people who worked with OF in the past.  It's unclear what the
royalty structure is, but obviously that sum is too much money to turn a
profit on a low margin board.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Geert Uytterhoeven]

On Thu, 15 Jul 1999, Matt Porter wrote:
> Motorola or IBM will be happy to sell you a "non-apple non-MacOS PPC"
> machine for Linux, it's just nobody wants to pay the price. :)  A startup
> with a very low overhead could probably provide a reasonably priced mobo
> with an MPC107 and MPC750@400+mhz.  They would want to then sell them to a

Are the specs for the MPC107 public now?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Matt Porter]

On Fri, 16 Jul 1999, Geert Uytterhoeven wrote:

> On Thu, 15 Jul 1999, Matt Porter wrote:
> > Motorola or IBM will be happy to sell you a "non-apple non-MacOS PPC"
> > machine for Linux, it's just nobody wants to pay the price. :)  A startup
> > with a very low overhead could probably provide a reasonably priced mobo
> > with an MPC107 and MPC750@400+mhz.  They would want to then sell them to a
> 
> Are the specs for the MPC107 public now?

No, not that I can find on the Mot SPS site.  The MPC8240's PHB is
supposedly an MPC107 core so you can take a look at the user's manual for
that device if you're interested.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

altivec

[Sacha Varma]

Some questions about altivec & LinuxPPC:

1. is there a free C compiler supporting altivec instructions for
   linuxPPC?

2. would it be possible to trap altivec instructions on a non-altivec
   processor and reroute them through code using generic instructions?
   (I believe this is how Apple's MacOS altivec simulator does it).
   Presumably there is a bad instruction interrupt or something and
   code in the kernel to trap these interrupts? (Excuse my naivety;
   I'm more of a kernel user than hacker - for now!)

3. has anyone written a C library to simulate the altivec instructions?

--
sacha varma : system simulation ltd : sacha@ssl.co.uk

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Holger Bettag]

Sacha Varma <sacha@ssl.co.uk> writes:

> 
> Some questions about altivec & LinuxPPC:
> 
> 1. is there a free C compiler supporting altivec instructions for
>    linuxPPC?
>
Possibly. Someone from Cygnus (the maintainers of egcs/gcc) mentioned he'd
gotten source patches from Motorola that add AltiVec support to gcc.

Since MacOS X is a descendant of NeXTStep, and since NeXT always used gcc,
and since Apple is going to embrace AltiVec, one can reasonably expect that
at least Apple will use an AltiVec-aware variant of gcc. In an ideal world,
AltiVec support would make it into the main gcc tree.

> 2. would it be possible to trap altivec instructions on a non-altivec
>    processor and reroute them through code using generic instructions?

Possible - yes. Dead slow - absolutely. (Apple's simulator is strictly a
development tool, nothing more.)

>    (I believe this is how Apple's MacOS altivec simulator does it).

I don't know.

>    Presumably there is a bad instruction interrupt or something and
>    code in the kernel to trap these interrupts? (Excuse my naivety;
>    I'm more of a kernel user than hacker - for now!)
>
Yes, such exceptions are supported by PPC hardware.

> 3. has anyone written a C library to simulate the altivec instructions?
>
Apple's simulator is the only such program I know of.

  Holger

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Mike DeSimone]

>> 2. would it be possible to trap altivec instructions on a non-altivec
>>    processor and reroute them through code using generic instructions?
>
>Possible - yes. Dead slow - absolutely. (Apple's simulator is strictly a
>development tool, nothing more.)

It shouldn't be dead slow, but it will be much slower than it would be on
Altivec processors (esp. since cache pipelining won't work nearly the
same).  Basically, most Altivec instructions can be replaced with for
loops.  So long as the iteration count of the loop is high, the overhead
from the illegal instruction trap activity should be minimized, so it
should boil down to about the same time as an assembly-coded loop.

>> 3. has anyone written a C library to simulate the altivec instructions?
>>
>Apple's simulator is the only such program I know of.

Something like this wouldn't be a library, it would have to be a kernel
addition.  A SIGILL handler just doesn't tell you enough to be able to
trap, analyze, and execute the instruction, then adjust the return pointer
and resume at the next instruction (and what about multiple Altivec
instructions in sequence?).

Personally, I'm looking for a LINPACK/CLASSPACK-like library that has an
Altivec and a non-Altivec version, so you can install whatever one is
appropriate on the machine. ^_^

I'm also wondering what has been done on this issue on the Intel side of
the fence, since KNI and 3Dnow! are similar to Altivec in concept and, at
least for 3Dnow!, implementation.
_________________________________________________________________________
                                __________
##   ##   ###   #####   #####   \********/   #####    ###    ##### ######
### ###  ## ##  ##  ## ##        \*/\/\*/    ##  ##  ## ##  ##     ##
#######  ## ##  #####   ####       /\/\      #####   ## ##   ####  ####
## # ## ####### ##  ##     ##      \**/      ##  ## #######     ## ##
##   ## ##   ## ##  ## #####        \/       #####  ##   ## #####  ######
_________________________________________________________________________
### Mike DeSimone ### Hot-Wire@mail.utexas.edu ### ares.marsbase.mars ###

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Holger Bettag]

Mike DeSimone <Hot-Wire@mail.utexas.edu> writes:

> 
> 
> >> 2. would it be possible to trap altivec instructions on a non-altivec
> >>    processor and reroute them through code using generic instructions?
> >
> >Possible - yes. Dead slow - absolutely. (Apple's simulator is strictly a
> >development tool, nothing more.)
> 
> It shouldn't be dead slow, but it will be much slower than it would be on
> Altivec processors (esp. since cache pipelining won't work nearly the
> same).  Basically, most Altivec instructions can be replaced with for
> loops.  So long as the iteration count of the loop is high, the overhead
> from the illegal instruction trap activity should be minimized, so it
> should boil down to about the same time as an assembly-coded loop.
> 
Well, if you do instruction-by-instruction emulation, the iteration count is
at most 16 (16 bytes in a vector). Furthermore, the overhead of a context
switch into privileged mode and back again is not negligible (at the very
least a pipeline flush and some saving/restoring of registers). Finally,
keeping the emulated vector registers somewhere in memory means that you will
quite often be limited by the availability of 'only' one load/store unit.

[...]
>
> I'm also wondering what has been done on this issue on the Intel side of
> the fence, since KNI and 3Dnow! are similar to Altivec in concept and, at
> least for 3Dnow!, implementation.
>
Similar? Please forgive my ranting, but AltiVec is feature-complete,
orthogonal, and implemented without compromises. MMX, 3DNow!, and ISSE have
none of the above three qualities. They were available sooner, but that's
about it.

  Holger


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Mike DeSimone]

>Well, if you do instruction-by-instruction emulation, the iteration count is
>at most 16 (16 bytes in a vector). Furthermore, the overhead of a context
>switch into privileged mode and back again is not negligible (at the very
>least a pipeline flush and some saving/restoring of registers). Finally,
>keeping the emulated vector registers somewhere in memory means that you will
>quite often be limited by the availability of 'only' one load/store unit.

That's true, I forgot about the 16 byte limit.  That will really make the
overhead significant.  Kind of annoying to me (my typical vector length is
over 900).  Maybe having two libraries is the way to go, then...

>> I'm also wondering what has been done on this issue on the Intel side of
>> the fence, since KNI and 3Dnow! are similar to Altivec in concept and, at
>> least for 3Dnow!, implementation.
>>
>Similar? Please forgive my ranting, but AltiVec is feature-complete,
>orthogonal, and implemented without compromises. MMX, 3DNow!, and ISSE have
>none of the above three qualities. They were available sooner, but that's
>about it.

That's why I said "similar in concept" ... not execution.  And I said KNI
(the PIII new instructions), not MMX, which is integers only.  (Also why I
didn't mention Sun's VIS).
_________________________________________________________________________
                                __________
##   ##   ###   #####   #####   \********/   #####    ###    ##### ######
### ###  ## ##  ##  ## ##        \*/\/\*/    ##  ##  ## ##  ##     ##
#######  ## ##  #####   ####       /\/\      #####   ## ##   ####  ####
## # ## ####### ##  ##     ##      \**/      ##  ## #######     ## ##
##   ## ##   ## ##  ## #####        \/       #####  ##   ## #####  ######
_________________________________________________________________________
### Mike DeSimone ### Hot-Wire@mail.utexas.edu ### ares.marsbase.mars ###

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[sean o'malley]

I would love to work with Altivec, does anyone have any idea where to get
the hardware preferably cheap =)?


>>Well, if you do instruction-by-instruction emulation, the iteration count is
>>at most 16 (16 bytes in a vector). Furthermore, the overhead of a context
>>switch into privileged mode and back again is not negligible (at the very
>>least a pipeline flush and some saving/restoring of registers). Finally,
>>keeping the emulated vector registers somewhere in memory means that you will
>>quite often be limited by the availability of 'only' one load/store unit.
>
>That's true, I forgot about the 16 byte limit.  That will really make the
>overhead significant.  Kind of annoying to me (my typical vector length is
>over 900).  Maybe having two libraries is the way to go, then...
>
>>> I'm also wondering what has been done on this issue on the Intel side of
>>> the fence, since KNI and 3Dnow! are similar to Altivec in concept and, at
>>> least for 3Dnow!, implementation.
>>>
>>Similar? Please forgive my ranting, but AltiVec is feature-complete,
>>orthogonal, and implemented without compromises. MMX, 3DNow!, and ISSE have
>>none of the above three qualities. They were available sooner, but that's
>>about it.
>
>That's why I said "similar in concept" ... not execution.  And I said KNI
>(the PIII new instructions), not MMX, which is integers only.  (Also why I
>didn't mention Sun's VIS).
>_________________________________________________________________________
>                                __________
>##   ##   ###   #####   #####   \********/   #####    ###    ##### ######
>### ###  ## ##  ##  ## ##        \*/\/\*/    ##  ##  ## ##  ##     ##
>#######  ## ##  #####   ####       /\/\      #####   ## ##   ####  ####
>## # ## ####### ##  ##     ##      \**/      ##  ## #######     ## ##
>##   ## ##   ## ##  ## #####        \/       #####  ##   ## #####  ######
>_________________________________________________________________________
>### Mike DeSimone ### Hot-Wire@mail.utexas.edu ### ares.marsbase.mars ###

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Matt Porter]

On Wed, 14 Jul 1999, sean o'malley wrote:

> I would love to work with Altivec, does anyone have any idea where to get
> the hardware preferably cheap =)?

The MAX processor hasn't even been released yet.  When it is, Apple is
always the cheapest supplier of PowerPC systems.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: altivec

[Josh Huber]

Matt Porter writes:
> 
> The MAX processor hasn't even been released yet.  When it is, Apple is
> always the cheapest supplier of PowerPC systems.
             ^^^^^^^^^^^^^^^^^

Something needs to be done about this :)

Josh

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Altivec

[sean o'malley]

Does anyone know how to acquire the G-4 with Altivec? I know its still a
proto, but im not too keen on waiting for the G-4 to get here and I want to
see if I can get something to work with Altivec and I cant do it with the
emulator.



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]