Path: utzoo!attcan!uunet!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.sys.m68k
Subject: Re: 68040 Transparent Translation problem
Message-ID: <706@ssp11.idca.tds.philips.nl>
Date: 28 Mar 90 08:49:29 GMT
References: <702@ssp11.idca.tds.philips.nl> <7814@quick.COM>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 49

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