|Re: [hatari-devel] MMU emulation broken ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] MMU emulation broken ?
- From: Douglas Little <doug694@xxxxxxxxxxxxxx>
- Date: Tue, 3 Sep 2013 14:22:03 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9i6erPQxNxayynnQofTllctEkh4Nz3Yv1JahB6P3AbE=; b=MjYq3O2bvC5etCGhFcUtDkIeLsdBWd8D/1QkSCAGRsewbcv06nd36ByvwLa+1sRnmS H8bzH56PeLDmm6QziyIzuN22i2blwxfP/bJ9o/oyhklQZCJIbn1FKuS69Ifg1viXIgw7 w+2jqxyKUq2pEw9SgS3KBCiXIr5Sx329wWV1ss2d97hfpcZ+4ee6EIp2E8ILV88yyqGr Cd2byuHIPlpEUN4sjiS5jjc3w/YZ1aICXjwvcNCQk/txTGnP5gNAnHXoPQmHDy4B/u9K frf330MU0XKEjbAlwJ7xQhFNHMgT4nMXVEZcQGAzZoXBDOB7YsEFQ9eJ+tqMpYTicoc9 zsDg==
The only strangeness I've seen so far relates to the state of CRP/SRP registers for saving/restoring MMU state.
The MMU can throw exceptions if illegal values are written to these registers - the bitfield gets sanity-checked by the CPU before the register is changed.
I noticed the initial value of SRP is garbage on the Falcon and therefore cannot be saved/restored without causing an exception. This should affect all Falcons (and Hatari).
However I found one additional (seemingly Hatari-specific) problem, which results in an incorrect value of 0 being read from CRP, which also causes an exception when restored on exit (but this doesn't happen on real hardware). This operation uses the 64bit pmove.d instruction.
I wondered if it needs to be quadword-aligned, but haven't investigated it properly yet so I'm not sure of the real cause for difference here.
I haven't noticed any other differences so far.