Malcolm Walker wrote:
| 
| Test results are trickling in while I can run them.
| 
| Machine: Mac SE/30 (m68030) running Debian Linux 2.0
|          8 megs RAM, 20MB swap, and nothing else to do
| 
| -InternHog actually DOES work, it just takes an hour (no lie!) to run. 
| So my Failure List is:
| Bean.java
| BeanBug.java
| ProcessClassInst.java
| Overflow.java
| TestNative.java (...SKIPPED, native methods are not available)
| ThreadStop.java (pizza warnings for lines 111 & 146: 
|                    function stop() in class java.lang.Thread has
|                    been deprecated
|                 -Test 4 within ThreadStop failed. (stop done thread))
| tthrd.java (couldn't find one of the classes...?)
| 
| All for now... I should have more info on the first 4 fails tomorrow when
| I can rebuild them and grab the output.

Is this with JIT or intrp?

I strongly suspect that my problems are related to caching.  I would be
interested in seeing Kiyo's results on the 3/260.  I have a spare 3/260 lying
around at home that I can install NetBSD on and test.  If the binary that
I create on my '040 runs fine on my 3/260, then that's pretty much confirmation
of a cache problem.

FYI, here is information on caches for machines that I happen to have lying
around at home:

Sun 3/260: MC68020 processor, 25 MHz.  This CPU has a 256-byte instruction
cache and no data cache.  However, there is a 32 KB L2 cache on the motherboard.

Amiga 3000: MC68030 processor, 16 MHz.  This CPU has a 256-byte instruction
cache and a 256-byte write-through data cache.  There is no L2 cache.

Mentor Graphics/HP/Apollo 425T: MC68040 processor, 25-33 MHz.  This CPU has
a 4 KB instruction cache and a 4 KB copy-back data cache.  AFAIK, no L2 cache.

(For those who wonder, I also have a SparcStation IPC, a DEC 486, and a dual-
processor Pentium-100.  I believe in diversity. :-)

The problem with caches is the following scenario:

1. Kaffe writes out JIT code to memory.
2. Kaffe jumps to start of said code.

If you have a copy-back cache ('040), then the writes from step 1 will go
into cache, and won't be pushed to memory unless the cache spills or is
explicitly flushed.  On step 2, if there was anything in the instruction cache
for those memory locations, then memory will not be read.  This is possible
for class initializers, where Kaffe throws away the code after execution.
Therefore, code for something else may end up in the same memory.

On Motorola machines, the instruction cache does not snoop the data cache.
Intel implemented snooping to cater to DOS games that use self-modifying code.
Motorola wisely avoided such nonsense, but that makes it critical that you
flush the data cache (force a write on step 1) and purge the instruction
cache (to force a read on step 2).  The existing NetBSD cache flush code is
slightly broken, but I have not seen improvement to be gained by tweaking it.
It's quite possible that there is a kernel bug such that the cachectl syscall
is actually broken.  After all, how many apps have a critical need to flush
the cache?

I'm away on business later this week so I don't have much time in the near
future to play with this, so I'll close with my findings on NetBSD's cache
flushing code.  My jit.h currently reads:

#define FLUSH_DCACHE(beg, end)                                  \
        __asm__ __volatile__(                                   \
                "movem%.l %/d0-%/d7/%/a0-%/a5,%/sp@-\n\t"       \
                "move%.l %0,%/a1\n\t"                           \
                "move%.l %1,%/d1\n\t"                           \
                "sub%.l %/a1,%/d1\n\t"                          \
                "movel  %#0x80000006,d0\n\t"                    \
                "trap   %#12\n\t"                               \
                "movem%.l %/sp@+,%/d0-%/d7/%/a0-%/a5"           \
                :                                               \
                : "g" (beg), "g" (end) )

#endif

The calling sequence here is: base address in a1, length in d1 and command in
d0.  The original code got the values in d1 backwards (I think.  I'll have
to verify with GDB, if it's indeed possible to plant a breakpoint at an
arbitrary assembler instruction.)  To see what happens in the kernel, it's
necessary to look at the kernel source, which I will not post here. :-)