Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!princeton!phoenix!tbrakitz
From: tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis)
Newsgroups: comp.sys.apple2
Subject: Re: Xapple2
Message-ID: <14347@phoenix.Princeton.EDU>
Date: 8 Mar 90 02:47:18 GMT
References: <53040@bbn.COM> <53134@bbn.COM> <14340@phoenix.Princeton.EDU> <22777@pasteur.Berkeley.EDU>
Reply-To: tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis)
Organization: Princeton University, NJ
Lines: 34

In article <22777@pasteur.Berkeley.EDU> fadden@cory.Berkeley.EDU.UUCP (Andy McFadden) writes:
>In article <14340@phoenix.Princeton.EDU> tbrakitz@phoenix.Princeton.EDU (Byron Rakitzis) writes:
>>

>>2) (the sneaky part) the "instruction" datum is simply an index to
>>another array of pointer to function! So, each function is an
>[...]
>>execute_instruction[x](), go there!
>
>Sneaky, yes.  Efficient, no.  With this method you get procedure call
>overhead with every single 6502 instruction.  Not a good way to go.
>

If you have a clever compiler, and if you store the pertinent
information in global variables (everything should really be in
globals: your mem[] array and a few register globals (pc, sp, a, x,
y)) then it is not less efficient. It should use a "JSR" like
instruction which does not chew up stack space (except for the return
address). 

Of course, if you are using a VAX, then 'CALLS' is all you got...
(I know there is another instruction, JSB, which does not use the
stack, but this does not conform to UNIX paramater passing
conventions. Hence, I've never heard of a compiler which uses JSB
instead of CALLS)

Now that I look at it again, perhaps a big switch() is okay too, but
at least with my method you don't have to worry about a compiler
making a good jump table. You are guaranteed that it will be good. 
-- 
Just try taking your VAX down to Jiffy-Lube these days!
			
Byron "Bo knows parallel computational geometry" Rakitzis. 
				(tbrakitz@phoenix.Princeton.EDU)