preston@felix.UUCP (Preston Bannister) (01/24/89)
I found a very interesting utility on Genie called RELOC. What it does is modify a program's code file to make it self-relocating and then changes the codefile type so that TOS thinks the codefile is position-independent. What does this mean? This means that programs load _much_ faster, as TOS does not clear all of memory when a position-independent program is loaded. (Much the same effect as using NULLFILL). I've used it on the MWC compiler codefiles to cut several seconds off each compile. I've also used it on GULAM, MicroEmacs, and several other utilities with similar good results. All in all, an interesting piece of software! -- Preston L. Bannister USENET : hplabs!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister
leo@philmds.UUCP (Leo de Wit) (01/25/89)
In article <80497@felix.UUCP> preston@felix.UUCP (Preston Bannister) writes: |I found a very interesting utility on Genie called RELOC. What it does is |modify a program's code file to make it self-relocating and then changes the |codefile type so that TOS thinks the codefile is position-independent. | |What does this mean? This means that programs load _much_ faster, as TOS |does not clear all of memory when a position-independent program is loaded. |(Much the same effect as using NULLFILL). | |I've used it on the MWC compiler codefiles to cut several seconds off each |compile. I've also used it on GULAM, MicroEmacs, and several other |utilities with similar good results. There is one little gotcha with programs marked 'position-independent': the program file that was just read in, is left open. This is a bug in the old Roms; it could well be solved in TOS 1.4. In practice this means you can run about 43 of these programs, and then you're out of file descriptors 8-(. Also when you try to run a non-program file (not 0x601a as the first word), GEMDOS correctly generates an error, but leaves the file open. And RELOC should better clear the BSS, or else your C programs will break, 'cause GEMDOS does no clearing in this case (not explicitly initialized global and static data must be initialized to all zero bits; this is guaranteed by both K&R and the dpAns). The idea of RELOC is however appealing; if only it would be able to get rid of the open file descriptor... Leo.
JOE@rcgl1.eng.ohio-state.edu (Joe Rohde) (01/27/89)
What was not mentioned is that RELOC.ARC comes with another file (gemfix.prg ??). well whatever it's name, you put this file into your auto folder and it installs itself as a fix to the open file handle problem. it also comes with a warning that it plays the vector stealing game, and may not be compatible with all auto programs, but i'v had no problems. Joe Rohde rohde-j@eng.ohio-state.edu or rohde@cis.ohio-state.edu
preston@felix.UUCP (Preston Bannister) (01/27/89)
From article <930@philmds.UUCP>, by leo@philmds.UUCP (Leo de Wit): > There is one little gotcha with programs marked 'position-independent': > the program file that was just read in, is left open. This is a bug in > the old Roms; it could well be solved in TOS 1.4. In practice this > means you can run about 43 of these programs, and then you're out of > file descriptors 8-(. Also when you try to run a non-program file (not > 0x601a as the first word), GEMDOS correctly generates an error, but > leaves the file open. Along with the RELOC utility came a little program for the \AUTO folder that is supposed to address exactly this problem. While the author was not certain that his solution was bulletproof, I have not (yet) run into a situation where it has failed. > And RELOC should better clear the BSS, or else your C programs will > break, 'cause GEMDOS does no clearing in this case (not explicitly > initialized global and static data must be initialized to all zero > bits; this is guaranteed by both K&R and the dpAns). It does, or more precisely, the code it appends on the end of codefile does. > The idea of RELOC is however appealing; if only it would be able to > get rid of the open file descriptor... All I can say is that for my usage (gulam,make,cc,grep,find,emacs,etc.) it does seen to work, and work well. -- Preston L. Bannister USENET : hplabs!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister