Conference 7.286::atarist

    I am still running the Beta version, no response to my check yet.
    
    						-Dave

    I was under the impression that V3.0 (actualy V3.0.6) was suppose
    to generate smaller programs PLUS have an extra peephole optimizer
    step that would make programs smaller yet. Well my first impression
    is that none of it is true.
    
    This is based on a limited test case (one program :-)) but I still
    would have expected better results than what I got. The bottom line
    is that V3.0 generates LARGER programs or at least in some cases
    (ie: this case).
    
    NOTE: in the following chart,
    	-VPEEP causes the code to go through the PEEPhole optimizer
    	-VSMALL causes PC relative code to be produced, limits code to 32k
    	-VNOOPT turns off all optimization, including the default done by CC
    
    VERSION	COMMAND	   	SIZE
    -------	---------	-----
    V2.0	CC		11925	The original to compare against
    V3.0.6	CC		11950	25 bytes larger
    V3.0.6	CC -VPEEP	11942	Still 17 bytes larger
    V3.0.6	CC -VSMALL	11712	213 bytes smaller!! Only good
    					for small progams like this one
    V3.0.6	CC -VNOOPT	11985	Just for kicks, 60 bytes larger
    
    These are realy trivial differences but not what one would expect
    from a "newer, better, plus peephole" version of the compiler! Also
    seems like it might get worse for decent size programs (>100k) where
    you realy want optimization to make your program smaller (not bigger
    :-)).
    
    Any one else made comparisons?
    
    Haven't tried the Resource editor (I just got the update last night)
    so can't tell you anything about that.
                                          
    	Ray

    Optimizers don't necessarily make the code smaller on newer machines.
    I think the argument is that you have more memory so why not make
    use of it and avoid some subroutine calls when code can be placed
    inline.  I must admit that I haven't looked into this aspect of
    the new compiler.  Did you measure the execution time of your program,
    and if so, did it run faster?  That to me is the bottom line.
    
    The Greenhills C cross-compiler that runs on the VAX specifically
    states that optimization may make the code larger, rather than smaller.
    In the days of the PDP11's, smaller was better, because you had
    to make the code fit.  That is not generally the case in newer
    architecture machines.
    
    						-Dave
    
    How bout them Celts!  On to game 7!

How did you measure the size?  Did you "strip" it first?

I got smaller code for both microemacs and for Whack.  I'll see about
generating numbers.

       I received my copy of MWC update this weekend, I didn't have much
     time to play with it, perhaps tonight.  I ran through MW sample 
     program using csd, but I must say that there source code debugger
     is no where near the quality of code view which comes with microsoft
     c, for the pc family.  I also was unsuccessful at getting one of my
     programs to come up in the debugger, it said the debugging info was
     not in my file, and I should recompile with -VCSD, well I was compiling
     with this switch (any theories).  I tried running the resource
     construction set, but after about 10 minutes of using it, my machine
     hung up, I know the sequence of things I did, so I can retry it
     tonight to see if it is reproducible.

     Bill Powers
 

    Dave is right I did overlook the fact that optimization can be for
    either size or speed (or a compromise). So I checked the execution
    time, both versions run at the same speed. Ok, there are some problems
    with my test, 1. The programs run in 13 seconds, not long enough
    to make a reasonable time comparison. 2. The program is disk intensive
    (read a file, massage it slightly, write a file) so again it's a
    bad test of the speed of the generated code.
    
    I will come up with some better tests/benchmarks.
    
    I measured the size by looking at the .PRG.  No I didn't strip the
    files, I thought about it but it seemed that the additional Csd info
    would not be added unless I asked for it (therefore the amount of
    data "stripped" from the files would be the same).
    
    I did have a thought that the MWC library routines may have grown since
    V2.0 so I should realy compare the .O files to determine the size.
    Since my program is realativly small a change in size of the STDIO
    library would make a difference in code size. I have not done this yet,
    but I will. 
    
    Since it generated smaller code for MicroEmacs and Whack I'm happy
    since it was the magnitude of the size increase in larger programs that
    I was woried about. Though It would have been nice for small programs
    to have gotten even smaller. 
                                            
    	Ray

