eric@valid.UUCP (06/18/86)
> In article <367@tolerant.UUCP> kevin@tolerant.UUCP (Kevin Flory) writes: > > > >The National 32032, 32332, and the Motorola 680XX both have a much better > >instuction set than the Intel 8086, 186, 286, and 386. This may not be > >as noticible at the machine code level, but when in compiled codes, especialy > >'C', the National and Motorola instrucitons sets are much more efficient. > > Executable file sizes, 6502 assembler program: > > Intel, 8086, Microsoft C 3.0 -> 15110 > > Motorola 68000, UniSoft cc -> 19500 > > This is more efficient? > > ---------------- > > Mike Farren > > hoptoad!farren > > No, not as memory space goes, but let's not compare different complilers > with different libraries and exepect people to use this as measure of > efficientcy. > > But I wasn't refering to memory space. I was refering execution, we were > talking about exectution speed. If you would like to demestrate this you > can take a compiler that either runs on both machines or one that produces > code for both processors. Write a small 'C' routine that uses number of > 'C' instructions, with not many library calls. I beleive that you will > find that the 68K and the 32K are much more useful to the compiler. > -- > Kevin Flory @ Tolerant Systems, San Jose CA > ..{bene,mordor,nsc,oliveb,pyramid,ucbvax}!tolerant!kevin We went one step further - John Reiser at Valid took SVS 68010 pascal object code and munged the bits into 80286 code. Guess what? The 286 code was 15%-20% smaller. You can't complain about diferent compilers, libraries, etc. in this example. As fas as speed is concerned, the 286 was comperable to the 68010 ONLY UP TO 64K worth of text and data. After that point, the 286 fell flat on its face. In the immortal words of Steve Sargent (valid!sbs): "Intel: still the best *@#&$% traffic light controllers around". ---------- Eric Burger valid!eric
b-davis@utah-cs.UUCP (06/19/86)
In article <350@valid.UUCP> eric@valid.UUCP (Eric Burger) writes: >We went one step further - John Reiser at Valid took SVS 68010 pascal >object code and munged the bits into 80286 code. Guess what? The 286 >code was 15%-20% smaller. You can't complain about diferent compilers, >libraries, etc. in this example. As fas as speed is concerned, the 286 >was comperable to the 68010 ONLY UP TO 64K worth of text and data. After >that point, the 286 fell flat on its face. We have a large software package (about 100,000 lines in multiple programs) that we are supporting on both a VAX running BSD4.3 and on PC's and clones. We are using the BSD pcc and Wizard C. Wizard C consistantly gives better code sizes than any other C compiler for the PC's. The library is very fine grained (we have sources anyway). Since our programs are over 300k long we use the large model. The PC programs are from 1.2 to 1.6 times larger than the equivalent VAX programs. Most of the programs fall into the 1.4-1.5 range. The sizes also seem to correspond to programmers. Good programmers get 1.2-1.3, normal programmers get the 1.4-1.5 range. This really hurts when you are running out of memory on a 512k PC, and most of your programmers are normal. -- Brad Davis {ihnp4, decvax, seismo}!utah-cs!b-davis b-davis@utah-cs.ARPA One drunk driver can ruin your whole day.
freed@aum.UUCP (06/19/86)
> We went one step further - John Reiser at Valid took SVS 68010 pascal > object code and munged the bits into 80286 code. Guess what? The 286 > code was 15%-20% smaller. You can't complain about diferent compilers, I feel that this method while interesting, is not significant. That is about the improvement that could be expected when compiler generated code is massaged by a competent assembly programmer... -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA ptsfa!aum!freed