Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!bcase
From: bcase@Apple.COM (Brian Case)
Newsgroups: comp.arch
Subject: Re: Code size vs. Data size (was 16 & 32 bit vs 32 bit only...)
Message-ID: <7569@apple.Apple.Com>
Date: 5 Mar 88 02:33:16 GMT
References: <9651@steinmetz.steinmetz.UUCP> <9678@steinmetz.steinmetz.UUCP> <2574@im4u.UUCP> <2116@saturn.ucsc.edu> <449@imagine.PAWL.RPI.EDU> <7520@apple.Apple.Com> <2377@geac.UUCP>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Ungermann-Bass Enterprises
Lines: 26

In article <2377@geac.UUCP> john@geac.UUCP (John Henshaw) writes:
>In article <7520@apple.Apple.Com> bcase@apple.UUCP (Brian Case) writes:
>>One thing is for sure though, code size is almost always much less important
>>that data size.
>
>The both code and data require memory accesses so that we can perform
>useful work. It seems to me that we do many more accesses to fetch
>instructions than we do to fetch data. This is of course, offset by the
>fact that the code is held in very fast cache memory (if we do things
>right :-)).
>
>I would appreciate it if Brian, (or anyone else of course) would care
>to expand on the above.

Er, I think I should have been more explicit.  I meant to say that "The
number of bytes of data is much greater than the number of bytes of code
in most applications."  There may be, understandably, some dissagreement
here.  I was not trying to make any points about caches or bus bandwidth
or whatever.  I was just saying that code can expand by a factor of two,
but the problem will still be one of data size.  I should say that I
have this opinion because I have written compilers, eg., that build very
big data structures to facilitate optimization.  Code size just didn't
matter.  I suspect spreadsheets and word processors and editors are
similar.

I would be happy to verbosely answer your question, but I don't understand
it.