plocher%sally@Sun.COM (John Plocher) (08/26/89)
>> If it going to be compiled with MSC that it's got to go through >> the 286/386 emulator > >I knew that (on uport, at least) an emlulator was used to run 286 binaries >of any type. But is an emulator used for 386 code? Looking at the new SCO 3.2 system I'd be cautious: They provide Microsoft C as their default compiler, but they also give you a version of pcc. When the two are benchmarked, MSC comes out looking faster! OK, says I, this does not jive with what I've seen of the MSC compiler - I mean, pcc is slow, but not *THAT* slow :-) Some sluthing later, it turns out that the version of pcc that SCO provides with their 3.2 system is considerably slower than that provided by AT&T's 3.2! I don't know if SCO deliberately crippled their version of pcc in order to make MSC look better, or if AT&T is shipping a different version, but the numbers I get from Microport's CC are in the same range as the ATT 3.2 CC, and both are better than SCO's pcc :-) Since it seems that the SCO version of MSC produces 286 code with 32 bit addresses, I can see where Bob P made his comment about an emulator, but the code is really running in the 386 world. If you use the 286 flag you can generate 286 executables which DO run under the 286 emulator, but that is not the default. Just to be fair, the SCO MSC compiler is the only one that I know of that can be told to produce DOS, 286 Unix, 386 Unix, 286 Xenix, 386 Xenix, and OS/2 executables - they even include the OS/2 libraries! Plus, they provide CodeView under Unix! It only works with the x.out files generated by MSC, so it has some limitations, but it is MUCH better than sdb! -John Plocher
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (08/28/89)
Before I bought Xenix for my home machine I got copies of Xenix/386, ix/386 and MicroPort. The Xenix compiler was best in overall speed and did not have any internal failures. Both MP and ix had some cases in which the C compiler would generate code which the assembler couldn't handle, using registers not in the 386 (R10 and R11 are PDP-11). Trying later versions I find that the MSC compiler still produces better code by a small margin, although not all you might be led to believe from the ads ;-) I have been led to believe by some ix/386 ads and hype at shows that they have enhanced the compiler and that what they ship is a good bit better than the original port. If this is true, then SCO may be shipping the original port. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
darryl@ism780c.isc.com (Darryl Richman) (08/28/89)
In article <196@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
"Both MP and ix had some cases in
"which the C compiler would generate code which the assembler couldn't
"handle, using registers not in the 386 (R10 and R11 are PDP-11).
Not to say that the original compiler didn't have a few bugs when it
shipped, but I'm surprised by this particular comment. (I seem to be
getting new surprises all the time! :-() I don't believe that the AT&T
RCC compiler was ever ported to the PDP-11, and it's a complete rewrite
from the PCC that we all know and love (?). Compared to any truly
optimizing compiler, RCC is still slow and stupid, but compared to the
old PCC, it's a real whiz!
--Darryl Richman
--
Copyright (c) 1989 Darryl Richman The views expressed are the author's alone
darryl@ism780c.isc.com INTERACTIVE Systems Corp.-A Kodak Company
"For every problem, there is a solution that is simple, elegant, and wrong."
-- H. L. Menckencampbell@redsox.bsw.com (Larry Campbell) (08/29/89)
In article <196@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
- ... Both MP and ix had some cases in
-which the C compiler would generate code which the assembler couldn't
-handle, using registers not in the 386 (R10 and R11 are PDP-11).
Must've been a PDP-11 from a parallel universe. The PDP-11 architecture
known in _this_ universe had eight registers, R0-R7; R6 was the stack
pointer, usually referred to as SP, and R7 was the program counter, usually
referred to as PC.
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146palowoda@megatest.UUCP (Bob Palowoda) (08/29/89)
From article <196@crdos1.crd.ge.COM>, by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): > > Before I bought Xenix for my home machine I got copies of Xenix/386, > ix/386 and MicroPort. The Xenix compiler was best in overall speed and > did not have any internal failures. Both MP and ix had some cases in > which the C compiler would generate code which the assembler couldn't > handle, using registers not in the 386 (R10 and R11 are PDP-11). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well this is something I could live with *when* I run into it. I must have compilied 20meg of misc c code and still haven't seen this. I'm useing the ESIX C compiler. > > Trying later versions I find that the MSC compiler still produces > better code by a small margin, although not all you might be led to > believe from the ads ;-) I agree that there optimizer is better. But when I turn on the loop-optimizer in Xenix MSC it produces "space-kadet loops". Runtime problems really bother me like this because no matter how well you QA your software there is a good chance this gets through the pipe. This *I* can accept, but when my customers run into it gets really messy. I would be interested to know what 386 Utilities on Xenix are still compilied with the 286 compiler. Can someone do a file * on the /bin and /usr/bin directories and pipe me the output. Also is the lib files for Xenix386 created with the optimizer turned on? In SCO UNIX? ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Work: {sun,decwrl,pyramid}!megatest!palowoda Home: {sun}ys2!fiver!palowoda (A XBBS System) 2-lines BBS: (415)623-8809 2400/1200 (415)623-8806 1200/2400/9600/19200
mattioli@took.dec.com (09/07/89)
In article <123591@sun.Eng.Sun.COM>, plocher%sally@Sun.COM (John Plocher) writes... >They provide Microsoft C as their default compiler, but they also give you >a version of pcc. When the two are benchmarked, MSC comes out looking faster! > >OK, says I, this does not jive with what I've seen of the MSC compiler - I mean, >pcc is slow, but not *THAT* slow :-) > >Some sluthing later, it turns out that the version of pcc that SCO provides >with their 3.2 system is considerably slower than that provided by AT&T's 3.2! > Does anyone out there know how gcc (the free software foundation's c compiler) compares with msc and pcc for speed of compilation, speed of compiled code, size of compiled code, etc? -------------------------------------------------------------------------------- John Mattioli "The Guy with the Bumpy Watch" (DEC E-NET) TOOK::MATTIOLI (UUCP) {decvax, ucbvax, allegra}!decwrl!TOOK.dec.com!MATTIOLI (ARPA) MATTIOLI@TOOK.dec.com MATTIOLI%TOOK.dec.com@decwrl.dec.com (US MAIL) John Mattioli 550 King St. LKG2-2/BB9 Littleton, Ma. 01460
plocher%sally@Sun.COM (John Plocher) (09/12/89)
>In article <123591@sun.Eng.Sun.COM>, plocher%sally@Sun.COM (John Plocher) writes... >They provide Microsoft C as their default compiler, but they also give you >a version of pcc. When the two are benchmarked, MSC comes out looking faster! > ... >Some sluthing later, it turns out that the version of pcc that SCO provides >with their 3.2 system is considerably slower than that provided by AT&T's 3.2! I get to eat some crow here. First off, my apologies to SCO, and specifically to their compiler and tools people. (Hi Dave :-) I did some extensive benchmarks this weekend with several different compilers on the same hardware platform, and it turns out that I was very wrong. For this posting I will only refer to Dhrystone 1.1 benchmarks (200,000 loops), but other programs seem to show the same results. I used an Intel 301 machine (16 Mhz, no cache, 4MB RAM) for all these tests. I used SCO Unix 3.2 as the base Operating System for all the tests; the compiler subsystems were used in their complete form (Include files, Libraries, startup files, tools, etc were consistant with the compiler being tested. Thus the SCO versions of cc, as, and ld were used when testing the SCO compilers, the Microport versions of the same were used when testing the Vr3.0 compiler, and the ATT 3.2 environment was used for the Vr3.2 tests. (I loaded each SoftDev package into its own sub- directory and used gencc to generate a customized "cross compiler" for each package) Compiler systems tested Compiler abbreviation Derivation -------- ------------ ---------- SCO Unix 3.2 cc (MSC) Microsoft SCO Unix 3.2 rcc (rcc) ATT pcc Microport 3.0e cc (ucc) ATT pcc ATT 3.2 4.1.6 cc (pcc) ATT pcc Metaware Hi-C 2.2a (Hi-C) Metaware The SCO "rcc" compiler had different binaries than the ATT 4.1.6 "cc", but that *could* be explained if the "rcc" package was based on the 4.1.5 compiler. No matter, the 2 are quite similar and both produce nearly identical code. The MSC and pcc based compilers all produced numbers in the same ranges, with the Optimized MSC compiler generating code that ran about 1-2 seconds faster than the pcc code (this translates into about 300 dhrystones difference). The Metaware code was about twice as fast as that produced by any of the other compilers. I found the following dhrystones for each of these compilers. Except for the Metaware compiler all the compilers are statistically in the same ballpark, with a slight edge to MSC. (NOTE: the numbers only have an accuracy of about +/- 150 because of timing granularities) The Microport 3.0 compiler seemed to bracket the slower end of the spectrum, but the results *of this one benchmark* are not really conclusive. It is worth noting, though, that the rcc and pcc compilers are more mature versions of that shipped by Microport. Compiler cc cc -O -------- ---- ----- Hi-C 4400 - 6400 MSC 2300 - 3400 rcc 2400 - 3200 pcc 2400 - 3200 ucc 2400 - 3100 The only explanation I have for the earlier comments is that the testing was done on 2 different machines with different memory configurations. The recent talk about _Unix_Today_ made me realize that I was guilty of the same lack of "controls". Again, I am sorry about the inaccurate comments I posted earlier. -John Plocher