68000 inconsistency [message #72442] |
Sat, 25 May 2013 10:27 |
breuel
Messages: 16 Registered: May 2013
Karma: 0
|
Junior Member |
|
|
Message-ID: <5@harvard.ARPA>
Date: Sun, 5-Aug-84 23:41:33 EDT
Article-I.D.: harvard.5
Posted: Sun Aug 5 23:41:33 1984
Date-Received: Wed, 8-Aug-84 00:17:19 EDT
Organization: Aiken Computation Lab, Harvard
Lines: 35
Consider these two short pieces of 68000 Assembly language:
(1) 1000 MOVE.L #$04001008,A0 (2) 1000 JMP #$04001006,A0
1006 JMP (A0) 1006 LEA *-6,A0
1008 LEA *-8,A0 ...
...
One would expect (at least I did) A0 to contain the same value after
both LEA instructions. Reality on the 68000 (I tried it on a LISA and
a Mac) is different, though. In case (1), A0 contain $04001000, and in
case (2), A0 contains $00001000. I find this behaviour inconsistent.
Apparently, the program counter actually gets set to the 32bit number
in the first case, whereas only 24 bits are used in the second case.
This feature is particularly noticable on the LISA and the MacIntosh,
on which most addressing is done PC-relative to make code
position-independent: PC-relative instructions use the whole 32 bits
of the program counter, and PC-relative jumps and jsr's preserve the
highest 8 bits, so that any setting of the 8 msb is preserved through
long sections of a program. The LISA/MacIntosh debugger, MWLB, however,
clears those 8 bits. Altogether, this can create pretty obscure bugs.
[The way I discovered this feature was when working on my "Infinite
Improbability Lisp Interpreter" for the MacIntosh: certain functions
called by the evaluator failed mysteriously, but only if they did not
contain debugger trace points. The RTS instruction at the end of these
subroutines restored the program counter to normality... If one of
these functions called the panic routine, though, all of a sudden the
reader and the interpreter would not recognise LISP anymore. Maybe I
should have chosen another name for the thing.]
Thomas M. Breuel
...{genrad!wjh12!tardis,allegra!harvard}!gallifrey!tmb
|
|
|
re:68000 inconsistency [message #72457 is a reply to message #72442] |
Sat, 25 May 2013 10:27 |
doug
Messages: 117 Registered: May 2013
Karma: 0
|
Senior Member |
|
|
Message-ID: <161@oakhill.UUCP>
Date: Thu, 9-Aug-84 19:15:11 EDT
Article-I.D.: oakhill.161
Posted: Thu Aug 9 19:15:11 1984
Date-Received: Mon, 13-Aug-84 00:22:24 EDT
Organization: Motorola Inc. Austin, Tx
Lines: 12
The 68000 does not lose the upper 8 bits of the
address. Internally all 32-bits are significant on the 68000 regardless
of whether there are 24, 31, or 32-bits of address visible from outside
the chip. The implementation internally is the same for all cases.
I agree completely with the description given by John Gilmore as to the
motivation for not mucking with the address.
It seems highly likely that the culprit may be a program playing games
with those upper bits, it's not the processor.
Doug MacGregor {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!doug
|
|
|
Re: 68000 inconsistency [message #72458 is a reply to message #72442] |
Sat, 25 May 2013 10:27 |
breuel
Messages: 16 Registered: May 2013
Karma: 0
|
Junior Member |
|
|
Message-ID: <8@harvard.ARPA>
Date: Fri, 10-Aug-84 18:57:38 EDT
Article-I.D.: harvard.8
Posted: Fri Aug 10 18:57:38 1984
Date-Received: Mon, 13-Aug-84 00:25:20 EDT
Organization: Aiken Computation Lab, Harvard
Lines: 43
Doug MacGregor (Motorolas) writes: 'The 68000 does not lose the upper 8
bits of the address'.
Well, my 68000 *does* seem to loose the upper 8 bits when loading an
absolute address from memory. Again, consider the following code
fragments (they were run as such under LisaBug, and the register
contents are what LisaBug reported):
----------
1000: 4ef9 ff00 1006 jmp $ff001006
1006: 41fa fffe lea *,a0
a0 = $00001006
1000: 227c ff00 1008 move.l #$ff001008,a1
1006: 4ed1 jmp (a1)
1008: 41fa fffe lea *,a0
a0 = $ff001008
----------
Or is there another explanation?
Thomas.
P.S.: About choice of implementation of type tags: given that the LISP
runs on an MacIntosh with very limited memory resources, given that the
Mac has a "fixed" architecture and is unlikely to profit from
Motorola's corrections to the 68000 (as in the 68010), and given that
the LISP performs very well speedwise, I think the choice of putting
type tags into the "unused" msb of pointers, and not explicitely
stripping them before dereferencing (except for the case of indirect
jumps :-) is justified. Since all type reconisers and selectors are
defined as macros, this efficiency hack even leaves the program
portable. Normally, I prefer partitioning to tagging, but in the case
of the MacIntosh there isn't much choice.
Thomas M. Breuel
...{genrad!wjh12!tardis,allegra!harvard}!gallifrey!tmb
|
|
|