Date   : Wed, 26 Jan 1989 12:31:21 EDT
From   : <SAGE@LL.ARPA>
Subject: HLL Access to the Z Environment

Dave Goodman responded to my earlier message on this subject.
 
>> But the present system is really, with all due respect to Jay, a kludge,
>> albeit an ingenious one.  When ZCPR 3.0 was written, the Cp/m world was
>> stuck with the Digital Research bdos, so another way had to found to
>> transfer the ENV address to a transient program.  Z3INS was the answer;
>> and under ZCPR 3.3/3.4 Jay ingeniously converted the original
>> installation system to an auto-install system.
 
>> Now, however, we have alternatives to the Digital Research bdos, and one
>> or the other of these alternatives are probably going to be used on most
>> up to date systems.  We expect to be able use calls such as #27 (return
>> ALLOC address), #31 (return DPB address); what is conceptually different
>> about call #nn (return ENV address)?
 
I thought that this was what I was suggesting.  At the moment there is no
such support in the DOSs.  Adding another full function call, while nice,
may entail too great a penalty in the code.  The new DOSs already have new
function calls to identify themselves, and I was suggesting the possibility
that this new call could be modified to serve as the GETENV function as
well.  This was just a way to keep the code shorter.
 
NZCOM makes it easy to allocate space for an expanded DOS, but doing so
entails risks, since there are quite a number of programs that make use of
the standard sizes defined by Digital Research.  We probably will soon be
playing with DOSs and CCPs that are larger than standard.
 
I realized that few HLLs would allow one to get control of the code before
they obliterate the contents of the HL register pair.  In any case, however,
the patch required to capture the value in HL is quite a lot easier to
implement than one that has to simulate a full Z3 header on the program.  In
fact, it seems almost trivial except for figuring out where to store the
address so the program can find it later.  Perhaps the ENV address could be
put in the word at 101H and the byte at 100H changed to C9H (RET) to prevent
catastrophic reexecution using the GO command.  This would be system
independent (unlike trying to use some area in page 0).  But I don't know
much about the inner structure of HLL programs, so there may be obvious
answers (or problems) that I am ignorant of.
 
I cannot go into any details at this time, but there is a good chance that
sometime this year a version of a popular high level language with integral
support for Z-System features will be released commercially.  If anyone has
any suggestions as to what features they would like to see supported, please
let me know.  Obviously the ENV address will be available.  The next item on
my list was support for DIR: (named directory) references in all file and
directory specifications.  Access to TCAP functions (via a standard Z
library) would be desirable also.  Have I missed any important functions
that must be built into the main compiler code (and could not be handled by
a function library)?  Thanks for any input you can offer.
 
-- Jay Sage
 


End of INFO-CPM Digest
******************************