Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!amdahl!nsc!levy
From: levy@nsc.nsc.com (Jonathan Levy)
Newsgroups: comp.sys.nsc.32k
Subject: Re: software compatability
Keywords: compatability, stack frame
Message-ID: <10205@nsc.nsc.com>
Date: 22 Mar 89 19:22:55 GMT
References: <18216@gatech.edu>
Reply-To: levy@nsc.nsc.com.UUCP (Jonathan Levy)
Organization: National Semiconductor, Santa Clara
Lines: 38

In article <18216@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes:
>What are the problems involved in moving software up in the 32000
>chain (i.e. moving stuff compiled on a 32016 or 32032 to the 32332 and
>32532).
>
>I know there are stack frame problems when moving from the 68000 to
>the 68020, does such a thing exsist on the 32000s?
>
>Are the 32082, the 32382 and the 32532 MMUs compatable?
>
>Oh...to clarify, I'm primarily interested in binary compatability.

Any user code written for the 32016 will run unmodified on any 32000
member. The only differences are in some supervisor code, and these
are:

1. The 32382 MMU has a different page table orginization (4K pages
   rather than 512 byte pages), and the registers are a little
   different. This means that the MMU stuff will have to be slightly
   modified when moving from a 32016 / 32032 based virtual memory system
   to a 32332/32532 system. The 32382 is FULLY compatible to the internal
   532 MMU.

2. Debug features are different in 32082, 32382, 32532.

3. One new instruction was added to the 32532 for cache management. This
   is the CINV instruction which is used to invalidate the caches
   (partially ae fully).

To summarize, all application s/w which was compiled for any one processor
in the family will run on any other processor. The optimizing compiler
from NSC ( CTP ) does have switches for the different processors, but
these are needed only to squeeze some 5% or so additional performance based on 
peep-hole optimizations for each processor.

I hope this answers the questions.

Jonathan Levy