Path: utzoo!mnetor!uunet!husc6!mailrus!ames!pacbell!att-ih!att-cb!clyde!watmath!watcgl!lily!jafischer
From: jafischer@lily.waterloo.edu (Jonathan A. Fischer)
Newsgroups: comp.sys.atari.st
Subject: TRAP handler question
Message-ID: <3738@watcgl.waterloo.edu>
Date: 26 Mar 88 20:20:19 GMT
Sender: daemon@watcgl.waterloo.edu
Reply-To: jafischer@lily.waterloo.edu (Jonathan A. Fischer)
Organization: U. of Waterloo, Ontario
Lines: 68


	This will undoubtedly reveal the vast storehouse of ignorance I have
at my fingertips, but here goes anyway...

	Since "Tempus" came out, it seems that countless programmers took it
as a personal challenge to write some screen routines that were as fast. 
Myself included.  Well, writing the printing routines wasn't much trouble (a
nice intro to 68000 assembly language programming, I felt), but in trying to
hook the thing into the GEMDOS trap handler so that it catches Cconws() calls,
I've come across a pretty strange bug.  Hopefully someone can help me out. 

	I use oldvect = Setexc(...) to point TRAP #1 to my trap handler with
no problem.  In the trap handler, I check 6(sp) for the function number.  This
is where the problem is... 
==============================================================================
fp_handler_:
	cmpi.w	$9,6(sp)	/ Never results in "true" condition.
	beq	is_Cconws

	movea.l oldvect,a0	/ Not Cconws(), so jump to GEMDOS.
	jmp	(a0)

is_Cconws:
	move.l	(sp),4(sp)	/ Overwrite GEMDOS function number with return
	lea	4(sp),sp	/ address.
	jmp	fastprt		/ Jump to the fast print routine.
==============================================================================
	However, as I said, the test never results in the jump to is_Cconws.
I examined the stack with 'db', MWC's debugger, and the value '9' is certainly
on the stack (although I don't know why it's at 6(sp) rather than 4(sp)...),
but here's the weird part: this is what the stack looks like:
==============================================================================
	BEFORE executing "cmpi.w ...":
	sp -->	XXXX XXXX 0000 0009 YYYY YYYY ...
				    ^^^^^^^^^ pointer to string
			  ^^^^^^^^^	      GEMDOS function # (why long &
			  			not int?)
		^^^^^^^^^		      return address

	AFTER executing "cmpi.w ...":
	sp -->	XXXX XXXX CE21 0001 YYYY YYYY ...
==============================================================================
	That is, the cmpi instruction seems to be changing memory contents!
(I know that that can't be what's happening, so what's going on?)

	The "CE21 0001" is garbage, & the first word changes everytime (the
0001 doesn't).  But why does it change from 0000 0009?  Is it that there are
still interrupts going on that change that area of memory?  (Like, maybe
debugging a TRAP is a no-no?)  Or what?  I am completely lost.

	I have ACACHE, so I had a quick look at its source, but at first
glance I couldn't see anything that it's doing differently.  Maybe I'll
examine in more detail.

	Actually, I'll probably end up using a different method, since this
will only speed up Cconws(), and a lot of programmers use Bconout(1, character)
in a loop, since it's faster than Cconws().  Ideally, I'd like to have ALL
screen text output (non-VDI) go through the fastprt() routine.	If someone can
tell me how to do this (without checking explicitly for one of Cconout(),
Cconws(), Bconout(1, ch), and Fwrite() to stdout), then I'd appreciate it.

	(And yes, I know I'll have to add a test for stdout being redirected to
a file.)
--
	- Jonathan A. Fischer,    jafischer@lily.waterloo.edu
...{ihnp4,allegra,decvax,utzoo,utcsri}!watmath!lily!jafischer
"Happiness is a dead lobber."
	- motto of a "Gauntlet" player.