On Sat, 2009-12-05 at 00:51 -0800, David Brownell wrote: > On Friday 04 December 2009, Zach Welch wrote: > > > > > That's a useful statement of the extreme, but note that it's in > > > two parts: decouple ... and switch. > > > > > > Decoupling is one of those things that's not fully understandable > > > except in the context of concrete options. Without seeing a few > > > different front ends -- not necessarily languages, but perhaps > > > just custom JTAG tools -- it's hard to know how well decoupled > > > things really are. :) > > > > Today, I started looking into the possibility of adding Lua for > > precisely this reason. I think it would be a good fit for us, and it > > would ensure that the decoupled APIs are both complete and robust. > > I've been intrigued by Lua too. Though I might prefer to integrate > with a Scheme environment ... or even "Go". ;) > > Rule of thumb: it's not sufficiently general until it's got at > least three significantly different layers on top of it.
I agree completely. Scheme is totally viable too, on par with Lua. These are both viable. Personally, I think that I have talked myself into Jimv2 as the second language, adding Lua, Scheme, or another as a third language that seals the encapsulation and re-use deal. >From what you said about Go in the past, I like the idea... except for the fact that OpenOCD will not be thread-safe anytime soon. But even if we could fix that, I am not sure exactly how we could benefit from it, when we have bottlenecks other than the CPU. Right? But just to cover the bases of crazy, why not just make OpenOCD a back-end to LLVM.... ;) With libopenocd, that should not be infeasible, as far as I can understand. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
