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: 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 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 ' 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 To: JoSH at RUTGERS cc: BUG-MIDAS at MIT-AI Date: 31 Jul 1980 0048-EDT From: JoSH 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 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 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==+1 does the right thing, but foo==1 ? 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 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 - 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,,[] 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? = same as = Allow spaces between 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 ? ; Establish stack for this symbol (no value) .PUSH , ; Push value onto stack (no value) .POP , ; Pop & return topmost value from stack .STKFLS , ; Reset/clear a stack (no value) .STKLEN , ; Return current # objects on stack. .STKV , ; Return indexed value from stack. 0, -1, etc. Reference to global stack?? .PUSH ,, ... (like SCALAR/VECTOR) .POP ,... 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 ,,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" 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 B construct that MACRO is so fond of. Syntax would be 0 or 0H. This could be made general, as in [][] ] 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 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, * Symbol/expression type tester .IFN x,q, * 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, =? like IRP but only inside a macro IRPC dum, =? 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" .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, = 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 ,, 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 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.