Simon: I have run into similar difficulties using J to write interpreters, in my case for DVI files. I can just offer a few initial observations.
You want to cut the rom code, as you indicated. You are in luck if the opcode determines the instruction length: if not you have to do some preprocessing, and maybe cut the operands too. To implement the opcodes, you need something like implement=:[EMAIL PROTECTED] where opcode selects the opcode and op0,...,opn are gerunds (preferably tacit). This will give much better performance than an explicit case statement. If you have to maintain a lot of state between operations, especially if does not change very much, you are best off using global variables than tacit operations: otherwise you end up with a great deal of copying. You then have the form state=:instruction implement state where instruction is the opcode with arguments. You then iterate this through your instruction array. J works best when it knows in advance what operation to apply to each element of an array. Parsing problems are not well adapted to J because you have to make a decision for each element based on both the element and some external state. I have also tried "vertical interpretation": there are always some operations that are orthogonal, and you can do better by reordering the code and implementing these en masse. It seems unnatural, though. I have had a tough time getting good performance out of this. Any wisdom from the forum would be appreciated by me, too. Best wishes, John Simon Ampleman wrote: > Hello, > > I have found an old email I wanted to send to the forum last year but > wasn't able to send it because of the forum, so here is it: > > J is fine for most operations.... But there is case where I would like > to use it but I can't... > > For example, I wanted to emulate a Ricoh 6502 RP2A03G 8-bit NMOS chip > [used in old nintendo 8 bit system] for a good exercise to learn > electronic, assembler, low level programming of video, sound, serial > port, etc... This chip is running at 1.7897725 MHz. This is very slow. > While trying to find some information to start this project, I found > example source code in almost any language C, VB and even the old > QuickBasic... Minimum specification of a 386 DX 25mhz. > > I started with the sound channel emulation, the easiest thing.... I had > to create 2 square wave channel, 1 triangle channel, 1 white noise > channel... I did not find a way to do in J so I created a C++ DLL with > DirectSound at this time which worked well.... Then, the real thing... > The function to read the next op code and emulate each one. > > Most people would code it like this : > > DO > READ NEXT OPCODE > SELECT CASE OPCODE > CASE 1: > EMULATION FOR OPCODE 1... > CASE 2: > EMULATION FOR OPCODE 2... > .... > WHILE (EOF) > > It give a clear code easy to follow.... > > J in loop is extremely slow, but creating a DLL in C for this part is > useless since it will contains the entire project. > > I tryed to optimize my J code... Cut the rom file in opcode in advance > with the length of each operation, But still, would have to call a > function to emulate each opcode one at a time since the content of the > registers are changed. > > I started to read Henry Rich book "from c++ to j..." to see how to > achieve a better solution... > > But then I realized my J code would probably end up in a very "custom" > solution to this problem.... > > My final reflexion concludes that J has speed limits to interpret every > lines of the code until it's run on the computer... Decode, validate, > convert the code..... which set speed limits. If I could decode, > validate and convert (compile the code myself) before execution, I would > have the ideal environment for developping and when using the compiler > software it would become very fast. > > So I started to write a compiler software, A C++ class for a J variable. > A byte buffer array that records the data (type, shape, value) the same > way J stores them with 3!:1 var. Then replaced some operator like = with > basic types of variables that J support (bool, char*, int, double...) to > fill the buffer... I saw a possibility there, but thousand of hours to > write the whole thing... > > I wanted to know : > > - Is there a J solution ? What other programmer does with the same > context? Another language? Extreme optimization? > > - If not, is there anyone working on a compiler solution? I saw some > email on the forum in oct. 2005 about this subject but no development in > progress... > > Simon > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
