On Mon, Jun 13, 2011 at 6:58 PM, Jecel Assumpcao Jr. <[email protected]>wrote:
> Casey, > > > > But did you actually understand the Visual6502 and not just the idea of > > > it? > > > > Nope. But it struck me to be able to see it compute. I do think I took > > something of value from the experience: I just don't know what it is yet. > > I agree it is a very interesting experiment and I like to show it to > people. > > > Even simple microprocessors are hard to grok, yes, because they're > > vast. The next watershed, though, might be finding a relatively simple > > architecture which is also fast. > > Here were are back to the FONC/Steps goals. C isn't a particularly hard > language to understand. Once you learn the rules, you can figure out > what a 100 line program does. But not human can understand a 4 million > line program in any meaningful way. At least we have subroutines - which > in the case of the microprocessor would be hardware modules. A modular > design is far easier for us to understand than a flat one, but sometimes > the needs of the different levels are different and one language for all > of them isn't the best way. > > Many designs these days are done in SystemC or Bluespec and then > translated to Verilog or VHDL. In the Smalltalk area, you might want to > look at > > http://averschu.home.xs4all.nl/idass/ > > > Field programmability gives me a touch of hope that systems will be > > able to optimize adaptively to the behavior of the user(s) driving, and > > evolution itself is a pretty straightforward idea, but this is just a > > thought-example. Most likely the shape it would take would end up > > surprising me. Biology is a great place to look for working concurrent > > systems, at least I think so, so hopefully that's a worthwhile thought > > experiment. > > http://www.cogs.susx.ac.uk/users/adrianth/ade.html > > > Have you looked at the ALUs that kids have been making in Minecraft? > > You can _walk around_ in there. Inside the simulated microprocessor, > > and actually watch the "electrons" walk down the "Redstone wire." And > > when you want the birds-eye, a simple server mod lets you fly way up > > and look down. > > I watched some movies of this and while very neat, it has some of the > limitations of Visual6502. If I had actually played with it and had been > able to choose what to look at, it might have been more undestandable. > > > Sure. So in this hypothetical Logo, which I'm calling WeeHDL like a right > > parody, you should be able to do macroscopic things like what you do > > in Verilog. We seem to have learned that different sets of metaphors > > help explain different sets of problems. > > I should have mentioned that the newer OKAD, like Logo, gives you a > textual representation for a visual object. A Logo program that draws a > house is not a drawing of a house that you can directly manipulate. In a > very large scale that is often considered an advantage and not a > failure, hence OKAD and Verilog and so on. > > > The problem I have with Verilog seems to be that it's used to avoid > > thinking about the very details that I hope to understand. I obviously > > want a lot of abstraction, but I also want to able to understand the > > mapping between these representations, which got me thinking > > OMeta, etc. > > Verilog allows you to be as detailed as you like. If you download any > processor design from Sun, for example, you will see that they define > their own flip flops and adders rather than let the Verilog compiler > generate what it likes from a high level description. > > Having said that, there is a feature in a simulador I wrote in Self 1.0 > that I miss in all other tools I have seen: each componente could be > defined as a behavior or as a composition of lower level components (all > the way down to transistors). If any given component had both, then you > got to select which one to use in each simulation. So if a processor had > 8 registers, you could simulate 7 of them at the behavioral level and > the remaining one it terms of its subcomponents. And you could watch two > registers, one of each kind, side by side to better understand what was > going on and to check that the two descriptions were equivalent. > > One design method that you might find very interesting is the Path > Programmable Logic - PPL. This was developed at the university of Utah > back when the students only can access to text terminals hooked up to > large computers. So their tool was a patched Emacs and used characters > to represent both the functionality and the layout of the integrated > circuits. Rather than use different languages for different things > (schematics for funcionality and rectangles for layout) like we have > been discussing above, they aimed to have a single representation that > would be good for both. > > "A strctured approach to VLSI circuit design" > J. Gu and K. F. Smith > IEEE Computer, vol 22, issue 11, Nov 1989 > http://portal.acm.org/citation.cfm?id=74714 > http://ieeexplore.ieee.org/iel1/2/1667/00043523.pdf > > You need to be an ACM or IEEE member to get the paper, unfortunately. > This methods was made even more visual for graphical workstations at > Cirrus Logic, but it was only used internally and never made available. > > See some comments about PPL on this old (1998) page of mine: > > http://www.merlintec.com/lsi/cpu/tools.html > > -- Jecel > Here is one proposed to be buildt in Squeak http://www.computer.org/comp/proceedings/c5/2003/1975/00/19750120.pdf Karl
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
