From mint-bounce@lists.fishpool.fi Tue Aug 16 00:29:46 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <430115B5.7060205@chello.nl> Date: Tue, 16 Aug 2005 00:22:45 +0200 From: Henk Robbers User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mint list Subject: Re: [MiNT] what's wrong with this code? References: <20050815220941.0e0a7536.mandin.patrice@wanadoo.fr> In-Reply-To: <20050815220941.0e0a7536.mandin.patrice@wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: h.robbers@chello.nl Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: 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.1 tagged_above=-50.5 required=7.0 tests=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 j7FMTjOI026082 Patrice Mandin wrote: > Le Mon, 15 Aug 2005 20:52:21 +0100 > a écrit: > > >>-----Original Message----- >>From: mint-bounce@lists.fishpool.fi on behalf of Johan Klockars >>Sent: Mon 15/08/2005 19:50 >>To: Mint list >>Subject: Re: [MiNT] what's wrong with this code? >> >> >> >>>There are physically separate registers for the various stack >>>pointers, which just get "remapped" in hardware depending on the >>>bits in SR. >> >>Question. >> >>When you normally write the following... >> >> move.w D0,-(SP) (or A7) >> >>You write this instead... >> >> move.w D0,-(SSP) or >> >> move.w D0,-(USP) >> >>What happens when the CPU is in super or user mode? > > > ssp and usp are used through A7. Just look at generated assembler code. > The only difference is the 'move from usp' privileged instruction, used > for example in most system traps to read parameters on user stack, from supervisor mode: > > my_xbios_trap: > lea sp@(8),a0 ; start of stacked parameters if trap #14 from supervisor mode > btst #5,sp@ ; check S bit in stacked SR > bnes supervisor_mode > movl usp,a0 ; read user stack pointer if trap #14 from user mode > supervisor_mode: > movew a0@,d0 ; read xbios function number > > [etc] > > rte > Another unspecific example of usp/ssp mechanism: trap enters SV mode --> A7 represents ssp, SR saved on the stack, real SR gets SV bit. If trap was issued in user mode and you set SV bit in SR on stack rte will not enter user mode and A7 will keep representing the ssp The usp itself will be unchanged. Because you are still in SV, you can clear SV bit in real SR and lo and behold, you are in user mode and A7 represents the usp again. andi #notSV,SR Correct? Things can go weird if you move something to A7 somewhere. For instance if you move usp,A7 when in SV mode. ssp:=usp. :-) A short journey into the unknown. To go boldly where no one has returned before. -- Groeten; Regards. Henk Robbers. mailto:h.robbers@chello.nl http://members.ams.chello.nl/h.robbers/Home.html Interactive disassembler: TT-Digger; http://digger.atari.org A Home Cooked teXt editor: AHCX