Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.lang.c
Subject: Re: setjmp/longjmp, 68000 moveml instruction
Message-ID: <214@desint.UUCP>
Date: Tue, 13-Nov-84 02:50:27 EST
Article-I.D.: desint.214
Posted: Tue Nov 13 02:50:27 1984
Date-Received: Thu, 15-Nov-84 03:54:12 EST
References: <1@imd.UUCP> <469@ncoast.UUCP> <5669@brl-tgr.ARPA>
Organization: his home computer, Thousand Oaks, CA
Lines: 47

>> Ummm... it's easy to push the register mask when you moveml the registers
>> to be saved on entry to a subroutine in the 68000, but moveml mask,(a7)-
>> and moveml mask,(a7)+ expect the mask reversed from each other!  How
>> do you propose to invert a 16-bit mask end-for-end (i.e. 11100...001
>> <=> 100...00111 ) and still have a fast calling sequence?
>
>Just great -- more computer architecture brain damage!

The only brain damage around here is in the theory that you have to reverse
the bits in software during the calling sequence.

Here is the 68000 entry/exit sequence used by the MIT pcc:

	link	a6,#<localsize>
	tstb	sp@(132.)
	moveml	#mask,a6@(offset)
	...
	moveml	a6@(offset),#mask
	unlk	a6
	rts

(The tstb is a "stack probe instruction";  it has to do with the things
that keep you from doing virtual on a plain 68000).

Now, to implement setjmp/longjmp, there is no need to write fancy code to
reverse the bits in a 16-bit word.  (By the way, that task can easily be
done in a very few instructions with a table lookup on the two bytes and a
byte swap.)  Why would you want to insert all that extra code into a
call/return sequence when you already *know* at compile time what those
reversed bits are?  In fact, the only thing you need to do is store the
information longjmp needs to restore the resgisters that were actually saved.
This involves pushing a 16-bit copy of the moveml mask onto the stack.  You
have to decode it in longjmp by bit shifting (unless you are into
instruction modification), but who cares if longjmp is a bit slow?

There is one other subtlety here:  the MIT pcc puts the saved registers at
the *lowest* address of the stack frame, not the highest.  Since longjmp
does not know how big the frame is (it can't find the link instruction in
the general case), this makes it impossible to find the registers.  So,
while you were modifying the compiler, you would also have to make a slight
modification to allocate the saved registers at the very top of the frame,
where they were easy to locate.
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff