I've started working through SICP in my free time [1], and I'm an electrical/computer engineer who looks at HDL and hardware all day at work. I haven't worked t

I've started working through SICP in my free time [1], and I'm an electrical/computer engineer who looks at HDL and hardware all day at work. I haven't worked through this idea so it may not be possible or useful (this is most likely), but it seems to me that a simple lisp itself could be the machine code of a massively parallel CPU architecture, with minimal compilation. Scope in Scheme is built into the language in an explicit way. The SICP Scheme dialect contains very few constructs to implement as instructions. My basic idea is to have many many simple processor units that evaluate only a given scope of an s-expression. For instance, starting from the beginning of an expression, core A reads the first operator and starts executing it on the following data. We continue to perform that operation until either encountering "([operator]", which engages a new core (let's call it core B) and toggles some kind of flag/register to notify this core to expect a result from core B, or ")", upon which we output the result, given we're not waiting on something below to finish. Now where this gets awesome is the core A in the example above can continue to execute at its own scope level while waiting for a result, and kick off any other lower-scope expressions it finds along the way. Assuming the order of the data does not matter (it usually doesn't!) a given core only has to idle when it's reached the end of its own scope and is waiting on a lower level. For example, let's say we have: (define (fib n) (cond ((= n 0) 0) ((= n 1) 1) (else (+ (fib (- n 1)) (fib (- n 2)))))) (fib 5) Right now I'm thinking a function definition will simply compile into an address label. So execution would really begin with (fib 5). Then we get to cond, which is really just a sequence of conditional branches. Even here we can probably have two separate cores evaluate (= n 0) and (= n 1) simultaneously. Even though order matters in this case, perhaps we could come up with some way to keep track of it. Anyway, then the fun part begins. A core evaluates + and starts waiting, and two other cores evaluate (fib (- 5 1)) and (fib (- 5 2)), which means that in turn, two more cores are dispatched to evaluate (- 5 1) and (- 5 2). They return 4 and 3, and the two other cores both branch to the fib function, one with 4 in its personal register, and one with 3. And so on. The result of this for this function is that, handwaving away the conditional for now, and assuming lower levels of scope are able to be "skipped over" when being read, (fib n) as written is calculated in linear time, and with a normal processor it's exponential time (c^n). With this architecture, the "stack" would just be the number of cores. I don't know if this is an efficient use of hardware, but I think the cool thing about it would be it would make a lot of programs execute more in parallel, as written. [1] I'm only at the end of chapter 1 though. Progress is slow but already rewarding.