[Aranym-user] JIT problems
Francois LE COAT
lecoat at lutece.net
Sun Oct 17 16:57:12 CEST 2004
Xavier Joubert wrote:
> Selon Francois LE COAT :
>>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 :-(
Ozk has a Hades 60 with 40Mb of memory ... How I know it ? Because
I have the same, and that I just leave SetMMU configuration files in
the state, unmodified, because I have the same hardware ! I can
use either full STRam or create TTRam, but I prefer STRam configuration
that is more compatible with most of softwares ... But TTRam works
> 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.
Right. The information that gave me Olivier Landemarre is then correct !
>>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.
That works on a 68030 (?), but doesn't work on a 68060, except if
TOS is patched, and that you use SetMMU ...
>>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. ;)
Didn't you saw the Smiley ? That was ironical !
Of course I know assembly ! I first bought an ATARI machine in 1986 to
practice my 68000 lessons ... In June 1996 I had the first Hades 60 that
was bought in France, and I had to make it work by myself ... You're not
reading fr.comp.sys.atari ? You seem to ignore completely the French
community, apart what is around CT60 ...
I programmed a software FPU for my Hades 60, that is still available
on my home page, in the POV 3.1g archive, that is assembly ... Part
of my Eureka software is written in assembly (GCC and PURE C).
But I'm not really interested in systems developments ... My part is
rather applicative ... Please have a minimum of respect for peoples
that worked on 68060 when you didn't even know it existed ! Please
stop thinking that you're the best, and that CT60 is the only system
because you gave a hand to Didier, or because you adapted JIT for
WinARAnyM ! Please consider also that I was the first person that
ported ARAnyM on a Sun Sparc, and that it is not the first time that
we are talking with Ozk, Milan or Petr ... You can go and see in the
archives of this mailing list ;-)
> 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.
Well, I don't see such effects on my Hades 60, as I explained here
>>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 ! ;)
I generally speak about my ideas before coding like a "nerd" ...
> 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...
Ho well, as I explained, I'm interested in applicative part. The
knowledge of the MMU is useless for me, except for generalities,
because that is simply totally transparent on a well configured
system. And that works quite well on my Hades 60. My softwares
are not critical, and are working on all known systems !
> 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
> here already).
Every systems so far, except ARAnyM with JIT :-)
> 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".
That's not what I've thought ...
> 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). :)
I can imagine !
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
More information about the cz-bobek-lists-aranym-user