Simon Ampleman wrote:
> 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
...
> 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....
Since the 6502 has no inherent sound capability, you must be
trying to emulate the entire system containing the 6502?
> 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.
J will tend to be slow for this kind of thing. The fundamental
issue is that J operations are meant to operate on arrays,
and thus every operation contains that abstraction overhead --
and you're not using any of it.
One thing that would help: don't use a select. Instead, have
a 256 element list of opcode emulation handlers and index by
the opcode. Perhaps using @. or perhaps using ". pc { mem
Since J tends to be overly abstract for your purposes, try and
keep the implementation for each opcode as concrete as possible.
> 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.
Yes.
> - Is there a J solution ? What other programmer does with the same
> context? Another language? Extreme optimization?
If I were using J to emulate the 6502, I'd try to keep my J implementation
as simple as possible. If I hit a point where I needed speed that J
couldn't give me, and I thought my J code was appropriately designed,
I'd farm the slow part out to another language (perhaps using cd).
Ultimately, J isn't really designed to support "high speed state
machine emulation". It's great for specifying how such a thing
would work, but we don't have a good J compiler to eliminate
unnecessary operations.
> - 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...
Well... there's problems...
In order to wrote a compiler for J, you'd need to have some
target system it would be generating code for. At first glance,
C would seem like a good target -- C is widely available, and
does not impose too many explicit requirements on the generated
code. Unfortunately, J's semantics do not map very well onto C.
For example, consider the following C code:
int multiply(int x, int y) {
return x*y;
}
The result of executing this code is undefined, for arbitrary values
x and y. (You can get defined results by using unsigned int, but
the definition for that case is... less than completely useful for
implementing J's semantics for multiplying integers.)
One workaround involves the use of double instead of int, but that
can get obscure on a system like amd64 where
int identity(int y) {
double t= (double) y;
return (int) t;
}
the result of identity(x) will not always be x.
The other approach -- targetting each machine's assembly (or
machine) language directly -- is perhaps natural for a compiler,
but... is an even bigger project than targetting something like
C.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
