On 01/02/2005, at 7:11 AM, Paul Baxter wrote:
> Glen,
>> I want to congratulate you on your work. Its been evident from your
> posts on the altivec list that you love this stuff and are very good
> with it.
>
Thanks!
> Any chance of outlining future plans for MacSTL beyond the yellow,
> red/green blocks in vec-common-interface? It may help those of us
> considering the redistributable license. Its quite a commitment
> (particularly if just wanting to use this on Intel/AMD) without
> knowing a very broad outline of what is going to be added over the
> course of the next year. $499 for rights to use in my commercial code
> was fine as a disposable 'try it out' price, $2499 was a bit of a
> surprise. (though I understand the need to eat as well :-)
I think it's reasonable. JoelOnSoftware thinks software should either
be less than $1,000 or more than $75,000, so perhaps this is in the
middle of the field. Then again, given that macstl is by nature and
intent open-source, I doubt I could sell a proprietary version for
$75,000 :-). However VAST, an autovectorizer for Altivec sells for
$3,000 for embedded systems.
Also it's a bit to do with the size of the market. Eric Raymond of CATB
/ OSI fame thinks 80% of the software written is in-house vs.
shrink-wrapped packaging, so it makes sense that the redistributable
price is 4x to 5x the in-house price.
> I've seen the coloured feature boxes, but it doesn't make clear
> whether for instance you may devote more effort to bringing the x86
> platform intrinsics onto a par with the altivec ones. For instance I
> am interested in implementation of complex numbers of the x86 platform
> and despite my realisation the 'Mac'STL may never truly be as well
> supported on x86 as on the PowerPC, I would be interested to know your
> take on things.
I hope to tackle the low-lying fruit first -- multiplies, divides and
some trig functions, and then complex numbers, all of which can be
easily ported over from the Altivec side. Help is always welcome!
Or particular development could be sponsored -- that's how the complex
number arithmetic on Altivec came to be, it was sponsored. (SSE3
intrinsics would help in this regard.)
>> On a separate note, perhaps you could explain if your code might be
> used with something like GPL'ed code. Is your open source code
> amenable to being published within a GPL'd context (given GPL's
> 'viral' nature) or is it limited to open source that only supports
> your reciprocal license?
>
I had this discussion with the RPL writers (Technical Pursuit) and
raised it with license-discuss at opensource.org and also briefly with the
FSF. The main opinion seems to be that RPL is incompatible with GPL. On
the other hand I'm pretty amenable to making some exceptions a la the
MySQL folk, but it's hard for me to figure out how to maintain the
"extra" virality of RPL when it's combined with GPL -- e.g. if I
explicitly allow RPL to be combined with a particular piece of GPL, can
I maintain that the whole must be reciprocated even if it is in-house?
Would this be a violation of GPL (no extra restrictions allowed)?
Cheers, Glen Low
---
pixelglow software | simply brilliant stuff
www.pixelglow.com