From mint-bounce@lists.fishpool.fi Thu Apr 27 11:07:57 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <1146128724.44508954548e4@imp3-g19.free.fr> Date: Thu, 27 Apr 2006 11:05:24 +0200 From: Xavier Joubert To: mint@fishpool.com Subject: Re: [MiNT] Low-memory protection References: <44500380.3222.F08F60@localhost> In-Reply-To: <44500380.3222.F08F60@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 84.4.248.33 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: xavier.joubert@free.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=2.6 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id k3R97vSg019739 Hi, Some thoughts for completeness... I think we can say Milan is "Atari compatible" in that it can run well written software designed for original Atari hardware. This missing feature is however a problem for programmers. One can miss a minor bug on Milan that will crash instantly on another hardware. This problem exists also on CT2 accelerator board. CT60 was designed with this in mind. 040 and 060 only support 4 and 8 kb PMMU pages. 2 kb pages are not available. This problem could be fixed by reprogramming the logic, given there's enough space available... This could obviously slow the whole computer down. The real problem here is that logic sources are not available, and even if they were, I don't who have skills and time to work on this. Selon Roger Burrows : > For better compatibility, the bus error interrupt handler could be updated so > that the user sees no error for accesses to locations 0x800->0x1fff. This > could be done by rerunning the failing instruction in supervisor mode. If > this > is feasible, this ought to be a subsidiary run-time option, since it has the > potential to be a performance killer. This is feasible by : - copying the faulty instruction in a reserved space followed by the code to return to user mode and rts, - putting the adress of the instruction folowing the faulty one on the user stack (as the rts return adress) - modifying the bus error stack so the system retry execution in our reserved space in supervisor mode. The problem with this is that it introduces a nice security hole. One can use this to write any memory location in supervisor mode, by first writing the desired value between 0x800 and 0x1fff, then moving this value from there to the desired (supervisor only) address. This instruction will be executed in supervisor mode... And this is a performance killer, of course. Best regards, Xavier