Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ctvax
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!convex!ctvax!pedz
From: pedz@ctvax
Newsgroups: net.emacs
Subject: GNU on Integrated Solutions
Message-ID: <34700009@ctvax>
Date: Wed, 4-Sep-85 19:07:00 EDT
Article-I.D.: ctvax.34700009
Posted: Wed Sep  4 19:07:00 1985
Date-Received: Sat, 7-Sep-85 13:47:01 EDT
Lines: 52
Nf-ID: #N:ctvax:34700009:000:2656
Nf-From: ctvax!pedz    Sep  4 18:07:00 1985


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.)