Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!jbray@bbn-unix From: jbray%bbn-unix@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: 16032 calling sequences Message-ID: <2013@sri-arpa.UUCP> Date: Fri, 10-Jun-83 10:01:47 EDT Article-I.D.: sri-arpa.2013 Posted: Fri Jun 10 10:01:47 1983 Date-Received: Sun, 12-Jun-83 06:35:15 EDT Lines: 23 From: James BrayIn response to your quandry regarding jsr vs. cxp in a 16032-targeted compiler, I would like to raise the following points. First, I should note that I don't know the 16000-series, but hear that they are good chips. In a general sense, it seems there are often situations imposed by a particular architecture in which one must choose between space and speed: for example, because of constraints in the architecture of the underlying micromachine, the sis (subtract-immediate-short) macroinstruction on the Perkin-Elmer 3200-series machines is one machine-cycle (200ns on most of them) longer than an equivalent shi (subtract-halfword-immediate) instruction. The sis accepts nibble operands, and is 16 bits long. The shi accepts halfword operands, and is 32 bits long. There were other instances in which one could trade a halfword for a cycle or two. One wonders if the -O flag should have an s/t argument to indicate space vs time... But this wouldn't work for a calling sequence, which must be standard -- which brings me to the second point: perhaps NS will reimplement the cxp instruction in later versions to speed it up; if you have contacts with them, you might try to find out whether that is possible, or whether it is already up against the limits of the microarchitecture (I am assuming it is microprogrammed). Good luck. It sounds like a good chip, so it deserves a good compiler. --Jim Bray @ BBN-UNIX