dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/26/90)
The MC68040 has four independent transparent translation registers. Two for data, two for instructions. Reading the User's Manual I get confused about this `independent' as it states in paragraph 6.3 (page 6-12): Also, since the instruction memory unit is used only for instruction prefetches, different instruction and data TT registers can cause PC relative operand fetches to be translated differently from instruction prefetches. (so PC relative addressing uses the data TT's, not the instruction TT's). What I get from this is that the data TT's must always be the same as the instruction TT's otherwise the code may not run properly. If this is the case then why are there different instruction and data TT's ? Note that the translation table structure of the MC68040 MMU does not distinguish between data and instruction. -- Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcsun!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands n n n It's a pity my .signature is too small to show you my solution of a + b = c
srg@quick.COM (Spencer Garrett) (03/27/90)
In article <702@ssp11.idca.tds.philips.nl>, dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes:
->
-> The MC68040 has four independent transparent translation registers. Two
-> for data, two for instructions. Reading the User's Manual I get confused
-> about this `independent' as it states in paragraph 6.3 (page 6-12):
->
-> Also, since the instruction memory unit is used only for instruction
-> prefetches, different instruction and data TT registers can cause PC
-> relative operand fetches to be translated differently from instruction
-> prefetches.
->
-> (so PC relative addressing uses the data TT's, not the instruction TT's).
Data accesses use the data TT's, regardless of addressing mode.
-> What I get from this is that the data TT's must always be the same as the
-> instruction TT's otherwise the code may not run properly. If this is the
-> case then why are there different instruction and data TT's ? Note that the
-> translation table structure of the MC68040 MMU does not distinguish between
-> data and instruction.
There are separate TT's because there are separate MMU's and caches.
The 68040 runs a Harvard architecture internally, so data and instruction
accesses proceed in parallel until they have to use the (single) external
bus. PC relative references work just fine as long as the data addresses
they generate are mapped as part of the data space. The reason for letting
you write to 4 separate TT's rather than 2 copies of 2 logical TT's is so
that you can control the caching methods independently. (This is my
speculation, of course. I can't speak for Motorola.)caveh@csl.sri.com (Caveh Jalali) (03/28/90)
In article <702@ssp11.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: > >The MC68040 has four independent transparent translation registers. Two >for data, two for instructions. Reading the User's Manual I get confused >about this `independent' as it states in paragraph 6.3 (page 6-12): > > Also, since the instruction memory unit is used only for instruction > prefetches, different instruction and data TT registers can cause PC > relative operand fetches to be translated differently from instruction > prefetches. > >(so PC relative addressing uses the data TT's, not the instruction TT's). > >What I get from this is that the data TT's must always be the same as the >instruction TT's otherwise the code may not run properly. If this is the >case then why are there different instruction and data TT's ? Note that the >translation table structure of the MC68040 MMU does not distinguish between >data and instruction. "it's not a bug, it's a feature!" the key is that the two MMU's are completely independent. also, the translation caches are completely independent. this means that each MMU has to be programmed independently -- to make life easy (sane) you basically configure both MMU's the same way. in the case of the TT's you would normally put them at the same virtual address in both MMU's, but can choose to do it differently for some special effect. example: you have EPROM at some address which you run your boot code from -- program this into your instr-MMU + you have some scratch ram which you use for stack, etc... this goes into your data-MMU. there is no need for one MMU to know about the other MMU's TT entires. the following 2 code segments will give different results IFF the TT's are configured differently in each MMU. it's not that the code won't work, it does exactly what it's spec'd to do. if the MMU's are configured the same, we have a special case because both code segments give the same result. in case_1 data fetch goes thru the instr-MMU, whereas in case_2 the fetch goes thru the data-MMU. case_1: movl pc@(data),d0 (FCODE=CODE) ... data: long <value> case_2: lea pc@(data),a0 movl a0@,d0 (FCODE=DATA) -- 00c -- Who was that masked interrupt? Internet: caveh@csl.sri.com UUCP: {ames|decwrl|pyramid|sun}!fernwood!hercules!caveh ICBM: 37d 27' 14" North, 122d 10' 52" West
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/28/90)
In article <7814@quick.COM> srg@quick.COM (Spencer Garrett) writes:
<In article <702@ssp11.idca.tds.philips.nl>, I (i.e. Dolf) wrote:
<-> [ quote of MC68040 User's Manual of paragraph 6.3. (pp 6-12) deleted ]
<-> (so PC relative addressing uses the data TT's, not the instruction TT's).
<Data accesses use the data TT's, regardless of addressing mode.
That is what I understand too. Although this a little bit strange as prior to
the MC68040 the PC relative addressing mode was in program space. They even
invented the ZPC notation to allow to access the program space without using
the PC in calculating the effective address.
<-> What I get from this is that the data TT's must always be the same as the
<-> instruction TT's otherwise the code may not run properly. If this is the
<-> case then why are there different instruction and data TT's ?
<There are separate TT's because there are separate MMU's and caches.
Agreed, but they could have decided to use only one set of TT's, just as
they only have one TC, MMUSR, URP and SRP.
<The 68040 runs a Harvard architecture internally, so data and instruction
<accesses proceed in parallel until they have to use the (single) external
<bus. PC relative references work just fine as long as the data addresses
<they generate are mapped as part of the data space.
What I understand of the MC68040 is that they merged the program and data
space, which is a distinction from the previous MC680x0. They had to because
otherwise PC relative addressing mode would not work. On the other hand
in my MC68040 User's Manual they talk about PC relative addressing modes
are program space references (note that in 3.5.12 they made a funny mistake:
in the example An is used in stead of PC ;-), so instruction MMU/cache sounds
more reasonable in this case.
< The reason for letting
<you write to 4 separate TT's rather than 2 copies of 2 logical TT's is so
<that you can control the caching methods independently.
Still I do no see why different data & instruction TT's are nice, because
when I set them differently you get in serious problems with PC relative
addressing modes. To me this separate TT's sounds like a very unuseful
feature. The only way I can think of to set the TT's differently is to
guarantee that (at least) 32M of code does not use PC relative addressing
(16M per instruction TT). Even disabling the instruction TT's and only
using data TT's (or the other way around) is unsave, as PC relative addressing
now uses the normal MMU tables, which may come up with an unwanted address.
--
Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl
Philips Telecommunication and Data Systems UUCP ....!mcsun!philapd!dolf
Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands n n n
It's a pity my .signature is too small to show you my solution of a + b = c