toml@xrxns.UUCP (05/06/87)
i have been dinking around with MWC 2.0 for about 1.5 months now. i bought
version 1.1 in january, so i had about 2-3 months with 1.1 before i got 2.0.
i will not disagree with any of the things posted here about mwc 2.0 so far,
but i would like to clarify one point. MW is claiming significant improve-
ments in compile/link times (something on the order of 50%, i can't remember
for certain right now), supposedly putting them *ahead* of Megamax in
this area of performance. i spoke with their national marketing manager
about their benchmarks. the bottom line is that they achieved the lion's
share of their improvement in compilation speed by doing the compiles out of
the ram disk. of course, the next obvious question is, how did they bench
the megamax performance? without a ram disk, of course! so their performance
claims are based on an apples-and-oranges comparison. their justification
is that they sell the compiler+ramdisk as a package, while megamax just sells
the compiler, and the benchmark reflects a "system" performance. well, i
guess that's fine, but i'd also bet that 80% or more of "serious" megamax
users are using ram disks acquired commercially or from the PD.
further complaints: i had problems making a bootable ram disk which would
install itself out of the auto folder - i plan to talk to MW about that this
week. also: the installation procedures are ok for a hard disk or dual
floppy system, but are an incredible, frustrating pain on a single floppy
(e.g. 1040stf) system. multiple swaps *per file* are performed, and we're
talking *lots* of files. there is a lot of room for user confusion. i
suspect that appropriate use of a ram disk at install time could make this
much more reasonable, but this is not supported by their installer. this sort
of brings up another issue, the appropriateness of this compiler for "small"
systems, e.g. 520 with ss drives, either 520 or 1040 without a hard disk.
single sided drives are supported, but i don't think i'd want to try it. and
though work on a single floppy is supposedly possible, i haven't succeeded
at the install yet, and even when i do succeed a lot of the convenience of
having the msh commands and everything available at once will be impaired on
a single disk system.
and now, after having bashed MWC for a bit, let me say some nice things. the
documentation is superb, and includes tons of examples of real programs, not
just code fragments. i really feel that a person could learn an awful lot
about both c programming and dealing with GEM/TOS just from perusing the
manual and its examples. although i haven't been using it much yet, the
microemacs shipped with MWC 2.0 is enhanced to allow the compiler to toss
you into the editor at the appropriate line when it detects a compiler
error. the package includes source for this microemacs, as well as source
for their ram disk. they do include a debugger, but it's a pretty low-
level beast (looking forward to a reasonable symbolic debugger for the ST!!).
and the shell, msh: while it is loaded with peculiarities (it is a strange
blend of csh, sh, and god knows what else), it is a pretty reasonable tool.
the important this is that it comes with *many* unix-derived tools, many
more so than what is bundled with beckemeyer's $50 or so micro c shell.
i really think that if MW's msh had a better history feature i would put
beckemeyers shell away for good. the thing about beckemeyer is that they
have all the unix stuff, but to get it all you have to buy something like
four packages, at a total cost of exceeding the discount price of MWC (about
$110)! oh yeah, MWC includes a pretty good "make" too, that's another
$30 or $40 package from b'meyer.
bottom line: i'm a big fan of mark williams' C compiler, as i suspect most
programmers who cut their teeth on unix would be. they have a few warts to
address, and some of their performance claims ought to be taken with a
grain of salt, but their package is a class act all the way. plus it is
an excellent value for the money - even if you threw away the compiler
(not that i would encourage that at all), for a little over a hundred
bucks you get a reasonable shell with something like 30 or 40 unix-derived
and st-specific utilities, make, microemacs + source, ram disk + source,
and a debugger. not a bad deal.
i write a c language column for "st applications" magazine. the first half
of a two-part review i am writing is in print in this month's issue (may 87).
the second half, which is still in progress, will be published in the july
issue. i am performing benchmarks on MWC1.1, MWC2.0, Megamax 1.1, and (if
i receive it in time) the new Megamax 1.2. if anyone out there has any good
benchmarks they think i should run, drop me a note and include source code.
i'm not keen on the ones i'm currently using (august 83 byte benchmarks,
including fibo, sieve, diskio, a sort, and floating pt) plus the
dhrystone. is the savage FP benchmark worthwhile? any others? (note: this
has to be in hand and running within the next two weeks or it's no good
to me! so if you have input, please don't put off getting in touch).
i plan to post the result of the benchmarks to this group when they're ready.
i will probably have more to say about mwc2.0 and megamax 1.2 by then.
if anyone wants copies of my review, you can find "st applications" on the
shelf at most atari dealers (plug plug!), or drop me a mail note and i'll
mail you a copy.
tchuss!
tom love
xerox edds
leesburg, va 22075
(703)729-8000 x5185
uucp: {various and seismo}!rochester!rocksanne!xrxns!toml
XNS: toml:lsbg-egp/cad:xerox
disclaimer: of course i'm associated with st applications, i told you so
above! no connection to megamax or mark williams though! and xerox would
definitely disavow any knowledge of my existence.minow@decvax.UUCP (05/07/87)
I use Mark Williams C on a single-disk Atari 1040STf. Without more than
moderate pain, I built a 512K ramdisk, loading it as follows:
c:\desktop.inf
c:\auto:
c:\bin:
as.prg cc.ttp ld.prg make.prg me.tos
msh.prg postfile profile
c:\lib:
cc0.prg cc1.prg cc2.prg cc3.prg cpp.prg
crts0.o crtsd.o crtsg.o libc.a mactions
mmacros
c:\tmp:
Using the Ramdisk setup program, I built a "cold-boot" disk that starts
the system in short order. My C code is on a source disk that also
contains all #include files, as well as libaes.a, libm.a, and libvdi.a.
Here are the pieces of my profile file that I changed (... marks elisions):
...
set sys=a:
set usrdrive=b:
set tmp=c:
set drive1=$cwdisk:
setenv PATH=.cmd,,$tmp\bin,$drive1\bin,$drive1\lib,$sys\bin,$sys\lib
setenv SUFF=,.prg,.ttp,.tos
setenv LIBPATH=$tmp\lib,$drive1\lib,$drive1\bin,$sys\lib,$sys\bin,
setenv INCDIR=$drive1\include
# This directory is used by the shell when evaluating
# `commands` substitutions, so the `getrez` and `getpal`
# below will fail if TMPDIR does not exist or TMPDIR is
# not defined and the default TMPDIR, \tmp, does not exist.
setenv TMPDIR=$tmp
setenv HOME=$drive1\tmp
setenv TIMEZONE=EST:0:EDT
...
# the list directory in columns command from the documentation
set in .cmd lc="ls -w"
echo `df` "free bytes in drive $cwdisk"
---
I also modified profile to give me black text on a white screen.
To give you an idea of MWC performance, a full rebuild of my
home-made terminal emulator (about 60,000 bytes of C source and
over 30,000 bytes .prg) takes about 4-5 minutes (compile + link).
Martin Minow
decvax!minowbaron@transys.UUCP (Joe Portman) (05/07/87)
In article <136@xrxns.UUCP> toml@xrxns.UUCP (Tom Love) writes: [much deleted] > >also: the installation procedures are ok for a hard disk or dual >floppy system, but are an incredible, frustrating pain on a single floppy >(e.g. 1040stf) system. multiple swaps *per file* are performed, and we're >talking *lots* of files. there is a lot of room for user confusion. i >suspect that appropriate use of a ram disk at install time could make this >much more reasonable, but this is not supported by their installer. The installer I used specifically tells you to install a ram disk. On disk number one of the installation floppies there is a sample rdydisk.ram info file. I loaded that, went to the desktop and installed the disk as drive C. After that, back into the install and away we go. Total install time: about 12 minutes. I tried to install about twice before I realized the installer was looking for drive C as the ramdisk. This is probably a bug. >this sort >of brings up another issue, the appropriateness of this compiler for "small" >systems, e.g. 520 with ss drives, either 520 or 1040 without a hard disk. >single sided drives are supported, but i don't think i'd want to try it. and >though work on a single floppy is supposedly possible, i haven't succeeded >at the install yet, and even when i do succeed a lot of the convenience of >having the msh commands and everything available at once will be impaired on >a single disk system. A 520 SS system is probably not suitable for development work without at least a ram upgrade. I have a 1040STf and a single DSDD floppy. I created a boot disk with just the compiler passes, cpp and a couple of often used commands (msh, me and grep). When I boot with MSH in \AUTO I have a special PROFILE that copies the entire disk to the ram disk. I then put the compiler disk created by install in the drive and cd to the ram disk. With the compiler passes in ram, there is still about 100k or so left for a source file on a 400k ramdisk. This is plenty for a lot of applications, in fact I am amazed at how much can be done on a single drive system. When I need a special command, I simply swap the commands disk in and away I go. If you want it to, you can make the shell prompt you for the commands by adding drive b: to the PATH variable. The shell will search ram, drive a: and then ask for drive b:. Incidentally, with the shareware FORMAT2 program, you can format a disk to hold 820k. With this extra space you can add a lot of commands to your compiler disk, thus eliminating swaps. I have'nt completely customized my setup yet, I just realized that with the compiler passes in ram, I don't need them on the compiler disk any more. Oh well, bottom line: Single drive development is very practical using MWC. [goes on to say much good about MWC] I agree. For the price (I paid 114.50) I believe it is a super value.
braner@batcomputer.tn.cornell.edu (braner) (05/10/87)
[] One thing the MWC users did not post: how many seconds (minutes?) does it take to compile and link a program and reenter the editor, using your optimized floppy+RAMdisk setup? (Using Megamax on a RAMdisk, the time for that cycle is less than 20 seconds for a small program.) (Using Absoft FORTRAN: about 5 seconds...) - Moshe Braner