dick@cca.ucsf.edu (Dick Karpinski) (10/29/90)
I'm looking for examples of RISC/6000 assembler programs to assist in a language processor port to the 6000. The only thing we need assembler for is to code up the co-routine transfer mechanism. I found the man page for as, but have yet to find the Principles of Operation or anything else that allows me to RTFM. Obvious and subtle hints about how to use Info will be appreciated. Dick
bengsig@oracle.nl (Bjorn Engsig) (10/30/90)
Article <3210@ucsfcca.ucsf.edu> by dick@ccnext.UUCP (Dick Karpinski) says: | |I found the man page for as, but have yet to find the Principles |of Operation or anything else that allows me to RTFM. The CDROM version of the Info database has an assembler reference manual on it. -- Bjorn Engsig, E-mail: bengsig@oracle.com, bengsig@oracle.nl ORACLE Corporation From IBM: auschs!ibmchs!cs.utexas.edu!uunet!oracle!bengsig "Stepping in others footsteps, doesn't bring you ahead"
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/30/90)
In article <3210@ucsfcca.ucsf.edu> dick@ccnext.UUCP (Dick Karpinski) writes: >I'm looking for examples of RISC/6000 assembler programs to assist >in a language processor port to the 6000. The only thing we need >assembler for is to code up the co-routine transfer mechanism. One could always use "cc -S" right? Wrong. IBM sees no market demand for "cc -S" so speak up. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
abe@mace.cc.purdue.edu (Vic Abell) (10/31/90)
In article <4081@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: >In article <3210@ucsfcca.ucsf.edu> dick@ccnext.UUCP (Dick Karpinski) writes: >>I'm looking for examples of RISC/6000 assembler programs to assist >>in a language processor port to the 6000. The only thing we need >>assembler for is to code up the co-routine transfer mechanism. > >One could always use "cc -S" right? Wrong. You can get an object code listing that looks like assembler code from the XL Fortran compiler. The following command xlf -qsource -qlist -qdebug=cycles example.f produces a combined source and object code listing in ./example.lst.
madd@world.std.com (jim frost) (11/06/90)
bengsig@oracle.nl (Bjorn Engsig) writes: >Article <3210@ucsfcca.ucsf.edu> by dick@ccnext.UUCP (Dick Karpinski) says: >| >|I found the man page for as, but have yet to find the Principles >|of Operation or anything else that allows me to RTFM. >The CDROM version of the Info database has an assembler reference manual on it. Beware that both the printed and online manuals are missing several assembler instructions. They were deliberately removed between the original and final versions of the manual (I have both). If your program needs to synchronize the I and D caches, you will need the "POWER Processor Architecture" document, which is somewhat difficult to get hold of. Also beware that the assembler examples are not clear as to how to set up the various sections of your program. The `hello' example is poor at best and the proportional font it's printed in makes it very difficult to read. For programming techniques I suggest using dbx's /i command to disassemble simple C programs. This won't help you set up the assembler sections but it provides wonderful insight as to how to call functions, access globals, and code function prologues and epilogues. If you care about the calling conventions, beware that both the info and printed documentation are incorrect about shadowing floating point arguments and how to call varargs functions. Floating point arguments should always be shadowed in GPR's (the documentation says otherwise) and there is no special calling convention for varargs functions. If you are yourself a varargs function you can just write the GPR arguments onto the stack and access them that way. Write some sample C programs and see how they do it, don't trust the documentation. Happy hacking, jim frost saber software jimf@saber.com
madd@world.std.com (jim frost) (11/06/90)
abe@mace.cc.purdue.edu (Vic Abell) writes: >You can get an object code listing that looks like assembler code from >the XL Fortran compiler. The following command > xlf -qsource -qlist -qdebug=cycles example.f >produces a combined source and object code listing in ./example.lst. You can get this from xlc too but the code cannot be fed as-is into the assembler. Disassembling via dbx is far more educational. jim frost saber software jimf@saber.com
marc@arnor.uucp (11/07/90)
madd@world.std.com (jim frost) writes: >If you care about the calling conventions, beware that both the info >and printed documentation are incorrect about shadowing floating point >arguments and how to call varargs functions. Floating point arguments >should always be shadowed in GPR's (the documentation says otherwise) >and there is no special calling convention for varargs functions. If >you are yourself a varargs function you can just write the GPR >arguments onto the stack and access them that way. Write some sample >C programs and see how they do it, don't trust the documentation. Be careful about reading the documentation or looking at what the compiler does with reference to passing floating point value parameters. There is a problem with the description in both the compiler manuals and the compilers. I don't know which manual you were referring to, but I couldn't find it anywhere else. The problem occurs when the callee expects more floating point value parameters than were passed and generally only is manifest at low opt levels as caller's automatics getting hosed. The reason is that the callee is storing what it thinks are its parameters in the stack. It shouldn't store past the first 32 bytes of parameter list for unreferenced parameters. The stores should happen on the calling side. There may be a fix available to the compiler shortly (in the form of an option that does the correct thing). In the next release the correct thing will be the default and there will be an option to do what release 1 does. The correct thing: - the first 8 words of arguments correspond to the 8 parameter registers r3-r10 - the non-float value words from the first 8 words of arguments are passed in the corresponding GPRs - the first 13 floating point value parameters are passed in fp1-fp13 - if there is no function prototype for the called function, or the prototype contains an ellipsis then all floating point values are also passed in GPR/stack (GPRs for those occurring in the first 8 words of the parameter list, stack otherwise) - if there are more than 8 words of arguments, then the extra words are stored on the stack regardless of type - the called function takes the parameters from fp1-fp13 for the first 13 floating point value parameters, from r3-r10 for the first 8 words of non-floating point value parameters and from the stack otherwise. If it wants its parameters in contiguous storage (at low opt or if the address of a parameter is taken) then it stores only the first 32 bytes from either FPRs or GPRs depending on the type. Note that you can pass a floating point argument to an integer parameter but not vice versa. J.B. Minish