Path: chuka.playstation.co.uk!news From: sosman@terratron.com (Steven Osman) Newsgroups: scee.yaroze.freetalk.english Subject: Re: Daft Question [long] Date: Fri, 31 Aug 2001 03:48:59 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 72 Message-ID: <3b900725.34899202@www.netyaroze-europe.com> References: <01c129ca$a5a6f700$d81fe4d5@pal-s-omnibook> <9m1d9c$b2i7@www.netyaroze-europe.com> <01c12ceb$fba64880$9709e4d5@pal-s-omnibook> <9m9c88$ioj5@www.netyaroze-europe.com> <01c12edc$cc2bf440$991fe4d5@pal-s-omnibook> <9me1g1$1sb13@www.netyaroze-europe.com> <9meajl$1sb17@www.netyaroze-europe.com> <9med8s$1sb18@www.netyaroze-europe.com> <9mekaq$1sb20@www.netyaroze-europe.com> <3b915bb2.83462112@www.netyaroze-europe.com> <9mm6uc$h6i10@www.netyaroze-europe.com> NNTP-Posting-Host: dsl092-099-074.nyc2.dsl.speakeasy.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.452 I have a big fat PDF file actually that has a lot regarding the MIPS 3000 and it's instruction set... If anyone's interested, I'll see if I can dig up the URL where I got it from. I'm definitely not one to discourage optimization, I just wanted to keep everything in perspective. Actually, I don't know if CW or GCC allows you to have register variables. If you're going to do a lot of work on a couple of variables, storing them in registers will probably save big time clock cycles. By looking at some CW disassembly now, I don't think it treats register variables any differently... That's a shame, really. Sauce On Thu, 30 Aug 2001 21:16:45 +0100, "Jon Prestidge (Jon@surfed.to)" wrote: >Hello Steven > >> I'm sure that many of us won't be >> using assembly anyway, so whether or >> not the MIPS cpu is capable of more >> powerful instructions is >> irrelevant > >> the ultimate question is >> "What code does the C compiler >> generate?" for a lot of us. > >...well yes I agree that's what I'm interested in too .... when your C code >consists of simple operations like + - >> etc. your C code is quite >representative of assembler anyway (assuming you're using integer math) and >each translates to one CPU instruction. So you can get a pretty good idea >of how much work the CPU has to do and it could help you write a faster bit >of C code. I don't use assembler either, there's no need to when you're >using C, I don't think. > >Now knowing that a divide and multiply is a lot slower than the other >operations then... if say you had a bit of code that divided by a thousand >to convert millimetres to metres then you may want to sacrifice a bit of >accuracy and divide by 1024 instead (the compiler will convert it to >>10 >for you... unless it's a very crap compiler). > >The work that you don't see in your C code that the CPU has to do is mainly >loading-in the variables from memory and then writing them back after the >opperation is done. You can reduce this loading and unloading if you group >together opperations on the same variable where convenient. > >If I've got a small perfomance critical routine to write I develop it in a >separate source file and then dissassemble it and keep experimenting and >dissassembling it until I reduce the number of CPU instructions (and now >I'll also be trying to recuce the number of divides and multiplys too) , but >I didn't mean that I kept it in assembler --- I just discard the assemly >code and use the tuned-up C code instead. Doing the dissassembly is easy in >CW -- you just right click on the file... I dunno how you do it in GNU off >hand though. > >I've attached a list of instructions for the R3000, I'm not sure if that's >exactly the CPU that the PSX uses, or if it's just in the same seris, >perhaps someone could confirm that? >Anyway it's something I should have looked at before blerting-out all that >guff in that earlier message I posted! I think I had a load of different >info about different CPUs in my head and had got it >jumbled-up...doh!....many appologies. > >Jon > >