Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.apple » 68000 inconsistency
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
68000 inconsistency [message #72442] Sat, 25 May 2013 10:27 Go to next message
breuel is currently offline  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 Go to previous messageGo to next message
doug is currently offline  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 Go to previous message
breuel is currently offline  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
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: MODEM7 program for Apple II+ needed
Next Topic: Buffering of printer between Apple and unix
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 11:21:10 EDT 2024

Total time taken to generate the page: 0.05532 seconds