chris@tharr.UUCP (Chris Allen) (10/03/90)
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
[.. some others which are not important]
What is the difference between program and data?
.. from the point of view of both the processor and the user.
Any help would be much appreciated.
chris allen.
--
chris@tharr.uucp ..!ukc!axion!tharr!chris
Disclaimer: The views expressed above are those of my employer..
<-- tharr free public access to Usenet in the UK 0234 261804 -->pl@news.funet.fi.tut.fi (Lehtinen Pertti) (10/03/90)
From article <1057@tharr.UUCP>, by chris@tharr.UUCP (Chris Allen): > > 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 > [.. some others which are not important] > > What is the difference between program and data? > > ... from the point of view of both the processor and the user. > My intuition says, that all those accesses, which use PC as their base, are program accesses, and all other are data accesses. This means that: - opcode fetches - pc relative accesses go to program space All other go to data space. -- pl@tut.fi ! All opinions expressed above are Pertti Lehtinen ! purely offending and in subject Tampere University of Technology ! to change without any further Software Systems Laboratory ! notice
briel@sctc.com (Marc Briel ) (10/03/90)
> >What is the difference between program and data? > >.. from the point of view of both the processor and the user. The processor uses the "Program Space" function codes for all instruction fetches and PC-relative (addressing mode) operand reads. Writes to program space never occur in normal instruction processing but they can be generated by the MOVES instruction in Supervisor Mode by placing the appropriate function code in the DFC (Destination Function Code) register. Most commercial 68xxx based systems ignore the distinction between Program Space and Data Space in both the hardware (i.e. both program and data map the same physical memory) and in the software (memory management, seperating read and execute permission, etc.) Marc Briel briel@sctc.com
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (10/03/90)
In article <1057@tharr.UUCP> 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
-[.. some others which are not important]
-What is the difference between program and data?
"Program" is instruction fetches. Data is anything else. But I beg to differ
with you about the unimportance of other codes. In particular, FC7 is the
interrupt acknowledge cycle. You want to make sure all memory and IO
addressing is turned off, especially if you have memory-mapped IO registers.
Marc Kaufman (kaufman@Neon.stanford.edu)wcarroll@encore.com (Mr. New Dad) (10/04/90)
From article <1990Oct3.150536.6378@sctc.com>, by briel@sctc.com (Marc Briel ): > Writes to program space never occur in normal instruction processing > but they can be generated by the MOVES instruction in Supervisor Mode > by placing the appropriate function code in the DFC (Destination Function > Code) register. Please note that the MOVES instruction and the DFC/SFC registers do not exist in the 68000 and 68008, only the 68010 and above. The original question did explicitely mention the 68000, so let's not expand the context without qualifiers. -- William R. Carroll (Encore Computer Corp., Ft. Lauderdale FL) wcarroll@encore.com uunet!gould!wcarroll "The brain-dead should not be allowed to operate motor vehicles!" - Me
jkg@prism.gatech.EDU (Jim Greenlee) (10/05/90)
In article <1057@tharr.UUCP> chris@tharr.UUCP (Chris Allen) writes: >Can anyone explain the interpretation of the function code >outputs on the 68000 (FC0-FC2). [...] >What is the difference between program and data? This is kind of picky, but nobody else has mentioned it so far. The first fetch (on RESET) of the initial Supervisor Stack Pointer and Program Counter values are considered to be from the Supervisor Program Space (all other exception vectors are fetched from Supervisor Data Space). All fetches for which the PC is the address source are considered to be from the Program Space, but the converse is not necessarily true. Jim Greenlee -- Jim Greenlee - Instructor, School of ICS, Georgia Tech jkg@cc.gatech.edu Jryy, abj lbh'ir tbar naq qbar vg! Whfg unq gb xrrc svqqyvat jvgu vg hagvy lbh oebxr vg, qvqa'g lbh?!
chris@tharr.UUCP (Chris Allen) (10/06/90)
In article <1990Oct3.160343.401@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: ]In article <1057@tharr.UUCP> 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 ]-[....] ]-[.. some others which are not important] ] ]-What is the difference between program and data? ] ]"Program" is instruction fetches. Data is anything else. Many thanks both to you and to the many people who sent mail about this. I have tried to reply but I expect that a lot of it will bounce :-( ]But I beg to differ ]with you about the unimportance of other codes. In particular, FC7 is the ]interrupt acknowledge cycle. You want to make sure all memory and IO ]addressing is turned off, especially if you have memory-mapped IO registers. My apologies.. What I should have said was "some others which are not important because I already know what they mean"! Thanks again for your help. chris. -- chris@tharr.uucp ..!ukc!axion!tharr!chris Disclaimer: The views expressed above are those of my employer.. <-- tharr free public access to Usenet in the UK 0234 261804 -->
mcmahan@netcom.UUCP (Dave Mc Mahan) (10/09/90)
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