Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.sys.m68k
Subject: Re: Interpretation of 68000 Function Code Outputs
Message-ID: <14422@netcom.UUCP>
Date: 9 Oct 90 03:40:29 GMT
References: <1057@tharr.UUCP>
Organization: Dave McMahan @ NetCom Services
Lines: 67


 In a previous article, chris@tharr.UUCP (Chris Allen) writes:
>
>Can anyone explain the interpretation of the function code
>outputs on the 68000 (FC0-FC2). The manual says that they can
>represent
>
>User Program
>User Data
>Supervisor Program
>Supervisor Data

These are common, but you only get User accesses if your CPU has entered the
non-supervisor state of operation.  This occurs if you clear the proper bit
in the status register.  Note that clearing this bit is easy (since you would
be in the supervisor state if it was set) but setting it requires an exception
or interrupt (since you would be in user mode).


>[.. some others which are not important]

I'm not so sure that the interrupt acknowledge is 'not important'.  As far
as I know, decoding the function codes is about the only way to detect an
interrupt acknowledge and do the proper thing (such as asserting an autovector
bus cycle).  Other codes are unassigned on the 68000 CPU, but may be used in
the future by Motorola for advance CPU configurations.


>What is the difference between program and data? 

A program fetch is when a memory access is fetching data that will be
interrpretted as part of an op-code.  Data fetch is used when the CPU is
attempting to load or store something due to the outcome of a CPU instruction
like:
        MOVE.B		D1,(A0)

In this instruction, the op-codes would be fetched via the program function
code being asserted (either supervisor or user, depending on the state of the
bit in the status register) and the actual data operation (a 1 byte write to
memory) would be asserted as a data transfer (again, the proper supervisor or
user mode would be asserted according to the status register).  Data operations
can be either read or write, but as far as I know, there is no way to get
any kind of program access other than a read operation.  


>.. from the point of view of both the processor and the user.

The above stuff was the nitty-gritty about how the CPU sees memory and
asserts the function codes.  As long as the hardware design didn't use the
function codes to play games with memory mapping, the user probably doesn't
care what comes out on these pins.  It could be possible to re-map memory
in hardware (or fail to assert a DTACK or actually generate a bus error) if
the function codes are examined for the type of operation being performed.
I have never seen a system that does this, but it could be done.  It would be
kind of confusing in my opinion, and there really is no point unless the
hardware designer wants to guarantee that certain memory or devices can't
be accessed in anything but supervisor mode in a controlled fashion.  You could
also inhibit the user from writing to peripherals and force proper use via
a TRAP instruction if the OS was set up that way.  For embedded applications,
I find that it is best to just always stay in supervisor mode.



>chris allen.
>         chris@tharr.uucp  ..!ukc!axion!tharr!chris 

    -dave