Path: chuka.playstation.co.uk!scea!pro1-137.barrie.connex.net!user From: developer@woodentulip.com (Sean Kennedy) Newsgroups: scee.yaroze.programming.codewarrior,scea.yaroze.programming.codewarrior Subject: Re: GTE asm with CodeWarrior Date: Sun, 31 Jan 1999 20:54:58 -0500 Organization: Wooden Tulip Ltd. Lines: 162 Message-ID: References: <78dk65$nd41@chuka.playstation.co.uk> <36AAF8E8.E85886FB@hinge.mistral.co.uk> <78f5ll$nd46@chuka.playstation.co.uk> <36AB8574.82169D5F@hinge.mistral.co.uk> <78le37$gpd8@chuka.playstation.co.uk> NNTP-Posting-Host: pro1-137.barrie.connex.net Xref: chuka.playstation.co.uk scee.yaroze.programming.codewarrior:441 scea.yaroze.programming.codewarrior:384 I am answering Craig Graham and well as John Blackburne. Craig: **** Paste of Irrelevant Content: **** ;) > Sean Kennedy wrote: > > Very true, about the Commercial version, but to save time and money > > Metrowerks used the same code base for th Yaroze IDE as they did with the > > Commercial IDE. > > With Bits Yanked out. > The pro-dev version is 3 years of development ahead of the yaroze version. Unfortunately, I believe that is not the case. At least from what I have seen and asked questions about. The Yaroze Code base started when the CW IDE for Commerical PSX development was in its 2nd year. But the two are twinned. Namely on its resource base. Again, I mentioned that bits were yanked out. THAT and only that constitutes the difference. The graphics are re-arranged, and the debuggers are different, but the IDE has plenty of similarity. Trouble is, When is the Next CW for Net Yaroze version coming out? That may be never... I cannot guess. > > That does not mean that the Yaroze system can be used for Assembler > programming. > Yes it does. Download the ARS library source code from my SCEE site > for an example..... Sean is a bit tick-ed here... ARS shows and proves that one can develop code using Assembler for the PSX_NY. From the way you responded, {and you were not alone} you indicate that the Yaroze cannot be programmed in assembler. You can. Why would Metrowerks AND Sony both mention that you could. You just needed to talk with Sony for someone to get you a code snippet. > > When the North American Groove crew were in the SCEA management of the > > Yaroze program, there was an open invitation for those who whished to > > investigate R3000 assembler to request the information from the contact > > staff. Hence the code snippet mentioned above. > R3000 asm is not what was being discussed. That's easy. And permitted. What assembler code was it? So the discussion is about using assembler code developed {or copied from} for use with the commercial development system. Or compiling assembler code that was developed by someone [Their own content] with access to the CD_PSX, and they could not make it work on a Yaroze development system. You have a problem with that? > > > -sean > Craig. **** PASTE irrelevant stuff. **** John Blackburne: > (Sean Kennedy) wrote: > > That does not mean that the Yaroze system can be used for Assembler > programming. > > It can. Details follow. > > > Hah, nothing in the "documentation" says anything > > See pages 81 - 87 of the PDF file "C Compiler Reference MIPS", from the > CodeWarrior CD. Documentation is was referring to was not from Metrowerks. I was indicating SCEA documentation. -sorry. > > but I noticed a > > few Metrowerks examples and .h files that contained defintions that > > allowed GTE / GPU optimizations in assembler. > There's that too: ASM.H is the interesting one as it lets you refer to R3000 > registers by standard names. This leads into the next category. The ASM.H refers to the R3000 registers as part of the processor definition. That is normal. It is part of the support for R3000. As well an R3000.H file exists too. What I was referring to was the GTE registers. Those are not documented. > > Wait a minute here. The assembler will ony make sense to those that know > > what its true register designation defintions do and are documented. > > MIPS assembly, including register and calling conventions, e.g. which > registers variables are passed in, is fully & publicly documented. You can > find the info online and in bookstores. The CodeWarrior Docs give some > references. The CodeWarrior docs do not include this info, rather they > describe MetroWerks implimentation of MIPS assembly. Together with the > public docs it tells you everything you need to know to be able to program > in assembler on Yaroze. Again, true. This is covered by the ASM.H file. And if I wanted to write some code to do some fast "EnterCriticalSection()" code bits I would use all above public access documentation relating to the R3000. > > Nice motives, just stick to what you know you can do with supporting > > documentation. What supporting documentation as part of either the Metrowerks Documentation, or the SCEA Net Yaroze documentation talks about the GTE co-processor internals as it relates to assembly language? Or to the GPU? or the MDEC? Any documantation that relates to machine-language specific optimisations of the above three is not packaged as part of a Net Yaroze Development kit. But the R3000 processor is publicly documented as we all know, and my reference was not related to that. > I plan to. > > > Assembler is a very powerful developer tool if you know EXACTLY what you > > are doing at ALL Times. > I do (mostly). Heh, same here. :) > > This example is a clear case of someone who got a > > code snippet, and tried using it without proper file/library support in > > the compiler. > > However, if Sony had released an assembler fragment to allow "lets say" > > Force feedback control as part of the GetPadBuf() routine, to allow an > > output. Called PutPadBuf( *padFF_Info ) and there was good documentation > > support. Then Yes Metrowerks CW for Net Yaroze can compile the assembler > > source, and it would work. But it is easier to maintain these hooks in > > Library Upkeep in the file: LIBPS.A > > Assembler is like digging a post hole with a teaspoon. > > Keep in mind, you have control over EVERY Little Piece of Dirt. > > For most coding it's better to work in a high level language such as C: > going to assembler provides little benefit if most of the work is done by > libraries, or if the code is non-critical. But there are many occasions > where you will see significant gains after re-coding in assembler. And even > if you always code in C a good understanding of the processor and its > assembly language can help you write much better code, on the Yaroze as much > as any other processor. > John Yep, I agree. I found THAT out coding for PowerPC. A recent book proved what I already found out for myself. And just think, I had no one to chat about it either. :( I like to code in assembly when it suits me. But not as an everyday approach to coding in general... -sean