Re: [B2-devel] JIT Compiler: Direct Addressing likely to be mandatory

[Lauri P. <lpe...@ni...>]

On Fri, 5 Jan 2001 18:59:46 +0100, you wrote:

Hi Gwenol=E9,

>3) Forbid usage of banked memory addressing with the JIT compiler. I
>will tend to this solution since direct addressing is so much faster
>than banked memory addressing. Both with the JIT compiler, of course.

I think number 3) makes sense...

>Lauri, is it really impossible to do Direct Addressing under Win 9X ?

Not at all.

Your post inspired me to test it after a very long time, it seems
to work ok now. I'm not sure when it got fixed, but in theory, it
should have been working all along.

Writes to random memory crash Windows 9x a lot more easily than NT.
At least for me, MacOS writes to illegal addresses during the boot and
later on too, not only to ROM. Most of the illegal writes are catched
by the exception handler, but if it happens to write to a legal (but
fatal) host address, say, the B2 stack, heap or static data, anything
can happen. I suspect that something like this was the reason.

It's a bit scary that things can break this way. The only way
(that I know of) to make sure it won't happen is to precede every
memory access with a "bound" assembly command, but it's slow.

>As far as the Unix ports are concerned, I really don't have to do
>"triple_allocation".
>
>Rough process:
>
>- allocate RAM + ROM at the same time but keep their respective base
>address properly page-aligned
>
>- ROMBaseMac seems to be relocateable. Therefore, it is simply
>        RAMBaseMac + aligned_ram_size;
>
>- Init MEMBaseDiff to be RAMBaseHost - RAMBaseMac. As RAMBaseMac is 0,
>MEMBaseDiff simply turns out to be RAMBaseHost.
>
>- MacFrameBaseMac seems to be relocateable too. Then, when it is time to
>initialize VideoMonitor.mac_frame_base, you simply assign the result of
>the call to Host2MacAddr(the_host_screen_buffer);
>
>It will work because we have distinct regions and offsets between a
>virtual (Mac) address and a native (host) address is constant.

Conceptually this is pretty much the same what I have been doing.
But when I started to write the triple allocation thing, I assumed
that it is not safe to relocate anything. Given the 1GB/2GB
address space I had, I quickly realized that I must relocate
*something* and it worked, but I tried to keep them at absolute
minimum.

But I already changed the code to reflect what you said,
allocating only one memory block. It makes the code cleaner;
and either one relocates something or doesn't -- you can't be
almost dead either now can you :)

In fact: I tested under OSR2/VMware and Win98 only after doing this
aforementioned change, so it might be that you fixed it :)
Would you like to try it out?

>- As for write-protecting the ROM region, you can stick with you
>step_over() method=20

The stepping is needed not only because of the ROM, but
other illegal memory accesses as well.

>or simply implement the ScratchMem subterfuge as
>well.

What's that? I have probably missed something.

I grepped the old mails and found some hits, but none
of them explained what's that all about.

>Conclusion:
>
>What should I do ? Struggling myself to make the JIT compiler "fast" in
>banked memory addressing and therefore fix the problems I related
>hereabove ? You know, current results shows that banked memory
>addressing is twice as slow as direct addressing... I am just wondering
>if it is worth the effort ;-)

As far as the Windows port is concerned, banks are needed only
under Classic emulation, I don't think that those addresses
can be relocated, although I have never tried.

Classic emulation has been broken for some time in Windows port,
but I'm hoping to get it working again some day. I have no
real use for it, but some other people do.

And anything I might want to run under Classic emulation
is more than fast enough already.

>PS: I placed a new source tarball on my website.
>
>Bye.

Lauri