My first pass at a simulation program is mostly done now. All I need to do next is to start running it, debug any problems with the coding, and see what it does. This first “proof-of-principle” simulation program I’ve done in LabVIEW. Yes I know, LabVIEW? The reasons are that it’s a software tool I have, I’m very accustomed to using it, and it’s a great tool to put together a Windows program very quickly. This first pass is only intended to get a feel for the direction I’m trying to take this programming.
There are a number of initial choices about the construction of an asynchronous-array-of-simple-processors that I don’t have any good answers for. I’ll just have to try different things out first and see if they work or not. And that sort of effort is best done with the simplest programming environment you have to work with.
One of those choices is the machine instruction set I’ll need to give each of the simple processor cells. There is also the choice of how the I/O handshaking works between each of the neighboring cells.
For my case, I’m opting for a stack-based architecture using a dual stack arrangement with the program memory and data memory mapped to the same physical block of RAM. Mapping data space and program space together will allow the program code to modify itself on the fly.
If it all works, then the next step is to go to a simulation routine written in C running on a Linux desktop system. At that point, I’ll be able to take some screenshots and make source code available on my webpage.
The one thing that became obvious very quickly, once I started coding, was that whatever machine instruction set I give each simple processor cell, it will have to be both rotationally and translationally symmetric with respect to right/left and up/down directions. This forces some constraints on the design. One of the interesting implications of this requirement for symmetry is that the individual cells in such a processor array can’t have absolute array-location addresses. And any stable programming that can exist in this array has to be relative and not absolute in its addressing of neighboring cells. Anyway, fun stuff to think about.
Writing the simulation routine is only half of the effort. The second part is writing the programs that will run in the individual processor cells. But in this regard, most of the work has already been done. I already have a generic assembler that I created years ago that takes a file written in assembly code format, along with a list of mnemonic/machine-code associations, then outputs a machine code file that I can import into each processor cell’s program memory.
Over the years, I’ve written in Verilog a number of small processor cores that were embedded into the FPGA designs I've worked on. In these design situations, I needed such a generic assembler to create the code files to run in these minimal cores.
Just as an aside, it’s fun to work at the HDL-Verilog level of programming. You can create custom processor cores that have just the machine instructions that you want; no more, no less. This really lets you dial-in the performance of your FPGA part!
Slightly off-topic now… Why my interest in asynchronous array processors as a likely candidate for a learning system? There have been a number of attempts to create chips that mimic neural networks at the silicon level. But these attempts to mimic the human brain fall short in one important aspect, the nerve cells that form your brain can grow and/or prune the neural connections between them. A neural network built on an IC chip can’t do this. Whatever connections there are between individual cells, these connections are permanent and cannot be modified later via software.
But there is a trick in asynchronous arrays that can get around this hardware level limitation. While the individual cells within an asynchronous array only connect to their nearest neighbors, there is a concept, what you might call a “code-worm”, where a data packet can originate in one cell and travel across the array to a destination cell that is not a nearest neighbor. These code-worms can be spawned or pruned on a real-time basis and can be used to reproduce the functionality of the axons forming the neural connections in the brain.
So that was my first realization, that you can use an asynchronous array like you would a neural network with code-worms acting like the axon connections between the individual neurons. So not only can you train such a neural network using the standard methods, but a neural network, constructed as an asynchronous array, would also be able to change connections between the cells as well. It would seem that a neural network built this way would be much closer to how our brains function than the techniques currently used.
So this is the goal of the first proof-of-principle simulation program; to see if I can get this code-worm concept to go.
The idea of using an asynchronous array as an ecosystem for cellular automata came later to me. But it’s also an extremely fascinating one which I’d like to pursue for its own sake.
No comments:
Post a Comment