Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site dartvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!dartvax!chuck From: chuck@dartvax.UUCP (Chuck Simmons) Newsgroups: net.micro.68k,net.arch,net.micro.16k Subject: Re: RISC (Really NS32000 density stats) Message-ID: <3239@dartvax.UUCP> Date: Wed, 12-Jun-85 23:57:23 EDT Article-I.D.: dartvax.3239 Posted: Wed Jun 12 23:57:23 1985 Date-Received: Fri, 14-Jun-85 00:39:18 EDT References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <611@lll-crg.ARPA> <591@terak.UUCP> <5673@utzoo.UUCP> <810@mako.UUCP> Organization: Dartmouth College, Hanover, NH Lines: 53 Xref: watmath net.micro.68k:906 net.arch:1376 net.micro.16k:338 > In article <5673@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >Also, don't be too sure that the 68* and 32* chips use 16-bit instructions > >a lot. Remember that things like offsets take extra bytes... > > In my experience 16 bit instructions get used quite often on the NS32000 in > well written assembly code. The NS32000 has an edge over the MC68000 in code > density in that instructions need not be word-aligned. Henry is correct in > stating that offsets are used on virtually every memory reference, but those > offsets are usually 8 bits. Following is some statistics for one module > pulled at random from my present project. The code is highly optimized for > speed, so code density is not even as good as it should be, i.e. "jump" is > used instead of "br", saving one clock, but costing two bytes, etc. > > Size Count > 8 0 > 16 14 > 24 13 > 32 1 > 40 0 > 48 2 > Total 30 > Ave 22.1 bits per instruction. > > The average instruction size of 22.1 bits is indeed more than the 16 bits the > original poster assumed, but much less than the 32 bits Henry expected, due > in large part to the large number of 24 bit instructions available on the > NS32000. I believe the MC68000 would have a larger number of 32 bit > instructions with the consequent increase in average bits-per-instruction. > > Of course, no analogy can be drawn for compiled code. Many compilers under- > use register space and I suspect the average bits-per-instruction would be > much higher for compiled code on both machines. > :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: Pulling out a "random" chunk of 68000 code (the only chunk I have sitting near by) gives us the following table: Size Count 16 22 32 17 48 1 Total 40 Ave 23.6 bits per instruction. I'm not sure that code density is really what we want to be looking at, however. I can recode the above algorithm to use more instructions that are smaller on the average and thus acheive a higher code density. (The 17 32-bit instructions can be replaced by 33 16-bit instructions and 2 32-bit instructions, giving an average of 18.4 bits per instruction.) However, this denser code would be both slower and longer. Somewhere we need to take into account the "usefulness" of each instruction. Chuck Simmons