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