wolf@csclea.ncsu.edu (Thomas Wolf) (02/03/88)
It seems that Mark Williams C is one of the more popular C compilers for the ST. Well, I've had my copy (an early v1.2) for more than a year now and am ALMOST happy with it: I can't stand the speed (or lack thereof) of the compile/link phase. Even after optimization (letting the compiler put temp files in ram-disk), my hard-disk based system still took over 5 minutes to 'make' a 3-module (total < 1200 lines) program. That's an average compile/link time of 220 lines/minute! MW-Quick C and Turbo-C for the PC's supposedly compile/link 10,000+ lines/minute. Could that be? Am I just TOO impatient? After all, it gives me time to fix a cup of tea while I wait for compiles/links :-) I didn't bother upgrading to v2.0, since I didn't detect any significant speed improvements (and the cost was $50.00 -- for an UPGRADE!) when I tried it out on a friends machine. Could some kind soul post (or send to me) some compile benchmarks for the newest MW-C ? (Is it v2.17?) If possible, I'd hope to see a benchmark for APSKEL.PRG -- but even a 'hello world' result would be appreciated. Perhaps this info will help me decide whether I want to upgrade to the new MW or just wait for Laser-C by Megamax. Thanks in advance for any info. Tom Wolf
CEN@PSUVM.BITNET (03/25/88)
HI
I am in the market for a C compilier. I think I've decided on
MWC, but I'm wondered how useable it is on a ST with 1 meg and 1
SS drive. If anyone has used this configuration, could I hear some
comments.
Jim Condon
CEN at PSUVM
P.S. Does anyone know where you can find v2.0 of Xlisp on the
net?steven@cwi.nl (Steven Pemberton) (05/17/89)
In article <431fba10.14a1f@gtephx.UUCP> covertr@gtephx.UUCP (Richard E. Covert) writes: > I am still waiting for Mark Williams to release an ANSI C compiler for the ST!!! Surprisingly, Mark Williams C 2.0 already has a lot of ANSI C in it. But the naughties, they #define __STDC__ but do *not* implement all of ANSI C, so that programs that I have that compile differently depending on the absence or presence of __STDC__ don't work. It would have been better not to have defined __STDC__ until everything was implemented. I don't know about MWC version 3, because it has taken me nearly a year to get it, and it *still* hasn't arrived. Why is the Dutch distribution of MWC so bad? The Dutch distributors that I was using (Compudress) blame Mark Williams, but I've had such bad experiences with them on other matters, that it's difficult to tell whether they're telling the truth. Steven Pemberton, CWI, Amsterdam; steven@cwi.nl "Let us go then you and I/while the night is laid out against the sky/like a smear of mustard on an old pork pie" "Nice poem Tom. I have suggestions for changes though, why not come over?"- Ez. The above are my opinions and do not reflect CWI's opinions and policies.
saj@chinet.chi.il.us (Stephen Jacobs) (05/18/89)
There have been some musings about when/whether Mark Williams Co is going
to do an ANSI C compiler. I've had several occasions in recent months to ask
people at Mark Williams about upcoming improvements in documentation and
compiler performance. They've been very open about rather large amounts of
future probabilities. As of six months ago, more than one knowledgeable
MW employee expected their ANSI-compliant compiler to be in beta test by
now. More recently, they have been optimistic, but a little more restrained.
Nobody ever outright promised ANYTHING except that it was being worked on.
They are a strange company to deal with: very helpful and friendly, but
often rather disorganized. I guess they don't want to get a reputation for
vapor, so the first >official< mention of their ANSI compiler will probably
be when they offer it for sale.
Steve J.dag@per2.UUCP (Daniel A. Glasser) (05/19/89)
In article <8120@boring.cwi.nl>, steven@cwi.nl (Steven Pemberton) writes: > > Surprisingly, Mark Williams C 2.0 already has a lot of ANSI C in it. > But the naughties, they #define __STDC__ but do *not* implement all of > ANSI C, so that programs that I have that compile differently > depending on the absence or presence of __STDC__ don't work. It would > have been better not to have defined __STDC__ until everything was > implemented. > __STDC__ is defined as 0 in MWC V3.0 (and earlier). This means that the compiler is NOT compliant with ANSI C in these releases. The preprocessor, however, is compliant in V3.0 and I believe 2.0 as well. The simple presence of the __STDC__ definition is not sufficient to tell if you are using an ANSI compiler, you must check the value of the macro. Ie, don't use "#ifdef __STDC__", use instead "#if __STDC__". If the macro is undefined, the #if evaluates to false. If your preprocessor does not allow #if on undefined symbols, it isn't even Unix V7 compatible. Section 3.8.8 of the ANSI X3J11 standard defines __STDC__ to be the decimal constant 1. It is not the compiler that has it wrong... Daniel A. Glasser -- _____________________________________________________________________________ Daniel A. Glasser One of those things that goes uwvax!per2!dag "BUMP!!!(ouch)" in the night. ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
siebren@cwi.nl (Siebren van der Zee) (05/23/89)
In article <857@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >In article <8120@boring.cwi.nl>, steven@cwi.nl (Steven Pemberton) writes: >> Surprisingly, Mark Williams C 2.0 already has a lot of ANSI C in it. >> But the naughties, they #define __STDC__ but do *not* implement all of >__STDC__ is defined as 0 in MWC V3.0 (and earlier). This means that the [...] >Ie, don't use "#ifdef __STDC__", use instead "#if __STDC__". If the >macro is undefined, the #if evaluates to false. If your preprocessor >does not allow #if on undefined symbols, it isn't even Unix V7 compatible. >Section 3.8.8 of the ANSI X3J11 standard defines __STDC__ to be the >decimal constant 1. (Steven is a collegue of mine, I complained about this on the net too) So what? They put in an annoying symbol that has _NO_ meaning, and _NO_ purpose other that polluting my namespace. Remember that once, a long, long time ago, #if did not even exist. Not even for defined symbols. Steven's config program works for all compilers I know of, including one that doesn't implement #if. Ever thought about how careful you have to code to accomplish that? Ok, then MWC comes around, defines a macro without any meaning, but completely correct. He had to make a decision whether to support MWC or the other compiler. I think his decision not to support MWC V3 is the right one, especially since they are probably working on an ANSI version. > >It is not the compiler that has it wrong... That right. But that doesn't solve our problems. If only somebody could explain to me what use the definition of __STDC__ as 0 might mean, why I might want to have my compiler to define it... Siebren van der Zee, siebren@cwi.nl -- waiting for MWC V4
saj@chinet.chi.il.us (Stephen Jacobs) (05/24/89)
In article <8137@boring.cwi.nl>, siebren@cwi.nl (Siebren van der Zee) writes: > In article <857@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: > >In article <8120@boring.cwi.nl>, steven@cwi.nl (Steven Pemberton) writes: > >> Surprisingly, Mark Williams C 2.0 already has a lot of ANSI C in it. > >> But the naughties, they #define __STDC__ but do *not* implement all of > If only somebody could explain to me what use the definition of __STDC__ > as 0 might mean, why I might want to have my compiler to define it... > > Siebren van der Zee, siebren@cwi.nl -- waiting for MWC V4 This whole discussion has been about telling whether a compiler complies with the proposed standard. Defining __STDC__ as zero is a very reasonable way of telling a program that you don't comply with the standard. As far as I can see, it's the only way that's consistent with the obviously intended 'Other Shoe': a future language standard will define __STDC__ as 2. As to why one might want a non-complying compiler in a world of complying ones, there are the usual maintenance/library arguments. I've seen machines with 3 generations of FORTRAN compilers, or 2 levels of Pascal available. Steve J.
karl@haddock.ima.isc.com (Karl Heuer) (05/27/89)
In article <8530@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >Defining __STDC__ as zero is a very reasonable way of telling a program that >you don't comply with the standard. But not nearly as reasonable as undefining it completely, which would work with *both* "#if" and "#ifdef", and which would be consistent with all the compilers that were written before X3J11 invented the __STDC__ symbol. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
bill@twwells.uucp (T. William Wells) (05/28/89)
In article <13475@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
: But not nearly as reasonable as undefining it completely, which would work
: with *both* "#if" and "#ifdef", and which would be consistent with all the
: compilers that were written before X3J11 invented the __STDC__ symbol.
The ANSI standard applies only to implementations and programs
claiming conformance to it. Who should care what others do? If you
are writing programs that have to check the implementation for
conformance, you had just better only check for __STD__ == 1.
Anything else is just damn lazyness on your part.
If you are writing code that has to deal with preprocessors that will
complain about #if __STDC__ == 1 when __STDC__ is undefined, add this
to the top of your code:
#ifndef __STDC__
#define __STDC__ 0
#endif
Then wherever you need to test for ANSI conformance, you can just
test for __STDC__ == 1 without worrying about __STDC__ being
undefined at that point.
---
Bill { uunet | novavax } !twwells!billkarl@haddock.ima.isc.com (Karl Heuer) (06/01/89)
In article <1000@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >[You could, if necessary,] add this to the top of your code: > #ifndef __STDC__ > #define __STDC__ 0 > #endif I think that, instead, I'll add the equivalent of #if defined(__STDC__) && __STDC__ <= 0 #undef __STDC__ #endif until someone decides just what __STDC__==0 is supposed to mean. Does MWC, running on a non-UNIX system, predefine `unix' to be `0'? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
bill@twwells.uucp (T. William Wells) (06/04/89)
In article <13522@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: : In article <1000@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : >[You could, if necessary,] add this to the top of your code: : > #ifndef __STDC__ : > #define __STDC__ 0 : > #endif : : I think that, instead, I'll add the equivalent of : #if defined(__STDC__) && __STDC__ <= 0 : #undef __STDC__ : #endif : until someone decides just what __STDC__==0 is supposed to mean. The problem with that is that there are still an appreciable number of compilers that don't do defined(). Of course it could be done as: #ifdef __STDC__ #if __STDC__ <= 0 /* Or maybe even __STDC__ != 1 ? */ #undef __STDC__ #endif #endif (But if you want portability to compilers without #if, you are *really* screwed!) --- Bill { uunet | novavax } !twwells!bill
rec@elf115.uu.net (Roger Critchlow) (06/05/89)
In article <13522@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > I think that, instead, I'll add the equivalent of > #if defined(__STDC__) && __STDC__ <= 0 > #undef __STDC__ > #endif Sorry, you aren't allowed to #undef __STDC__. "The rule that these macros may not be redefined or undefined reduces the complexity of the name space that the programmer and implementor must understand;" [Rationale for dpANS C, 13-May-88, p. 67] > until someone decides just what __STDC__==0 is supposed to mean. It means that MWC does not claim dpANS conformance. The preprocessor conforms to dpANS in all respects except for the value of __STDC__. Since this makes it behave differently than previous versions of the preprocessor, it seemed reasonable to give some indication of the fact. The Rationale suggested that: "This macro should be of use in the transition toward conformance with the Standard." [Ibid., p. 68] so I made use of it. Since the Rationale suggested that "future versions of the Standard could define [ __STDC__ ] as 2, 3, ..." [Ibid.] I should have known right off that everyone would poll its value with #ifdef. :-) I missed that clue and the deed was done by the time everybody's C magazines were cranking out examples filled with #ifdef __STDC__ conditionals. I am sorry for the inconvenience which my perverse interpretation has caused users of the MWC compiler. > Does MWC, running on a non-UNIX system, predefine `unix' to be `0'? No, MWC only runs on non-UNIX systems, it never defines unix to be anything. -- rec@elf115.uu.net == uunet!elf115!rec == Roger Critchlow, Sea Cliff, NY --
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/05/89)
In article <13522@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: > #if defined(__STDC__) && __STDC__ <= 0 > #undef __STDC__ > #endif >until someone decides just what __STDC__==0 is supposed to mean. I don't know about the particular compiler in question, but I don't think you're supposed to be able to #undef of re-#define the __????__ macros. That's why I ended up using my own symbol STD_C instead of trying to "fix" the vendor's __STDC__ in general.
ralph@nastassia.laas.fr (Ralph-P. Sobek) (06/12/89)
Since the previous postings were discussing what one complier supports or does not support, I have a simple question. Is it true that MWC does not support the IEEE floating point standard? Is it in the queue? According to our local ST mag (precisely: ST Magazine), they stated that MWC uses the DEC standard. Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU
kens@atari.UUCP (Kenneth Soohoo) (06/13/89)
In article <381@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes: > >Since the previous postings were discussing what one complier supports >or does not support, I have a simple question. > >Is it true that MWC does not support the IEEE floating point standard? >Is it in the queue? According to our local ST mag (precisely: ST >Magazine), they stated that MWC uses the DEC standard. > Yes, Ralph, MWC _does_ support the DEC format, which isn't a heck of a lot of help with the MC6881 floating point co-processor board, which uses IEEE standard floating point. As far as _I_ know, MWC has plans to support IEEE in the near future (i.e. "we're working on it, OK???"). You should check out, oh, any number of other compilers if you _really_ need IEEE... Aztec, Alycon... ;-) Oh, and regarding the expansion bus which the '881 sits on in a Mega, it'd be _really_ hard to make the equivalent slot for a 520/1040 style machine, sorry. -- Kenneth Soohoo {ames,imagen,portal}!atari!kens Atari Engineering "So Atari doesn't necessarily agree with me, so what!"
n62@nikhefh.hep.nl (Klamer Schutte) (06/14/89)
In article <1557@atari.UUCP> kens@atari.UUCP (Kenneth Soohoo) writes: >In article <381@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes: >>Is it true that MWC does not support the IEEE floating point standard? >Yes, Ralph, MWC _does_ support the DEC format, which isn't a heck of a lot >You should check out, oh, any number of other compilers if you _really_ need >IEEE... Aztec, Alycon... ;-) Oh, and regarding the expansion bus which the Or you can try TURBOC; it is nice, and support IEEE (extended format, 80 bits for calculations and normal, 32 bits for float). Klamer PS 1 I do not have a 6888n; so i haven't tried whether it is really IEEE PS 2 I am not connected to Borland, the Turbo company -- ________________________________________________________________________________ Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhefh.hep.nl
kbad@atari.UUCP (Ken Badertscher) (06/16/89)
In article <211@nikhefh.hep.nl> n62@nikhefh.hep.nl (Klamer Schutte) writes: | In article <1557@atari.UUCP> kens@atari.UUCP (Kenneth Soohoo) writes: | >You should check out, oh, any number of other compilers if you _really_ need | >IEEE... Aztec, Alycon... | | Or you can try TURBOC... Or you can use Laser C. Laser supports IEEE format reals, and the software FP libraries are very very fast. Megamax has recently added 68881 support in their FP libraries, too! -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
saj@chinet.chi.il.us (Stephen Jacobs) (06/19/89)
In article <1557@atari.UUCP>, kens@atari.UUCP (Kenneth Soohoo) writes: [A lot of other stuff that was more to the point of the original discussion] > Oh, and regarding the expansion bus which the > '881 sits on in a Mega, it'd be _really_ hard to make the equivalent slot > for a 520/1040 style machine, sorry. > > -- > Kenneth Soohoo {ames,imagen,portal}!atari!kens > Atari Engineering > "So Atari doesn't necessarily agree with me, so what!" I'd like to invite some of the hardware hackers out there to enlighten me on this point. (Even Atari people are invited) Earlier comments had led me to believe that you basically needed to buffer all the data and control pins on the 68000, sort them out, and you had a Mega bus. This wouldn't be out of the question as a hobbyist project, and I kinda hoped it would eventually be something my friendly local service shop could install. What's the catch? Steve J.
smaal@duttnph.tudelft.nl (Wouter Smaal) (05/07/91)
What is the latest version of Mark Williams C (for the Atari ST). I use version 1.1 updated (in '88) to 3.0. I asked my local ST dealer, but it is unknown who is the current distributor in Holland for Mark Williams C ... Regards, Wouter Smaal ------------------------------------------------------------------------ E-Mail-To: smaal@duttnph.tudelft.nl P-Mail-To: Delft Univ. of Tech., Lorentzweg 1, 2628 CJ Delft, Holland V-Mail-To: 31-(0)15-782031, 31-(0)15-781416, Fax 31-(0)15-626740 ------------------------------------------------------------------------ -- Regards, Wouter Smaal
smaal@duttnph.tudelft.nl (Wouter Smaal) (05/07/91)
What is the latest version of Mark Williams C (for the Atari ST). I use version 1.1 updated (in '88) to 3.0. I asked my local ST dealer, but it is unknown who is the current distributor in Holland for Mark Williams C ... Wouter Smaal E-Mail-To: smaal@duttnph.tudelft.nl P-Mail-To: Delft Univ. of Tech., Lorentzweg 1, 2628 CJ Delft, Holland V-Mail-To: 31-(0)15-782031, 31-(0)15-781416, Fax 31-(0)15-626740 -- Regards, Wouter Smaal