home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / cpm / utils / asmutl / zas-slr.dqc / ZAS-SLR.DOC
Text File  |  1986-09-05  |  7KB  |  110 lines
  1.                 ASSEMBLING SYSLIB WITH ZAS AND Z80ASM (SLR)
  2.  
  3.                                   Jay Sage
  4.                              September 4, 1986
  5.  
  6.  
  7.      I was moved to write these comments after reading Richard Conn's
  8. article on the libraries (SYSLIB, Z3LIB, and VLIB) in Micro/Systems Journal. 
  9. In that article he states that ZAS is the only assembler that is capable of
  10. assembling the new version 3.6 release of SYSLIB.  This statement seemed
  11. both odd and self-serving, odd because ZAS is always promoted as being
  12. compatible with other standard assemblers and self-serving because Conn is
  13. now an employee of Echelon, which distributes ZAS.  I began to do a little
  14. investigating.
  15.  
  16.      Please understand that I am generally a strong supporter of Echelon,
  17. the company marketing the Z-System and its support programs.  They are, I
  18. believe, the last hope for 8-bit CP/M-type computers, and we should support
  19. them by buying their products and encouraging our friends to do the same. 
  20. However, ZAS has been a sticking point for me.  I formed a less than
  21. enthusiastic opinion of ZAS at the beginning and tried to help the author
  22. make an honest Z-System program out of it.  Unfortunately, its subsequent
  23. development has done nothing to change my original opinion (more on that
  24. below).  Once the superbly written, high performance assembly-language tools
  25. from SLR Systems became available at a comparable (slightly higher) price, I
  26. saw no reason to settle for the mediocrity of ZAS.  If Conn had said in the
  27. article that the SYSLIB source was written to be assembled using ZAS and
  28. might require slight modifications for other assemblers, I would not be
  29. writing this comment.
  30.  
  31.      I found it hard to believe that Z80ASM would have any significant
  32. problem assembling SYSLIB, so I gave it a try.  The complete assembly of 189
  33. source modules to Microsoft-format REL files took only 11 minutes and 25
  34. seconds on my Ampro floppy-based system, an average of 3.6 seconds per
  35. module (considering the tremendous disk thrashing required to read 189
  36. source files and write 189 REL files, things would have been much faster
  37. with a hard disk).
  38.  
  39.      It turned out that very strictly speaking Conn was right.  There were
  40. five files, the ones dealing with library management (SLUDIR, SLUOPEN,
  41. SLUCLOSE, SLUREAD, and SLUINIT), that produced error messages.  The reason
  42. was their use of ZAS's idiosyncratic ".IN" insert pseudo-op.  If one spends
  43. a moment with a text editor and changes the five instances of ".IN" to
  44. ".INCLUDE", then Z80ASM works beautifully.  Knowing Steve Russell of SLR, I
  45. would not be surprised if the next version of Z80ASM recognizes the ".IN"
  46. pseudo-op.  It already tolerates ZAS's peculiar requirement of square
  47. brackets where other assemblers use normal parentheses.  Changing ".IN" to
  48. "MACLIB" and putting in the ".Z80" directives might even make M80 work (I
  49. did not try that).  If anyone reading Conn's comment thought that he should
  50. buy ZAS just to be able to work with the SYSLIB source code, he was
  51. seriously misled.  I am sure that almost any assembler using Zilog mnemonics
  52. can be made to work with very little effort.  Since the code appears to use
  53. no Zilog-only instructions, one could probably even convert the source back
  54. to the Intel mnemonics in which Conn wrote the original routines and use an
  55. Intel assembler.
  56.  
  57.      Having gone through the assembly process with Z80ASM, I was now curious
  58. to see how ZAS would perform.  I got out a copy of ZAS version 2.3.  Since
  59. ZAS does not support internal script files and multiple assemblies as Z80ASM
  60. does, I prepared a ZEX script file to perform the task.  At first I wrote
  61. the script to invoke ZAS for each module.  Then it occurred to me that it
  62. was unfair to force ZAS to reload for each module when Z80ASM only had to
  63. load once.  So I decided to use the ZCPR "GO" command for all but the first
  64. module.
  65.  
  66.     For some reason I decided first to make sure that ZAS could be rerun
  67. using "GO", as Z-System programs generally should.  I tried it manually on a
  68. pair of files with the command line "ZAS FILE1;GO FILE2".  It seemed to work
  69. fine.  I ended up with two appropriately named REL files, but something
  70. about the ZAS output message made me suspicious -- both files were reported
  71. as having the same number of lines, symbols, etc.  Sure enough -- ZAS messed
  72. up.  It gave the appearance of working but in fact did not, the worst kind
  73. of failure.
  74.  
  75.      I don't know exactly what ZAS is doing, since the second output REL
  76. file did not correspond to either the second or the first source file.  One
  77. thing is for sure.  The author of ZAS still does not fully understand the
  78. principles of Z-System programming.  [My first disillusionment with ZAS came
  79. when I tried for many months to get the author to make it support the ZCPR3
  80. program error flag (I even sent the code to do it).  Steve Russell grasped
  81. the principle immediately and implemented it quickly and correctly; he even
  82. made the logical extensions of the concept to CP/M3 (set CP/M3 error flag)
  83. and CP/M2.2 (kill $$$.SUB submit file).]  ZAS apparently relies on the
  84. initial loading of ZAS.COM from disk to initialize some data space. 
  85. Programs that are to work under the "GO" command must, obviously, perform
  86. all required initializations in code.  Otherwise the buffers, flags, and
  87. file control blocks will not necessarily be in their initialized state when
  88. the program is rerun using "GO".
  89.  
  90.      With a ZEX script that reloaded ZAS for each assembly (I had no
  91. choice), ZAS took 43 minutes and 30 seconds to assemble SYSLIB, nearly four
  92. times as long as Z80ASM.  Carrying out the five source changes to make
  93. SYSLIB compatible with other assemblers, including Z80ASM, would take much
  94. less than the 22-minute time difference.
  95.  
  96.      One final note on the SYSLIB code itself.  There are some unfortunate
  97. inconsistencies in the code due to reliance on the truncated external
  98. references of the Microsoft REL format.  The SLR assemblers can optionally
  99. generate special SLR-format REL files (only the SLR linker can process
  100. these) that, among other advantages, support 16-character external names. 
  101. When assembling SYSLIB to SLR-format REL files, however, one discovers that
  102. the external and internal names of some routines in SYSLIB are not
  103. consistent.  The module S0FILEIO.Z80 makes reference to the externals
  104. "FI$CLOSE" and "FO$CLOSE".  However, the module SFILEIO, which defines these
  105. references, specifies the public names as "FI$CLOS" and "FO$CLOS".  With
  106. Microsoft truncation of externals to 6 or 7 characters (I don't know which
  107. ZAS does), these are equivalent.  In making the SLR versions of the
  108. libraries (SYSSLR.REL, Z3SLR.REL, and VSLR.REL), I had to correct these
  109. inconsistencies.
  110.