[net.micro] Review

vestal (03/31/83)

A few months ago I bought a Z80+CP/M system to do program development
    
    
    
    
on (because this corresponds to the available market.  Someone
told me the largest CP/M user-base, in terms of hardware, was
Apple + CP/M card -- any hard data out there?)  Anyway, I chose
Pascal (C fans please communiate to me in private).  I chose
Pascal/MT+... 

Why did I choose Pascal/MT+ ?
   1) Of the compilers I was aware of (Pascal/Z, Whitesmith's
      C preprocessor) it alone claimed to implement the full
      ISO standard.
   2) Even the benchmarks published by the Pascal/Z people
      (Ithaca Intersystems) admit that MT+ has faster
      floating point, which I thought would matter to me
      in my intended application.  Two notes here:
      A)  My intended application was numerical; in fact,
          around 50% of real execution time is spend reading
          overlays.
      B)  MT+ allows easy interface to the AMD 9511 Floating
          Point chip.  For non-overlayed programs which are
          intensively computational, this could make a real
          difference.

This isn't intended to be a comparison between Pascal compilers,
since I've only used one (on microprocessors).  It simply
presents a list of my beefs (which are admittedly colored by
years of mainframe use).

PRO:
    1) While I have only run 15,000 lines or so of code through
       the compiler, I haven't uncovered a bug in code generation
       yet.  I have discovered a few in mainframe compilers, so
       I commend MT+; on the other hand, I haven't really given
       it much of a shakedown yet.

CON:
    2) Pascal/MT+ claims to compile to both 8080 and Z80 
       architectures: there is a "z" compiler option to
       generate Z80 code.  I've just compiled three modules
       (total 1523 source lines, selected from applications to
       be pointer/data-structure intensive, numerical intensive,
       and part of a recursive-decent parser) where the 8080
       code is 11485 bytes and the Z80 code is 11483 bytes.
       This is an 8080 compiler!  The benchmark data given
       in Ithaca Intersystem's "The Facts About Pascal" indicate
       their compiler can produce code which averages about 75%
       the space of MT+.  I gather Pascal/Z was written for Z80's.

    3) MT+ comes with an optional Speed Programming Package (SPP).
       I got the false impression, after reading the MT+ hype
       and working on an early UCSD system, that the two were
       remotely related.  Well, of course MT+ doesn't have that
       kind of support in SPP.  Nevertheless, I have some bitches
       with SPP in it's own right:
       A) It's an in-core editor; files are limited to around
          500 lines on a 64K system.
       B) SPP can create files it can't read.  This seems to
          be due to the way it reads/writes files in blocks.
          If you "append" text into that last block, SPP will
          will do fine and write the file.  Unfortunately, it
          seems to sense EOF before that last block, and refuse
          to edit the file.  (Fix:  edit a new file and ^Q
          Y)ank the old file.  Yank seems to read characters,
          not blocks.)
       C) If you exceed SPP's memory buffer while typing, the
          whole thing hangs.  Very frustrating after you've
          added those last few hours of comments.  It all
          goes down the tubes.  Rule: when near memory buffer
          exhaustion, ^Q and check remaining space often.
       D) SPP incorporates a syntax checker.  MT+ supports
          modules and the (*$I *) include option.  Due to the
          limited editor space, EVERY program includes files.
          The syntax checker doesn't know about includes, so
          every module using them has syntax errors.  MORAL:
          Syncheck is useless.
       E) SPP incorporates a routine which counts the number
          of times a variable reference appears.  This is
          (claimed) to tell you if a variable is declared
          but unused, or used but undeclared, because it's
          # of uses is 1.  With include files (see D), there
          are huge numbers of identifiers which occur only
          once.  Another useless feature.
    
    4) The linker supports overlays.  You must tell the linker
       where the overlay areas begin, the starting addresses
       of global data, etc.  Linking requires two attempts,
       a notepad beside the terminal, and a willings to perform
       hexadecimal addition by hand.
   
    5) 253 procedure (or program body) too long
       Well, what can I say?  I haven't said a word about the
       fact that it takes 30 minutes to compile 5000 lines,
       though I have bitched about not being able to edit
       modules 500 lines long.  This should be chalked up
       as a FLAME -- it IS irritating.

If you've gotten this far, you're interested.  There are some
tricks you can pull during overlay definition and linking, and
the usual stunts diddling with dynamic memory allocation at
run-time if you're curious.  One final bitch:  I got my
software through Discount Software, and it took me over 6
months.  I have no complaints about this.  I DO complain about
the fact that I got my check back two months before they would
tell me it had been cashed, and every time I called them it
was a different story! (shipped last week... we'll ship it
next week... we don't have your order on file... we'll
have it in stock in a week...   sigh!!!!)
Stephen Vestal, Ab.D.
a.k.a.   The Acme Computer Company
...decvax!uw-beaver!vestal
VESTAL@WASHINGTON