Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_SRC_3_19910112
-
midas/midas.ideas
There are no other files named midas.ideas in the archive.
This file represents a MIDAS "to-do" list. It contains actual
bug/feature reports gleaned from the BUG-MIDAS transcripts,
and several of these are real bugs which someday need to be fixed.
However, the bulk of this file is just a collection of wild ideas
which have been set down to avoid loss amidst progressive
brain rot (although the ideas themselves may well be symptomatic!)
The canonical location is [MIT-MC] MIDAS;IDEAS > and the version number
should be considered significant. --KLH
Various bugs and requests:
Real bug: On TNX (possibly others too?) trying to specify NUL: to an
.INSRT's "Use what file instead?" question will fail; the GTFDB
to find its length gets an illegal instruction since the JFN
isn't for a real file. Same thing happens with TTY:!!
Real bug: at BAKAR it does an ASHC to perform logical-shift. It seems to
be trying to hack 70-bit values but loses anyway; I cant figure out
what this code wants to do, maybe it is trying to do something
clever for floating point values????
Symptom of this is fact that 777777777777_-1 produces 177...
instead of 3777... but almost any other form of specifying the
first value will win, e.g. <-1>_-1 works, since this avoids
the drop-through in BAKAR to the ASHC. --KLH
Bug: Fix TNX MIDAS to work with PRARG% CCL (V4+ T20)
Provide SEARCH and REQUIRE facility similar to MACRO.
Implement .PSECT and .ENDPS as in MACRO.
Improve listing output.
MRC wants MACRO-type listing control
RSH@MC wants failing conditionals not to show their contents.
Minor quibble: On ITS, nulls in input file are not flushed. On TNX
and DEC they are. MRC has several reasons why it is a bad idea to not
flush nulls on the latter. EAK wants a pseudo to control whether
nulls are flushed or not, so that constructs like ASCIZ foo can be
used on TNX. KLH's conclusion: avoid using nulls, use KEEPSTRUNG
macro syntax, and report any real screw cases.
On TNX, do hair so that output files have same version number as
main input file, unless result would not be highest number.
Perhaps provide a way to specify it, as in FOO.EXE.* _ FOO ?
Someday think about providing access to full filespec components,
either with string vars or something similar, eg .FVERS MAIN,
to get string version of main input file, etc.
For benefit of cruddy DEC DDT, output all used JSYSes and monitor
symbols. This may require an additional symtab entry flag which
indicates whether the symbol has been referenced or not.
Replace HALTs in MIDAS with some better kind of error handling.
Problem is that the JRST 4, can destroy some last-error-context
information on TNX.
Also, perhaps modify TNX version so that JSYS error returns are
caught with ERJMP whenever possible. Add illegal instruction handler
to simulate the ERJMP? This probably implies replacing XJSYS with
something else.
* Allow labels in literals, ditto $., for absolute assemblies as well.
Date: Mon, 17 Oct 1983 07:07 EDT
From: Gail Zacharias <GZ%[email protected]>
Subject: block structure
The following gets a "multiply defined" error:
inqpag==100
.begin hakinq
.scalar inqpag
.end hakinq
[KLH: this happens because scalar/vector share too much code with .GLOBAL
and don't look up the symbol properly. The old construct FOO' does work
correctly. This definitely needs to be fixed up.]
Selected stuff from BUG-MIDAS mail:
RMS@MIT-AI 07/17/78 23:05:39
To: KLH at MIT-AI
By the way, there are several things in my RMAIL file from
you and other people about MIDAS, if you are in the mood to
hack it. One thing that might be doable would be labels
inside literals, by making them save up some sort of reminder
to define the symbol later when the location of the literal is
chosen. Because it can legitimately happen that literals
which are distinct on pass1 collapse on pass 2, it would be
necessary to detect on pass 2 that the literal contained
a label, and advance the location counter if necessary to
make the label match up with its pass 1 value. If you had
to decrement the location counter, that would be an error,:
since that shouldn't ever be necessary, and if it were necessary
it could cause lossage as things are now.
[KLH: I don't think I fully understand the business of
advancing/decrementing loc counter, probably because I
don't yet understand how literals are collapsed.]
The symbol "." will probably still have to refer to the
location outside the literal.
MOON@MIT-AI 03/28/76 17:46:36 Re: Feature MIDAS
To: RMS at MIT-AI
How about IRPM: IRPM dummies:calls considers dummies a list of macro
dummies of various syntaxes and repeatedly scans calls for their values.
Need 2 more macro dummy syntaxes: SYLLABLE and SINGLE CHARACTER.
SYLLABLE should re-read its terminator.
-----------
Date: 16 Jan 1982 0338-PST
From: KLH at SRI-NIC
Subject: .SCALAR doesn't define labels
To: bug-midas at MIT-AI
Is it deliberate that .SCALAR and the equivalent <var>'
construct don't define symbols as labels, but rather
as some form of parameter assignment? The effect of
this is that saying .SCALAR FOO in one part of an
assembly, and .SCALAR FOO in a different part, will
give you NO error message, and who knows where the
references are going to point.
This seems counter-intuitive and this behavior,
as far as I can see, is not described in MIDAS INFO.
Is there some problem with defining those symbols in such
a way that a second occurrence in the SAME pass will
print a multiply-defined warning message?
-------
Date: 17 Jan 1982 1247-PST
From: KLH at SRI-NIC
Subject: Re: .SCALAR doesn't define labels
To: RMS at MIT-AI
cc: bug-midas at MIT-AI
In-Reply-To: Your message of 16-Jan-82 1313-PST
The reason why a second declaration of .SCALAR FOO should be flagged
is the same as the reason why a second label definition should be
flagged; the hacker is probably doing something wrong. It used to
be that FOO' was a convenient way to assign a location for FOO, and
allowing several occurrences of FOO' meant you didn't have to remember
whether you'd already given one (the little ' is hard to spot). But
when using .SCALAR, I think most people (me for sure) think of
it as a better way of saying FOO: 0. It's "better" because it is
a convenient way of lumping all variables into an impure section, and is
a built-in pseudo-op so that you don't have to worry about .insrt'ing
this or that library.
The main thing is that I got screwed because I was working on a big
program and adding code here and there, "knowing" that if I goofed and
re-used a symbol for some variable, MIDAS would tell me. It didn't, and
it took me a while to figure out why I was losing and why something kept
getting smashed.
Either MIDAS should flag multiple .SCALARs, or the INFO doc should
have an explicit note about the way it behaves. If the doc had said
something, I might still think it was the wrong thing to do, but
I won't be so annoyed and I won't have sent a bug-midas message.
-------
Date: 12 August 1980 04:46-EDT
From: Ken Harrenstien <KLH at MIT-AI>
To: JoSH at RUTGERS
cc: BUG-MIDAS at MIT-AI
Date: 31 Jul 1980 0048-EDT
From: JoSH <JoSH at RUTGERS>
is there any way to prevent midas' printing the constants areas when
it finishes? I mean the double column of addresses it dumps on the
tty. I have lots of these (to keep references on the same page) so it
spits a long list at me which is most annoying. I would prefer still
to see the rest of the stuff (ie run time etc).
-------
No. I sympathize, though; for certain programs like CRTSTY this is
pretty bad. Rather than introduce a new pseudo, anyone object
to merely printing the (1) # of constants areas, and (2) total # of wds
used by these areas? If a programmer really needed to know the
locations, a simple typeout macro would do it.
---------
Date: 12 Aug 1980 0204-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: constants area printing
To: JoSH at RUTGERS
cc: Bug-MIDAS at MIT-AI
Actually, if MIDAS is invoked with a CCL start then there is no problem.
It's just that nobody has fixed MIDAS to work with CCL in release 3/4.
-------
MOON@MIT-MC 05/16/80 22:29:26
To: (BUG MIDAS) at MIT-MC
The enclosed program assembles incorrectly; it was about the simplest case
I could find that did. The bug is that the JRST is assembled before the
POP rather than after. This broke the mailer; I will change Comsat to
rplace the ? with a carriage return, which assembles correctly.
title test
define foo (list)
push 1,2
bar!list
pop 1,2
termin
define bar (list)
termin
test: jumple 3,[foo (zot) ? jrst zoo ]
zoo: end
----------
GSB@MIT-ML 08/29/79 17:06:40
To: (BUG MIDAS) at MIT-ML
Why ain't ..SRND & ..RRND defined?? (..RJCL etc are.)
[KLH: why not put all these BREAK 12, symbols into the ITS symbol table
too, instead of updating them in the MIDAS symtab? Not very many
of them.]
JONL@MIT-MC 06/05/79 10:18:45
To: (BUG MIDAS) at MIT-MC
The .FASL option does not recogize vertical-bar as a symbol quoter,
while it does recognize slash as a character quoter.
Date: Thursday, 17 May 1979 15:02-EDT
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: bug-midas at MIT-AI
Subject: feature
It'd be really nice to have a remainder operator in MIDAS.
Date: 19 MAY 1979 2206-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: EKILLIAN at MIT-AI, (BUG MIDAS) at MIT-AI
Date: 19 May 1979 1626-EDT
From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
If I type
DEFINE FOO #(A,B)
then A and B are made balanced but not evaluated. If I type
DEFINE FOO (#A,B)
then A and B are evaluated, but not balanced. How do I get
both of these options at once?
That is meaningless. You can't have two different ways of parsing
specified.
The only reason I want the arguments balanced is so I can
call the macro with the parenthesized call syntax:
FOO(N,5)
which doesn't work unless A and B are balanced.
-------
I don't think this desire is unreasonable, but it can't be achieved in
any such simple fashion as marking the argument as "both balanced and
evaluated". Evaluated args work by just reading in an expression,
evaluating it. What must be done is to make this do something
reasonable when it comes across an extra unmatched closeparen.
Date: 14 DEC 1978 0420-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: multiply defined bug
To: (BUG MIDAS) at MIT-AI
Yeah, the sequence
foo==1 ? foo==<bar==foo>+1
does the right thing, but
foo==1 ? foo==<bar==:foo>+1
gives a multiply-defined error for FOO.
Date: 21 Nov 1978 1417-PST
From: Klh at SRI-KL (Ken Harrenstien)
Subject: OUTUPD and OUTN1 and NED error on TNX
To: bug-midas at AI
Well, the mysteriousity remains mysterious. The file
AI:KLH;.BOMB > will work OK on ITS, but get a NED (No
END statement) error on TNX. The reason it does this is
that the NED checking logic at NEDCHK tests the variable OUTN1
which is only bumped by the OUTUPD routine, which is only
called by output-format-selecting pseudos such as DECREL and
FASL. DECSAV and SBLK in particular do NOT call it. I
can't figure out what the hell any of it is supposed to mean,
especially since most of this NED-hacking stuff is conditionalized
by A1PSW (pass-1 auto-reassembly hack) which I doubt anything
has ever used for at least 10 years.
(incidentally don't be fooled by the fact that the source file
selects DECSAV format; MIDAS helpfully does an automatic DECREL
selection as part of the pass initialization)
Perhaps a good solution is to set A1PSW==0 for TNX midases.
-------
RWK@MIT-MC 11/10/78 21:45:32
To: (BUG MIDAS) at MIT-MC
The BINPRT info gets all filenames including device as zero, when the input
is from the TTY:
Also, it should clobber DSK: to MC: or ML:, so one can tell what machine
a program was assembled on.
Date: 27 OCT 1978 2317-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG MIDAS) at MIT-AI
The who-line display loses
when .INSRT is done. It shows the page number in the .insrt'ed file correctly
but with the filename of the main file.
EAK@MIT-MC 09/29/78 19:30:34
To: (BUG MIDAS) at MIT-MC
MIDAS should put the filenames of all .INSRT'd files into the binary
information block. If I remember correctly its all setup to take
variable length information so there should be no problem there.
Sometimes the version no.s of some packages are more important than
the main file so this info is needed.
MOON@MIT-MC 09/28/78 21:38:19
To: (BUG MIDAS) at MIT-MC
CC: EAK at MIT-MC
EAK@MIT-MC 09/28/78 18:37:24
To: (BUG TECO) at MIT-MC, (BUG MIDAS) at MIT-MC
CC: MOON at MIT-MC, RWK at MIT-MC
I've figured out why TECO wasn't assembling correctly these days.
The problem is that I assembled it on MC, a KL. TECO wants to
increment various byte pointers so it does:
.AOP IBP,0,XX
which on a KA leaves an incremented byte pointer in .AVAL2. On a
KL, however, an IBP with a nonzero AC is the ADJBP instruction!
Thus it was doing the wrong thing. One solution would be to
use
.AOP IBP,1,XX
and if .AVAL2 is not equal to XX then use it, otherwise use .AVAL1.
Probably it would be better if Midas used AC 0 for assembly-time
instructions, or let the user specify.
I always knew someone would be shafted by the crockish way DEC
put in ADJBP, but I never suspected it would happen in this fashion.
Date: 24 SEP 1978 1930-EDT
From: KLH at MIT-AI (Ken Harrenstien)
To: RWK at MIT-MC
CC: (BUG MIDAS) at MIT-AI
RWK@MIT-MC 09/24/78 16:09:06
To: (BUG MIDAS) at MIT-MC
On ITS, where it is possible to win, MIDAS shouldn't close and
re-open the file between the two passes, but should just position back
to the beginning, so if you've written a > file with a minor change
in between passes you don't have to start MIDAS all over again.
Maybe on other sites the file is closed at EOF, so it may not be possible
to win elsewhere, but that's no reason to lose here....
This might be accomplished for the main file, and perhaps on TNX for
all files, but in general you can't win this way, because .INSRT
files are equally vulnerable to this (exceedingly rare) lossage
and ITS simply can't save anything like a JFN. I've thought about
doing this for TNX just as a means of improving efficiency (with
large PMAP buffers, moderately-sized files would only be read once!) but
gave it up.
Date: 22 Sep 1978 1410-PDT
From: Mark Crispin <MRC at SU-AI>
Subject: Command line scanning
To: Bug-MIDAS at MIT-AI
Tops-20 MIDAS seems to slurp command lines when run manually in the same
losing way as Tenex MIDAS does. How about making it use RDTTY and/or
GTJFN hackery so display stuff (and maybe recognition) will win?
EAK@MIT-AI 09/03/78 16:10:29
To: (BUG MIDAS) at MIT-AI
Why does MIDAS print out "SBLK Encountered", "RIM Encountered", or
"RIM10 Encountered"? And why is there both .SBLK and SBLK? What
is the difference?
Date: 28 Aug 1978 1113-EDT
From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
Subject: .SITE
To: Bug-MIDAS at MIT-AI
Also, how about changing the way .SITE works. It shouldn't take an
argument, it should just return the whole thing like SIXBIT does.
You could use .NTHWRD to be like .SITE n. Also you could then do
.SITE and get the whole thing.
Thus, .SITE would be identical to SIXBIT/SITE-NAME/. If you used it
in an expression the value would be truncated to one word, just like
SIXBIT. If you used it to generate storage words then it would take
as many as necessary, like SIXBIT and ASCII. Finally if you wanted
the effect of .SITE n then you could trivially get it with .NTHWRD.
RG@MIT-AI 08/03/78 01:07:44
To: (BUG MIDAS) at MIT-AI
IT WOULD BE NICE IF $. INSIDE CONSTANTS WORKED IN AN ABSOLUTE ASSEMBLY.
IE IT SHOULD GIVE YOU THE LOCATION IN THE CONSTANTS AREA WHERE THE CURRENT
STORAGE WORD WILL BE PUT.
Date: 2 Aug 1978 2301-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: RG's $. idea
To: Bug-MIDAS at MIT-AI, RG at MIT-AI
I agree completely. FAIL has this feature in relocatable assemblies and
wins just fine with it, and I would think absolute assemblies would be
easier since on pass 2 MIDAS should know where the storage word is going
to be(?).
By the way, is it still true that -<relocatable value> loses with DEC's
LINK? A program of mine needs to compute the number of bytes accumulated
in a buffer from the byte pointer and does a MOVEI AC,-START(PNTR) to get
the number of words to start off with. I ended up making the program an
absolute assembly since it's a Twenex program (so relocatability doesn't
matter!) and it turned out I wanted to do LOCs to start on different pages,
but it would be nice to know if the restriction is still necessary. Or is
it a MIDAS loss?
KLH@MIT-AI 07/23/78 02:26:37
To: (BUG MIDAS) at MIT-AI
By the way, just for the record, the # of symbols that gets printed
out at end of assembly is a lie. For example during assembly of an
ITS verson of MIDAS, the # syms as returned by A.SYMC was 3558 upon
calling PSYMS to punch out the symbols, and 4787 afterwards; apparently
the symbol table compaction/sorting done for SBLK and DECSAV formats
leaves some cruft around. I noticed this when the # syms reported
for various programs suddenly jumped when I began assembling with
DECSAV format.
It's not a crucial bug but can easily be fixed sometime.
It would probably be nice also to print out the # o symbols actually
punched out; for absolute assemblies this is trivial, for relocatable
ones slightly harder I think.
EAK@MIT-MC 07/18/78 22:35:48 Re: MIDAS .SAV output
To: KLH at MIT-MC
Perhaps instead of having lots of pseudos like .DECSAV you want
one pseudo that takes an argument saying which format to use?
EAK@MIT-MC 07/10/78 23:14:42
To: (BUG MIDAS) at MIT-MC
Why does IFNDEF 0 succeed? I would think that no.s would always be
"defined". This was a screw when I used it in a macro which did
something like:
.TTYMAC F
IFNDEF F,[ ... ]
FLAG==F
TERMIN
etc.
Date: 16 Aug 1977 0505-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Bug MIDAS
To: RMS at MIT-AI
MIDAS treats grave accent (`) as question mark, ie, it says new word. I
accidently typed ` when I meant ' and got no message, and in general was
screwed.
-------
Moon@MIT-AI (DLW) 08/04/76 17:28:37
To: BUG-MIDAS at MIT-AI
I'm not sure if this is a bug, but I think it used to work.
IRPW fails to consider tabs preceding semicolon as part of the comment,
and IRP FOO,,[<tab>] IRPs once, with FOO bound to just tab. So the effect
is that a line containing just an indented comment, being picked up
by a whole-line type macro and decommentified by IRPW, appears to
contain something and screws up the macro which is expecting to
IRP over symbols.
Constants problems:
KLH@MIT-MC 03/24/80 02:52:17
To: RMS at MIT-MC
CC: MOON at MIT-MC, (BUG midas) at MIT-AI
Okay, so after several hours of lossage I found that the [0,,U3]
was getting mapped to the U3 in a SYSCAL FOO,[A ? U3 ? U4].
On the second pass this became [x,,U3] so didn7t collapse, and
caused a larger constants area. Apparently, something in
the old NLISTS DID collapse on the second pass but not the first,
so that it all evened out, and never caused an error until
I unknowingly got rid of the literal in NLISTS which saved the world.
The big problem was mostly being completely misguided by
most debugging principles (eg look at changes, assuming
previous stuff was winning).
So... no MIDAS bug in the strict sense. But somehow it seems
there ought to be some kind of help for the poor loser
who is trying to figure out WHERE the constants area actually
becomes bigger and starts losing. If the constants tables
could retain their info from pass 1, it would be easy to
catch funnyness by flagging any places where a literal that
DID formerly collapse DOESN'T do so on the second pass.
If necessary, this could be invoked by a debugging pseudo at
the same time a .SYMTAB declares the constant area sizes.
This might be done as part of label-inside-constant feature,
and is plausible since the constants tables are all set
up for dynamic allocation.
Or maybe a pseudo turning off optimization altogether, just
so that in such cases the program could still be forced to
assemble a working version, even if not the most compact.
Maybe there are simpler hacks that would still help pinpoint
the problem better, but I'm done. Constants lossage is really
a sort of unusual problem since the error is only caught
at a point far removed from the original location; most other
errors will barf instantly and you at least know where it is.
Even if you're not quite sure at the moment how to fix it, you
can ask someone else "why doesn't the code at FOO+5 win?" and
stand a good chance of being helped. But nobody wants to
tangle with a constants problem for the good reason there's
no locality and few clues.
RMS@MIT-AI 03/26/80 04:02:38
To: KLH at MIT-MC
Constants tables can't be saved from pass 1 because they are re-used
when a program contains more than one constants area.
Even if they were saved, it isn't clear how that could be used, since
the values of words in the constants are not the same on pass 2, and
can't even be matched up with the constant words they mapped into on
pass 1! The pass 1 constants data does not supply enough information
to figure out, on pass 2, what the value would have been!
FOO*BAR on pass 1 becomes "0 and don't optimize me". On pass 2 it
will be just a number.
Date: 26 MAR 1980 1427-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: more ideas about constants bug finding
To: RMS at MIT-AI
CC: (BUG MIDAS) at MIT-AI
Well, I wasn't actually thinking of matching up the values,
which is clearly impossible.
Rather the idea is to remember in some fashion what the constants
area size is for each time a constant is seen. That is, you
would identify constants not by their value but by their
place in the sequence of constants seen. If on pass 2 the
n'th constant causes an expansion of the constants area, but
on pass 1 the n'th constant didn't, that's an error, but it
might not be necessary to flag it if the constants area size
at that point is equal to or less than its value on pass 1;
pass2 collapse of literals that were distinct on pass1 might have
saved you. This error would only happen once for each constants
area; it might even be postponed until the constants pseudo is
seen and MIDAS can tell for sure whether something will be screwed
(again, pass2 optimization after the first "error" might have
saved things).
It could be made even simpler by just remembering the sequence
(possibly as a string of 1-bit bytes), although this may have more
danger of getting out of phase and would definitely only be
reported if a larger-on-pass2 error happens.
One alternative (or supplemental) hack might be to let the CONSTA
pseudo take an argument specifying how many extra words to reserve on
pass 1 beyond those needed for the constants seen thus far. Then on
pass 2 MIDAS would ignore the argument and just compare the size this
pass with the total size reserved on pass 1. When it DOES barf, it
should say by how many words the reserved size was exceeded. This
will allow certain obscure pass1-pass2 hacks to win which currently
lose. The error message would in any case provide a little more information
to help track down the problem (or solve it with appropriate extra
allocation). Of course if this feature was requested for a constants
area, the sequential-checking hack may not do what you want, but
could still provide useful information when the size IS exceeded.
One other thing. If lots of constant areas are sprinkled around,
they reduce the scope of errors and even eliminate some (by
flushing optimization). As it happens, the main objection to using
lots of constant areas is not the loss of optimization but the
verbosity of the printout!! I think it would be reasonable to
simply say how many constants areas there were and how large the
total sizes are and what the size of the largest area is.
If a particular constants area is in error, the err message for it
would say where it is and how big it is, which is about the only
time you need to know this thing.
It would be interesting to have a pseudo to disable optimization
altogether and see how much storage was lost. I don't think it
is such a significant factor nowadays as it used to be, except
for moby hacks like ITS.
Small randomnesses:
C-style assignment syntax?
<sym> <op>= <expr> same as <sym> = <sym> <op> <expr>
Allow spaces between <sym> and operators, as in "FOO = 120"? Currently
the op must follow symbol immediately.
Remainder operator: "//"? Develop hooks for multi-char ops,
perhaps add floating point ops as in /$ where $ is a REAL escape!!
There are some ASCII chars that MIDAS doesn't use for anything,
because historically they were unavailable on an uppercase-only teletype.
These are `, |, and ~. ({ and } are now used for certain frobs such
as conditionals). Could think about what to use these chars for...
invent new constructs or whatever. Use for .ESCCHR? (see below re string
ops)
Note one bug report that "`" currently is the same as "?" !!!!
.PUSH/.POP
Two pseudos .PUSH and .POP to hack a stack of values.
Should there be more than one stack?
If more than one, how to define and use them?
.STACK <sym>? ; Establish stack for this symbol (no value)
.PUSH <stk>,<val> ; Push value onto stack (no value)
.POP <stk>, ; Pop & return topmost value from stack
.STKFLS <stk>, ; Reset/clear a stack (no value)
.STKLEN <stk>, ; Return current # objects on stack.
.STKV <stk>,<idx> ; Return indexed value from stack. 0, -1, etc.
Reference to global stack??
.PUSH <val>,<val>,<val> ... (like SCALAR/VECTOR)
.POP <sym>,<sym>...
What sorts of objects can be pushed/popped?
Simple 36-bit values? (absolute, relocatable?)
Strings? Macros? Text?
Symbol defs?
STRINGS:
Introduce a new data type, "strings". These would not
be the same as macros because they would not automatically be
expanded and can be manipulated without regard to contents.
Various pseudos would exist to perform this string manipulation.
Define a string:
Should string values be assignable just like 36-bit words??
Or only moved around by means of pseudos?
foo=="text" ; conflicts with "ch construct.
foo==.string /text/ ; like 36-bit val
.string foo,/text/ ; like DEFINE
If assignable then what happens when operators applied to string?
e.g. foo+str2 = ?
Would be nice to avoid lots of special purpose pseudos but
may have to do lots of special casing otherwise.
Evaluate a string:
When symbol defined as string is seen in a place where it
wants to be evaluated (like all by itself on a line)
treat it like a macro without args/dummies etc?
But if so, must figure how to keep this from happening in
wrong context, eg inside other pseudos that hack string vals.
Perhaps require explicit evaluation (pseudo or syntax) in order
to expand string like macro.
Concatenate two strings:
.CONC resultstr,str1,str2,"this is literal string",str4, ...
Take substring of string:
.SUBSTR <loc>,<len>,resultstr,inputstr
Parse a string: (see FSM)
New macro string arg, noticed by " like [ and \?
EVALUATION ESCAPE
Specify .ESCCHR, -1 normal (no esc), else val of esc char.
Evaluate within ASCIZ-style string args
e.g. ASCIZ "Foo !BAR zap" will eval/expand BAR.
Force re-evaluation?
(eg .STOP passed back to a macro)
MACRO FSM PARSER
Idea here is to allow the facility of truly indefinite loops,
by providing input text directly from the "outside" upper level,
rather than by pre-digesting it into dummies. In theory this will
allow a macro to parse all the rest of the input file, operating as
a somewhat inefficient Finite-State Machine in a manner similar to MIDAS
itself.
Some examples should get the idea across. The counterpart
to IRPC (Indefinite repeat on chars) would be (eg) ZIRPC:
IRP A,,[This is input for the IRPC]
ASCIZ /A/
TERMIN
ZIRPC A
IFSE [A][}] .ISTOP
ASCIZ /A/
TERMIN
This is input for the ZIRPC}
Thus ZIRPx (or IIRPx, etc) would read from the next higher
input level. If found in mainline, it would read stuff from the
mainlne. If found in macro, could either read from the rest of the
macro body, or from the next higher level outside the macro. Sort of
like a ghost IRP that stays around even though the input level has
changed.
IRP's are a little restrictive though, because they
require another level of macro-ing and explicit means of stopping.
More likely, it should be possible to utilize strings for handling
the input, and pseudos will just return string values.
Stuff needed:
Backup facility (one char should be enough)
Evaluative components
Char
Syllable
Field
Word
Macro-arg components
Line
Strung
Balanced
Evaluated
IRP terminators?
Bracket levels?
Specified/default break chars?
MACRO ARG HACKING
The central idea here is to augment flexibility and speed by
providing mechanisms which will NOT expand the dummies of a macro,
but rather return various information about them.
For example, have a pseudo that will return various flags defining
what manner of macro argument a dummy corresponds to. This would
allow a macro to determine for example if an argument was possessed
of brackets, or was a quoted string, or suchlike.
Another example would be a variant of IRPNC that would slurp
stuff out of the argument without requiring that it be completely
expanded at the start. In fact the same string parsing hooks proposed
for STRINGS and FSM could be used here on macro dummies.
MORE MACRO ARG-TYPES etc.
Invent more macro call and argument syntax features,
to handle strings better, etc. etc. blah blah
A lot of this is oriented to:
* making it easier to simulate simple higher-level language
procedure calls. Or does this really want more explicit
support in the vein of .I, .F? Such as IF, THEN, ELSE
and FOR/WHILE constructs?
* Avoiding more screw cases where the "non-intuitive" behavior
of MIDAS macro parsing screws up the erstwhile coder.
Much of this is confusion between IRP and MACRO syntax,
particularly w.r.t. commas.
* Adding more debugging stuff for list output to help puzzle out
more of said non-intuitive behavior.
PARENTHESIZED MACRO CALL CHANGE:
Suggest change in the way parenthesized calls are handled,
such that if a parenthesized call is about to be terminated before all
dummies are accounted for, and this termination is NOT due to a close-char
as could be the case for balanced args -- that is, if termination happens
due to EOL (with or without comment) then under the new regime the macro
call would NOT end, but would ignore the EOL (plus comment), plus any
following whitespace, in its search for the next argument.
This allows macro calls to extend over several lines, without
needing an explicit continuation or interfering with the syntax of any
macro argument. For example:
FOO(A,B,C, ; This is an example of new-style parenthesized
D,E,F, ; call, which can extend over
G,H) ; several lines.
This could be tried out by means of a .MLLIT-style switch.
MACRO ARG: "QUOTESTRING"
Introduce a new option for macro arguments called "quotestring",
as an attribute which can apply to either normal or balanced arguments.
Specified by " in DEFINE line:
" - Turns quotestring ability on and off.
When this attribute is present for a macro arg, parsing is
exactly as usual except that if the first character is a
double-quote (") then the argument is parsed like a "strung"
arg. Whether keepstrung or simple strung is defined by
whether keepstrung syntax was in effect at the time the
macro dummy was defined; if not, default is simple strung.
E.G.
DEFINE FOO ?BAR,"GLUB
Defines macro FOO with two balanced dummies, the latter
of which has the quotestring option specified. If a (")
is seen as the first char of the dummy, it will be parsed
as a simple strung argument.
DEFINE FOO &"&?BAR,GLUB
Just as before, except both dummies have the quotestring
option, which if invoked will act like "keepstrung".
Quotemarks can be included in the string by doubling them.
This matches popular convention and is the same syntax .QMTCH==1 uses.
Proposal is to make this globally useful by making it a convention for
ALL string hacking pseudos (ASCII, SIXBIT, etc) that whenever the delimiter
is doubled, that means to include one instance of that delimiter.
A further extension is to have the quotestring syntax-option enable a
check for EMBEDDED quotemarks anywhere in the text of the macro
argument. If the quotemark is prefixed by a squoze symbol, however,
it would be passed as-is. This is to take care of the block symbol
construct, such as .U"FOO"BAR. This could be made conditional on
.QMTCH, since there would be some screwage anyway if FAIL-style syntax
wasn't used for the "CH construct (ie use "CH", with exactly the same
doubling convention to quote). Note that the construct FOO" isn't
crucial because one can use the .GLOBAL pseudo to do the same thing,
just as .SCALAR is better than FOO'.
One screw, it won't work trivially to just slap quotemarks around
some text that was acquired from a simple-strung type of quotedstring,
because any quotemarks inside the string will no longer be doubled.
This can be avoided with keepstrung syntax, but it really sounds as if
string variables are wanted here.
Some comments about S-1 assembler with interesting sidelights on MIDAS:
Most from GLS, perhaps initial stuff from JBR:
------------------------------------------------------------------
FASM improvements:
[KLH: Only those of possible relevance to MIDAS are included here]
Make sure multiple flag bits can't be set for a symbol.
[KLH: Hmm, what's this?]
Finish cleaning up FASM documentation. Think about micros as macros
that are expanded when defined. Think about SAIL type loops at assembly time.
[KLH: Micros? SAIL-type loops?]
Think about concatenation character problem in case of self-redefining macro.
[KLH: e.g.?]
Local symbols (1$:, etc.)
[KLH: Yes, yes, would be nice...]
Arithmetic FOR
[KLH: is this really needed, considering that REPEAT has .RPCNT to
do clever things with?]
26-Jan-79 1822 GLS FASM and `
To: JBR at SU-AI
CC: GLS at SU-AI
The more I think about it, the more I believe that `` ought to
be replaced by a parenthesizing pair such as {~, so that the
construct can be nested. Moreover, there ought to be a quoting
character for getting { ~ ` \ into places without having them
take effect.
As an (admittedly poor) example of why one might want this,
suppose one wanted to have a number of macros MAC1, MAC2,
etc. which behaved as gensymmers in the manner of the FOO`MAC`:
example in the FASM manual, so that one could have independent
gensymmers for some reason. Then one might want to write
FOO`MAC`X-2``
butt this wouldn't work because as soon as FOO`MAC` was parsed
the evaluation of MAC would begin (and FOO`\MAC\`X-2`` doesn't
work either, as I understand it).
By the way, does the REPEAT pseudo provide no .RPCNT?
16-Mar-78 2119 FTP:GLS at MIT-MC (Guy L. Steele, Jr.) Macros
Date: 17 MAR 1978 0020-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: Macros
To: JBR at SU-AI
CC: GLS at MIT-MC
Well, I have been pretty happy with MIDAS. I would say that relative
to many other macro processors I have seen, it fits in pretty comfortably
with the language in which it is embedded. I do have a list of criticisms,
though, and I have also considered FAIL, MACRO-10, and MACRO-11 as sources
of ideas.
The biggest problem with MIDAS is that macros and IRPs have completely
different rules; they should be unified. Macro args surrounded by []
take no following comma in MIDAS, whereas IRP args do take a comma.
[KLH: Yeah! Yeah! ]
Also, rather than having different IRP names (IRPC, IRPS, ...),
each IRP variable should be able to have any macro-arg syntax specifying
how much to gobble. One advantage is that a single IRP loop can
IRP over different kinds of things; e.g. one can IRP in parallel
over both a list of symbols and a string of characters.
Conversely, anything that is an IRP mode should be a macro-arg syntax;
thus one could have macro-args which gobbled just one character, etc.
It would be nice to have a kind of IRP (which MIDAS lacks) which
would IRP over tokens, where a token is a squoze symbol or an operator
(IRPS doesn't let you see all the operators, just one after each
symbol).
[KLH: I like those ideas. ]
FAIL seems to have a neat way to allow continuation lines in macro calls.
It seems also to have a drawback, if I understand it correctly:
if you enclose an argument in braces in order to include a comma
in the argument, does FAIL indeed expect to find another arg on
the next line? I.e. how does one omit all the arguments after a braced
argument? Line continuation seems a good idea (even more important for
continuation of IRPs, which would look much better with each loop spec om
its own line), but some other convention should be used, such as
a special character used solely to mark this.
[KLH: Would my idea for continuation of parenthesized calls fit
the bill here?]
I have found the ability in MIDAS to specify a default value for
an omitted argument valuable, but I wish that the default value for
an argument could refer to previous arguments:
DEFINE FOO A,B=[A],C=[SON OF A]
...TERMIN
FOO BARF ;same as FOO BARF,BARF,SON OF BARF
FOO BARF,BAZ ;same as FOO BARF,BAZ,SON OF BARF
[KLH: I don't think this should be too difficult to do, but making
it work right for all the special cases (like keyword args) could
be a real pain.]
One issue regarding handling of text is that there are certain contexts
(ASCIZ strings, e.g.) where it can be very hard to get something
substituted in, in MIDAS, because you need to evoke evaluation.
MIDAS has a \ feature, but it insists on finding a numeric value.
Evidently the equivalent thing in FAIL does not have this drawback?
KLH has been thinking about putting a "string variable" feature
into MIDAS. I know that IBM 360 Assembler H also has such a feature.
This can be tricky, though; in particular, if you try to implement
macros using such string variables rather than substitutions, certain
embarassing "funarg problems" can arise.
[KLH: What about if strings are not really macros, although they can
be expanded as necessary, i.e. never take any args and have no
dummies? Would still require some means of forcing evaluation,
perhaps similar to the way FASM does it with a special character,
perhaps only effective in text-string pseudos like ASCIZ.
Would like more comments about that.]
As far as delimiting macro and IRP bodies does, I marginally prefer
the TERMIN convention to using {~ or <>, solely because in the common
case of wanting to generate code-like looking stuff having a { hang
at the end of the DEFINE line or at the beginning of the first line
of text looks pretty yechhy. Also, for various hacks it is useful
to have the [] of conditionals and the TERMIN guys mutually
transparent. (However, TERMIN has proved to be an unfortunate
syllable, as comments abouts "terminals" and "terminating" have introduced
many bugs. A better word should be chosen, preferably not a prefix
of any English word, if a TERMIN-likee syntax is used.)
On the other hand, MACRO-11 uses TERMIN-like syntax for just
about everything, and it gets completely ridiculous. Also,
it is harder to control exactly what characters get generated.
(MIDAS, and FAIL I think, are very good about letting you
control very precisely what characters are generated and how
characters get swallowed.)
[KLH: MIDAS is a little better now, it will point out funny-looking
cases of TERMIN, so it is a lot more obvious when one is being
screwed. It would be possible to have both syntaxes, by checking
for an open-brace or open-broket as the last thing (other than
comment) on the DEFINE line, and then going into a mode that
ends the definition when a balanced close char is seen; otherwise,
normal TERMIN is used. Certainly it would be trivial to just adopt
a substitute for TERMIN, by making the new name an option.]
Some assembler issues not directly related to macros:
I've often wished for a "newio" feature in MIDAS; i.e. the ability to
ask MIDAS to allocate me an I/O channel and open a file, so
that at assembly time I can PRINTX information to different files.
These could be used for several purposes, not the least of which
re-inserting later in the assembly (lots easier than the remote macro
hack).
[KLH: Perhaps efficient strings would largely obviate the desire for
such I/O? Anyway, providing such an I/O feature wouldn't be difficult
at all, just have to figure out a reasonable set of pseudos and operations.]
Perhaps more important, I stringly recommend that there not be a 6-character
limit on symbols. Systems are getting big enough now that thinking
up new unique meaningful menmonic names is getting to be a pain.
In particular, since names of widely-used bits, etc. are being given
universal symbolic names nowadays, one must be careeful
not to conflict with them; so when writing MacLISP I cannot name
my bits the same way ITS does. Some conventions about this are in order;
in particular note that regular naming conventions allows the ITS DDT
"bit typeout mode" (? command). Anyway, if arbitrary-length names
are not feasible, I recommend ten to twelve characters.
Well, I guess that'S all I can think of. Hope this helps.
27-Mar-78 2102 GLS at MIT-MC (Guy L. Steele, Jr.) Macro assembler, long names, etc.
Date: 28 MAR 1978 0002-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: Macro assembler, long names, etc.
To: jbr at SU-AI
CC: GLS at MIT-MC
After some consideration, it seems to me that maybe six-character
names would be enough, if MIDAS-type block structure could
be used (I say MIDAS-type as opposed to FAIL-type, because the
former allows one to refer to qualified identifiers such as
FOO"BAR"BAZ meaning BAZ in block BAR in block FOO - a sort of
pathname). If it were legitimate to use the same name
for both a block and a location, then instead of calling
[KLH: True for MIDAS.]
bits in the TTYSTS word %TSFOO, %TSBAR, etc. it might be
acceptable to call then TTYSTS"FOO, TTYSTS"BAR; one could also
introduce the convention that TTYSTS"<FOO+BAR> would work
(in general, an expression after an incomplete
pathname would use that prefix for all symbols in the expression).
Very important, hoowever, is that thhe debugger let you use the
same notation! I think MIDAS block structure goes unused largely because
DDT is very clumsy to use on block structure. Oh well,
end of random thought. -Quux
[KLH: There is a note in the MIDAS doc saying not to use block
structure for anything but .insrt'able libraries. I'm not sure
exactly what philosophy is being advocated there, or what might
mitigate against using block structure for bit flags as suggested above.]
Stuff from Earl Killian...
------------------------------------------------------------------
A trivial thing I've wanted is a remainder operator (yes, MIDAS
currently doesn't have one!).
[KLH: what character or syntax to use?]
Also, I know someone that wanted .RADIX 16,N to work, but I couldn't
care less.
[KLH: I think it would be nice, but would require some re-doing of the
way numbers/symbols are parsed. This re-do could potentially
even speed things up, however. If done, it should be merged in with
ability to understand the <n>B<m> construct that MACRO is so fond of.
Syntax would be 0<hex digits> or 0<hex>H. This could be made general,
as in <required digits>[<possible hex digits>][<base specifier such as
".", "B", "D", "H">]
]
String variables would be nice, but...
[KLH: see other parts of this file.]
There are some ideas on SECTIONs that would be nice to think out
and implement, but they're as yet still unthought out.
[KLH: e.g.?]
12 character names would be nicer than 6!
[KLH: I think main problem is that everything else in the world expects
6 chars, like DDT, Loaders, etc. Also would make things somewhat slower,
SYM2 ac needs to be allocated, etc. Probably much harder than string
vars or labels in literals or almost anything else. You do know that MIDAS
will accept n-length names but only distinguishes on first 6 chars. Would
it be a win if it distinguished more than 6, but continued to only pass
6 to the outside world? ]
Making it run twice as fast wouldn't bother me at all, though
it's probably impossible.
[KLH: You could try writing your code for 1-pass assemblies, like
FAIL is set up for.]
You could have it produce PDUMP (SSAVE on TNX) files directly.
[KLH: Is possible but pain seems out of proportion to benefits.
(However RMS didn't like .DECSAV either.) Also, is there any way to
accomplish equivalent for DEC system? Probably the easiest way to do
this is to assemble for absolute using a temporary file, then when all
done, LOAD/GET that file into an inferior and PDUMP/SAVE it into right
output filename. This doesn't let you use cute pseudos that examine
a location in the output assembled thus far, but seems a lot easier.]
You could make .I and .F generate better code, add IF-THEN-ELSE,
WHILE-DO, and generally make it into a compiler.
[KLH: I've thought about this, though mainly in the vein of beefing
up macro capabilities to the point of doing it reasonably via macros.
If there are some simple things MIDAS could do to provide a great return
for the investment...]
Floating point arithmetic.
[KLH: This can currently be done with .OP, as in <.OP FMPR FOO,BAR>, so
is not crucial; I don't think about it. But if some good syntax were
proposed...]
MACRO comparison
As a source of ideas, this section tries to list things that
MACRO has, which MIDAS doesn't.
As a start, all MACRO pseudos as of the April 1978 "MACRO Assembler
Reference Manual" (AA-4159C-TM) are listed.
== Identical for all purposes
= Same function exists in some MIDAS form (given)
* Potentially desirable feature
? Not sure
ARRAY s[x] = .VECTOR s(x)
ASCII "str" ==
ASCIZ "str" ==
.ASSIGN s,s,x ? Load time hack (REL block type 100)
ASUPPRESS ? Kill unused symbols at end of pass2
BLOCK x ==
BYTE bdef,... ? like .BYTE, sort of
COMMENT ==
.COMMON sym[x] ? Fortran-type COMMON block (REL block type 20)
.CREF s,... ? With no args, = .CRFON (resume CREF output)
Otherwise no equivalent function.
DEC x,y,... = easily defined as macro
DEFINE <macro> Macro definition is lots different; more limited but more std.
DEPHASE = OFFSET 0 (see PHASE)
.DIRECTIVE d,... Hack to avoid using pseudo symbols, sets various
MACRO switches.
.ITABM, .XTABM
MACMPD
LITLST, FLBLST
.OKOVL, .EROVL
MACPRF
SFCOND
.NOBIN
KA10, KI10, KL10
END x ==
.ENDPS * Pops PSECT loc ctr (REL block 22)
ENTRY ?
EXP = easily defined as macro
EXTERN s,... = .GLOBAL s,... (I think)
HISEG x = obsolete TOPS-10 pseudo, use TWOSEG
.HWDRMT ? listing: show binary in halfwd format.
.IF x,q,<code> * Symbol/expression type tester
.IFN x,q,<code> * inverse of above
IFx = IFx for most part (MIDAS also has IFSQ, IFNSQ)
IFE,IFN,IFG,IFGE,IFL,IFLE =
IF1,IF2,IFDEF,IFNDEF,IFB,IFNB =
IFIDN, IFDIF = IFSE, IFSN
INTEGER s,... = .SCALAR
INTERN s,... ?
IOWD x,y = -x,,y-1
IRP dum,<code> =? like IRP but only inside a macro
IRPC dum,<code> =? like IRPC but etc
LALL ? listing: show everything (see XALL)
.LINK x,y,z ? Hairy loader static chains (REL block 12)
LIST = .LSTON listing: resume listing after XLIST
LIT = LITERALS
.LNKEND x,y ? End loader static chain (see .LINK)
LOC x = but odd diffs (implies absolute, and w/o arg restores
. previous to last LOC) (see .ORG, RELOC)
.MFRMT ? listing: causes "multiformat" listing of binary
MLOFF = .MLLIT==0
MLON = .MLLIT==1
.NODDT s,... = .HKILL s,...
NOSYM ? listing: suppress symtab listing
OCT x,... = easily defined as macro
OPDEF - not needed in MIDAS
.ORG x = LOC x (but not quite - see LOC, RELOC)
PAGE ? listing: skip to next page
PASS2 =? 1PASS switch to "pass2" processing. MIDAS implication is
slightly different, means "do only 1 pass".
PHASE x = OFFSET x-.
POINT x,y,z = can be defined as macro
PRGEND ? Ends program module; allows assembling several REL
modules from one file.
PRINTX line = PRINTX "line<CRLF>"
.PSECT s/sw,x * Defines a PSECT section
PURGE s,... = EXPUNGE s,...
RADIX x ==
RADIX50 x,s = .RSQZ x,s Note right-justified SQUOZE.
RELOC x = LOC x (but not exactly, see LOC and .ORG)
REMARK line = COMMENT "line"
REPEAT x,<code> = REPEAT x,[code]
.REQUEST file * Load file if necessary (REL block 17)
.REQUIRE file * Load file always (REL block 16)
RIM ==
RIM10 = can be simulated via WORD
RIM10B = RIM10 (different format but same effect)
SALL ? listing: suppress macro/repeat expansion listing
SEARCH s(file),... * Defines list of symtabs for MACRO to search.
SIXBIT "text" ==
SQUOZE x,s = .RSQZ x,s (same as RADIX50)
STOPI = .ISTOP
SUBTTL line ==
SUPPRESS s,... * Don't output these symbols unless referenced
SYN s1,s2 = EQUALS s2,s1 (note reversed order)
TAPE - sort of like .INEOF (go on to next file)
.TEXT "text" = .DECTXT "text"
TITLE line ==
TWOSEG x = .DECTWO x
UNIVERSAL s * Says this stuff is a universal symtab (and file)
VAR = VARIABLES
XALL ? listing: resume std listing after LALL or SALL
.XCREF s,... = .XCREF s,... (but action for no args is to
turn off all CREF output; this function is = .CRFOFF)
XLIST = .LSTOF listing: suspend output
XPUNGE ? Deletes local symbols during pass2.
XWD x,y ==
Z x,y = 0 x,y
Notes:
MACRO can only output a listing on pass2, unlike MIDAS which can
do both pass1 and pass2. Thus the MACRO listing pseudos are only meaningful
on pass 2.
How to hack MIDAS packages:
New pseudo .INSLIB which acts just like .INSRT but which defaults
the device and directory fields to a system-dependent location, possibly
to a search path. E.g. for TOPS-20 this can be MIDAS:, MID:, UNV:, SYS:.
On ITS this can be SYSENG, SYSEN1, MIDAS, etc.
Can re-specify the defaults by giving .INSLIB with no filename argument
(just device/dir).
Should a search path specification be allowed? Should
a search path default specification be allowed for .INSRTs as well?
Some special kind of syntax?
.INSxx <filespec>,<filespec>,<filespec>
If no filenames given, sets search defaults.
If a filename given, inserts it. Allows inserting several files... can
produce confusion between default-setting and inserting, but that seems OK.
How to read previous search defaults? How to add something at beg or end
of search path? How to find dev/dir name of file we found?
Discussions on system symbol definitions
KLH@MIT-AI 08/04/78 18:40:17 Re: symbols
To: MRC at MIT-AI, RMS at MIT-AI
CC: (BUG MIDAS) at MIT-AI
Let me see if I can get things straight. This is only a
first pass, is incomplete with respect to comparisons with FAIL/MACRO,
and has no conclusions. Comments welcome.
Case IA: User program to run on assembly system.
This is the majority of cases; for example, assembling
FOO on ITS to run on ITS, or BAR on 20X to run on 20X.
The MIDAS philosophy seems to be that no system symbols
should have to be .insrt'd, and they shouldn't be written
out in the program's symbols.
FAIL and MACRO, on the other hand, make use of UNIVERSAL
files (extension .FUN and .UNV respectively) which are
explicitly requested by the user program with a SEARCH pseudo.
Hence the "SEARCH MONSYM" you see for Macro programs. Read
up on these in MACRO or FAIL documentation. Any symbols
which are used by the program are written out in its symbol
table; unreferenced ones are not.
Case IB: User program to run at another system. (Cross-assembly)
MIDAS requires the user program to .insrt one of
the standard sets of symbol definitions, depending on
what system one is assembling for. These symbols are
included in the outputted symbol table for the program,
unless .KILL'd.
For FAIL and MACRO one just SEARCH's the appropriate
universal files instead of the normal MONSYM or MACSYM.
Essentially this is no different from case IA.
Case IIA: MIDAS to run on assembly system.
The basic difference between MIDAS and a random user program
is that during the assembly the symbols which are to be pre-defined
must be assembled into the initial symbol table. This
is why DEFSYM exists, so that one can deposit symbol names and
values into the storage area reserved for initial symbols.
Since by definition in case IA MIDAS has all of the
system symbols pre-defined, one could get away with just knowing the
symbol names, and letting the assembling MIDAS furnish the
values. This will work unless some new symbols have
been added or some values have changed. Thus it is
still necessary for DEFSYM to pull out the value, and if
the MIDAS being assembled uss one of the new symbols, it is
also necessary to define them at start of assembly, just as for
a cross-assembly.
Case IIB: MIDAS to run on another system. (cross-assembly)
Clearly it is necessary to both .insrt the symbols as
a means of defining them (so that the code will assemble properly)
and to put them in the initial symtab area of the assembled
MIDAS. In this case, it is reasonable for the DEFSYM macro
to let the assembling MIDAS furnish the value (since the symbol has
been defined by the first .insrt).
---------------
Date: 4 Aug 1978 1946-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: ( Forwarded Mail )
To: [midas;midas bugs] at AI
Mail from SU-AI rcvd at 4-Aug-78 1939-PDT
Date: 4 Aug 1978 1938-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: universal files in MIDAS
To: RMS at MIT-AI, KLH at SRI-KL
[just a side note, MIDAS compiles TWXBTS faster than MACRO searches (reads
a universal file) MONSYM!!!]
Well, reading a universal file sounds like a win, although I would prefer
that it would be done intelligently. In particular, DEC cretinously
introduced a symbol called .SYMTAB into MONSYM. Its purpose in life isn't
terribly justifiable, and in fact it should NOT be used on Tenex at all, so
I flushed it when I made TWXBTS. Another problem is that I would prefer not
to have to say .SEARCH MONSYM in my programs; SYS:MONSYM.UNV should always
be read in (and, I guess, dumped out) in the Twenex version (in Tenex, you
read <SUBSYS>STENEX.UNV instead). I think it is safe to assume that this
file would be present.
What to do about the DEC systems is a bit harder. The true right thing to
do at SAIL is to get them from the monitor. Look at the CALLIT UUO writeup
on page 113 of the UUO manual, and low core location 272 on page 260 (in
Appendix 3). FAIL knows about the UUO's and gets the CALLI's only, but it
is possible using CALLIT to get all the UUO's with appropriate heuristics.
An alternative way is to do a CALLIT on any symbol which would be otherwise
undefined; this of course means a system call has to be done for every UUO
(or undefined symbol) in the program. Actually no matter what you do it is
almost too horrible to comtemplate, depending on where your values are.
On Bottoms-10, you would try to snarf UNV:UUOSYM.UNV. If that fails, try
UNV:C.UNV. If that fails, try device SYS: instead of UNV:.
As for the cases where you can't get at the file, well, on Tenex and Twenex
I think it is safe to assume the file would exist. Bottoms-10 is another
story (unfortunately); some cretinous business systems actually have deleted
the files (to my unending chagrin). A safe alternative is to continue the
basic DFS files (both DECBTS and TWXBTS are out of date by now), to at least
provide in a bare MIDAS what MACRO provides. If we go the universal file
route, I do have a universal file for ITS on DECSYS;SITS MAC and SITS UNV--
DFTP uses it, although no ITS bits are included in it.
An alternative approach is to continue as we have done, except that we will
attempt to get up to date copies of UUOSYM and MONSYM from DEC to update our
files. That may end up as the best way.
One last note before I end this over-long message; in any case, MIDAS should
dump out its symbol table in the system-dependant crud since there is no
hope of fixing DDT.
-- m
-------
MRC@MIT-AI 08/04/78 19:00:44
To: RMS at MIT-AI, KLH at MIT-AI
FAIL and MACRO only put into the symbol table those system symbols and
bits which the program actually used. UUO's which are opcodes are
included always since DDT knows about them, but it doesn't know about
extended things. In other words, JSYS, CALLI, and OPEN are known, but
OUTSTR or SOUT or EXIT aren't known unless the program does one, which
is quite a screw. I suspect it is DEC trying to bum a K or two. Sigh.
FAIL and Stanford DDT should know better, but they don't.
RMS@MIT-AI 08/04/78 20:42:21
To: MRC at MIT-AI, KLH at MIT-AI
Looking at the comparison of MIDAS with FAIL and MACRO,
it seems to me that FAIL and MACRO win in that the way
to specify which symbols to use is independent of whether
you are assembling on the same system of a different one.
But they lose in that only the symbols you use
are defined in DDT. Clearly, they should all be in DDT.
So, unless people can fix DDT (unlikely), MIDAS should put
all of the system symbols in the binary, for best results.
However, since any user can request this for himself by
doing the .insrt, we need not put this in MIDAS. We should
just change the documentation to point out that this is possible.
The other possible advantage of FAIL and MACRO is that universal
files are at least potentially much faster than .insrt files,
especially .insrt files which are being parsed by DEFSYM.
So maybe we should make MIDAS able to read and write universal
files. It would read them by looking at them and putting the
data in the regular symbol table. Of course, macros wouldn't
have to be made to work, and macros in universal files written
by MACRO almost certainly wouldn't work, but that doesn't matter
as long as they are ignored reasonably.
Then users would write in MIDAS just as they write in FAIL or MACRO,
except that the symbols would go in the user symbol table, which is
even better (of course, there could be an option saying whether to
.KILL the symbols being gobbled). An additional advantage would
be that we would not have to maintain any more defs files.
We could just copy DEC's defs files.
KLH@MIT-AI 08/05/78 05:48:56 Re: Universal files
To: RMS at MIT-AI, MRC at MIT-AI
CC: (FILE [MIDAS;MIDAS BUGS]) at MIT-AI
I've thought about this too, but there ae a number of problems
which would need solving.
First, as far as understanding DEC's universal file format,
FAIL doesn't and MIDAS would have a lot of problems doing so,
because the symbol table structure is so different. Also it
turns out to be fairly important that macros be preserved, since
DEC defines some which are used a lot in user programs (prime
example is .FLDDB which sets up args for the COMND JSYS).
Granted it would be an amazingly impressive hack, if anyone bothered.
So it would be better for MIDAS to have its own format
not only for speed but for macro-saving capability as well. But
here again there are problems because we can't just run MIDAS
over the DEC MONSYM source file; it uses various macros and
lots of nBm value constructs and the like. This is why MRC
consed up the equivalent for MIDAS by hand (!!). Naturally this
is not what we want to do either.
My suggestion here would be to concentrae on the immediate
problem (getting symbol definitions into MIDAS) and worry about
universal file capability later, by making it easier to snarf
DEC symbol definition files into MIDAS-readable format; the more automatic
this can be made, the less hassle we'll have. Basically I have
two suggestions:
(1) define a pseudo which enables MIDAS to read nBm values,
and likewise to stop recognizing them.
(2) write and document a TECO macro which will make the
minor changes necessry to MONSYM.MAC; this will need
to be changed only when the MACRO macros are
substantially modified. This teco macro will also
insert DEFSYM's in the appropriate places.
Then we .insrt the file twice into MIDAS, once for the definitions
and once for the symbols alone, not bothering to evaluate them
the second time but just using the scheme of storing the value as
defined on the first .insrt. This avoids the pain of trying to
change the monsym.mac format so that DEFSYM can pluck out the value alone,
making it much easier to write this teco macro.
Reading nBm values will of course break existing programs, which is
why we will make it a normally-off switch and let the source
code turn it on and off. I haven't thought of a reasonable name
for the pseudo(s) but that shouldn't take long.
This will also make it a lot easier to snarf and convert TNX routines
by the way, not that I'm in love with the stupid syntax.
RMS@MIT-AI 08/05/78 18:27:27
To: KLH at MIT-AI, MRC at MIT-AI
I don't agree that, in processing a MACRO universal file,
not understanding macros would be a significant disadvantage.
So what if there are macros in MONSYM? Those macros are not
present in DECBTS or TWXBTS, so the lack of them can't be too bad,
and won't make things any worse than they are now.
If we make MIDAS able to read and write MACRO universal files
(actually we can do without writing), ordinary numeric symbols only,
that will make things a lot more convenient for us. It could be
smart enough to detect conflicts between symbols in the universal
file and predefined MIDAS symbols, and prefer the latter. Then there
would be no trouble with .SYMTAB. Since some losing sites delete the
universal files supplied by DEC, we can just supply copies of them
with MIDAS.
Alternatively, I think we should use a TECO macro to convert a MACRO
file into a MIDAS one. Making MIDAS understand the mBn construct
would not eliminate the need for this, since we would still have
to put in the calls to DEFSYM. It would make the TECO macro simpler,
but we would still need to perform a conversion. So we might as
well put it all in the TECO macro and not change MIDAS. I will
write the macro now.
Of course, reading universal files is only for the future.
Right now the problem has to be fixed some other way, so you might
as well just do so the way you plan to, without further discussion.
If we decide we really want to provide some macros as well as
symbols, we can always have a .INSRT file which defines the macros
and then gobbles the DEC universal file for the other symbols.
RMS@MIT-AI 08/31/78 01:23:07
To: (BUG MIDAS) at MIT-AI
I have put a new TWXBTS > on AI:SYS;
It was made from MIDAS;MONSYM > by using Convert MONSYM
and then deleting some things (jsys defs) and adding the first and
last pages.
Please check it over.