spencer@usc-oberon.UUCP (Randy Spencer) (08/04/86)
I have just got one question, and it is just one word:
Resident?
I want to use it so bad! Has any body got an example of how to use it? I want
to get lattice and emacs both in ram, boy that would be great. Is there any
programs that run as a demonstration? I am going to be such a happy man!
ps. Resident is a new, documented by two sentences, command on the v1.2
toolkit disk.
--
==============================================================================
....I disclaim everything, I had nothing to do with it, it's not my fault!....
Randal Spencer - DEC, {amiga} Consulting - University of Southern California
phone: (213) 743-5363 Arpa:Spencer@USC-ECL,USC-Oberon Bitnet:Spencer@USCVAXQ
UUCP:...up to you!{{decvax,ucbvax}!sdcrdcf,scgvaxd,smeagol}!usc-oberon!spencer
Home: 937 N. Beverly Glen Bl. Bel Air California 90077 (213) 470-0428
New permenant address (for several years anyway): Box 4542 Berkeley CA 94704
------------------------------------------------------------------------------neil@amiga.UUCP (Neil Katin) (08/06/86)
In article <661@usc-oberon.UUCP> spencer@usc-oberon.UUCP (Randy Spencer) writes: >I have just got one question, and it is just one word: > >Resident? > >I want to use it so bad! Has any body got an example of how to use it? I want >to get lattice and emacs both in ram, boy that would be great. Is there any >programs that run as a demonstration? I am going to be such a happy man! > >ps. Resident is a new, documented by two sentences, command on the v1.2 > toolkit disk. >-- The resident command links segments together onto a system list. There is a special cli (on the toolkit disk) that searches this list first to find your programs. HOWEVER, your code needs to be fully reentrant to live on this list. Neither lattice C nor emacs are reentrant. It turns out that all BCPL programs are. C programs can be written so that they are reentrant, but they typically are not. We are working on a fuller set of 1.2 release notes now. We hope to get most of the new features talked about in this new & improved release notes. Neil Katin
phils@tekigm.UUCP (Phil Staub) (08/06/86)
In article <1468@amiga.amiga.UUCP> neil@rocky.UUCP (Neil Katin) writes: > >HOWEVER, your code needs to be fully reentrant to live on this list. >Neither lattice C nor emacs are reentrant. It turns out that all BCPL >programs are. C programs can be written so that they are reentrant, >but they typically are not. > Question: I am interested to know what it is about the lattice C compiler that generates non-reentrant code. I am not familiar with this compiler, but (at least according to my understanding) any code which does not utilize static or extern variables (i.e., only uses automatics or registers) should be re-entrant in C. I also know that with some compilers, functions which return structures do so in a non-reentrant way. Are these the only non-reentrancies to which you refer, or is there a gap in my understanding about reentrancy, or is there something else about Lattice which is non-reentrant. Thanks
jimm@amiga.UUCP (James D. Mackraz) (08/07/86)
In article <870@tekigm.UUCP> phils@tekigm.UUCP (Phil Staub) writes: >In article <1468@amiga.amiga.UUCP> neil@rocky.UUCP (Neil Katin) writes: >> >>HOWEVER, your code needs to be fully reentrant to live on this list. >>Neither lattice C nor emacs are reentrant. It turns out that all BCPL >>programs are. C programs can be written so that they are reentrant, >>but they typically are not. >> > >Question: > >I am interested to know what it is about the lattice C compiler that >generates non-reentrant code. I am not familiar with this compiler, >but (at least according to my understanding) any code which does not utilize >static or extern variables (i.e., only uses automatics or registers) should >be re-entrant in C. I also know that with some compilers, functions which >return structures do so in a non-reentrant way. Are these the only >non-reentrancies to which you refer, or is there a gap in my understanding >about reentrancy, or is there something else about Lattice which is >non-reentrant. > >Thanks Since I read Neil's posting the same way you did, I'll make the clarification. 1) The Lattice C Compiler is not itself a re-entrant program. The reason this bears mentioning is that having a resident compiler was our in-house motivation for resident programs (it is a large program that is loaded again and again in a typical development session). 2) Perhaps the Lattice C Compiler can create re-entrant code. Indeed some compilers create non-reentrant code, when returning structures, for example. Greenhills does this, and I almost set myself up for the most insidious of bugs in Intuition by not respecting this. I do not know what things to watch out for with Lattice. Another area of concern would be the startup code (and other linked libraries) which might contain statics. I can't see a way to be sure of this stuff without consulting Lattice. Go Wild. jimm Amiga/Commodore
pete@topaz.berkeley.edu (08/17/86)
In article <870@tekigm.UUCP> phils@tekigm.UUCP (Phil Staub) writes: >In article <1468.....> neil@rocky.UUCP (Neil Katin) writes: >> >>HOWEVER, your code needs to be fully reentrant to live on this list. >>Neither lattice C nor emacs are reentrant. It turns out that all BCPL >>programs are. C programs can be written so that they are reentrant, >>but they typically are not. >> > >Question: > >I am interested to know what it is about the lattice C compiler that >generates non-reentrant code. I am not familiar with this compiler, >but (at least according to my understanding) any code which does not utilize >static or extern variables (i.e., only uses automatics or registers) should >be re-entrant in C. I also know that with some compilers, functions which >return structures do so in a non-reentrant way. Are these the only >non-reentrancies to which you refer, or is there a gap in my understanding >about reentrancy, or is there something else about Lattice which is >non-reentrant. > >Thanks The only thing that is really non-reentrant about (any) C on the Amiga is the way start-up is handled. Certain static locations -- defined at the assembly level -- are filled with items like the top and base of the stack, pointer to the command line, and so on. If you try to enter the same loaded segment of code (with the same static data area) a second time, you're bound to screw things up. The answer has to be to write an alternative startup.obj that puts the data somewhere that's exclusive to that process. I'm working on't.... Pete G.