Thanks for that reference, Raul. I'm glad to see the FORTH community still plugging away. In the days when I implemented event-queues in FORTH on a 6502 chip for central-heating control, I could have done with something like that.
So the advantages I'm keenly aware of. The limitations I'd say have mostly to do with contention for shared resources by near-simultaneous events. You need something which can malloc quickly. Or not have to malloc at all, preferably. As I wrote what I did, I recalled IBM did market a thoroughgoing event-driven computer once, for applications like managing door-locks and security sensors. We're talking 70s or 80s now. It never broke out of its market niche. Maybe the biggest reason why event-driven computers never broke out was the difficulty of recruiting programmers who understood them. We'd all been von-Neumann-ized into feeling that the only way to resolve multi-server-multi-queue shared-resource issues was to funnel everything through one CPU. Which suited IBM fine in those days, because the party line was that everything needed a big-big central processor. Start distributing your processing power outwards and the plug-compatibles would eat your market from the edges inwards. As happened. On Sat, Apr 30, 2011 at 2:10 PM, Raul Miller <[email protected]> wrote: > On Sat, Apr 30, 2011 at 5:20 AM, Ian Clark <[email protected]> wrote: >> But why-oh-why weren't hardware architectures made completely >> event-driven in the first place? > > Some are. > > http://greenarraychips.com/ for example. > > Apparently this approach has some significant advantages, and some > significant limitations. > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
