linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sacha Varma <sacha@ssl.co.uk>
To: Benjamin Herrenschmidt <bh40@calva.net>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: altivec
Date: Fri, 10 Sep 1999 13:27:14 +0100	[thread overview]
Message-ID: <37D8F922.67F18F1F@ssl.co.uk> (raw)
In-Reply-To: 19990910135935.015493@mailhost.mipsys.com


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/

  reply	other threads:[~1999-09-10 12:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-10 10:32 altivec Sacha Varma
1999-09-10 11:59 ` altivec Benjamin Herrenschmidt
1999-09-10 12:27   ` Sacha Varma [this message]
1999-09-10 17:43     ` altivec Brad Midgley
1999-09-10 17:51       ` altivec Brad Midgley
1999-09-10 18:02       ` altivec Vitaly Oratovsky
1999-09-10 17:39 ` altivec David Edelsohn
  -- strict thread matches above, loose matches on Subject: below --
1999-07-20 17:04 altivec David DeHaven
1999-07-20 17:04 altivec David DeHaven
1999-07-20 17:04 altivec David DeHaven
     [not found] <Pine.PMDF.3.96.990715091130.538970498B-100000@uni.edu>
1999-07-15 16:11 ` altivec Matt Porter
1999-07-15 16:22   ` altivec Jason Haas
1999-07-15 16:29     ` altivec Josh Huber
1999-07-15 12:14       ` altivec sean o'malley
1999-07-15 17:36     ` altivec Matt Porter
1999-07-16  6:29   ` altivec Geert Uytterhoeven
1999-07-16 14:47     ` altivec Matt Porter
1999-07-09 11:29 altivec Sacha Varma
1999-07-09 12:14 ` altivec Holger Bettag
1999-07-09 13:04   ` altivec Mike DeSimone
1999-07-09 15:33     ` altivec Holger Bettag
1999-07-10  0:41       ` altivec Mike DeSimone
1999-07-14 10:17         ` altivec sean o'malley
1999-07-14 21:04           ` altivec Matt Porter
1999-07-14 21:42             ` altivec Josh Huber
1999-06-21 14:34 Altivec sean o'malley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37D8F922.67F18F1F@ssl.co.uk \
    --to=sacha@ssl.co.uk \
    --cc=bh40@calva.net \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).