Re .-2, Did you LINK with -VCSD?  Unless you link with CSD, the image
doesn't have debugging information.

One reason you need to "strip" normal programs is that, by default, you
get enough debugging information for "db".  (Global symbols, etc.)  The
format and location of the "db" debugging information has changed, and
it might be slightly larger than before, which could throw off your
measurements.

I have found CSD to be "useful", but I'm not impressed by the
cumbersome user interface.  They could, and should, have done much
better.  It seems like a boring port of a boring IBM PC program.  You
should see what it's like trying to set a breakpoint on some routine in
the middle of an image that has both microemacs and the windowing
system from Whack in it.  There are about 25 modules, and the only way
to get to one in the center is to pass through every one in between.
(It's a lot better if you only include debugging information for a few
suspect modules.)  Another really tough thing to do is single-step
through a program.  You can't just hit a single key for each step (no,
that would be too easy), you have it hit F4 first.

    Well, personally, I was really annoyed by the obnoxious update program,
    in conjunction with the poor installation notes.
    
    The installation procedure seems to imply that you are going to
    make copies of each of your distribution disks, and then install
    from those copies.  If you have single sided drives, that means
    a total of 21 disks for the installation procedure (of which, you
    supply 14).
    
    That is ridiculous enough, but if you have double sided disks, the
    procedure to get a complete installation is totally opaque.  You
    must also select some of the installation options from the single-sided
    choices and some from the double-sided choices.
    
    Also the fact that you can only do one installation step per invocation
    of UPDATE.PRG is a further lose.
    
    I think I would have been better off just copying the files from
    the update disks onto my working disks...
    
    The beast probably works fine for installing on a hard-disk, though.
    
    After the installation, I had no energy left to actually test the
    product.
    
    Steph
    
    

    Since your talking about the UPDATE program how did you like these?
    (These quotes from the UPDATE procedure are apporximate but not
    exact quotes)

    Keep in mind you are working with six disks labled something like -
    	MWC 1of3
    	MWC 2of3
    	MWC 3of3
    	UPDATE 1of2
    	UPDATE 2of2
    	CSD 1of1

    The first UPDATE prompt is -    
    	"insert distribution disk 1"
    In my opinion both the original MWC disks and the update disks are
    "distributions" and there are there disks marked 1of.. so you have
    to guess. Time for a poll, how many people guessed correct? Just
    a raise of hands no replies please :-)!
    
    The last UPDATE prompt is as bad as useless as the first -
    	"insert update disk 3"
    There is no update disk 3! They of course mean CSD 1of1, but that
    is not an update (it's a first release) and it definitly isn't marked
    with a 3!
    
    Other than that the Hard Disk installation went smooth.
    
    Of course they wanted me to make floppy copies of all six disks
    before I installed them  on my HD. Did I laugh, oh boy did I laugh.
    What's the difference if I read the floppies once to back them up
    or read them once to install them on the HD? The floppies are all
    write protected and the installation is controlled by the UPDATE
    program so no humun error could easily cause them to get corrupted.
    
    Of course after all is said and done MWC is like the ST it is still the
    best bang for the buck! Right? Am I right? :-) Okay thats one humble
    opinion for someone who has never used any other compiler on the ST and
    has never used an Amiga. It was meant to make you chuckle not to
    start a "war" over which compiler or computer is better for what
    purpose.
    
    Well before I cause any trouble I better get out of here >>>>>>>>>> 
    
    	Ray

