asm@utcsri.UUCP (05/03/87)
[.]
Hello Folks!
I have version 1.4 of the Mark Williams compiler and am
thinking of sending in for the upgrade to 2.0 if the
improvements are substantial. Can you tell me the following:
1. Has the compiler changed significantly? Does it allow inline
assembly language now? Has the optimzer been improved further?
2. I heard that there was new documentation. Is this doc any different
from version 1.4 (single manual describes compiler, Make and
MicroEmacs rather well, but no docs on Gem calls).
3. Have the libraries been improved further. What has changed specifically?
4. In short, what improvements have been made?
I would appreciate any info on this. Also,
what is the procedure for upgrading (I heard something about sending in
page 2 of the manual along with some money).
Thanks for any info.
-anees
ps. I have found the quality of the software and documentation to be
very good; therfore, unlike for other compilers, the motivation
for sending for an upgrade is not there!
#include <standard disclaimer about no connection to MWC>
--
Anees Munshi @ University of Toronto Engineering.
ARPA asm%csri.toronto.edu@csnet-relay.arpa
BitNet asm@utcsri.UTORONTO
CSNet asm@csri.toronto.edu
UUCP {allegra,ihnp4,decvax,pyramid}!utzoo!utcsri!asm
Reality is so much better!baron@transys.UUCP (Joe Portman) (05/04/87)
In article <4722@utcsri.UUCP> asm@utcsri.UUCP (Anees Munshi) writes: >Hello Folks! > > I have version 1.4 of the Mark Williams compiler and am > thinking of sending in for the upgrade to 2.0 if the > improvements are substantial. Can you tell me the following: >1. Has the compiler changed significantly? Does it allow inline > assembly language now? Has the optimzer been improved further? They claim 25% faster compile times and better code generation, but I don't have an old version to compare to. I do have the mark johnson shareware compiler, and I will say that mark williams does produce smaller code. >2. I heard that there was new documentation. Is this doc any different > from version 1.4 (single manual describes compiler, Make and > MicroEmacs rather well, but no docs on Gem calls). Yes there is a complete dsecription of all aes,vdi and bios, xbios calls with many examples. I was able to design a simple menued program with objects just reading from the manual. >3. Have the libraries been improved further. What has changed specifically? Hmm, don't know. Other than the fact that they seem very complete. The startup code is particularly interesting. Hmm, they also have a note about supporting the beckermeyer C shell. >4. In short, what improvements have been made? The documentation is excellent. Every routine I wanted to know about (and some I did'nt) is described. According to the docs, the MSH (shell) has been vastly improved. They do include a bootable ramdisk utility, very handy. As an aside, I purchased the product as an evaluation unit for possible sale by my company. I am very tough on such things, so flame away if you like, the product is going to get woefully abused before we decide to sell it.
jdn@homxc.UUCP (J.NAGY) (05/04/87)
In article <4722@utcsri.UUCP>, asm@utcsri.UUCP writes: > I have version 1.4 of the Mark Williams compiler and am > thinking of sending in for the upgrade to 2.0 if the > improvements are substantial. Can you tell me the following: > > 1. Has the compiler changed significantly? Does it allow inline > assembly language now? Has the optimzer been improved further? There are miscellaneous bugfixes and the optimizer has been improved. Compile time has been reduced approximately 25%. It does not allow in-line assembly and probably never will, as this goes against the grain of Mark Williams "philosophy". > > 2. I heard that there was new documentation. Is this doc any different > from version 1.4 (single manual describes compiler, Make and > MicroEmacs rather well, but no docs on Gem calls). The docs are the same excellent format, but substantially expanded. All GEM calls are now included. MWC 2.0 documentation is the best that I've seen for the Atari 1040ST. > 3. Have the libraries been improved further. What has changed specifically? > I don't recall any mention of change to the libraries. > 4. In short, what improvements have been made? The Mark Williams shell has been expanded and vastly improved. Also included is a very nice RAM disk and loader which has a GEM interface and allows booting off the RAM disk. > I would appreciate any info on this. Also, > what is the procedure for upgrading . I sent them the first page of my 1.4 manual and a check for $55, and had the new version in three days. I recommend the upgrade. Jonathan Nagy {ihnp4|harvard|allegra}!homxc!jdn
minow@decvax.UUCP (Martin Minow) (05/05/87)
In article <4722@utcsri.UUCP> asm@utcsri.UUCP (Anees Munshi) asks a number of questions about the Mark Williams C compiler upgrade. I am a satisfied user of MWC and have recently upgraded my system. Hope this helps. >1. Has the compiler changed significantly? Does it allow inline > assembly language now? Has the optimzer been improved further? It appears to run faster. Inline assembly is not permitted. I haven't checked resulting code, but their documentation talks about improvements both in code speed and code size. >2. I heard that there was new documentation. Is this doc any different > from version 1.4 (single manual describes compiler, Make and > MicroEmacs rather well, but no docs on Gem calls). There is 690 page single manual. It has slightly fewer pages than the previous (V1.1) manual, but has a slightly larger paper size, so there's more information. The GEM and TOS calls are well described, including small sample programs for most (if not all) TOS/GEM routines. >3. Have the libraries been improved further. What has changed specifically? The header files have been extended slightly. Nothing else that I noticed. >4. In short, what improvements have been made? The shell has been extended substantially. There is an excellent RAMDISK that survives reset, and can be made bootable. You can also save a copy of the ramdisk in the \auto directory of a floppy that makes cold-boots painless. You can tell the compiler to call the editor with one buffer pointing to the file, and another pointing to your error messages. When you exit the editor, compilation proceeds. >what is the procedure for upgrading (I heard something about sending in >page 2 of the manual along with some money). If you're registered with Mark Williams, they should have sent you an upgrade form. Otherwise, I'd recommend calling them at (312) 472-6659. If I remember correctly, the upgrade cost me $50 plus shipping. >ps. I have found the quality of the software and documentation to be > very good; therfore, unlike for other compilers, the motivation > for sending for an upgrade is not there! Agreed, but the upgrade is still worthwhile. Martin Minow decvax!minow Disclaimer: I am friends with one of the Mark Williams C developers. The above does not represent the opinions of Digital Equipment Corporation.
sansom@trwrb.UUCP (Richard Sansom) (05/05/87)
(regarding version 2.0 of the Mark Williams C Compiler for the ST) In article <4722@utcsri.UUCP> asm@utcsri.UUCP (Anees Munshi) writes: >1. Has the compiler changed significantly? Does it allow inline > assembly language now? Has the optimzer been improved further? The compile/link time has been reduced by about 25%. As for inline assembly - this is still unavailable (at least, it is not mentioned in the documentation & I haven't tried it). I'm looking forward to this one. Code size has also been improved by about 25% (I'm guessing here). >2. I heard that there was new documentation. Is this doc any different > from version 1.4 (single manual describes compiler, Make and > MicroEmacs rather well, but no docs on Gem calls). The manual now includes _complete_ GEM AES & VDI documentation. There are also quite a few sample programs included (in the documentation) which demonstrate GEM programming. It's interesting that Mark Williams Co. has been able to do what Atari could not (produce some _real_ documentation) in so short a time. >3. Have the libraries been improved further. What has changed specifically? The libraries _seem_ to have been optimized a bit further (I can't swear to this). The most noticeable difference is in the amount of time it takes to link the libraries with your code (it has decreased _substantially_). >4. In short, what improvements have been made? I don't have the official release document with me, but I will say that what was already (in my opinion) the finest C compiler for the ST has been improved by much more than the upgrade fee warrants. If you have version 1.x then you should definitely buy version 2.0. >...what is the procedure for upgrading (I heard something about sending in >page 2 of the manual along with some money). Send a check for $55, along with the inside front cover of the manual (the one with heavy paper) to Mark Williams for an upgrade. -Rich -- /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /// Richard E. Sansom TRW Electronics & Defense Sector \\\ \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA /// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
rwa@auvax.UUCP (Ross Alexander) (05/05/87)
> In article <4722@utcsri.UUCP> asm@utcsri.UUCP (Anees Munshi) asks: >1. Has the compiler changed significantly? Does it allow inline > assembly language now? Has the optimzer been improved further? Inline isn't supported. The grammar of C hasn't changed ;-). But the optimizer seems to be measurably better; my old version would report about 833 on the dhrystone bench, 2.0 does exactly 1000 dhrystones. I feel that this, coupled with the many other nice features of MWC 2.0 makes the upgrade price quite reasonable. Certainly the shell is a vast improvement (it now has flow-of-control constructs and aliases) over its previous incarnation. ...!ihnp4!alberta!auvax!rwa Ross Alexander, Athabasca University
woodside@ttidca.TTI.COM (George Woodside) (05/07/87)
I have the MWC 2.0 update (to my original 1.1 compiler). While I can't
answer all your questions, here's what I can offer:
Inline Assembly - Still not supported.
Optimizer - Documentation says it is improved. Having looked at the code,
I'd say it could use a bit more improving. It will still write
the same instruction two (or even three) times consecutively.
Documentatioin - Buy the upgrade just for it, even if nothing else is of
interest to you. It is now the most thorough documentation
on GEM and VDI anywhere.
Libraries - Again, the documentation says it is improved. Object modules
are a little bit smaller, execution is about 15% - 20% faster.
The compiler itself is a bit faster. It comes with a vastly improved shell
(which I still don't use) and, at last, compatibility with Beckemeyer's
C-Shell (which I use almost exclusively). It also includes a RAMdisk, in
source. You are supposed to send in the page from your old book with the
copyright notice on it, and a fee of $50 plus $5 S&H in the US (I don't
remember the S&H for international customers). I think anyone who likes
their old version should upgrade, there is plenty of reason to.
The change for Beckemeyer shell compatibility requires that you have
C-Shell 2.0, which changed the way C-Shell saves and parses the PATH
environment variable.
Known bugs - there is a glitch in the assembler which causes the value of
generated long constants to have their high order byte zeroed (ie. 0x87654321L
yields 0x00654321L in the object. Printf will still not write any output until
it gets a line feed (this is not a bug as far as MW is concerned, but a design
"feature").bammi@cwruecmp.UUCP (Jwahar R. Bammi) (05/10/87)
In article <692@ttidca.TTI.COM> woodside@ttidcb.UUCP (George Woodside) writes: >Known bugs - there is a glitch in the assembler which causes the value of >generated long constants to have their high order byte zeroed (ie. 0x87654321L >yields 0x00654321L in the object. Printf will still not write any output until >it gets a line feed (this is not a bug as far as MW is concerned, but a design >"feature"). Firstly, many kudos to George Woodside for his excellent TURTLE hard disk backup program. It is absolutely the best backup utility out there, commercial or otherwise. Thanks. Just to add to to the bugs list above, we've come across the following: - Some of the Bit testing type constructs generate a cryptic internal compiler error message. For instance typedef struct { char *name; int flags; .... } AType; #define THISFLAG 0x0020 Atype *x; ..... if(x->flags & THISFLAG) ... ^^^^^^ On this line it will generate an internal compiler error and will display a hex number. This was reported to MWC and they said it would be fixed. - the rindex() library routine does not return a NULL is a NULL string is passed to it. pm@case spent many hours tracking down a bug caused by this. char *s, *t; extern char *rindex(); s = ""; t = rindex(s,'<any chararacter>'); returns s, and not (char *)NULL; The printf bug you describe above is not a bug, as standard i/o streams (except perhaps stderr, depending on who you talk to) are buffered. These buffers are flushed only when they are full, or when and end of line is written, or when they are closed. If you need to flush a stream, use the fflush() call. Now i wish MW would lift the silly 32k limits on the static data structures. Other than the minor inconveniences listed above, MW works great for me. -- usenet: {decvax,cbatt,cbosgd,sun}!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (05/12/87)
Another Mark Williams C 2.0 bug; there is as least one case where the compiler will, in an expression that has generated a 16-bit signed temporary result and that temporary result needs to be extended to 32 bits (again signed), generate the incorrect code to do the sign extension. Instead of the correct "ext.l" instruction, it generates "ext.w", which clobbers the top byte of the 16 bit temporary result. Assuming that their assembler is written in C, the previously reported bug in the assembler might even be caused by this. dgc