Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!agate!shelby!neon!max
From: max@nic.gac.edu (Max Hailperin)
Newsgroups: comp.sys.next
Subject: 030/040 incompatible caching (was Re: Scheme for NeXT)
Summary: simple program with different results on 040 than 030
Message-ID: <1991Jan23.181100.11914@Neon.Stanford.EDU>
Date: 23 Jan 91 18:11:00 GMT
References: <5436@husc6.harvard.edu> <1991Jan23.161546.6623@Neon.Stanford.EDU>
Sender: max@Neon.Stanford.EDU (Max Hailperin)
Organization: Math and CS Department, Gustavus Adolphus College
Lines: 30

In article <1991Jan23.161546.6623@Neon.Stanford.EDU> I wrote:
> [description of CScheme-7.1 doing weird things on 040, not on 030] ...
>I would lay very large odds that the problem concerns the [caching] ....

Here is a much simpler, safer example of how the 030 and 040 caches
behave differently than the scheme crashing stuff.  The below program
modifies a simple machine-language routine that just returns a number
to return a different number.  On the 030, it then returns the new number,
but on the 040 it still returns the old.  This is just a test program,
not an example of how anyone should really write code.  But, it is similar
to what native-code lisp/ML/... systems do for good reasons.
============================== Here's the code ======================
#include <stdio.h>

static unsigned char foo[] = {112, 13, 78, 117}; /* moveq #13, d0; rts */

main(){
  int (*fp)();
  
  fp = (int (*)()) foo;
  printf("unmodified foo (%d), returns %d.\n", foo[1], (*fp)());
  foo[1] = 7;
  printf("modified foo (%d), returns %d.\n", foo[1], (*fp)());
}
=========================== Here's the 030 output: ===========================
unmodified foo (13), returns 13.
modified foo (7), returns 7.
=========================== Here's the 040 output: ===========================
unmodified foo (13), returns 13.
modified foo (7), returns 13.