Oh, I was mostly fishing to see if anyone was doing anything fun with hardware description.
The present time sees a bigger trade between performance and power consumption, but that's all in the realm of optimization. A mentor of mine in the software world once said something to me to the effect of "Don't look under the ISA, you don't want to see what's down there." Of course, that only encouraged me to look. After having done so, I'm seeing a lot of the same stuff there that motivated FONC. Cruft built up over generations of deadlines and back compat, etc. I'm pretty sure one could really put the STEPS treatment to hardware design, but there's a catch. If you wanted to run Frank over a machine designed to be understandable (rather than fast and compatible) and Frank hadn't seen anything more in the way of optimization than what the researchers working on it had to overcome with optimizations in order to complete their research, one might end up with a whole system too slow to experiment with. That's conjecture (obviously) given that I don't have Frank to play out over my FPGA rig, but I tend to trust my gut. Hence the post:) So I got to thinking, while I was doing my little armchair exploration of Verilog, what if we could declare/specify behavior with some concrete algebra, and (I know, I know, I added an "and") find a way to do optimization in an automated way. Thought experiment: what if I designed a behavior-specifying language, which could be reduced to S-expressions, and then tried to find a set of fitness functions around performance? Would it be possible to converge on a performance goal by ripping off nature? If it was possible, how much compute would I need to converge on an acceptable solution? Probably crazy expensive compute because I'm doing two things that don't want to sleep in the same room... verifying correctness (think a lot of tests in some test language) and optimization (convergence on some set of perf metrics.) Not just gen algs but gen programming. This popped into my head after thumbing through this thing: http://www.amazon.com/gp/aw/d/0262111888 Of course, I'm skeptical (of both the content of that book and of my own crazy ideas!) While a performance metric (in some continuum of flops and watts) *does* seem like something GP might be able to optimize, correctness *absolutely* does not. Hence the question about language. Has anyone here read that? I'm quite sure I haven't understood all of the content, and with as obscure as it seems to be, it could be full of bunk. Of course, with regard to obscurity, one might say the same thing of other stuff folks around here know, understand well, and love. I could go into specific ideas I've had, but I won't, because I haven't really a framework for vetting them. Instead, I'm going to ship the Wouldn't It Be Cool If and let the good people of the list slaughter my little thought experiment with the raw unrelenting debunking power of a group of people who like science. Bonus points if anyone can name the Dylan song title that I spoofed for the thread, but that's way OT so please reply direct! Casey On Nov 30, 2012, at 3:35 PM, David Barbour <dmbarb...@gmail.com> wrote: > Could you clarify what you're thinking about? Is your question about > metaprogramming of Verilog (with an implicit assumption that Verilog will > save battery life)? > > I've spent much time thinking about language and protocol design to extend > battery resources. I happen to think the real wins are at higher levels - > avoiding unnecessary work, amortizing work over time, linear logics, graceful > degradation of services based on power access. > > (Questions about power and energy were common in survivable networking > courses.) > > Low level power saving is a common aspect of mobile computer architecture > design. But it's hard to push fundamentally better hardware designs without > an existing body of software that easily fits it. > On Nov 30, 2012 2:06 PM, "Casey Ransberger" <casey.obrie...@gmail.com> wrote: > Since I'm running out of battery, and my adder is starting to go oh so > slowly, I thought I might challenge the lovely people of the list to make it > stop draining my battery so quickly. > > :D > > My first challenge idea was for someone to make it stop raining in Seattle, > but I realized that I was asking a lot with that. > > Verilog would be cool, but better if you're translating whatcha got to > Verilog with OMeta, and you've come up with some randomly pretty language for > wires! > > Come on, someone else has to be thinking about this;) > > -- > Casey Ransberger > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
