Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

29-Sep-83 12:27:32-PDT,4018;000000000001
Mail-From: KLH created at 29-Sep-83 12:27:31
Date: Thu 29 Sep 83 12:27:30-PDT
From: Ken Harrenstien <KLH@SRI-NIC>
Subject: Re: Some questions
To: MRC@SU-SCORE
cc: KLH@SRI-NIC
In-Reply-To: Message from "Mark Crispin <MRC@SU-SCORE.ARPA>" of Thu 29 Sep 83 11:49:17-PDT

	.INSRT libraries should default to (in order) to device MID:, UNV:,
	and SYS: on both TOPS-10 and TOPS-20.  WAITS should use SYS:.

I was thinking of MIDAS: but MID: is fine especially if it is already
in use.

	Yes, CCL doesn't work.  Either use the TOPS-10 TMPCOR UUO (which will
	load in PA1050, ugh) or learn how the PRARG% JSYS works.  FAIL uses PRARG%
	so you might want to look at FAIL's code.

I did look at how the EXEC sets PRARG% but it is hard to understand; a
pointer to a program that reads it is exactly what I needed.  I'll look at
FAIL.

	Bug: the command "R MIDAS" attempts to assemble MIDAS.

Good news: not any more it doesn't!

	Bug: MIDAS does not write out the system symbol table along with the
	program's.  RMS thinks this is the right thing, but DEC DDT disagrees and
	is quite unlikely to change due to its limited address space -- every time
	a bugfix is inserted something has to be rewritten or removed!  The answer
	is not "use IDDT"; that translates into "don't use MIDAS".  It is alright
	to do what MACRO does, e.g. just write out the system symbols which the
	program actually uses.

If it is really OK to only write out the symbols that are used, then I have
no problems with that.  The thing to avoid is a full-scale dump of MONSYM!
What makes this hard (and which may be why RMS avoided it) is that I don't
think there is any bit in the symtab which says "this symbol has been
referenced".  An easy temporary hack would be to just write out the JSYS
definitions, if this would help.
(I wish DEC would support IDDT, it is so obviously the right thing except
for monitor DDT... sigh!)

     MIDAS still doesn't write usable listing or CREF files.  Sometimes
	@'s limitations are intolerable.  It should write output for DEC CREF,
	and some thought should be given to listing control.  FAIL and especially
	MACRO does much better.  This is especially the case when using the various
	structured programming macros.  .DIRECTIVE FLBLST is especially useful to
	have implemented.

Yes.

      MIDAS should understand universal files, or the procedures for updating
	MIDAS should be made clearer.  It is rather a crock that you have to rebuild
	MIDAS every time MONSYM or MACSYM changes.

Understanding UNVs is a major undertaking.  Creating a MIDAS-format UNV
feature sounds a lot more interesting and efficient.  It would also be
something of an undertaking too, though.  At any rate I agree it needs
improvement.  Insofar as building MIDAS goes, I think I have improved
considerably on the documentation and setup for this in the latest
version; that should kill most of the common "How do I build this thing?"
messages to BUG-MIDAS.

     It is a major limitation of MIDAS that it does not support PSECTs or
	Polish expressions.  That's why I've pretty much abandoned programming in
	MIDAS; most of my stuff uses PSECTs.

From what I can understand from the MACRO doc, PSECTs are doable as macros,
unless you are trying to get the loader to do something funny.  Can you tell
me what the features are that are needed?  Re polish expressions, I think
the main problem is that the DEC REL format was not well understood at the
time the MIDAS code was hacked; there is certainly this incredibly complex
set of polish hacking stuff for STINK.  So it may be easy, maybe not.

     It is possible that MIDAS doesn't run on TOPS-20 as well as it could.

MIDAS uses PMAP for input, but SOUT for output.  Since the major job
of MIDAS is input, and output is buffered, this doesn't seem to be
any problem.  I don't notice any difference in pass1 and pass2 time
although it might be interesting to measure it if you are really
worried.
-------
29-Sep-83 13:17:17-PDT,3844;000000000001
Return-Path: <MRC@SU-SCORE.ARPA>
Received: from SU-SCORE.ARPA by SRI-NIC with TCP; Thu 29 Sep 83 13:17:11-PDT
Date: Thu 29 Sep 83 13:16:36-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: Some questions
To: KLH@SRI-NIC.ARPA
In-Reply-To: Message from "Ken Harrenstien <KLH@SRI-NIC>" of Thu 29 Sep 83 12:28:44-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     I don't know if MID: is defined or not, but the DEC
convention is to only use 3-character logical names for "official
logical names."  Among other things it is TOPS-10 compatable.  I
suspect there is a TOPS-10 definition for it.

     I'll warn you that FAIL's code is rather ugly.  Somehow it
is very fast though; it makes MIDAS look sick.  Even so, Stanford
has pretty much abandoned FAIL; the TOPS-20 world here uses MACRO
almost exclusively although a few older programs are in FAIL.  No
new stuff is done in FAIL that I can think of.  Of course, the
WAITS world is still tied to FAIL.

     It would probably be better if there could be a bit added in
the symtab for "this symbol has been referenced."  The JSYS
definitions would help, but assuredly do not suffice.

     IDDT would need quite a bit of work to be acceptable to DEC
or most other sites for that matter.  I doubt IDDT supports
extended addressing, and its command language is still quite
different from DEC DDT.  A much better solution would be to
convince DEC to fix up DEC DDT to run in an IDDT fashion.  Note
that normal DDT is still useful; some programs know how to invoke
or transfer to it.

     One thing that DEC did in 5 to make things more pleasant was
to make the EXEC much smarter in its EXAMINE and DEPOSIT
commands.  A lot of "DDTing" can be done at the EXEC level
without using DDT at all.  Of course, once you get into anything
complicated you need DDT.

     I am glad you're going to fix up MIDAS's ugly listings.

     PSECTs are not doable as macros.  A PSECT is a program
section and in effect is an independant location counter whose
initial value is set at load time.  This difference becomes
significant when you have multiple independent modules, such as
evidenced in the monitor (or for a simpler case, the mailsystem).
PSECTs allow you to organize code into logical program modules
yet lets you define separate areas spread across the different
modules where it is loaded.

     The monitor has a very complicated use of PSECTs.  The
mailsystem is much simpler.  It has five major areas:
 . low core - 20 through 140, assembled absolutely
 . low segment - for DEC relocatable code from MACSYM which does
   not have a PSECT specification, usually just 140 to below 1000
 . PSECT DATA - random data structures, of variable length.
 . PSECT PAGDAT - data allocated on a page basis.
 . PSECT CODE - pure code only

     All of the PSECTs start of page boundaries.  Most of the
modules have entries in all three of these PSECTs although some
(e.g. HSTNAM) are CODE-only.  I can define my data with my code,
but have it go into a place to help the pager allocate memory
efficiently.

     In general, PSECTs are a generalization of the TOPS-10
high-seg low-seg idea, but allowing multiple segments of
arbitrary character to take advantage of what TOPS-20 has to
offer in terms of virtual memory.  When writing large, multi
module programs, PSECTs are almost essential especially when you
have modules such as HSTNAM which are used by many programs (not
just the mailsystem; the new unreleased TELNET and FTP uses it as
well).

     Another advantage of PSECTs is that their addresses are
specified at load time, although a module does have the option of
specifying the initial location of a PSECT for convenience.
-------