Re: Hello - and where to begin?

Gwenhwyfaer wrote:
> 
> The other idea I had for it is a new synth product, but then I tend to
> see *everything* in terms of whether I could build a synth around it.
> The short bit length and lack of multiplication are certainly
> complications for DSP apps, but perhaps not fatal ones.

How many bits does a SeaFORTH cell have? For fixed-point DSP, all you 
really need is 24 bits and a way of efficiently generating a 48-bit sum. 
But a lack of multiplier would be a bit harder to work around.

>> So is document search and indexing a la Google for the
>> same reason.
> 
> Since I'm sure you don't mean the absence of floating point hardware
> here, which reason is that?

Yes, I do mean the lack of floating point. The core of most statistical 
text processing functions, including the indexing, is something called a 
singular value decomposition. That's a variant of a matrix 
eigenvalue/eigenvector solver that requires efficient double-precision 
floating point vector operations.

> I'm not altogether convinced that the argument for not trying
> something different now is that trying something different didn't work
> before. It seems to me that this mindset is what's led us to the
> current, insufferably conservative, state of the computer market,
> where there is basically one of everything, and anyone who suggests
> that perhaps what has come about has not done so by merit is shouted
> down almost immediately.
> 
> ...Well, that and the ravages of unfettered capitalism:

Sure, different things get tried. Intel has built a number of 
"different" processors besides the x86, for example. Remember the i860? 
i960? ia64/Itanium? Intel built hypercube supercomputers. Intel built 
rectangular array supercomputers. Intel also builds sound and video 
processors and I think network interface controllers too. Intel still 
builds the 8051, I think.


> Hell, modern CPUs emulate their "native" instruction sets, which is a
> trend that always struck me as bizarre...

Not as bizarre as a Ruby interpreter running on a Java Virtual Machine 
*faster* than the same code run by a Ruby interpreter written in C and 
compiled -O3. :)