🚀 go-pugleaf

In his article, graeme@labtam.labtam.oz.au (Graeme Gill) writes:
>	   No, I did not mis-read the article. What I am pointing out is
>   that there is some demand for MM type features in commercial products.
>   As far as I know the MM doesn't have any peculiar capability-based
>   segmented-address-space stuff. I am not clear on the difference between
>   and MX and and MM since I have never seen a detailed data sheet on it.
>   The impression I got was that the MX was almost identical to the MM,
>   but with a different bus interface.

I'll give this a shot. 

MX and XA have been designed and verified to properly implement the i960
Extended Architecture -- a capability-based architecture with a 33rd bit for
tagging. A quick, broad, and over-generalized description of the extended
architecture follows (Just see the XA/MX PRM to know why I have to
overgeneralize to get this all on one page...)

      - Almost everything is within or controlled by an "object". Access to
	an object requires a "handle" to that object in the form of an Access
	Descriptor (AD). When an object is referenced by an execution
	environment, that execution environment either implicitly or
	explicitly provides an AD for the object. The object and the rights
	indicated by the AD are compared by the processor against an object
	table to see if the reference is permitted.

      - What stops an execution environment from fabricating an AD as opposed
	to using special, security-conscious instructions to request an AD?
	The 33rd bit -- i.e., the "tag" bit. With each register, there is an
	associated tag bit. When the security-conscious instructions return
	an AD, they set the register's associated tag bit. Any attempt by an
	i960 program to modify this value, will clear the tag bit. There is
	no way for an i960 program to set this bit. BY examining this bit,
	the processor can see if the AD being presented upon reference to an
	object is a valid AD.

      - An execution environment is specified by a domain or process
	object; this object has pointers to the various memory-objects that
	are assembled into the address space of the execution environment.

      - These memory objects contain memory and are variable sized upto 1 GB.
	The memory objects are conceptually independent of the execution
	environments they are associated with -- .i.e there need not be a 1:1
	mapping of memory objects to execution environment. So process or
	domain objects can mix and match memory objects.

      - There can exist non-process objects that export "services" to other
	objects. These objects provide a "public interface" to requestors
	in the form of a domain object. There can be numerous public
	interfaces to the same package of services, one domain object for
	each interface.

      - Invocation of these services is through a cross-domain call, which
	maps out some of the memory objects of the current execution
	environment and maps in other memory objects as specified by the
	package's domain object.

      - The mapping of objects to actual locations in physical memory is
	accomplished by an object table with the appropriate on-chip caching
	of useful translations.


MC and MM have been designed and verified to properly implement the i960
Protected Architecture. You can think of the protected architecture as what
results from crippling the extended architecture to get the traditional,
two-level, per-process, virtual memory model found in many 32-bit processors.
Contrasting this with above:

      - We still got objects; but, the ADs are provided implicitly by the
        process object.

      - Tagging is disabled / not implemented since there is no explicit
	generation of ADs.

      - The only execution environment of interest is specified by the
	process object. There is usually a 1:1 mapping between memory objects
	and processes with one exception -- the last region which is shared
	across all processes and used for system data strucutres and
	routines.

      - There is no generalized cross-domain call because process objects are
	the only objects that can specify an execution environment. However,
	there is one system domain object for system services and that can be
	reached by a "CALLS" instruction.

      - The mapping of objects to actual locations in physical memory is
	accomplished by an object table with the appropriate on-chip caching
	of useful translations.


Again, this is a very quick and dirty description which omits much and
over-generalizes heavily. But, maybe this helps a little ...


	- Rich
	  i960 Architecture






--

[Rich Brunner / ** Intel ** / rbrunner@sedona.intel.com]