Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: M2Amiga, a new Modula-2 compiler
Message-ID: <8711142308.AA01690@cory.Berkeley.EDU>
Date: Sat, 14-Nov-87 18:08:28 EST
Article-I.D.: cory.8711142308.AA01690
Posted: Sat Nov 14 18:08:28 1987
Date-Received: Sun, 15-Nov-87 19:58:18 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29

:The code for a ROM call is exactly the same as the code for a procedure call
:to a prodecure of an other module. The placing of parameters into registers
:doesn't make a big difference. With other compilers you have an external call
:to the assembler stub popping parameters into registers and eventually pushing
:results back on the stack again and the basic ROM call.
:
:Simplified: The time others arrive in their stubs we arrive at the function in
:ROM. 
:
:A German jounalist doing some reseach on this came up with following figures.
:machine cycles for a Library Call.
:TDI ~250, Manx ~140, M2Amiga 94, he complained because the optimal Assembler
:call only uses 74 cycles. This still leaves some space for improvement :-) 

	Well, I wouldn't get too caught up in it.  For one thing, those 
numbers are obviously averages over quite a few different calls, because 
things like Remove() from assembly take maybe 22 cycles of overhead
(loadregister-4, jsr-18) in the call... common RTS and meat not included.
If you look carefully, I think you will find that the library calls that run
quickest take fewer arguments and thus less overhead, and the library calls 
that take more arguments generally take longer to complete anyway, so the 
overhead can almost be thought of as a straight percentage of the execution
time for the call.

	This straight percentage is going to be very low, so optimizing
from 140 to 74 isn't going to be noticeable at all.

				-Matt