Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!ig!uwmcsd1!bbn!rochester!cornell!uw-beaver!uw-june!kevinr
From: kevinr@june.cs.washington.edu (Kevin Ross)
Newsgroups: comp.unix.xenix
Subject: Re: comp.unix.xenix
Message-ID: <5087@june.cs.washington.edu>
Date: 9 Jun 88 15:32:24 GMT
References: <25@libove.UUCP>
Reply-To: kevinr@uw-june.UUCP (Kevin Ross)
Distribution: comp
Organization: U of Washington, Computer Science, Seattle
Lines: 35

In article <25@libove.UUCP> root@libove.UUCP (The Super User) writes:

>Can someone please explain why a slightly too complex expression can
>cause the large model pass of the SCO Xenix 2.1.4g compiler to generate
>a compiler "infinite spill" error? What *exactly* does that mean?

>Basically, expressions like

>structptr->elt_struct.struct_item = int + str->elt.str;

>will cause the infinite spill error, and this can be corrected by:
>junkvar = str->elt.str;
>structptr->elt_struct.struct_item = int + junkvar;

>Jay Libove (Jay.Libove@andrew.cmu.edu  or  pitt!darth!libove!libove)


The problem is in the way the 80286 does pointer arithmetic. Actually, it is
a compiler error, since this shouldn't be a problem. If you create an 
expression that contains too many indirections, the compiler tries its hardest
to create the code. However, it runs out of ways to get at the data, since
there are a limited number of registers that can do indirect loads. 

There really is no excuse for this, just the reason. I have been fighting the
same damn problem every since I got XENIX. You made the proper adjustment to
the code, and it is the only solution.

The XENIX 2.1.4 compiler is very buggy. If I had the money, I would get the
2.2.1 version, but I don't, so I won't.


Kevin

kevinr@june.cs.washington.edu
Home: ...beaver!tikal!camco!carmine!kevin