I would encourage anybody who had to suffer through the update procedure
to write a complaint to Mark Williams about it.  They were simply too
cheap to include an extra disk in each update so that you would get an
ordinary kit.  They should be ripped to shreds over this one.

    was anyone successful doing the update on a system with only one
    floppy disk? The release notes say it will work as long as a ram
    disk has been created, but after specifying no hard disk and one
    floppy disk in the configuration dialogue I get a warning that says
    update recquires two floppies. Any suggestions?
    
    rw
    

    
      I too agree that the update program really s**ked.  I however
    did guess correct on the distribution disk/update disk prompt.
    However, I am still not convinced that my system is setup properly
    while trying to investigate why my -VCSD switch is not being picked
    up, I decided to check if it might be a problem with make.prg, well
    I did an ls -l on make.prg on my hard disk, and the one on the dis-
    tribution disk, and they were different sizes, so I then copied
    by hand the files from each of the directories \bin, \lib, etc.
    this still did not fix my problem.
    
    Here is how I am doing my compile for my program:
    
    in my make file STDCL.MAK i have
    
    stdcl.prg: stdcl.o screen.o
      $(CC) $(CFLAGS) -f -VCSD -o stdcl.prg stdcl.o screen.o -lm
    
    I then execute at the command level
    % touch stdcl.c screen.c
    to guarantee compilation
    
    % make -f stdcl.mak
    to start compiling/linking
    
    the computer responds
    cc -c stdcl.c
    cc -c screen.c
    cc -f -VCSD -o stdcl.prg stdcl.o screen.o -lm
    
    then I type
    % csd stdcl
    
    the debugger responds
     Source Language debugger Atari ST version 1.0 
     Copyright (c)...
     Fatal error: 'stdcl' has no debug information, should compile -VCSD
    
    anyone have any suggestions???
    
    thanks
    Bill Powers
    

    Re: .10
    
    I received my update copy about 2 weeks ago.
    
    I actually did the installation twice, the first time I hadn't deleted
    my old files (may apply to .12 as well).  After attempting to use
    the compiler I found that I thought I was getting the old version.
    After some checking, I decided to delete ALL the subdirectories
    and start from scratch.  After that everything but CSD was working
    fine.  The only way I got around the problem with CSD was to manually
    copy the file off the disk, who knows what happened there?!
    
    The beta test, on the other hand, installed without a hitch (they
    didn't scrimp on the floppies).  Having had the beta test installed
    may have also been the problem with my getting the wrong files on
    my disk, I am not sure.
    
    If you abort the update procedure, better check your system time,
    I think they alter the time to get the files to copy with something
    close to the date they built the upgrade.  I found that my system
    time was set to sometime in April at one point, and I think I had
    aborted the upgrade once (when bitten by the wrong distribution
    disk #1, which one do I use? problem).
    
    I complained about the lack of a single step during the Beta test,
    apparently they decided to ignore my complaint.
    
    While CSD may be difficult moving amongst different modules, I think
    that there visual way of setting breakpoints, and redisplaying
    variables is superior to the VAX debugger.  It has its strengths
    and weaknesses, it is nice to finally have a source level debugger!
    
    						-Dave

Regarding .12:

Your problem here is that you must use the -CSD switch on the compile
phase as well as the link phase.  Your instructions to MAKE were such
that the -CSD applied only to the LINK phase.  The "make" program
generated commands for the compile phase for you, using the CFLAGS.

There are several ways to fix this.  One is to give explicit compile
instructions in the makefile for each module in the system, such as the
lines:

	stdcl.o : stdcl.c
	    $(CC) $(CFLAGS) -VCSD stdcl.c

The other is to change CFLAGS to include -VCSD, by adding the line

	CFLAGS = -c -VCSD

The first has the advantage of allowing you to control exactly which
modules have debugging information included.  The second has the
advantage of being able to control debug information for the entire
program at once.

    RE: .11
    
    I assume you had your ram disk installed before you ran UPDATE?
    It's probable that UPDATE actualy looks to see if the ram disk is
    there.
    
    Try running RDY (the ram disk that comes with MWC) and use all the
    defaults ESPECIALY the drive letter (which I think is C). If I remember
    correctly the original (V2.0) installation was very picky about
    the ram disk configuration ESPECIALY the drive letter.
    
    	Ray

    I thought that the rdy drive letter should be ``K''.  (I saw that
    somewhere, but I can't for the life of me remember where).
    
    I agree that it is probably looking for a specific drive as the
    RAM disk, but I doubt it is looking for RDY vs any other RAM disk. 
    Atanyratewottaluse.
    
    Steph

    
         Well I tried the CFLAGS=-VCSD, and that worked.
    
    I also tried to crash the resource editor again, and I got it down
    to this sequence of actions.
    
    create a resource file, and open it up.  create a menu, and open
    it up, and drag the two menu selections "File", and "Desk" to the
    shredder, and the machine hangs.  I guess I should send this off
    to MW.
    
    Bill Powers
    

Using drive K for the RDY RAM disk applies to those of us that use the
SUPRA hard disk utilities with the Atari hard disk.  The reason for K
is that the Supra software, when used with the SH204, seems to double
the number of partitions that are out there.  So A and B are floppies,
C, D, E, and F are hard disk partitions, G, H, I, J are phantom drive
letters that are consumed by the hard disk driver but not used, which
leaves K as the next available drive letter.

(I suspect the reason for this is that the SCSI to ST506 controller in
the SH204 hard disk is capable of driving two hard disks, and the
software doesn't realise that there isn't actually one connected.

    Still, I think that is the letter for which the bozo installation
    program is looking when it trys to figure out if you have a RAM
    disk.  I haven't verified this, but I do recall somewhere in the
    release notes it saying that you should install RDY with drive letter
    K.
    
    Steph

 > (I suspect the reason for this is that the SCSI to ST506 controller in
 > the SH204 hard disk is capable of driving two hard disks, and the
 > software doesn't realise that there isn't actually one connected.
   
    I don't think that's quite it... I think the conclusive piece of
    evidence is when you run Supra's PARK program on an SH204. 
    
    When you do, it will go out an search for all SCSI disks and park
    them. The SH204 responds to SCSI 0, LUN 0 _and_ SCSI 0 LUN 1. So
    I think the reason is that the controller ignores the LUN bit and
    therefore the Supra hard disk software sees *two* disk drives. I
    seriously doubt the controller can handle a second unit...
    				- HBM

Well, the controller in the SH204 is an Adaptec 4000, which is capable
of handling two ST506 devices.

    Hmmm, I wonder why the controller responds on LUN 0 and 1, in that
    case? My Xebec S1410 absolutely does not do that (I don't think
    you *could* do that on the Xebec; there are separate cables for
    unit 0 and unit 1).
    
    Did Atari do something twisted to this hardware? 
    					- HBM

    As Jeff mentioned the controller isn't Atari's it is Adaptek's (4000?).
    However Atari does have there name on the ROM's plugged into the
    controller so it could be they wrote or modified the firmware and
    screwed it up.
    
    	Ray

       Does Mark Williams C support Signal Handling functions?, what
       about statements like:

       int junk = 12;

       Lattice C is woefully lacking in such sophistication and I am
       considering buying another C compiler.

       Thanks

       Permjeet

MWC handles

    int junk=12;

just fine, both as static allocation and as automatics.

There doesn't appear to be any built-in signal handling.  There's no
entry in the lexicon for signal(), gsignal(), or any other related
routines.

You do, however, get setjmp() and longjmp().

    I just received the rev 5.0 manual, it contains docs for MWC, Emacs,
    and the Resource Editor.  They have used better fonts and bolded
    items in the lexicon, the lexicon is still there, however.  They
    have functional sections that point to page numbers in the lexicon
    so that you can see all items related to a particular topic.
    I personally wish they would split out the Emacs and Resource Editor
    into separate manuals, as it has gotten quite thick at this point.
    CSD documentation is still in a separate manual that matches the
    cover size of the MWC manual.  Current version of MWC is 3.0.5.
    
    						-Dave

MWC V3 got a rave review in the Feb ST WORLD (a UK rag) but left the
impression that it cost �130 including the CSD. 
A dealer, Cambridge business SW just told me the CSD is an extra �60 and is not
bundled (list prices). He also told me the CSD was not included in the V3
upgrade package either. UK MWC'ers watch out. 
They sound like DEC $-->� mark ups don't they. 

Steve

In the U.S., MWC is NOT bundled with CSD.  List prices are about $150
for MWC V3, and $60 for CSD.  The upgrade deal from V2 offered CSD at a
discount.  The UK prices sound high, as last I heard 60 of your currency
was about 120 of ours.