Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site stcvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!stcvax!crp From: crp@stcvax.UUCP (Charlie Price) Newsgroups: net.unix-wizards,net.micro.68k Subject: Re: Pre-fetch Message-ID: <404@stcvax.UUCP> Date: Tue, 16-Jul-85 12:58:01 EDT Article-I.D.: stcvax.404 Posted: Tue Jul 16 12:58:01 1985 Date-Received: Thu, 18-Jul-85 05:47:55 EDT References: <891@bunker.UUCP> Organization: Storage Technology Corp. Louisville, CO Lines: 23 Xref: watmath net.unix-wizards:13875 net.micro.68k:1013 Instruction pre-fetch causing problems when the last instruction is at the end of memory isn't new. Back in the dark ages when I was learning assembly language programming on a CDC 6400 we were warned about this problem (pre-fetch also forces you to be careful for *shudder* self-modifying code.) The 6000 series machines have base-and-limit-register memory management and 60-bit words with 15 or 30 bit instructions. After the first instruction of a word is executed, the machine prefetches the next word into the instruction buffer. If you are in the last word: Bang, you're dead. With the 6000's memory management scheme I suppose that compilers "naturally" never cause this problem for compiled languages. Given that this is a bad gotcha for a compiled language, I don't think it would be an outrageous "feature" to have the linker (whoever builds finished executables) on any system normally elminate this problem by forcing some extra null words into the text if needed. -- Charlie Price {hao ihnp4 decvax}!stcvax!crp (303) 673-5698 USnail: Storage Technology Corp - MD 3T / Louisville, CO / 80028