jans@mako.UUCP (Jan Steinman) (06/10/85)
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 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
john@frog.UUCP (John Woods) (06/12/85)
> 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 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. > I counted words for some random compiled code here for the 68000 (the famous Knight's Tour, which I still have lying around). Size (bytes) 2 4 6 8 Sample 1: 23 4 3 0 Average 21.3 bits / 30 main() Sample 2: 18 7 4 0 Average 23.4 bits instr. try() The Greenhills compiler tries to make good use of registers. On the other hand, I don't know how much these instructions actually accomplished. I wouldn't be surprised to find that the 32?32 does more with those 22 bits per instruction, but I wouldn't be horribly shocked to find that the 68000 does more [despite my employer, I am a closet 32032 fan, by the way- it is almost as nice as the PDP-11 !-) ]. I suppose the true lesson is that "bits per instruction" is yet another Red Herring in Heavy Oil: a computer with 64 bit instructions would have "poor" "code density", but if one of those instructions was "Solve the (reg0)x(reg0) Knight's Tour and output the table to channel (reg1)", the program would be awfully short !-). -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA Five tons of flax!
chuck@dartvax.UUCP (Chuck Simmons) (06/13/85)
> 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
hull@hao.UUCP (Howard Hull) (06/15/85)
In article 195@frog, John Woods writes: > On the other hand, I don't know how much these instructions actually > accomplished. I wouldn't be surprised to find that the 32?32 does more with > those 22 bits per instruction, but I wouldn't be horribly shocked to find that > the 68000 does more [despite my employer, I am a closet 32032 fan, by the way- > it is almost as nice as the PDP-11 !-) ]. Just out of curiousity, what *ARE* you 320xx and 68k fans using for the PDP-11 instruction MOV (SP)+,@(R5)+ eh? (It's useful for initializing tables or mapped video windows from stack images.) I only need one or two examples, please, so read all your micro mail before replying to this. If you see a correct answer, and you think yours is better, please send me mail; In a subsequent posting, I'll summarize whatever I get. Thanks. Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull