Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.sys.hp Subject: Re: HP 9000/400 question Message-ID: Date: 9 Aug 90 20:53:31 GMT References: <7370187@hpfcso.HP.COM> Sender: news@wheaties.ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 30 In-reply-to: rjn@hpfcso.HP.COM's message of 9 Aug 90 00:03:43 GMT > What kind of architecture is it? Compared to your 375, these things are the same: * Same SPU architecture, including 68030 processor daughter board, cache and memory management. Your self-modifying code for your 300 will work fine on your 400, (but will break on both 300 & 400 when you upgrade to 68040 with copyback cache enabled :-) This is actually no laughing matter. Some Lisp systems (and other systems with garbage collectors) put (some) user code in data space by default, and it is rellocated and moved at garbage collection time, so in effect, it has to be re-linked at every GC. If the data updates are not seen by the I-cache, the system will not work. Hopefully there will be some system call in future versions of HP-UX to flush the complete cache system back to memory (and invalidate I-cache entries). On the Series 800 this can be done by using FIC, FDC, FICE, and FDCE, which are all user-mode instructions, but on the 68040 the cache management instructions are, unfortunately, priviledged instructions. Note that this problem is not confined to esoteric languages such as Lisp. The GNU C compiler depends on cache consistency to make local procedures work, since local procedures are implemented as instructions on the stack that jump to the shared code. I hope HP doesn't shoot itself on the foot on this one.