[Aranym-user] JIT problems
xavier.joubert at free.fr
Sun Oct 17 15:33:30 CEST 2004
Selon Francois LE COAT <lecoat at lutece.net>:
> SetMMU on Hades is a program from Ozk, who seems to have the same
> Hades 60 than mine ... Ozk's Hades 60 is now broken, and it's a pity
> because he is a main developer of XaAES and freeMiNT :-(
The only thing you can do with SetMMU to correct this type of problems is
something like :
- fully disabling instruction cache, or
- disable instruction cache on ST-Ram (given you configured GemView flags to
load its module in ST-Ram).
The two solutions are of course worse than flusing instruction cache on every
Pexec() and Malloc() calls like Didier did in the CT60 TOS.
> That's not true. For external code, system calls like Pexec() or
> shel_write() are called ... Am I wrong ?
That's true for any well written program. GemView doesn't fall in this category.
It simply allocates a memory area with Malloc(), loads a module there with
Fread() and then calls it with a mere JSR. That's wrong on any processor with a
separate instruction cache.
> Certainly ... Well then CT60 owners are not lucky with their memory
> management. CT60 must have a considerable speed loss ... The benches
> are proving it ... CT60 solution is far from optimal ! ;-)
We took a lot of time to allow the CT60 to be the first Atari compatible
plateform with a 060 running at full speed. I really appreciate such a comment
from someone who don't know ASM. ;)
On CT60, instruction cache is activated. Didier simply patched TOS to allow
broken programs to run by flushing (not disabling !) instruction cache on
Malloc(). Of course, this patch is useless under FreeMiNT. So I believe GemView
does not run on CT60/FreeMiNT unless SetMMU is used. But this implies a huge
loss of speed.
> The solution would definitely be to handle MMU ...
> We're far from it unfortunately :-(
If it's the solution, then go for it. We're waiting for your patch ! ;)
Really, François, I don't understand you. You don't know anything about
assembler, PMMU and instruction cache (according to what you wrote). Still you
try to convince people like Petr and Milan, who know perfectly what they are
talking about, that they are wrong...
Well, which OS do you use to run GemView ? If it's TOS, I could write an
optional patch that would flush instruction cache on Malloc() calls (I it's not
If it's FreeMiNT, then there's nothing ARAnyM developpers can do for you. You'd
better contact FreeMiNT developpers and ask them for "an optional instruction
cache flush on Malloc() calls".
Another solution would be to patch GemView to correct this bug. But, IIRC from
past experiences, GemView verify the integrity of its code from time to time and
exits if it has been modified. This didn't prevented me from writing a key
generator for this program (Never released, of course. That was just a nice
challenge for a beginner in assembly language). :)
More information about the cz-bobek-lists-aranym-user