home .. forth .. colorforth mail list archive ..

Re: [colorforth] parallel Forth for music synth

On  Sun, 20 Jan 2008 20:29:37 +0000 
Gwenhwyfaer <gwenhwyfaer@xxxxxxxxx> 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.
 
To which on  Sun, 20 Jan 2008 13:43:29 -0800
"M. Edward (Ed) Borasky" <znmeb@xxxxxxxxxxx> replied: 

 .... 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.
 
 >>

Nick here:  Like Gwenhyfaer (is that Welsh for
Guinevere? Jennifer?) I want 
to code a syth (hobby).  CF gave me good results on a
550 MHz Asus P2 board; then I needed 
more speed and (unwisely) became impatient with the slow
release of actual SeaForth 
hardware in eval board format.  So I blithely bought a
3MHz Dual Core Intel PC and am now left scratching my
head how to get CF to find the video on my new Intel
945 board (boots with black screen).... 

Meanwhile, Sam Falvo reports that Intallasys have
demonstrated mouth-watering  hardware:  a synth on a
SeaForth thumbdrive.  Posted by Jeff on Sun, 20 Jan
2008 18:42:47 -0800 (PST) in reply to your query. 

http://www.falvotech.com/blog/index.php?/archives/200-Forth-Day-Report.html

Apparently it can play 10 voices of guitar by wave guide
synth (plucked string?).  I hope Dr Montvelishsky's demo
(thumbdrive + sourcecode) will be available to hobbyists
as an evaluation board, so I can upgrade my present
primitive CF code for string quartet (imagine coding
four bowed strings by wave guide syth!).  If it had
been available earlier (and if I had not been so
impatient) I would not have needed to buy that new PC.


Also I am glad to hear from Jeff that voice input is
still on Chuck's agenda; should be a natural for Forth
words (with CF in tone colour?).

Caritas,

Nick Maroudas 



Quoting Gwenhwyfaer <gwenhwyfaer@xxxxxxxxx>:

> On 20/01/2008, M. Edward (Ed) Borasky
> <znmeb@xxxxxxxxxxx> wrote:
> > Well then ... suppose you build a SEAforth PC --
> wrap up a few billion
> > or trillion Forth MIPS in a box with RAM, some mass
> storage, a keyboard,
> > video, audio and mouse, running colorforth. Where
> would this machine
> > have a *compelling* selling proposition?
> 
> This might sound perverse, but I wonder whether a
> SEAforth chip (with
> enough processors, and enough RAM for each of them)
> could be persuaded
> to emulate an x86, or an ARM? After all, each of
> those little CPUs is
> running so fast that external memory is going to be
> far and away the
> constraining factor anyway...
> 
> 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.
> 
> More generally, the sense I get from these chips is
> that they're
> basically intended to be FPGAs in software - instead
> of a logic cell
> thingy, as FPGAs have, you get an extremely fast
> processor and a few
> hundred words of RAM. Dataflow applications should be
> a cinch...
> 
> > 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?
> 
> > What else do people do with high-performance
> computers? Well ... crypto,
> > large-scale finite algebraic computation in
> general, maybe some kinds of
> > simulation, some kinds of CAD. But that's really
> it, I think. Massively
> > parallel non-floating-point machines have been
> built before, and they've
> > invariably foundered on the difficulty of
> programming them and the lack
> > of demand for MIPS without
> MFLOPS/GFLOPS/TFLOPS/PFLOPS.
> 
> 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:
> 
> > To be blunt, Intel is trying to kill the XO and
> probably will succeed. :(
> 
> Anyway.
> 
> > Well, yeah ... I've seen the hoops Anton Ertl and
> Bernd Paysan have had
> > to jump through to get something as simple as ANS
> Forth to perform
> > acceptably when the inner interpreter is compiled
> by GCC and run on a
> > "modern" x86 with caches, branch prediction, etc.
> It's ugly.
> 
> That's the price of portability, though - the point
> of gforth is that
> it'll compile and run on just about anything. If
> they'd restricted
> themselves to the x86, they'd probably have had a far
> easier time of
> it.
> 
> On the other hand, modern processors (of all
> flavours, not just x86)
> are simply not optimised to run threaded code. For a
> predictor which
> works on the principle that an indirect jump will go
> to the same place
> it went last time (which isn't actually too bad for
> method calls, the
> major use of indirect jumps in modern code), the
> inner interpreter's
> indirect jumps will invariably end up being
> mispredicted, and so far
> (I believe) the Core 2 series is the only processor
> that works any
> harder to predict them.
> 
> Whereas for threaded code, the relatively simple
> prediction of
> "whatever's in the register in question when the jump
> enters the
> pipeline is the assumed target address" would make it
> possible to
> achieve nigh-on 100% prediction rates. Does anything
> do that?
> 
> > Yes, you can outperform that with a Forth machine.
> In their day, Lisp
> > machines could outperform a VAX with the same
> hardware costs too. Lisp
> > survives, but neither the Lisp machine nor the VAX
> does today. :)
> 
> Although both architectures can be emulated on a PC.
> I dare say a
> SEAforth wouldn't make too bad a job of them either.
> 
> Hell, modern CPUs emulate their "native" instruction
> sets, which is a
> trend that always struck me as bizarre...
> 
> > Actually, it's the other way around. The C
> compilers and operating
> > systems are designed to keep the processor busy.
> :)
> 
> Actually, they're not - hence the use of the HALT
> instruction in idle
> loops. Leaving modern x86s in a busy-wait loop runs a
> real risk of
> melting them. ;)
> 
> Regards
> Gwenhwyfaer
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail:
> colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com
> 


-- 
Dr Nicolas George Maroudas
Avigdor Meiri 9/1 
Sea View 
Haifa 3 55 00 
Israel 
Tel +972 048 337 315 

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com