sparc ii vs. sparc 10

[oe@dfki.uni-sb.de (Stephan Oepen)]

friends,

for a couple of weeks now we have a sparc 10 set up under SunOS 4.1.3
(two cpus, lots of memory); among the first things we found out about
it was that the acl (4.1) executable built on a sparc ii would not run
on the 10 because of what is known as the `difference in stack
allocation bug'.

the friendly and helpful people (yes, they really are nice people) at
franz inc. advised us to install patch 0138 available as
`sparc-acl-4.1-stack-fix-patch.tar.Z' on ftp.uu.net which is supposed
to address the problem; however, installing the patch simply makes no
difference for us: executables built on sparc ii refuse to startup on
the 10 with the ususal message:

  The environment this lisp is running in has used
  up too much stack.  It cannot be restarted

and, likewise, executables built on the sparc 10 dump core on the ii
with an illegal instruction error (for those interested: in
new_sysvector_pvec()).

now, i cannot imagine that we are the only site trying to run the same
acl 4.1 executable on sparc ii and 10 architectures; anyone out there
with experiences in this direction (like: `yes, we do that all the time
--- no problem' or `no clue; there is no money for a 10' |:-).  am i
doing something wrong?

what makes it worse: from time to time we get very weird errors from
code compiled on a sparc ii fasl loaded (into a different executable)
on the 10.  usually, then, few functions simply return random results;
evaluating the function definition (from exactly the source file
corresponding to the fasl file) makes the problem go away (note, that
we `fasl' load instead of `libfasl' loading --- should not make a
difference, i guess).

someone who had similar things happen to him before?

                                thanks for your interest  -  oe

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Stephan Oepen, Duerkheimer Str. 7, 66oo Saarbruecken, (o681) - 3o2 52 84
;;;      - oe@dfki.uni-sb.de | oe@cs.tu-berlin.de | oe@gnu.ai.mit.edu -
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;