pedz@ctvax (09/05/85)
I am once again trying to get GNU Emacs up on an Integrated Solutions machine. I am working with 16.56. Here is what I have determined. 1) The operating system does not go to the entry address but some number of bytes after. Instead of starting at 0, it start someplace before address 6. Thus I have padded the bottom with 3 nop's which seem to get the job done. 2) crt0.c is the same as for the other 68000's except for the padding mentioned above. 3) alloca not only has the same problem on the IS as on the other 68000 systems but it has one much more serious problem. The IS compiler does the link and then movm to save the registers. Thus when the stack pointer is moved down, the registers are popped back off with the movm get bad values from the alloca storage. My kludge to this problem was to add an extra 40 bytes to the size of the space requested and copy the top 40 bytes of the stack to top of the new stack. The returned result is 40 bytes below the top of the stack. The magic number 40 is 4 bytes per register times 10 possible regester variables. Note that I can not determine how many register variables are actually being used which is why I can not reuse the space of the old copies. 4) The memory protection system on the IS is strange at best. It seems that the only part which is write protected is the section of memory from the top of text segment upto the next 64K boundry. (The page size is 4K, not 64K.) I solved this by defining SUN in the unexec.c file and then defining SEGSIZ to be 0x10000. I have not determined if the special things in dispnew.c for SUN should be activated or not. My problem: When xemacs is run (after temacs has preloaded and written itself out), it starts up and gets into a routine called init_display. At some point, it appears to trash the stack and jumps back to address 0 which is where crt0 (_start in this case) is located and begins to restart but now the environment has been screwed up. It gets back into init_display and determines that TERM has not been set, complains, and then exits. I have determined that it nevers gets out of init_display the first time by using print statements. I tried putting print statements into init_display but the problem changed. I have not determined if it gets into init_term (term_init?) yet. Is there anyone out there that has any suggestions? Also, is there anyone out there who can more clearly explain items 1 and 4 above? If you would like copies of what I've done, just drop me a note. (ps to the person who sent me a note on this before -- I will send you something more definate as soon as I really fix it or give up.)
fnf@unisoft.UUCP (09/08/85)
In article <34700009@ctvax> pedz@ctvax writes: > >3) alloca not only has the same problem on the IS as on the other >68000 systems but it has one much more serious problem. The IS >compiler does the link and then movm to save the registers. Thus when >the stack pointer is moved down, the registers are popped back off >with the movm get bad values from the alloca storage... Hmm, I don't know what the IS compiler is doing but both our 5.0 compiler (based on the mit port of the pcc) and our 5.2 compiler (the SGS from the generic 68000 microport), use the *frame pointer* with the link and movem instructions, not the *stack pointer*. Thus mucking with the stack pointer has no effect on subroutine linkages or register save/restores. Here is a copy of alloca.s that we use with our GNU emacs port under SVR2 on a dual systems machine. It seems to work fine. Whether or not it is correct is another matter :-). -Fred file "alloca.s" global alloca alloca: mov.l (%sp)+,%a1 # pop return addr from top of stack mov.l (%sp)+,%d0 # pop size in bytes from top of stack add.l &R%1,%d0 # round size up to long word and.l &-4,%d0 # mask out lower two bits of size sub.l %d0,%sp # allocate by moving stack pointer tst.b P%1(%sp) # stack probe to allocate pages mov.l %sp,%a0 # return pointer as pointer mov.l %sp,%d0 # return pointer as int to avoid disaster add.l &-4,%sp # new top of stack jmp (%a1) # not a normal return set S%1,64 # safety factor for C compiler scratch set R%1,3+S%1 # add to size for rounding set P%1,-132 # probe this far below current top of stack =========================================================================== Fred Fish UniSoft Systems Inc, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,dual}!unisoft!fnf (415) 644 1230 TWX 11 910 366-2145 ===========================================================================