Path: chuka.playstation.co.uk!news From: James Russell Newsgroups: scee.yaroze.programming.libraries Subject: Re: SsVabTransfer locks up! Date: Fri, 17 Jul 1998 09:59:43 +0100 Organization: Sony Computer Entertainment Europe Lines: 31 Message-ID: <35AF127F.9C67BF57@scee.sony.co.uk> References: <359E82E9.1134@dial.pipex.com> <35a17582.898850637@news.scea.sony.com> <35A5E635.6368@dial.pipex.com> <35AC619C.3A76@dial.pipex.com> <35ADC9B6.64475D04@scee.sony.co.uk> <35AF0089.5956@dial.pipex.com> NNTP-Posting-Host: camfw01.millennium.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5b1 [en] (Win95; I) X-Accept-Language: en Chris Chadwick wrote: > > James Russell wrote: > > > > 0x1f8003f0 is one word less than the top address of D-Cache (which is 1024 bytes long). That's what > > the stack is being set to in your code, so it is the _top_ of the D-Cache. > > You're right. Sorry, I had a bit of a brainstorm! > However, why set it to 0x1f8003f0 and not 0x1f8003ff (the top)? > For alignment? 0x1f8003fc xx xx xx xx 0x1f8003f8 xx xx xx xx 0x1f8003f4 xx xx xx xx 0x1f8003f0 xx xx xx xx According to Colin, when a function is called in the MIPS processor the first 4 parameters are passed in the registers, but stack space is allocated for them just in case the function wants to save them for later. Since you're always in a function when you set the stack to D-Cache, that function will need that space allocated, which is why there are 4 words (16 bytes) unavailable to you. This isn't set in stone, but it is a standard adhered to by the GNU compiler. Cheers, James -- == James_Russell@scee.sony.co.uk +44 (171) 447-1626 == Developer Support Engineer - Sony Computer Entertainment Europe Two elephants fell off a cliff. Boom Boom.