Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!cvl!umd5!zben From: zben@umd5.UUCP Newsgroups: net.arch,net.lang.c Subject: Re: register variables allocation in Pyramids (actually TI9900) Message-ID: <643@umd5.UUCP> Date: Mon, 8-Jul-85 22:12:02 EDT Article-I.D.: umd5.643 Posted: Mon Jul 8 22:12:02 1985 Date-Received: Thu, 11-Jul-85 06:16:21 EDT References: <409@umcp-cs.UUCP> <1271@opus.UUCP> <2496@topaz.ARPA> Reply-To: zben@umd5.UUCP (Ben Cranston) Organization: U of Md, CSC, College Park, Md Lines: 26 Xref: watmath net.arch:1535 net.lang.c:5482 Summary: Replacement of workspace pointer is optional In article <2496@topaz.ARPA> vijay@topaz.ARPA (P. Vijay) writes: > Pyramid C compiler seems to be taking an easy way out, when >it comes to allocating register variables. However, I would like to >point out that Pyramid architecture allows for a large number of >registers and every invocation of a function results in a new set of >registers (a la TI994, I think)... Actually there are TWO subroutine call instructions, one for local procedures and another for distant procedures, only the second one gives you another registerset. This can be done cheaply because the registers actually live in memory! There is a Workspace Pointer register that points to the base of the memory used for registers. This is a BIG lose timewise because every reference to a REGISTER requires a bus cycle. Ick. But there was sort of a win silicon-wise - they saved enough space by not having registers on the chip to implement an integer multiply AND integer divide operation! From the proud owner of a Technico 9900 board with 1k bytes of RAM and NO disk. Assembler? Who has room? I program in HEX... (ick) Not too bad - A is add, C is compare... :-) -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA