Path: chuka.playstation.co.uk!news From: sceetech Newsgroups: scee.yaroze.programming.3d_graphics,scee.yaroze.programming.gnu_compiler,scee.yaroze.programming.codewarrior Subject: Re: Best Compiler bug ever (almost) Date: Thu, 10 Apr 1997 14:57:21 +0100 Organization: SCEE Lines: 51 Message-ID: <334CF1C1.23A4@interactive.sony.com> References: <334c572f.9721328@news.playstation.co.uk> <334CB737.3E25@interactive.sony.com> <334ed0d3.1764129@news.playstation.co.uk> Reply-To: ps_yaroze@interactive.sony.com NNTP-Posting-Host: 194.203.13.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) Xref: chuka.playstation.co.uk scee.yaroze.programming.3d_graphics:76 scee.yaroze.programming.gnu_compiler:18 scee.yaroze.programming.codewarrior:33 > That is what I thought. We created a mapfile but having never used a > mapfile before didn't make much sense of much of it. It looked as if > half the variables overwrite each other - I think I need to get the > gnu docs this weekend! The mapfile is just oddly structured; once I started using them I never had memory troubles again. They specify everything, where things go and how large they are, text segments, offsets, etc etc etc. > > Not at all. We were just comparing my bg routine with the Sony ones as > we were just chucking across a pacman level. We were just declaring a > few map layers, one was for player stuff. The size was 23*19 u_shorts. > There were 3 array declarations in a row, the first two being 1 letter > shorter than Playerwhateveritwas. The first two were done fine, but > the final one caused the crash no matter what others had been > declared. All were tested individually and all was fine except the > final one again. We added just a single letter to the variable name > (in various places) and it worked fine. I simply can't say anything about the length of the variable name, I've never experienced anything like it. I am still certain that the underlying problem is the 4byte boundary aligning. The fact that an even-named array which doesn't align worked seems neither here nor there. At the risk of sounding pedantic I'd like to say that I cannot ever see the point of declaring an array with any of its dimensions being odd. I most definitely cannot see the point of using u_short instead of int for such a small array, and this minute memory save caused the crash. The Yaroze has Lots of memory, and I've never needed to replace ints with shorts, chars, etc to fit anything in. There's always far larger rearrangements that are far safer to do if you ever find yourself gettting short of memory E.g. reducing number of object files (the mapfile shows that each extra .o file has a 4096 byte overhead) E.g. reducing the global/stored data of a program by finding a quick way of re-inferring it at runtime (apply this ruthlessly and you'll find yourself with huge amounts of room) E.g. packing all resource files tightly together (find size of al TIM, TMD, SEQ, VH, VB files in bytes and pack like sardines). Hope this is useful Lewis