CP/M/CPM_CDROM.iso/zsys/simtel20/doc/zas-std.doc

Text File | 1986-09-06 | 5.3 KB | 94 lines

    ZAS (from Echelon)/Z80ASM (from SLR), and the Z System Libraries
        by Richard Conn, 6 September 1986

    Jay Sage's recent comments in the file ZAS-SLR.DOC are understood,
although somewhat in error, and I feel that it is necessary to clarify my
position on the subject.

    First, as Jay admits, there are no errors in the article.  ZAS is
the only assembler (to my knowledge and his) that can assemble the libraries
without error at this time.  Granted, I'll take Jay's word for it that five
library modules (LUDIR, LUOPEN, LUCLOSE, LUREAD, and LUINIT) can be modified in
a minor way to allow Z80ASM to assemble them.  What Jay doesn't know is that
the new Z3LIB requires all 70+ modules to be edited and reassembled in order to
use the SLR assembler with them.

    Second, Jay is totally wrong and uninformed about my relationship
with Echelon.  I am not an employee of Echelon and have never been an
employee of Echelon.  I receive royalty checks from Echelon for the sale
of my books and software and I work closely with them.  The sale of ZAS
has no impact whatsoever on my income.  Obviously, the sale of the libraries
does, since the libraries constitute a product line of which I am the author.
I really resent Jay's insinuations and feel they reflect very poorly on him.

    Third, ZAS is the only assembler I use today.  I use it for the
following reasons: (1) it meets my needs, (2) it represents a standard
language that Echelon and I have some influence on, (3) it is reliable
in the way I use it, and (4) it is supported.  I have been an advocate of
Ada for many years now, and the reasons for my love of Ada include the same
reasons given in the previous sentence (with the exception that I don't
have as extensive influence on the development of Ada as I do of ZAS).  I
have seen the benefits of having a standard language and am completely sold
on them.  Among many other reasons, having a standard language like ZAS
allows us to change the language definition as our needs change, and I
definitely have such changes in mind for the future.

    Fourth, I have nothing whatsoever against SLR or any other
company or its products.  I have heard others say that the SLR tool is
a fine tool, and I have no reason to doubt such a statement.  I have
never used the SLR Z80ASM tool, but this may change since SLR contacted
me and wanted to send me a copy.

    Fifth, we are not at an impass.  Taking a lesson from the Ada
community, we see Ada as a standard language with over 50 different compilers
for it.  All of these compilers implement the same language, which means
that there are no subsets or supersets, and I can write an Ada program on
any computer using any one of these compilers and port this program to
any other computer using any other of these compilers.  Porting the program
amounts to placing the source code on the target system, compiling, and
running.  No change to the source code at all.  But these compilers are not
all identical.  Some are faster than others, some generate more efficient
code than others.

    I want to see the same thing happen in the Z System community.
Any source code program can be ported to any Z System machine and assembled
with the standard assembly language.  This was my goal in standardizing on
ZAS from the beginning.  Echelon will soon be offering an implementation of
C, which I haven't seen yet, but if it meets the four requirements outlined
above, I imagine that I will adopt it in the same way.

    This action does not close the Z System market in any way, just like
Ada did not close the compiler market.  The vendors who wanted a piece of
the Ada action simply (actually, after enormous investments) marketed their
own Ada compilers which were validated.  Validation meant that each compiler
was approved by the US Government Ada Joint Program Office after passing
through a suite of over 4000 tests to assure that it compiled Ada programs
with no supersets or subsets.  This test suite was not exhaustive, and some
minor differences exist in the compilers, but the test suite is under
constant revision to make it progressively better.

    Echelon supports something called the "Z Team", which is a
team of people developing products for the Z System.  The authors of ZAS,
DSD, ZDM, the new C compiler, etc., as well as myself are on this team.
We receive our own mailings from Echelon as a team and are kept up to
date with each other's activities.  We also receive internal data on what
Echelon is up to.  I understand that Echelon and SLR, which is the subject
of this particular message, discussed the possibility of SLR joining the
Z team (ie, Echelon carrying their product), but an agreement was
not reached.  The Z Team works well together overall.

    If SLR or any other company wants to join in Echelon's adventure
with the Z System, there is no reason that yet another team, one concerned
with the Z System standard language (which is now ZAS only) and other
details of the Z System development, can be formed.  It is not appropriate
to use the Echelon Team for this purpose, since companies that may be
competators of Echelon may be involved.  The Z System as a standard
goes beyond specific companies.

    With a standard language, call it ZA, then ZAS and Z80ASM could
become products which compete with each other fairly and we could still
have ONE language for the Z System.  One language is what I want, and
I don't care if it is just ZAS or a group of assemblers made by a group
of companies.