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 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
