Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 87 01:09:13 EDT Date: Sat, 13 Jun 1987 01:06 EDT Message-ID: From: Rob Austein To: Bug-MIDAS@AI.AI.MIT.EDU Subject: TSRTNS.MID.233 (20X @COMPILE command support) I added support for the crufty PRARG%/TMPCOR CCL kludge to MIDAS, so that @COMPILE will work right on MIDAS files on Twenex. I installed TSRTNS.MID.233 on XX, OZ, and AI, installed new MIDAS.EXE on XX only. Support for MIDAS has been in the Stanford EXEC for ages, I just added it to the MIT EXEC as of version MIT160.  Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Oct 85 06:49:06 EDT Date: Fri 18 Oct 85 03:51:31-PDT From: Ken Harrenstien Subject: * and & in macro defs To: bug-midas@MIT-MC.ARPA Message-ID: <12152065869.17.KLH@SRI-NIC.ARPA> There is a possible bug in the way * and & (and perhaps other such switches) are implemented, or at least in the way they are documented. One is given the impression that there are several orthogonal attributes an argument can have, and that once you turn on a certain attribute, that applies to all following arguments until explicitly turned off again. However, it appears that for some (most?) cases the "turn-off" switch actually does a global reset back to type "normal" instead of merely turning off its specific attribute. I found this when trying to figure out why a macro definition of this form DEFINE FOO ?BAR,&STR&,ETC,ETC2 resulted in ETC and ETC2 being normal-syntax instead of balanced. Really screws one up when FOO is invoked as a parenthesized call with 2 args! During the debug process I stared at the documentation several times without catching on. MIDAS macro syntax is so baroque that it would probably be handy to have a pseudo-op like .DEFINE which acted like DEFINE but which also generated, in the listing output, a readable description of its arguments so that you know exactly what MIDAS thinks you did. .DEFINE'd macros could also have additional helpful listing output when being expanded. Oh well, who's going to bother anyway. -------  Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Oct 85 06:49:06 EDT Date: Fri 18 Oct 85 03:51:31-PDT From: Ken Harrenstien Subject: * and & in macro defs To: bug-midas@MIT-MC.ARPA Message-ID: <12152065869.17.KLH@SRI-NIC.ARPA> There is a possible bug in the way * and & (and perhaps other such switches) are implemented, or at least in the way they are documented. One is given the impression that there are several orthogonal attributes an argument can have, and that once you turn on a certain attribute, that applies to all following arguments until explicitly turned off again. However, it appears that for some (most?) cases the "turn-off" switch actually does a global reset back to type "normal" instead of merely turning off its specific attribute. I found this when trying to figure out why a macro definition of this form DEFINE FOO ?BAR,&STR&,ETC,ETC2 resulted in ETC and ETC2 being normal-syntax instead of balanced. Really screws one up when FOO is invoked as a parenthesized call with 2 args! During the debug process I stared at the documentation several times without catching on. MIDAS macro syntax is so baroque that it would probably be handy to have a pseudo-op like .DEFINE which acted like DEFINE but which also generated, in the listing output, a readable description of its arguments so that you know exactly what MIDAS thinks you did. .DEFINE'd macros could also have additional helpful listing output when being expanded. Oh well, who's going to bother anyway. -------  Received: from decwrl.ARPA by MIT-MC.ARPA 4 Aug 85 18:36:09 EDT Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34) id AA03542; Sun, 4 Aug 85 15:36:11 pdt Message-Id: <8508042236.AA03542@decwrl.ARPA> Date: Sunday, 4 Aug 1985 15:35:23-PDT From: budne%mrfort.DEC@decwrl.ARPA (Phil Budne) To: bug-midas@mit-mc.ARPA Subject: New program CVTUUO ----- Delivered by TOPS-20 Message Services --- Date: 4 Aug 1985 1830-EDT From: Phil Budne To: """bug-midas@mit-mc.arpa""" at DECWRL Subject: New program CVTUUO Message-ID: <"MS11(2411)+GLXLIB5(0)" 12132532256.137.48.52511 at MRFORT> MC: GUEST0; BUDD CVTUUO contains a version of MRC's CVT program that runs under TOPS-10, and sucks in UNV:UUOSYM.UNV and UNV:MACTEN.UNV to produce DECDFS.MID. -Phil Budne --------  Received: from SIMTEL20.ARPA by MIT-MC.ARPA 19 Jun 85 21:20:35 EST Date: Wed 19 Jun 85 06:51:18-MDT From: Mark Crispin Subject: Re: system bits To: CSTACY@MIT-MC.ARPA cc: BUG-MIDAS@MIT-MC.ARPA In-Reply-To: Message from "Christopher C. Stacy " of Tue 18 Jun 85 22:37:21-MDT I was under the (perhaps mistaken) impression that system definitions are snarfed from the operating system, which would imply that you would need to install a new version of ITS. At least that's the way FAIL on WAITS gets UUO definitions, and I thought MIDAS on ITS worked the same way. -------  Date: Wed, 19 Jun 85 00:33:28 EDT From: Christopher C. Stacy Subject: system bits To: BUG-MIDAS@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].549329.850619.CSTACY> I was writing an init file for someone today and I wanted to make use the the ITS bit named %TYRLM. The bit is defined in SYSTEM;BITS but DDT did not know about it. DDT does not appear to explicitly include the BITS, so I assume it guess it gets its system symbols from MIDAS. MIDAS did not know about my bit either, and there seem to have been many changes to MIDAS lately, so I went to assemble a new MIDAS. I found and fixed two trivial MIDAS bugs in the TSRTNS module. The CORGET routine had an ill-formed system call, and the CMD routine was confused about JCL handling. I did not audit the numerous changes which have been made, and did NOT install MIDAS 458, which at least seems to work now. However, the %TYRLM bit is still not known to MIDAS (or a TS DDT assembled by same). I am not familiar with MIDAS at all. What do I need to do to get this bit known by MIDAS?  Received: from MIT-JIMI by MIT-MC via Chaosnet; 1 JUN 85 18:49:39 EDT Date: Sat, 1 Jun 85 18:48 EDT From: David Vinayak Wallace Subject: new midas for twenex To: info-midas@MIT-MC.ARPA Message-ID: <850601184814.1.GUMBY@JIMI> Twenex Midas now kills itself (via PRARG) when done. I think this will only affect MIT users, but if any other site's exec recognises the same PRARG options, ftp the file oz:ss:TSRTNS.MID.232. david  Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 10 APR 85 02:48:11 EST Date: Tue 9 Apr 85 23:31:50-PST From: Mark Crispin Subject: Re: should midas kill itself To: GUMBY@MIT-MC.ARPA cc: KLH@MIT-MC.ARPA, BUG-MIDAS@MIT-MC.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Tue 9 Apr 85 23:18:20-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 No, the COMPILE commands do not RSCAN% the filename to MIDAS. They use PRARG% which for TOPS-10 compilers is used by PA1050's support of the TOPS-20 TMPCOR UUO. -------  Date: Wed,10 Apr 85 01:56:35 EST From: David Vinayak Wallace Subject: should midas kill itself To: KLH@MIT-MC cc: BUG-MIDAS@MIT-MC In-reply-to: Msg of Mon 8 Apr 85 16:36:02 EST from Ken Harrenstien Message-ID: <[MIT-MC].449503.850410.GUMBY> Date: Mon, 8 Apr 85 16:36:02 EST From: Ken Harrenstien If there is some safe way of making this happen, I suppose it is all right. The problem is that I have never seen any documentation which explains the standard conventions for using PRARG%. I tried to find this once, so I could make MIDAS work with COMPILE-class commands, but gave up; that is one of the most obscure pieces of mumbo-jumbo I have encountered in quite a while. Now you are talking about PRARG% in the OTHER direction too? Argh... give me a .break.... I don't see what the hassle is for that...the COMPILE commands just RSCAN% the filename to MIDAS?  Date: Mon, 8 Apr 85 16:36:02 EST From: Ken Harrenstien Subject: should midas kill itself To: GUMBY@MIT-MC cc: BUG-MIDAS@MIT-MC Message-ID: <[MIT-MC].447245.850408163630.KLH> If there is some safe way of making this happen, I suppose it is all right. The problem is that I have never seen any documentation which explains the standard conventions for using PRARG%. I tried to find this once, so I could make MIDAS work with COMPILE-class commands, but gave up; that is one of the most obscure pieces of mumbo-jumbo I have encountered in quite a while. Now you are talking about PRARG% in the OTHER direction too? Argh... give me a .break....  Received: from MIT-OZ by MIT-MC via Chaosnet; 8 APR 85 00:20:56 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Apr 85 00:20-EST Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 8 APR 85 00:20:26 EST Date: Sun 7 Apr 85 21:19:51-PST From: Mark Crispin Subject: Re: should midas kill itself To: GUMBY@MIT-MC.ARPA cc: bug-midas%MIT-OZ@MIT-XX.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Sun 7 Apr 85 18:06:54-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Okay, at least you are talking about PRARG% instead of RSCAN%. I still remember the day I did a SEND on OZ and found that some wonderful (sic) person had "improved" SEND to RSCAN% out a RESET...since my environment ran it ephemerally it reset my EMACS. That was the last day I tried to do anything serious on OZ... Re: "PCL is bogus". The implementation is bogus, but certainly something of that functionality is needed. Or are you happy only when you are modifying the internals of the operating system and command decoder? You needn't tell me "VALRET is bogus". I remember when on ITS that was the only way to communicate between a program and DDT. .BREAK (I forget the value of n) was an improvement, but it was still bogus. I bugged RMS for something better, and one day .LOGOUT 1, appeared... "What if the compilation terminates abnormally?"...well I don't see how the MIDAS fork is useful, unless you mean MIDAS blowing up. I didn't think MIDAS did that any more. -------  Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 21:04:43 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 21:04-EST Date: Sun, 7 Apr 85 21:04:10 EST From: David Vinayak Wallace Subject: should midas kill itself To: MRC@SU-SCORE cc: bug-midas@MIT-OZ In-reply-to: Msg of Sun 7 Apr 85 13:49:00-PST from Mark Crispin Message-ID: <[MIT-MC].446043.850407210413.GUMBY> Date: Sun 7 Apr 85 13:47:38-PST From: Mark Crispin What do you mean "kill itself off when done"? If you mean to RSCAN% back a RESET command a number of people will be quite pissed, since very often MIDAS is run ephemerally or (in my environment) from a PCL command file. That RSCAN%'ing hack causes some other fork to be smashed! Date: Sun 7 Apr 85 13:49:00-PST From: Mark Crispin Why don't you write a PCL procedure to invoke MIDAS. You can even get it to grok filename completion that way. There is also the SET PROGRAM EPHEMERAL feature. Let's not have any more programs which magically RSCAN% stuff back to the EXEC. VALRET (i.e. RSCAN%) is bogus. So is PCL. What's wrong with using PRARG (the TNX equivalent of .BREAK)? Those systems whose execs ignore it won't notice; the MIT-exec at least will do the right thing. Setting it ephemeral is NOT the right thing! What if the compilation terminates abnormally?  Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 16:55:03 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 16:54-EST Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 7 APR 85 16:49:34 EST Date: Sun 7 Apr 85 13:49:00-PST From: Mark Crispin Subject: Re: should midas kill itself To: GUMBY@MIT-MC.ARPA cc: bug-midas%MIT-OZ@MIT-XX.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Sun 7 Apr 85 01:22:08-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 Why don't you write a PCL procedure to invoke MIDAS. You can even get it to grok filename completion that way. There is also the SET PROGRAM EPHEMERAL feature. Let's not have any more programs which magically RSCAN% stuff back to the EXEC. -------  Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 16:48:31 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 16:47-EST Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 7 APR 85 16:48:10 EST Date: Sun 7 Apr 85 13:47:38-PST From: Mark Crispin Subject: Re: should midas kill itself To: GUMBY@MIT-MC.ARPA cc: bug-midas%MIT-OZ@MIT-XX.ARPA In-Reply-To: Message from "David Vinayak Wallace " of Sun 7 Apr 85 01:22:08-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 Phone: 1 (415) 968-1052 What do you mean "kill itself off when done"? If you mean to RSCAN% back a RESET command a number of people will be quite pissed, since very often MIDAS is run ephemerally or (in my environment) from a PCL command file. That RSCAN%'ing hack causes some other fork to be smashed! -------  Received: from MIT-OZ by MIT-MC via Chaosnet; 6 APR 85 20:28:49 EST Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Apr 85 20:28-EST Date: Sat, 6 Apr 85 20:28:10 EST From: David Vinayak Wallace Subject: should midas kill itself To: bug-midas@MIT-OZ Message-ID: <[MIT-MC].445177.850406202842.GUMBY> Would anyone complain if I changed twenex midas to kill itself off when done if invoked with jcl? I like this behaviour on ITS.  Date: Fri 1 Mar 85 15:29:13-PST From: Ken Harrenstien Subject: Re: more help needed from a midas wizard To: HEDRICK@RUTGERS.ARPA cc: bug-midas@MIT-MC.ARPA, KLH@SRI-NIC.ARPA In-Reply-To: Message from "Charles Hedrick " of Fri 22 Feb 85 20:59:30-PST Have you been able to check the fix yet? -------  Date: 22 Feb 85 20:59:30 EST From: Charles Hedrick Subject: Re: more help needed from a midas wizard To: KLH@SRI-NIC.ARPA cc: bug-midas@MIT-MC.ARPA In-Reply-To: Message from "Ken Harrenstien " of 22 Feb 85 19:07:18 EST Thanks. It will be a couple of days before I have time to check it. I'll tell you either way. -------  Date: Fri 22 Feb 85 16:07:18-PST From: Ken Harrenstien Subject: Re: more help needed from a midas wizard To: HEDRICK@RUTGERS.ARPA cc: KLH@SRI-NIC.ARPA, bug-midas@MIT-MC.ARPA In-Reply-To: Message from "Charles Hedrick " of Tue 19 Feb 85 21:15:34-PST Try this patch, and tell me if it cures your problem. More importantly, tell me if it causes new problems! It fixes the test case, but I need to make sure it does not break anything else before firmly installing the change in the source. at ASMOT4+1, change the value PBY5 to BYTINR. at ASMOT4+2, ditto. If you want an explanation: the constants-optimization code tries to make sure that the constant does not contain still-undefined global quantities. However, when byte mode popped out of angle brackets, it was resetting the global-link table as if it had popped out of square brackets. Thus when the constant was stored, it appeared as if there were no undefined globals involved. I suspect this was just a mental spaz by whoever wrote the code. -------  Date: 20 February 1985 15:15-EST From: Alan Bawden Subject: more help needed from a midas wizard To: HEDRICK @ RUTGERS cc: BUG-MIDAS @ MIT-MC, tops-20 @ SU-SCORE Date: 16 Feb 85 21:18:13 EST From: Charles Hedrick Could someone tell me why the following code generates an error complaining that there are more constants in pass 2 than pass 1? I assume this is a bug in Midas. title test loc 140 define object(type,val) <.byte 6,30. ? type ? val> termin move 1,[object 3,<4,,a>] move 1,[object 3,<4,,b>] a: 1 b: 2 end If you replace the macro calls to OBJECT with their definition, the error does not occur. Putting () around the call does not help. I replaced the macros calls to OBJECT to obtain the following: title test loc 140 move 1,[<.byte 6,30. ? 3 ? <4,,a>>] move 1,[<.byte 6,30. ? 3 ? <4,,b>>] a: 1 b: 2 end Which also gets the "more constants on pass 2" error, so I don't think that the macro has anything to do with it. (You must have spazzed when you performed the expansion manually.) Your problem would seem to be just another instance of a perennial midas screw. This one has probably shafted everybody at least once. What is happening is that on pass 1 Midas uses 0 as the value of as-yet undefined symbols, such as A and B in your example. This causes both literals to look like they will contain the same one-word quantity. Midas tries to be clever and optimize one-word literals to share the same storage. Then on pass 2 they turn out to be different and Midas hasn't allocated enough constants space. I don't understand why this one doesn't shaft people -more- than it does now. Big programs generally generate enough noise in their constants between pass 1 and pass 2 that they don't get screwed, only small programs get bit. I guess I would advocate putting in a switch to turn the constant-sharing hack off so that people can work around this screw when it happens. Clearly there are better solutions, but that would be sufficient.  Return-Path: <@SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA> Received: from SU-SCORE.ARPA by MIT-XX.ARPA with TCP; Sat 16 Feb 85 21:24:15-EST Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sat 16 Feb 85 18:19:55-PST Date: 16 Feb 85 21:18:13 EST From: Charles Hedrick Subject: more help needed from a midas wizard To: tops-20@SU-SCORE.ARPA ReSent-date: Tue 19 Feb 85 13:47:12-EST ReSent-from: Gail Zacharias ReSent-to: bug-midas@MIT-MC.ARPA Could someone tell me why the following code generates an error complaining that there are more constants in pass 2 than pass 1? I assume this is a bug in Midas. title test loc 140 define object(type,val) <.byte 6,30. ? type ? val> termin move 1,[object 3,<4,,a>] move 1,[object 3,<4,,b>] a: 1 b: 2 end If you replace the macro calls to OBJECT with their definition, the error does not occur. Putting () around the call does not help. -------  Date: 10 February 1985 01:46-EST From: Alan Bawden Subject: IFSE poorly documented? To: DEVON @ MIT-MC cc: BUG-MIDAS @ MIT-MC In-reply-to: Msg of 9 Feb 1985 16:54-EST from Devon S. McCullough Well, IFSE has nothing to do with it. What you are trying to say seems to be that the way MIDAS parses normal arguments (to macros, conditionals, etc.) is confusing. That's certainly true, but I don't think the documentation could be any clearer on the point. There certainly are enough examples scattered throughout the documentation that are explicitly designed to get the reader thinking about this issue. For example, the documentation for IFSE reminds you that IFSE FOO,[BAR][BLETCH] conditionalizes "BLETCH" while IFSE FOO,[BAR],[BLETCH] conditionalizes ",[BLETCH]". You just have to learn to keep the silly rules in mind whenever you read anything written in MIDAS.  Date: 9 February 1985 16:54-EST From: Devon S. McCullough Subject: IFSE poorly documented? To: BUG-MIDAS @ MIT-MC, DEVON @ MIT-MC I experimentally determined the meaning of the following construct ifse [arg],[asciz/arg null/] .else [asciz/arg not null/] end after looking at :info programming midas cond, and not getting any info. Maybe if I were more familiar with other aspects of Midas it would be obvious, but I think this should be documented since it is used. I would rather not fix the doc myself for various reasons, mainly my inexperience with Midas.  Date: 19 Dec 1984 14:43 PST (Wed) Message-ID: <[SRI-NIC].IAN.19-Dec-84 14:43:58> From: Ian Macky To: "Frank J. Wancho" Cc: BUG-MIDAS@MC Subject: Can't build TECO... ERRRST+4 1604 0. 3-006 1B1 Undefined in = ERRRST+4 1604 0. 3-007 1B2 Undefined in = "nBm" is a MACRO construct, sort of like .DPB - what's it doing in that Midas file? 1B1 is 400000,,0 and 1B2 is 200000,,0 PS:TECO.MID.1206 GILLTB+23 50340 0. 337-023 Symbol table full Well, looks like you need to up the arguments to the .SYMTAB op at the top of the file, which defines how much storage to allocate for the symbol table and constants areas. They should be primes... Unterminated successful bracketed conditionals The first was at 285-002 of file TECO Error is fatal. Run time = 50.02 8001 Symbols including initial ones (100% used) Eh... Err...  Date: 19 Dec 1984 15:00 MST (Wed) Message-ID: From: "Frank J. Wancho" To: BUG-MIDAS@MC cc: WANCHO@SIMTEL20 Subject: Can't build TECO... MIDAS 436 and now MIDAS 458 work fine, except that I can no longer build the same TECO I was able to build successfully a year ago with a "NOTPUR" MIDAS 429. Also, never saw mention of VTSDEF in the log before: @midas MIDAS.436 **temp_teco TECO PS:VTSDEF.MID.3 ERRRST+4 1604 0. 3-006 1B1 Undefined in = ERRRST+4 1604 0. 3-007 1B2 Undefined in = END OF LOW IMPURE = 4023 PS:TECO.MID.1206 GILLTB+23 50340 0. 337-023 Symbol table full Unterminated successful bracketed conditionals The first was at 285-002 of file TECO Error is fatal. Run time = 50.02 8001 Symbols including initial ones (100% used) $ $  Date: 26 November 1984 17:39-EST From: Richard M. Stallman Subject: MIDAS bug To: HEDRICK @ RUTGERS cc: BUG-MIDAS @ MIT-MC I have a suspicion that DOCAR is a macro. Your problem is due to the fact that ? does not terminate macro arguments. You could put a newline in place of the ? or you could make the arguments balanced and put some sort of parentheses around the call or various other things. But I don't think that changing the definition of MIDAS macro calls so that ? will terminate one is an available alternative.  Return-Path: Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Nov 84 17:27:35-PST Date: 20 Nov 84 20:33:48 EST From: Charles Hedrick Subject: MIDAS bug To: tops-20@SU-SCORE.ARPA ReSent-Date: Mon 26 Nov 84 01:45:14-PST ReSent-From: Mark Crispin ReSent-To: BUG-MIDAS@MIT-MC.ARPA Does anyone have source to Midas? Our Common Lisp was giving incorrect results for MINUSP. It turns out that the code jrst [docar o1,o1 ? jrst minusp] was assembling into jrst [garbage] When I replace docar o1,o1 with move o1,(o1) [which is its expansion] the code is correct. I would like to fix this problem, since I find the concept of an assembler that produces bad code very scary. -------  Date: Wed, 7 Nov 1984 12:25 EST Message-ID: From: Gail Zacharias To: Alan Bawden Cc: BUG-MIDAS@MIT-MC Subject: .ASCII In-reply-to: Msg of 7 Nov 1984 01:51-EST from Alan Bawden Well, there are certainly other situations where Midas gives undefined errors on pass 1 even though things might turn out to work out alright in the end due to special circumstances. The solution then is to either ignore the warning or do something by hand that takes advantage of the special circumstances. In fact your second example can be trivially modified to work with an .ASCII which requires everything to be defined on pass 1, so making .ASCII complain on pass 1 wouldn't be a fundamental limitation. If it gave a warning but then proceeded the way it does now, then it wouldn't be a limitation at all. You'd have to ignore the warning in your case, but I think that's fair enough, it's certainly a matter of luck and a very rare case where it happens to work out. Your hack only works because the high octal digit of instructions is non-zero. That wouldn't necessarily be the case in another radix, e.g. RADIX 10. .ASCII "10/! " gives phase errors. So in a sense it would be more robust for you to do the allocation by hand as in your second example, and I think a warning is perfectly reasonable. The problem with the way it works now is that phase errors are such a pain to track down, especially if they're caused by something Midas silently did for you that you might not even be aware of. Maybe there should be two .ascii-style pseudo-ops (or a single pseudo-op and a switch), one that allocated the maximum number of characters for each value and then padded the string with 0 words on pass 2, and another that required everything to be defined on pass 1.  Date: 7 November 1984 01:51-EST From: Alan Bawden Subject: .ASCII To: GZ @ MIT-OZ cc: BUG-MIDAS @ MIT-MC In-reply-to: Msg of Tue 6 Nov 1984 20:23 EST from Gail Zacharias Date: Tue, 6 Nov 1984 20:23 EST From: Gail Zacharias Trying to assemble .scalar x .ascii "x=!x " results in all sorts of phase errors. I understand why I can't do this, but Midas really should give me an "undefined" error right away rather than trying to fake it and failing obscurely. Let me get this straight, you propose to make Midas generate an error if it finds something undefined while evaluating an expression after a "!" in a .ASCII? If that is what you mean, I claim that would be a screw. I have code that does: .ASCII "259/!" where the value of FOO isn't known until later in the first pass. This generates no phase errors because the value of has the same number of characters in either case. Why should I be bothered by unnecessary error messages? In fact I originally wrote .ASCII "259/PUSHJ P,!FOO" and lost in exactly the way you did. If I hadn't found that hack I would have protected myself by doing: .ASCII "259/PUSHJ P,!FOO" IF1, LOC .+17 IF2, IFG .-QAZ, .ERR 17 is too small. IF2, LOC QAZ QAZ:  Date: Tue, 6 Nov 1984 20:23 EST Message-ID: From: Gail Zacharias To: bug-midas@MIT-MC Subject: .ASCII Trying to assemble .scalar x .ascii "x=!x " results in all sorts of phase errors. I understand why I can't do this, but Midas really should give me an "undefined" error right away rather than trying to fake it and failing obscurely.  Date: Thu, 30 Aug 1984 22:54 EDT Message-ID: From: Gail Zacharias To: Ken Harrenstien Cc: bug-midas%MIT-OZ@MIT-MC.ARPA Subject: .decrel format In-reply-to: Msg of 30 Aug 1984 19:17-EDT from Ken Harrenstien [PHOTO: Recording initiated Thu 30-Aug-84 10:45pm] MIT TOPS-20 Command Processor 5(712115)-2 @type foolib.mid title FOOLIB foo: hrroi 1,[asciz " foo foo "] PSOUT% popj 17, end @midas foolib FOOLIB FOOLIB Constants area inclusive From To 3 5 Run time = 0.56 4728 Symbols including initial ones (59% used) @type test.mac title test search monsym,macsym .require foolib extern foo pdl: block 100 begin: reset% move 17,[-100,,pdl-1] pushj 17,foo haltf% jrst begin end begin @load test MACRO: test LINK: Loading ?LNKUGS 1 undefined global symbol FOO 242 EXIT @rename foolib.rel midas-foolib.rel FOOLIB.REL.1 => MIDAS-FOOLIB.REL.1 [OK] @type foolib.mac title FOOLIB search monsym foo:: hrroi 1,[asciz " foo foo "] PSOUT% popj 17, end @compile foolib.mac MACRO: FOOLIB EXIT @del test.rel TEST.REL.1 [OK] @load test MACRO: test LINK: Loading EXIT @typrel Output file= tty: Rel file= midas-foolib.rel Type Data Total 6 2 4 NAME FOOLIB 1 4 6 PROG 1 4 6 PROG 2 2 4 SYM 5 2 4 LAST '6 0 0 1 NIL Total file length (decimal words) = 25 Done. @typrel Output file= tty: Rel file= foolib.rel Type Data Total 4 0 2 ENTRY 6 2 4 NAME FOOLIB 1 7 11 PROG 2 4 6 SYM 5 2 4 LAST '6 Total file length (decimal words) = 25 Done. @pop [PHOTO: Recording terminated Thu 30-Aug-84 10:48pm]  Received: from MIT-MC by MIT-OZ via Chaosnet; 30 Aug 84 19:36-EDT Date: 30 August 1984 19:17-EDT From: Ken Harrenstien Subject: .decrel format To: GZ @ MIT-OZ cc: bug-midas @ MIT-OZ .DECREL works here. You are probably omitting something, but I haven't the faintest idea what it might be (without anything to look at -- hint, hint).  Date: Tue 28 Aug 84 19:56-EDT From: Gail Zacharias Subject: .decrel format To: bug-midas@MIT-OZ CC: gs@MIT-OZ How can I get midas to generate .REL files which are intended to be linked into other programs. When I try it, the linker can't find any of the symbols. I'm not too familiar with the formats, but comparing Midas and Macro produced files, it seems that Midas is not putting out any "ENTRY" blocks. Is there any way to make it do so?  Date: 27 August 1984 21:04-EDT From: Ken Harrenstien Subject: Is there some reason... To: JTW @ MIT-SPEECH cc: BUG-MIDAS @ MIT-MC Date: Sun 26 Aug 84 20:18:32-EDT From: John Wroclawski that DECSAV on 20X dumps .EXE files in non-sharable save format instead of sharable save format? Seems a bit dumb... Only the same reason that SBLK on ITS dumps BIN files in non-sharable SBLK format instead of sharable PDUMP format. It is not an impossible feature to add, but it would take a fair amount of work.  Date: Mon 27 Aug 84 13:27:28-PDT From: Ian Macky Subject: can't specify filename To: bug-midas@MIT-MC.ARPA I had a filenamed (don't complain) 7^V%.MID, which worked fine everywhere except for Midas, which simply would not allow me to specify that filename, no matter how I quoted it. It either came out with 7.MID or 7%%.MID but never just 7%.MID -------  Date: Sun 26 Aug 84 20:18:32-EDT From: John Wroclawski Subject: Is there some reason... To: bug-midas@MIT-MC that DECSAV on 20X dumps .EXE files in non-sharable save format instead of sharable save format? Seems a bit dumb... -------  Date: Mon 6 Aug 84 16:33-EDT From: Ian Macky Subject: !@(*&^%#$ To: bug-midas@MIT-OZ Once again MIDAS died of a "Fatal MIDAS internal error!" and couldn't even pull off printing out where it died, which is a bug. It was ephemeral, so I couldn't dump it.  Received: from MIT-MC by MIT-OZ via Chaosnet; 20 Jul 84 13:18-EDT Date: 20 Jul 1984 10:13 PDT (Fri) Message-ID: <[SRI-NIC].IAN.20-Jul-84 10:13:49> From: Ian Macky To: Ken Harrenstien Cc: bug-midas@MIT-OZ Subject: I just got ===== Fatal MIDAS internal error! ===== In-reply-to: Msg of 19 Jul 1984 23:33-PDT from Ken Harrenstien I couldn't reproduce it. Yes, there's nothing you can do, but I thought I ought to report it anyhow...  Received: from MIT-MC by MIT-OZ via Chaosnet; 20 Jul 84 02:32-EDT Date: 20 July 1984 02:33-EDT From: Ken Harrenstien Subject: I just got ===== Fatal MIDAS internal error! ===== To: IAN @ MIT-OZ cc: bug-midas @ MIT-OZ Date: Wed 18 Jul 84 12:54-EDT From: Ian Macky Subject: I just got ===== Fatal MIDAS internal error! ===== etc, with no location printed ("Error was at location:" then nothing). This was after 2nd pass, after it was displayed constats area... It was ephemeral, so I couldn't dump it out. Not much else to say... Well, you could at least say how to reproduce it. How would you like to try fixing MIDAS given only the above information?  Date: Wed 18 Jul 84 12:54-EDT From: Ian Macky Subject: I just got ===== Fatal MIDAS internal error! ===== To: bug-midas@MIT-OZ etc, with no location printed ("Error was at location:" then nothing). This was after 2nd pass, after it was displayed constats area... It was ephemeral, so I couldn't dump it out. Not much else to say...  Date: Mon 9 Jul 84 14:58:01-PDT From: Ken Harrenstien Subject: MIDAS info blocks To: ian@SRI-NIC.ARPA cc: klh@SRI-NIC.ARPA, bug-midas@MIT-MC.ARPA OK, I have looked at the stuff and have the following comments. (1) I think it would be better to define a completely new sub-block type (3 is currently the highest unused) which we can use as the "new improved MIDAS-info block". The old info-block format would become obsolete and only BINPRT would need to remember how to parse it. Then ITS programs can take advantage of the expanded format, as well as DEC programs, without breaking existing stuff. The key feature of this block is that it can use your new method of including long strings. I'd want the following items: Count of stuff (so it's expandable) Flag/value - Machine type assembled for (KA, KL, KS, *, etc) Flag/value - System assembled for (ITS, 20X, etc) Value/string - Date/Time of assembly (sys-dep or sys-indep format?) String - System host name (eg SRI-NIC, MIT-MC) String(s) - Source filename (including dev, dir, fn1, fn2, etc...) (by components, or as one single string, or either?) String - User who assembled String - Comments (arbitrary, furnished by program or loader) Anything else? Would it be useful to include info about the program that created the binary file (MIDAS, DDT, LINK, etc) or is this so esoteric it should be part of a comment? (2) I still don't think it is necessary to have a new sub-block type just for the purpose of specifying a "linked" filename. My gut feeling is that we should avoid unnecessary proliferation of new types (which lots of programs will need to know about) and this sort of stray information should be a comment, such as "This program just runs the file BAR.EXE". There aren't that many "boot" programs and it isn't clear what is ever going to need to look at this information besides BINPRT (which will just print it out, same as a comment). Now, if the EXEC were modified so that it scanned assembly sub-blocks, found such a block, and did the loading itself (thus making it unnecessary to have anything executable in the boot program at all) then it would make sense to have this sort of explicit specification. Of course that is not a good approach to the TOPS-20 filesystem link problem, but it demonstrates the kind of rationale for having sub-block types. You could perhaps argue in a similar way against most of the other things in the assembly-info sub-block (that is, why aren't they just part of a single large comment?) but I think more people would agree that they are of general interest to a wider range of software. Certainly the machine and system info must be rigidly specified, for example. Well, those are my thoughts. -------  Received: from MIT-MC by MIT-OZ via Chaosnet; 29 Jun 84 17:13-EDT Date: 29 June 1984 17:14-EDT From: Ken Harrenstien Subject: apparent bug around inch53... To: IAN @ MIT-OZ cc: BUG-midas @ MIT-OZ Fixed (not yet installed pending final touches to Ian's info-block additions)  Date: Thu 28 Jun 84 04:03-EDT From: Ian Macky Subject: apparent bug around inch53... To: BUG-midas@MIT-OZ if the input file is an even number of pages, inch53 seems to screw up in trying to figure out the last byte in the buffer, and points to a byte in the next page, causing an npx error when pure... reproducable, if ya wanna see it.  Date: 20 June 1984 18:28-EDT From: Alan Bawden Subject: @BINPRT To: Ian @ SRI-NIC cc: BUG-MIDAS @ MIT-MC, GZ @ MIT-OZ, Moon @ SCRC-TENEX In-reply-to: Msg of 20 Jun 1984 15:15 PDT (Wed) from Ian Macky I presume that the right thing to do is do the analogous thing to ITS SBLK format and have a general mechanism for putting typed info blocks after the entry vector word. Perhaps even a duplicate entry vector word at the end of the file to terminate it? Heck, then you could hack Midas to put the symbol table there as well. And then a version of DDT that new how to eat the symbols from those info blocks...  Date: 20 Jun 1984 15:15 PDT (Wed) Message-ID: <[SRI-NIC].IAN.20-Jun-84 15:15:37> From: Ian Macky To: Alan Bawden Cc: BUG-MIDAS@MIT-MC, GZ@MIT-OZ, Moon@SCRC-TENEX Subject: @BINPRT In-reply-to: Msg of 20 Jun 1984 14:25-PDT from Alan Bawden I looked at the GETSAV module that does GET, and looks like it'll work. Once it finds the entry-vector word (positive LH) it stops reading and finishes up. A practical test via FILDDT showed it works in practice, too! OK, so who's going to fix Midas?  Date: 20 June 1984 17:25-EDT From: Alan Bawden Subject: @BINPRT To: Ian @ SRI-NIC cc: BUG-MIDAS @ MIT-MC, GZ @ MIT-OZ, Moon @ SCRC-TENEX In-reply-to: Msg of 20 Jun 1984 13:04 PDT (Wed) from Ian Macky OK, so somebody try an experiment. What happens if there is additional words beyond the entry vector XWD at the end of the file?  Date: 20 Jun 1984 13:04 PDT (Wed) Message-ID: <[SRI-NIC].IAN.20-Jun-84 13:04:27> From: Ian Macky To: Gail Zacharias Cc: bug-midas@MIT-MC, Moon%SCRC-TENEX@MIT-MC.ARPA Subject: @BINPRT In-reply-to: Msg of 20 Jun 1984 10:35-PDT from Gail Zacharias We could do it the same way as on ITS, have one of the SBLKs just be an information block. Of course, it would have to be flagged as such and the GET call would have to know not to try and load it. Or, I suppose, it *could* be data and let it be loaded, but at some fixed offset, that you would look for as the key, to know this was the description block. From the JSYS manual: The format of a nonsharable save file is as follows: IOWD length, address at which to put "length" data words "length" data words IOWD length, address at which to put "length" data words "length" data words . . . XWD length of entry vector, pointer to first word of entry vector And that's all there is to it.  Date: Wed, 20 Jun 1984 13:35 EDT Message-ID: From: Gail Zacharias To: bug-midas@MIT-MC, Moon%SCRC-TENEX@MIT-MC.ARPA Subject: @BINPRT In-reply-to: Msg of 20 Jun 1984 04:36-EDT from David A. Moon Date: Wednesday, 20 June 1984, 04:36-EDT From: David A. Moon ... I wish I knew how to do :BINPRT on Twenex. I've often wished this too. I believe Midas doesn't put the necessary info in .EXE files. Is it because there is no place to put it or because nobody has bothered? How hard would it be at least put the source filename (and site) somewhere?  Received: from MIT-MC by MIT-OZ via Chaosnet; 20 Jan 84 15:23-EST Date: 20 Jan 1984 12:18 PST (Fri) Message-ID: <[SRI-NIC].IAN.20-Jan-84 12:18:11> From: Ian Macky To: E Gordon Strong Cc: bug-midas@MIT-OZ Subject: a question In-reply-to: Msg of 20 Jan 1984 12:01-PST from E Gordon Strong Yes, there is a .BYTE psuedo. You can do something like .BYTE 8. ? byte ? byte ? byte ? .BYTE which will pack "byte"s into 8.-bit chaos-style bytes; you can also do like .BYTE x,y,z ? byte1 ? byte2 ? byte3 ? .BYTE which packs byte1 into an x-bit byte, then byte2 into a y-bit byte, etc. All this stuff is documented in the MIDAS INFO node; there is a leaf on pseudos. For version numbers, you can also just use the MACROS.MID file on OZ (and probably on EE also), which has VERSION defined (as:) Define VERSION who,maj,min,edit Field(who,<700000,,0>)+Field(maj,<77700,,0>)+Field(min,<77,,0>)+edit Termin Hmm, actually, that would probably be better as a .BYTE construct...  Received: from MIT-EECS by MIT-OZ via Chaosnet; 20 Jan 84 15:02-EST Date: 20 Jan 1984 1501-EST From: E Gordon Strong Subject: a question To: bug-midas at MIT-OZ Is there a MIDAS pseudo-op analogous to BYTE in MACRO? Since the "correct" way to code Tops-20 programs is to use entry vectors, I wish to store the version information in the third word, as is done in several macro programs. I really dislike the macro assembler, but would like to use this feature in my midas programs. I would rather not construct the version information by hand. Thanks, Gordon -------  Date: 24 November 1983 05:42 EST From: Ken Harrenstien Subject: midas libraries To: GZ @ MIT-MC cc: BUG-MIDAS @ MIT-MC GZ@MIT-MC 11/15/83 13:54:36 Re: midas libraries I have this library on OZ, LIB:MACSYM.MID which translates many of the macros in MACSYM.MAC. I like to use it in programs I write, but with OZ being off the net, it's hard for me to tell people how to get hold of this library. Is there some place I could put it, like MIDAS; or something, so it goes out with Midas? It seems at least as general/useful as MIDAS;XJSYS ... Putting it in MC:MIDAS; is reasonable. I can include a pointer to it in the comments which describe how to install MIDAS on TOPS-20. If you do so, however, I would recommend that the MC version be considered the "canonical" version, so any changes made on OZ would have to be copied over quickly. That sound OK?  Date: Mon 17 Oct 83 16:58:16-PDT From: Ken Harrenstien Subject: .SCALAR bug To: "gz@oz"@MIT-MC cc: bug-midas@MIT-MC That appears to be a real bug. The code for .SCALAR/.VECTOR shares a lot of code with .GLOBAL and consequently is not looking up the symbol properly. I don't know if I understand it well enough to fix it, but in the meantime, you can win if you use the old single-quote construct such as inqpag'. -------  Date: Mon, 17 Oct 1983 07:07 EDT Message-ID: <[MIT-OZ].GZ.17-Oct-83 07:07:22> From: Gail Zacharias Subject: block structure To: bug-midas@MIT-MC.ARPA The following gets a "multiply defined" error: inqpag==100 .begin hakinq .scalar inqpag .end hakinq  Mail-From: KLH created at 4-Oct-83 13:49:28 Date: Tue 4 Oct 83 13:49:27-PDT From: Ken Harrenstien Subject: Re: Midas improvements. To: G.EGK@SU-SCORE, info-midas@MIT-MC cc: KLH@SRI-NIC In-Reply-To: Message from "Edjik " of Sun 2 Oct 83 17:15:13-PDT ReSent-date: Thu 13 Oct 83 00:21:40-PDT ReSent-from: Ken Harrenstien ReSent-to: info-midas@MIT-MC MIDAS does have this ability (FOO=BAR"), however it (and many other such features) exist only for the ITS STINK relocatable format, rather than the LINK format. I am looking at what would be required to provide functionality similar to STINK, but this is somewhat difficult as there are a bunch of things that STINK format allows, which LINK doesn't, so it requires really understanding what is going on in order to let only the LINK-allowable things happen. The person who did .DECREL originally took the easy way out by requiring things to be assembled more or less pseudo-absolutely. I haven't given up, but it's tough going as very little of the STINK format is documented. Fortunately a lot of it is extremely similar to LINK, and they are doubtless related far back in the dim past. -------  Date: 12 Oct 1983 10:33 EDT (Wed) Message-ID: <[MIT-OZ].IAN.12-Oct-83 10:33:21> From: Ian Macky To: Bug-MIDAS@MIT-MC.ARPA CC: GZ%MIT-OZ@MIT-ML.ARPA, RWK%MIT-OZ@MIT-ML.ARPA The following will die horribly: IRP ac,,[T,TT,A,B] IFNDEF ac,.FATAL ac is not defined IFLE ac-4,.FATAL ac must be not 1-4 TERMIN giving "TERMIN longer than 6 chars" (and a long string of other nasty message, eventually killing it), because of the "DEFINE". If I change it to IRP ac,,[T,TT,A,B] IFNDEF ac,.FATAL ac is undefined IFLE ac-4,.FATAL ac must be not 1-4 TERMIN then it works.  Date: 11 Oct 1983 15:47 EDT (Tue) Message-ID: <[MIT-OZ].IAN.11-Oct-83 15:47:16> From: Ian Macky To: Ken Harrenstien Cc: BUG-MIDAS@MIT-MC.ARPA Subject: IF1,[ .INSRT foo ] In-reply-to: Msg of 11 Oct 1983 15:19-EDT from Ken Harrenstien Nope, no storage is defined... it's just macros. The file is [OZ]LIB:MACROS.MID if you want to look.  Date: 11 October 1983 15:19 EDT From: Ken Harrenstien Subject: IF1,[ .INSRT foo ] To: Ian @ MIT-OZ cc: BUG-MIDAS @ MIT-MC I bet you will find that the .INSRT'd file is defining sme storage words. Either re-insert it on pass2, or find the code in it which is (presumably unexpectedly) screwing you.  Date: 11 Oct 1983 02:05 EDT (Tue) Message-ID: <[MIT-OZ].IAN.11-Oct-83 02:05:31> From: Ian Macky To: Ken Harrenstien Cc: BUG-MIDAS@MIT-MC.ARPA Subject: IF1,[ .INSRT foo ] Well, actually, what I was doing was IF1,[ .INSRT file DEFINE ... TERMIN DEFINE ... TERMIN ];End IF1 There was just no way I could make it work... what happens is this: [PHOTO: Recording initiated Tue 11-Oct-83 2:00AM] TOPS-20 Command Processor 5(742)-2 [Commands] !h: !midas tfinger @FINGER @FINGER CHNTAB+3 212 0. 3-028 OUTJFN Multiply defined CHNTAB+4 213 0. 3-029 HSTJFN Multiply defined CHNTAB+5 214 0. 3-030 PLNJFN Multiply defined CHNTAB+6 215 0. 3-031 MAIJFN Multiply defined CHNTAB+7 216 0. 3-032 CHAJFN Multiply defined CHNTAB+10 217 0. 3-033 TTLJFN Multiply defined CHNTAB+11 220 0. 3-034 PURJFN Multiply defined CHNTAB+12 221 0. 3-035 LLOJFN Multiply defined CHNTAB+13 222 0. 3-036 LMJFNS Multiply defined CHNTAB+25 234 0. 3-038 NOW Multiply defined CHNTAB+26 235 0. 3-039 ELAPSE Multiply defined CHNTAB+27 236 0. 3-040 RUNT Multiply defined CHNTA^C ! and from there on everything defined with a : get's Multiply-defined errors.  Date: 10 October 1983 16:38 EDT From: Ken Harrenstien Subject: IF1,[ .INSRT foo ] To: IAN @ MIT-OZ cc: BUG-MIDAS @ MIT-MC I recommend using: IF1, .INSRT FOO or if you like brackets: IF1,[ .INSRT FOO ] I haven't tried the following but it may also work: IF1,[ .INSRT FOO ;] The problem is that the .INSRT filename reader gobbles the whole line except for comments. At best you will get a filename parsing error, or a message about unbalanced brackets starting at the IF1. Conditionals are not like macros, they do not first gobble their arguments and then do something with them. They just set flags and dispatch to the appropriate stuff (regular assembly if successful, flush-conditional-text if unsuccessful).  Date: Mon 10 Oct 83 09:44-EDT From: Ian Macky Subject: IF1,[ .INSRT foo ] To: BUG-MIDAS@MIT-OZ Is there something wrong with doing that? I tried to put an IF1 around an .INSRT of a macro library and it died... putting the IF1 in the macro file itself died the same way (I can send details if you don't know the symptoms)  Date: Sun 2 Oct 83 00:25:46-PDT From: Edjik Subject: Midas improvements. To: info-midas@MIT-MC.ARPA One thing I've noticed MIDAS missing that MACRO has, is the ability to have external symbols in equals (=). This is quite handy and makes writing modules easier. Dunno how hard it would be to make MIDAS generate the appropriate LINK record but it probably is worth it. --E+ -------  Date: Wed 28 Sep 83 18:12:33-PDT From: Ken Harrenstien Subject: Some questions To: info-midas@MIT-MC cc: klh@SRI-NIC I have a few questions about some things I found in the MIDAS BUGS file. I seem to be in a mood to fix them, depending on the kind of answers I get... 1. .FAS or .FASL? Some people claim that on TOPS-20, output files generated with the .FASL pseudo-op should have the extension .FASL rather than .FAS. Is this true? Is this also true for TENEX? 2. TOPS-20 CCL? This purportedly no longer works for V3+. Where do I find out how it should work? Should compatibility with V2- be retained? 3. MIDAS .INSRT library? I would like to provide a system-independent way of allowing programs to .INSRT commonly used files. For this purpose I am thinking of adding a new pseudo called .INSLIB which would act exactly like .INSRT with the difference that the device/directory names would default to a place containing standard, public, or useful MIDAS .INSRT packages. This place can be defined on a per-system basis. If it was ever desired to change these defaults for a single assembly, this could be done by giving an .INSLIB specification with an explicit device/directory and no filename. Comments welcomed. 4. Others? If you have some ideas which have never been sent to BUG-MIDAS, now is a good time, not because I plan to try doing anything but because I am interested in seeing whether other people have found undocumented bugs or have hidden wish lists. I have a loooong list of MIDAS ideas as well as bugs, which will be available in MIDAS;IDEAS > (plus MIDAS BUGS), for those who care to avoid reiteration. The usual warning: very few such items ever get implemented. -------  Date: 27 September 1983 13:44 EDT From: Ken Harrenstien Subject: Mailing list on OZ... To: Ian @ MIT-OZ cc: INFO-MIDAS @ MIT-MC Yes, merge it (you can just point to it if you want to keep an OZ-specific group)... Latest version of MIDAS (not back on MC yet) fixes the various problems with building new MIDASes. I am currently scanning MIDAS BUGS (archive of bug-midas mail) to see if there are any interesting things that are easy to add before installing it.  Date: 27 Sep 1983 03:29 EDT (Tue) Message-ID: <[MIT-OZ].IAN.27-Sep-83 03:29:17> From: Ian Macky To: Info-MIDAS@MIT-OZ Subject: Mailing list on OZ... There's this list here... maybe it should be merged? It's mostly to do with 20-only stuff, usually OZ-only, like new packages and junk. MIDAS-USERS=Ian Jeh ZZZ Marty *SS:MIDAS.ARCHIVE Gumby egk GZ-OZ GS  Date: 16 September 1983 01:29 EDT From: Alan Bawden Subject: Adventures assembling MIDAS To: KLH @ MIT-MC cc: BUG-MIDAS @ MIT-MC In-reply-to: Msg of 15 Sep 1983 04:20 EDT from Ken Harrenstien Since you mentioned INFO-MIDAS, and since there was no such mailing list on MC, I hunted it down in the old AI:.MAIL.;NAMES > file kept on MC:KSC; and created it on MC. (Yes, I did check to see that it wasn't on OZ first.) Info-MIDAS used to be archived in AI:MIDAS;INFO MINS, a file we no longer have.  Date: 15 September 1983 04:20 EDT From: Ken Harrenstien Subject: Adventures assembling MIDAS To: MARTY @ MIT-OZ cc: BUG-MIDAS @ MIT-MC, ALAN @ MIT-MC, Moon @ SCRC-TENEX Yes, the proper method of putting together a T-20 MIDAS is not well documented. I am now fixing that, as well as making the purification code really work (all it is useful for on T20 is catching bugs, however). When done the new version will be available as usual from the canonical MC:MIDAS; location and announced to info-midas.  Date: 31 Aug 1983 21:48 EDT (Wed) Message-ID: <[MIT-OZ].MARTY.31-Aug-83 21:48:44> From: Martin David Connor To: Bug-Midas@MIT-MC Cc: Alan@MIT-MC, Moon@SCRC-TENEX Subject: Adventures assembling MIDAS A funny thing happened on my way to fixing a file server... First I consed up a TWXBTS file from UNV:MONSYM.MAC following the instructions in SS:TWXBTS.CONSING. Then I tried to compile, with the CVTSW off. [PHOTO: Recording initiated Wed 31-Aug-83 9:16PM] TOPS-20 Command Processor 5(742)-2 [COMAND] !i j Job 15, User MARTY, SS:, Account AI, TTY1 !midas midas /t MIDAS TTY: .INSRTed, end input with ^Z CVTSW==0 TNXSW==1 ^Z SS:TWXBTS.MID.10 1 0. 6-054 Comma past the 3rd field of a word 1 0. 6-054 Undefined format 2 0. 6-056 Comma past the 3rd field of a word .... 2 0. 6-056 Undefined format 3 0. 6-081 Comma past the 3rd field of a word 3 0. 6-081 Undefined format 4 0. 6-083 .... SS:TSRTNS.MID.194 422644 0. 54-032 DEFSTR Non-macro made macro in DEFINE Starting at 54-025 Pure pages = 14 ST = 13271 SS:TWXBTS.MID.10 EISYM1+1725 101255 1. 6-056 Garbage in ASCIZ-style macro arg in DEFSTR Starting at 6-054 EISYM1+1726 101256 1. 6-056 %%FNLC Undefined in LOC 101256 0. 6-056 Stray ) 101256 0. 6-056 Undefined format 101325 1. 6-083 ..... Garbage in ASCIZ-style macro arg in DEFSTR Starting at 6-081 101326 0. 6-083 Stray ) 101326 0. 6-083 Undefined format 101331 1. 6-090 Garbage in ASCIZ-style macro arg ..... ^C !;sigh. !pop [PHOTO: Recording terminated Wed 31-Aug-83 9:19PM] My, my, someone call a priest. Then I found the program CVT which I used to conse up a TNXDFS.MID file: [PHOTO: Recording initiated Wed 31-Aug-83 9:20PM] TOPS-20 Command Processor 5(742)-2 [COMAND] !i j Job 15, User MARTY, SS:, Account AI, TTY1 !midas midas /t MIDAS TTY: .INSRTed, end input with ^Z CVTSW==1 TNXSW==1 ^Z Pure pages = 14 ST = 13271 22206 words initialization coding. MINPUR-MAXMAC = 7 MIDAS Constants area inclusive From To 423146 426002 76453 76532 Run time = 1:07.57 7094 Symbols including initial ones (70% used) Well, it assembles, let's try purifying it. !v midas SS: MIDAS.CONSING.1;P777752 1 1173(7) 31-Aug-83 20:20:37 MARTY .DIF.1;P777752 1 2284(7) 31-Aug-83 02:14:09 MARTY .EXE.1;P777752 68 34699(36) 31-Aug-83 21:20:28 MARTY .MID.433;P777752 127 64841(36) 5-Apr-83 18:16:05 IAN .435;P777752 127 324202(7) 31-Aug-83 02:20:18 MARTY Total of 324 pages in 5 files !get midas.exe.1 !start purify ?Illegal instruction 256006,,0 at 417757 ?Invalid access requested Can't fool me, just barfed trying to do a SPACS call on a page that wasn't yours. !continue Purified, now SAVE Yes sir! !save midas MIDAS.EXE.2 Saved !v midas.exe SS: MIDAS.EXE.1;P777752 68 34699(36) 31-Aug-83 21:20:28 MARTY .2;P777752 47 24064(36) 31-Aug-83 21:27:14 MARTY Total of 115 pages in 2 files !get midas.exe.2 !i mem 46. pages, Entry vector loc 420074 len 254000 Section 0 R, W, E, Private 0-3 MIDAS.EXE.2 1-4 R, CW, E 76-120 MIDAS.EXE.2 5-27 R, CW, E 400-426 MIDAS.EXE.2 30-56 R, E !;looks good, but will it assemble? !midas ss:file FILE JOB FOR TOPS-20 (OZ's munched on version) NETWRK.MID included in this assembly. FILE JOB FOR TOPS-20 (OZ's munched on version) NETWRK.MID included in this assembly. END OF IMPURE=2770 START OF PURE=3000 END OF PURE=15570 FIRST BUFFER LOC=22000 Constants area inclusive From To 13740 15567 Run time = 9.74 5639 Symbols including initial ones (71% used) !;works fine. !pop [PHOTO: Recording terminated Wed 31-Aug-83 9:29PM] Now, I said all that to say that for my money MACCNV (or the instructions on how to use it) are broken, because the TWXBTS file that it generates is not assemblable. Perhaps someone would like to look into this. CVT seems to do fine. Maybe there is no need.  Date: 31 Aug 1983 02:52 EDT (Wed) Message-ID: <[MIT-OZ].MARTY.31-Aug-83 02:52:18> From: Martin David Connor To: David A. Moon Cc: bug-file@MIT-OZ, BUG-LISPM@MIT-OZ, bug-midas@MIT-OZ, Ken Haase , bug-system@MIT-OZ Subject: Options needed on file write. In-reply-to: Msg of 30 Aug 1983 15:09-EDT from David A. Moon Date: Tuesday, 30 August 1983, 15:09-EDT From: David A. Moon To: Ken Haase cc: BUG-LISPM, bug-file, bug-midas Re: Options needed on file write. Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS; Tue 30-Aug-83 15:15:01-EDT Date: Tuesday, 30 August 1983, 14:38-EDT From: Ken Haase In Release 4.4, Experimental LMRLL 11.0, FEP 12, site configuration 58, on Lisp Machine Janis Joplin: This should offer to run DIRED or CLEAN Directory. >>Error: File system bug on host MIT-OZ: Disk structure completely full (at 6021 inside FILE server) For OZ:PS:RLL.LISP It would have if the Lisp machine had known that this error meant "disk structure completely full". As you can see, it says "File system bug." I've reported this at least once before: the bug is that MIDAS is broken on OZ; it assembles the wrong system error codes into the FILE server. I don't remember now the exact error code that is wrong (or, more likely, undefined). Someone at OZ should fix MIDAS and reassemble SS:FILE.MID and start the resulting binary at PURIFY, which will dump it into SYSTEM:CHAOS.FILE. Fixed. The file server should now know all about IOX34 (Disk structure completely full). Fixing MIDAS was a pain. The TWXBTS file on OZ seems to be missing some things. I ended up getting the TNXBTS file from XX, and SRCCOMing XX's version of MIDAS with OZ's. What we have now is a MIDAS that is basically a TENEX version, but it seems to have everything defined properly. Also, starting MIDAS PURIFY barfs it when it tries to set the page access of a the core image (did I say CORE), but if CONTINUED it seems to win. There is a pure version now on PS:. If anybody *really* knows how to assemble a TOPS-20 version of MIDAS that uses TWXBTS, please spill your guts. MACCNV sort of works, but what it produced would not compile properly.  Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS; Tue 30-Aug-83 15:15:01-EDT Date: Tuesday, 30 August 1983, 15:09-EDT From: David A. Moon Subject: Options needed on file write. To: Ken Haase Cc: BUG-LISPM@MIT-OZ, bug-file@MIT-OZ, bug-midas@MIT-OZ In-reply-to: The message of 30 Aug 83 14:38-EDT from Ken Haase Date: Tuesday, 30 August 1983, 14:38-EDT From: Ken Haase In Release 4.4, Experimental LMRLL 11.0, FEP 12, site configuration 58, on Lisp Machine Janis Joplin: This should offer to run DIRED or CLEAN Directory. >>Error: File system bug on host MIT-OZ: Disk structure completely full (at 6021 inside FILE server) For OZ:PS:RLL.LISP It would have if the Lisp machine had known that this error meant "disk structure completely full". As you can see, it says "File system bug." I've reported this at least once before: the bug is that MIDAS is broken on OZ; it assembles the wrong system error codes into the FILE server. I don't remember now the exact error code that is wrong (or, more likely, undefined). Someone at OZ should fix MIDAS and reassemble SS:FILE.MID and start the resulting binary at PURIFY, which will dump it into SYSTEM:CHAOS.FILE.  Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 31-Jul-83 21:03:14-EDT Date: Sunday, 31 July 1983, 21:01-EDT From: David A. Moon Subject: Re: disk full error should give space-making proceed options To: bug-midas@MIT-OZ Cc: JTW@MIT-MC, Zvona@MIT-OZ, bug-twenex@MIT-OZ, BUG-LISPM@MIT-OZ, bug-file@MIT-OZ In-reply-to: The message of 31 Jul 83 19:44-EDT from David A. Moon IOX34 and IOX35 are undefined in Midas on OZ. Hence the FILE server installed there is misassembled.  Date: 2 June 1983 15:35 EDT From: Ken Harrenstien To: BUG-MIDAS @ MIT-MC Just testing, ignore this message.  Date: 26 May 1983 17:55 EDT From: Ken Harrenstien Subject: Building a new MIDAS for 20X To: IAN @ MIT-OZ cc: BUG-MIDAS @ MIT-MC Date: Thursday, May 26, 1983 3:27PM-EDT From: Ian Macky After I've assembled one up, do I need to purify it? PURIFY$G and it bombs out on a SPACS with illegal access requested. Anyone know what's going on? More details on request... No, don't bother purifying it. That stuff was for debugging but never really got debugged.  Date: Thursday, May 26, 1983 3:27PM-EDT From: Ian Macky Subject: Building a new MIDAS for 20X To: Bug-MIDAS at MIT-OZ After I've assembled one up, do I need to purify it? PURIFY$G and it bombs out on a SPACS with illegal access requested. Anyone know what's going on? More details on request...  Date: Mon 2 May 83 15:38:33-PDT From: Mark Crispin Subject: non-zero sections To: Ian%MIT-OZ@MIT-MC.ARPA, Marty%MIT-OZ@MIT-MC.ARPA, Bug-MIDAS%MIT-OZ@MIT-MC.ARPA, NCP.EGK@GSB-HOW Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) There is absolutely no way to get MIDAS to do a DECSAV with a non-zero section, just as there is no way to get PSECTs out of MIDAS. Your best bet is to do it the release-4 way; that is, have your code all boot in section 0, then SMAP% itself up into section 1. This isn't too bad since very few programs require more than 256K for code; it's generally data structures that get so big. MIDAS was a real nice assembler. Too bad it's fallen so far behind the times. We've abandoned FAIL for much the same reasons0. -------  Date: 2 May 1983 15:21 EDT (Mon) From: Ian Macky To: Bug-Midas@MIT-OZ Subject: [NCP.EGK: How Does one ...] Date: Mon 2 May 83 10:34:29-PDT From: Edjik To: Ian%oz%MC at SCORE, Marty%OZ%MC at SCORE Re: How Does one ... Received: from GSB-HOW by SCORE with Pup; Mon 2 May 83 10:35:03-PDT Get midas to do a DECSAV with a non zero section?  Date: 6 Apr 1983 16:30 EST (Wed) From: Ian Macky To: Ken Harrenstien Cc: BUG-MIDAS@MIT-MC Subject: MIDAS 433 In-reply-to: Msg of 6 Apr 1983 16:16 EST from Ken Harrenstien MACCNV is a Teco library that does MONSYM->TWXBTS in the current buffer (and fails trying); Hmm, creation day of the original was in '80 sometime, last mod by MT. Hmmpf. ;UNGETting the current system Midas after the patch results in one that's 4 pages longer; it works, tho. I'll try it on that WATSON program once I rearrange it again and let you know.  Date: Wed 6 Apr 83 13:43:55-PST From: Mark Crispin Subject: Re: MIDAS 433 To: KLH@MIT-MC.ARPA cc: Ian@MIT-OZ.ARPA, BUG-MIDAS@MIT-MC.ARPA Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In-Reply-To: Your message of Wed 6 Apr 83 16:16:00-PST I officially provided CVT to MIT years ago. The dispute which prevented its redistribution was resolved to everybody's satisfaction. If you can't find it, grab MRC:CVT.MID. CVT reads in the SYS:MONSYM.UNV and SYS:MACSYM.UNV files and makes a TNXDFS from it. This reads the UNVs, not the sources. -------  Date: 6 April 1983 16:16 EST From: Ken Harrenstien Subject: MIDAS 433 To: Ian @ MIT-OZ cc: BUG-MIDAS @ MIT-MC What is MACCNV? Is it a frob to gobble MONSYM and output TWXBTS? MRC had such a program, but didn't want it re-distributed; is this the same one? Don't bother explicitly purifying MIDAS on 20X, the TNX purify stuff was basically for debugging. Just patch it and dump it back with ;Unget.  Date: 5 Apr 1983 18:52 EST (Tue) From: Ian Macky To: Ken Harrenstien Cc: BUG-MIDAS@MIT-MC Subject: MIDAS 433 In-reply-to: Msg of 5 Apr 1983 16:26 EST from Ken Harrenstien Sigh. I grabbed the latest source from AI, and the TXWBTS and TNXDFS files needed to assemble it, but I can't get MACCNV to do anything reasonable with out MONSYM... the warning says to remove the INFDEF FOR,< ... >'s, which I do, but then it dies (Search failed) along the way... it dies if you leave them in, too. Anyone know how to make this work? I can't patch the .EXE we have since FILDDT doesn't believe it's a real .EXE file, and if I ;Yank it into an NDDT and then ;Unyank it out, and then try and purify it, MIDAS dies in an SPACS trying to set access to a non-existant page... this is pretty grim.  Date: 5 April 1983 16:26 EST From: Ken Harrenstien Subject: MIDAS 433 To: IAN @ MIT-MC cc: BUG-MIDAS @ MIT-MC I think I fixed your problem. You can either gobble MIDAS 433 from AI, or patch MINUS+3 to a JFCL. This shouldn't break anything that previously worked, but stay alert just in case. New MIDAS installed on *ITS:SYS;TS MIDAS.  Date: 5 April 1983 13:43 EST From: Christopher C. Stacy To: BUG-MIDAS @ MIT-MC Test  Date: 5 April 1983 13:38 EST From: Ken Harrenstien Subject: WATSON bug To: IAN @ MIT-MC cc: BUG-MIDAS @ MIT-MC Well after all that, how could I not look at the bug? You seem to have made a pragmatic fix in WATSON already, but I was able to write a small test program that tickled it. It's about what I expected; MIDAS is being confused by seeing both [a,,b] and [-a,,b] where a and b are not yet defined, and is doing constants optimization which tries to produce only one unique constantt whenever possible. On pass 2 it discovers its mistake and complains with a straight face. The fix for now is to define those symbols ahead of the constants reference. It is a real MIDAS bug, though. Will see if I can grovel over the optimization code.  Date: Tue, 5 Apr 1983 04:45 EST From: Leigh L. Klotz To: Edjik Cc: BUG-ITS@MIT-MC, BUG-MIDAS%OZ@MIT-MC, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC, KLH@MIT-MC Subject: Gross OZ lossage In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik KLH knows more about midas than most people, including you. Please keep your nitbrained views to yourself.  Date: Tue, 5 Apr 1983 03:26 EST From: PGS@MIT-OZ To: Edjik Cc: BUG-MIDAS@MIT-MC, KLH@MIT-MC Subject: Gross OZ lossage In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik Date: Mon 4 Apr 83 11:41:35-PST From: Edjik Gosh, I wonder just how many people on the 6 mailing lists that KLH shotgunned his msg to really give a ff about where the MIDAS sources live. Probably damn few. Oz is the successor to AI. Moving mailing lists and sources of system programs to it from AI seems natural to me. Since KLH got the msg Ian sent, he still is on the new offical list at oz, so why gripe? His talk of "sacrilege" conjures up images of the inquisition. Is KLH the defender of the ITS faith? Probably KLH's main gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20 site to look at the sources. If he uses it for TOPS-20 and 10X software, why does he need it on ITS? I hope the people in charge of the MIDAS mailing list and sources do the appropriate thing in response to KLH's flame, ie. ignore it. -- Edjik KLH is the only person who maintains MIDAS these days. Thus it is good to keep the sources in a place where he finds it convenient to access them. If he wanted to keep them in his back pocket it would be fine by me and most people here, so long as the rest of the world could get at them there. It seems to me completely bizarre and unpleasant of you to send a message like this about something you have nothing to do with.  Date: 5 April 1983 01:43 EST From: Alan Bawden Subject: Gross OZ lossage To: MARTY @ MIT-OZ cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, DCP @ MIT-MC, KLH @ MIT-MC In-reply-to: Msg of 4 Apr 1983 23:19 EST (Mon) from Martin David Connor What is all this flaming horseshit in my mailbox?!?! Is there anyone who will argue that it was correct that there were TWO BUG-MIDAS mailing lists? No. Have we fixed that? Yes. (Thank you Ian.) Now is there somebody out there who can actually claim to be maintaining MIDAS to a greater extent than KLH? If so, then lets hear from them. If not, then everyone shut the hell up.  Date: 5 April 1983 00:57 EST From: David C. Plummer Subject: Gross 8 inch spikes in various people's heads To: MARTY @ MIT-OZ cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, KLH @ MIT-MC, BUG-MIDAS @ MIT-OZ And you, Mr. Conner, have as much to learn as I. Reactionary is not bullshit. Go read a history book someday and notice how progress is often achieved by reactionaries and their ideas. As for the local history of OZ, there were several people willing (and eager) to help in creating another ITS. Moon was willing to hack microcode and oversee changes needed to the system (e.g., for disk support) which I was willing to help with. As I recall, you were against the idea of ITS on OZ. Several other people attended the Wars of Futility where it was decided to run 20X. These people warned about all the features that 20X was lacking and many of the problems it had. But the wars were futile; the decision was out of our hands. So now our only recourse is to sit back and be little brats about the whole thing. "Nah, nah, I told you so..." I, for one, am proud to be one of these brats. For god's sake bring up a machine because it is the Right Thing, not because you hate another machine so much. Wrong. Both are often true. In fact, this is how TWENEX was developed. The history told to me was that BBN disliked Bots-10 so much they went off and wrote TENEX. DEC started seeing the light and bought it from them and made it work on a 20. Learn from the mistakes of another attempt, ... If TWENEX only could. Plummer, ... until you learn to work FOR A GOAL instead of AGAINST AN ALTERNATIVE you will be counterproductive to the causes you Support. Goal: Help build better Lisp Machines. I think I am working for this goal. Goal: help MIT when I have the time. I think I do a fair job here. Goal: convince people they lost completely when they decided to run TWENEX on OZ. Perhaps this is a subconsious goal. How actively I work toward it is not clear. I would hope to think I keep such discussions among (ITS) friends except when something blatant happens. If you didn't blindly defend the obvious problems, OZ would probably be a lot nicer. Penny, I already know I will regret sending this, because so many minds are already closed, but I had to try. Forgive me. Mine is closed just enough so that spikes cannot penetrate. I know who does the real TWENEX development at MIT, and they have often responded to the requests of others for (ITS-like) features. I hope they also understand the spirit in which I write these flames. Marty, you earned your second spike.  Received: from GSB-HOW with Pup; Mon 4 Apr 83 11:42:17-PST Date: Mon 4 Apr 83 11:41:35-PST From: Edjik Subject: Re: Gross OZ lossage To: KLH@MIT-MC cc: BUG-OZ@MIT-MC, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC, BUG-MIDAS%OZ@MIT-MC In-Reply-To: Your message of Mon 4 Apr 83 13:53:00-PST Gosh, I wonder just how many people on the 6 mailing lists that KLH shotgunned his msg to really give a ff about where the MIDAS sources live. Probably damn few. Oz is the successor to AI. Moving mailing lists and sources of system programs to it from AI seems natural to me. Since KLH got the msg Ian sent, he still is on the new offical list at oz, so why gripe? His talk of "sacrilege" conjures up images of the inquisition. Is KLH the defender of the ITS faith? Probably KLH's main gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20 site to look at the sources. If he uses it for TOPS-20 and 10X software, why does he need it on ITS? I hope the people in charge of the MIDAS mailing list and sources do the appropriate thing in response to KLH's flame, ie. ignore it. -- Edjik -------  Date: 4 Apr 1983 15:31 EST (Mon) From: Ian Macky To: Ken Harrenstien Cc: BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, bug-mail@MIT-OZ, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC Subject: Gross OZ lossage In-reply-to: Msg of 4 Apr 1983 13:53 EST from Ken Harrenstien Hmm. Since you obviously have strong feelings about this, and since that mailing list was screwed up by their being two parallel versions (one on OZ and one on AI), I have done as you asked (insisted) and merged the two and put the now official list on MC, with appropriate pointers all around.  Date: 4 April 1983 13:53 EST From: Ken Harrenstien Subject: Gross OZ lossage To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ. This implies that OZ has a BUG-MIDAS mailing list, and furthermore that this list is NOT the same as the official list on AI. This reminds me of the BUG-ATSIGN lossage. I consider myself one of those people who now and then maintain MIDAS. For the list to be moved without notice is reprehensible. For it to not be on an ITS is sacrilege. I must insist that either AI or MC be the official home of MIDAS sources and mailing lists. This should probably apply to all ITS developed software. Since I was the person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly use it for 10X/20X software, you can hardly say my viewpoint is wedged.  Date: 4 April 1983 13:53 EST From: Ken Harrenstien Subject: Gross OZ lossage To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ. This implies that OZ has a BUG-MIDAS mailing list, and furthermore that this list is NOT the same as the official list on AI. This reminds me of the BUG-ATSIGN lossage. I consider myself one of those people who now and then maintain MIDAS. For the list to be moved without notice is reprehensible. For it to not be on an ITS is sacrilege. I must insist that either AI or MC be the official home of MIDAS sources and mailing lists. This should probably apply to all ITS developed software. Since I was the person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly use it for 10X/20X software, you can hardly say my viewpoint is wedged.  Date: 4 Apr 1983 12:28 EST (Mon) From: Ian Macky To: Bug-Midas%MIT-OZ@MIT-MC This table assembles fine as is: CmdTab: nCmnds,,nCmnds [Asciz "All"],,[AHelp,,All] [Asciz "Brief"],,[BHelp,,Brief] [CM%INV ? Asciz "Display"],,[-SHelp,,Show] [Asciz "Done"],,[DHelp,,Done] [Asciz "Edit"],,[EHelp,,EditIt] ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; [CM%INV ? Asciz "Exit"],,[-SHelp,,Show] ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; [Asciz "Fast"],,[FsHelp,,Fast] [Asciz "Help"],,[HHelp,,Help] [Asciz "Kill"],,[KHelp,,Kill] [Asciz "List"],,[LHelp,,Show] [Asciz "New"],,[NHelp,,New] [Asciz "Old"],,[OHelp,,Old] [Asciz "Quit"],,[QHelp,,Quit] [CM%INV ? Asciz "Show"],,[-SHelp,,Show] [Asciz "Slow"],,[SHelp,,Slow] [Asciz "Verbose"],,[VHelp,,Verby] [Asciz "Zero"],,[ZHelp,,Zero] nCmnds==.-CmdTab-1 and changing the bounded line to [CM%INV ? Asciz "Exit"],,foo where foo was defined previously as FOO: -DHelp,,Done works too, but if you do [CM%INV ? Asciz "Exit"],,[-DHelp,,Done] then I get a "More constants on pass 2 than pass 1" after the CONSTANTS op at the bottom of the program. The program is [OZ]SUB:WATSON.MID  Date: 10 February 1983 06:39-EST (Thursday) Sender: GUMBY @ MIT-OZ From: David Vinayak Wallace To: bug-midas @ MIT-OZ Subject: .FASL Files assembled under twenex with the .FASL pseudo-op end up with filetype FAS. this is OK for tenex, but no good for me.  Date: 5 Feb 1983 0116-EST From: EGK at MIT-OZ at MIT-MC (Edjik) Subject: MIDAS does NOT put JSYS Names in Symbol Table To: Bug-Midas at MIT-OZ at MIT-MC This bug has been buggin' me for a long time. Since most of the people I've spoken to privately seem to not think this is a bug, I'm sending this to the "official" bug list. The bug: MIDAS does NOT put JSYS Names in Symbol Table The Symptom: When DDTing a program written in MIDAS, Jsi appear as: JSYS instead of: PSOUT% or GTJFN% or etc. The Cure: Make Midas put the JSYS names in the programs symbol table. Note saying, "Use NDDT" is not a fix. NDDT knows about jsys names. DDT knows only about whats in the symbol table. Everyone has DDT. Only a fortunate few have NDDT. DDT is supported by DEC. NDDT is NOT. Not fixing Midas will only hasten its death. Its too winning an assembler to castrate it by not saveing JSYS names! Cheers, -- Edjik -------  Date: Tuesday, 21 December 1982 08:12-EST Sender: KLOTZ at MIT-OZ From: Leigh L. Klotz To: Sam cc: Bug-midas at MIT-OZ Subject: ?NIB errors In-reply-to: The message of 20 Dec 1982 23:19-EST () from Sam I just remembered that the problem with MTOPR was that MIDAS in its current dump thinks that MTOPR is different from what it is or something. I think it needs to be redumped with the V5 symbols read in. Leigh.  Date: 15 Nov 1982 2041-EST From: Sam Hsu Subject: System defs To: Bug-Midas at MIT-MC cc: CLamb at BBNA, Tappan at BBNA is there a way in Midas to get the equivalent of Macro's .SEARCH MONSYM,MACSYM and .REQUIRE MACREL? i'd like for it to get the system symbols in monsym, and the macros from macsym. is the way to do this .INSRT MONSYM.MID that was generated using MACCNV or CVT.EXE? that sounds right - i could use the SYSTEM.MID package? how about the MACSYM stuff? how can i get access to those macros defined in there? any help would be appreciated. sam -------  Date: 26 Oct 1982 0214-EDT From: Michael Travers Subject: Problem parsing twenex JCL To: bug-midas at MIT-OZ at MIT-MC If you invoke midas by saying "r sys:midas" to the EXEC, it will interpret the "sys:midas" as the file to assemble. -------  Date: Tuesday, 3 August 1982 04:34-EDT Sender: GREN at MIT-OZ From: GREN at MIT-MC To: BUG-MIDAS at MIT-MC CC: RMS at MIT-MC Subject: MIDAS bug The main program: ------- 20X==1 IFN 20X,[ .INSRT ME:FOO ];20X BEGIN: HALTF END BEGIN ------- the file it inserts: ------- IFNDEF $$SYMGET, $$SYMGET==0 .BEGIN DIEGO IFN $$SYMGET,[ ;[ ] ;END IFN $$SYMGET .END DIEGO ------- and it loses horribly. Why? The open bracket in the conditionalized comment line is not seen as a comment, but as a real open-bracket of some sort. If I change the line from ;[ to ;[] then it wins. *SIGH* --gren (after a long night) -------  Date: 16 May 1982 04:19-EDT From: Richard S. Hall To: BUG-MIDAS at MIT-MC Is there a way to suppress the listing of false conditionals in Midas assembly listings? I like to produce listing files to see if my macros are expanding properly, but if all the failing conditionals are listed it produces a cluttered and extremely large file. Surely there must be some way around this but I have been unable to find any information on this (or much else about listing control) in the on-line doc. Thanks, Rick Hall  dcp,alan@MIT-MC (Sent by DCP@MIT-MC) 03/19/82 00:45:04 Re: MIDAS outsmarting itself with undifined constants in literals To: (BUG MIDAS) at MIT-MC title midas bug go: move 1,[foobar/2,,0] ;these are uniquized to ;the same thing on pass one move 1,[-foobar,,0] ;but on pass 2... constants foobar: end go gives the following dialog: midas bug midas bug GO+4 104 0. 1-008 More constants on pass 2 than 1 Constants area inclusive From To 102 102 Run time = 0.13 1378 Symbols including initial ones (50% used)  Date: 2 March 1982 02:03-EST From: Ken Harrenstien Subject: literals in = To: GZ at MIT-MC cc: BUG-MIDAS at MIT-AI Sorry, that is how a two-pass assembler must work. It cannot assign the address for [...bar...] until it knows where it is going to put the literal, which isn't until later. Suggest that you simply make a macro out of it, as in define foo [...bar...] termin Or give it a real location, as in foo: ...bar... Depending on your tastes. MIDAS will merge all references to literals of the same value, which is why the macro above is still efficient.  GZ@MIT-MC 02/09/82 04:22:26 Re: literals in = To: (BUG MIDAS) at MIT-MC Doing something like foo=[... bar ...] where bar is not defined until later, gives an error (on pass 1 only of course) of "Undefined in =". This is annoying, since it is obviously not an error (everything needed to define foo is there on the first pass, and it does assemble correctly), and forces you to start ignoring some error messages, a dangerous thing.  Date: 28 January 1982 14:14-EST From: Stavros M. Macrakis Subject: :info Midas To: BUG-INFO at MIT-MC, BUG-MIDAS at MIT-MC Ideally, of course, the Midas info should be fully formattted for use in Info. But as an interim step, it would be nice if section numbers in headings were complete (e.g. B.3.b) so that string search will find sections.  Date: 18 Jan 1982 2130-PST From: KLH at SRI-NIC Subject: minor bug To: bug-midas at MIT-AI TSRTNS 195 on SRI-NIC has the SKIPE T,CMPTR at CMD: changed to SKIPLE T,CMPTR. This fixes a bug wherein 10X JCL was ignoring switches (/T in particular). I will install on AI when there is enough disk; just noting it here to avoid forgetfulness. -------  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: 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? -------  KLH@MIT-AI 12/18/81 06:36:47 To: DCP at MIT-MC CC: (BUG MIDAS) at MIT-MC I don't think the GAPFLS$G is ever necessary...  DCP@MIT-MC 12/12/81 18:43:09 To: (BUG MIDAS) at MIT-MC CC: DCP at MIT-MC Finally, :rename ai:sys;ts omidas,ts oomidas :rename ai:sys;ts midas ,ts omidas :link ai:sys;ts midas ,ts omidas :job midas :load midas;ts mid430 gapflsG purifyG :install ai:sys;ts midas --DM was down-- I will do be hand later. I have not deleted any files, in case I did something wrong. (It is hard to tell, since there aren't any directions.)  DCP@MIT-MC 12/12/81 04:05:00 Re: .value --> .lose To: (BUG MIDAS) at MIT-MC I changed the two .VALUEs in TSYMGT to .LOSE %LSSYS as threatened. I tried to assemble it, but I now give up. AI:MIDAS;MIDAS 430 is the version I created. MIDDIF 429430 is the comparison, TS MID430 is the assembled version, and TS ERR is the error file, which contains MIDAS Pure pages = 13 ST = 12335 2076 words initialization coding. 46000 0. 197-062 Pure too low. MINPUR-MAXMAC = 777777777767 MIDAS 46000 0. 197-062 Pure too low. Constants area inclusive From To 362162 364455 37075 37134 Run time = 2:05.76 3635 Symbols including initial ones (36% used) I have now idea if that is a an OK response, and I'm not awake enough to decide if it is or isn't. I'm not going to run it either, for fear it will bash the current installed MIDAS when it purifies itself, and I don't want to have to rename the current good one and go through all that junk in case something does go wrong. It would be nice if there were more documentation on how to assemble the damn assembler. (Some of us haven't been around for n years and therefore don't know all these things.)  Date: 9 December 1981 16:34-EST From: David C. Plummer Subject: Shouldn't this .LOSE instead of .VALUE To: BUG-MIDAS at MIT-AI The following is from the MIDAS assembler: TSYMGT: MOVE AA,[MXICLR-MXIMAC,,MXICLR] .CALL INITSB ;GET MACTAB PAGES NNOT LOADED INTO. .VALUE IFN PURESW,[ MOVE AA,[MINBNK-MINMAC,,MINBNK] .CALL INITSB ;GET PAGES FOR BLANK CODE & SYMTAB. .VALUE INITSB is a CORBLK request. My question: Why, if the CORBLK fails, does this .VALUE instead of .LOSE 1000? If CORBLK fails it is likely due to system bloat, and it is probably restartable. .VALUE does not let it restart, while a .LOSE does. If I hear no objections, I will change this and install it in a couple days; so if there is a really good reason why it should be .VALUE, please tell me now!  DCP@MIT-MC 09/15/81 22:25:12 Re: HUH?? To: (BUG MIDAS) at MIT-MC The program title foobar a=b b=2 end gives the error file foobar 100 0. 1-002 B Undefined in = foobar Run time = 0.14 1347 Symbols including initial ones (49% used) The INFO documentation reads = sets 's value to 's. If there are undefined symbols in the assignment is not performed. This construct is illegal where a value is needed, but if it is the last thing in a grouping it does supply the value of the grouping. Thus, FOO= is legal, though FOO=BAR=1 is not. Is this an error or a warning? (Notice the message is only for pass 1; it seems to be happy on pass 2.) Is it a bug to print the message on pass 1, or is it (in my opinion) a misfeature? The word assembler (the one who will convert MOVE A,B into a PDP-10 word) only complains on pass 2 that MOVE, A or B is undefined. Why should this be different?  Date: 1 May 1981 03:33-EDT From: Paul T. Friedl To: BUG-MIDAS at MIT-AI Would it be possible for me to get a symbolic listing of a large MIDAS program. I wish to use it as a model for my MIDAS programming. Thanks... Paul  Date: 2 February 1981 02:32-PST (Monday) From: WANCHO at DARCOM-KA To: BUG-MIDAS at AI Subject: MIDAS 428 cc: WANCHO at DARCOM-KA Well, you can half-cancel my previous MIDAS bootstrap request. I imported MIDAS.EXE.428 from XX and it seems to work. However, for future reference, I would like to know how to generate a new MIDAS for this TENEX machine. I now have the following: MACROS.MID;39 SYSTEM.MID;13 (from XX - I used to have ;8) TNXDFS.MID;6 TSRTNS.MID;194 (from AI - had ;192) TWXBTS.MID;12 (from AI - had ;3) XJSYS.MID;5 I tried regenerating a new MIDAS using the MIDAS from XX and the source from AI. All seemed to go well, except the generated version was 64 disk pages instead of the 68 that the XX MIDAS has. Also, when trying to generate a new CRTSTY using the generated MIDAS, .ICIFT, .ICILI, and .ICPOV show up as Undefined. The MIDAS from XX doesn't generate these Undefines. Why? What am I doing wrong, or better yet, what should I do? If you tell me that there is no Tenex dependencies and I can go ahead and use the versions found on XX, I will quietly go away. Thanks, Frank  Date: 1 February 1981 22:13-PST (Sunday) From: WANCHO at DARCOM-KA Subject: MIDAS 428 To: BUG-MIDAS at AI cc: WANCHO at DARCOM-KA Some time ago I tried to compile the latest CRTSTY and it bombed. EAK said that I would need the latest MIDAS (we have 416). So I brought over MIDAS 428 from AI and it bombed with: 0 0. 1-003 .SYMTAB 1st arg too big Error is fatal. Anybody have any idea how to boot up to 428? --Frank  Date: 13 January 1981 19:25-EST From: Earl A. Killian Subject: [LARSON: midas] To: Scott at SRI-KL cc: BUG-MIDAS at MIT-AI Any ideas? Yes, use ATSIGN.  Date: 13 Jan 1981 1044-PST From: Scott J. Kramer Subject: [LARSON: midas] To: Bug-MIDAS at MIT-AI It apparently doesn't like /C, am using the latest Twenex version here (ie, same as on XX & EE). -sjk --------------- Date: 8 Jan 1981 2007-PST From: LARSON Subject: midas To: Scott I cannot get it to make a cref listing for me. Here is what I said to it: midas temp_teco/T/C EMCSDV==1 INFODV==1 COMNDF==1 ^Z Any ideas? Alan ------- --------------- -------  Date: 10 Dec 1980 1556-PST From: Scott J. Kramer Subject: Re: MIDAS bug found and fixed To: EBM at MIT-XX, taa at MIT-XX, pdl at MIT-XX, clr at MIT-XX, bug-twenex at MIT-XX, bug-midas at MIT-AI In-Reply-To: Your message of 10-Dec-80 0953-PST In case anyone's interested, the fixed MIDAS is now installed as MIDAS at EECS. -sjk -------  Date: 10 Dec 1980 1253-EST From: EBM at MIT-XX Subject: MIDAS bug found and fixed To: taa at MIT-XX, pdl at MIT-XX, clr at MIT-XX, bug-twenex at MIT-XX, To: bug-midas at MIT-AI MIDAS broke some time ago, when all the MONSYM symbols were added. First, there were symbol table size problems, but JONL managed to get around that. The symptom that had been tripping me up was that a particular MONSYM symbol, .TICCA, was no longer defined. I have tracked this down, and fixed it, and have installed the working MIDAS into SUBSYS. The previous version is in SUBSYS, too, in case there are other bugs that nobody has found yet. The problem was: In TWXBTS, some symbols (.ICxxx, the interrupt channels) were to be done in decimal instead of octal; this continued through the .TICxx codes, and a little bit later, the radix was again set to octal. It turns out that setting the radix overall does not work for the second insertion of initial symbols, because one line in the DEFSYM macro reads: SQUOZE 10,Z where Z is the symbol being defined. The radix change changes the 10 from 8. to 10., and manages to destory the values of the symbols. By some simple fixes to TWXBTS (by hand), I got around this difficulty. Suggestion: either MIDAS or the TECO macro that converts MONSYM.MAC into TWXBTS.MID be changed to recognize this difficulty. I also noticed that the TECO macro sometimes output ".RADIX10." instead of ".RADIX 10.", if that tends to make any difference. -------  Date: 17 NOV 1980 1459-EST From: JONL at MIT-MC (Jon L White) To: JIS at MIT-MC, SJK at MIT-MC CC: (BUG MIDAS) at MIT-MC, CPR at MIT-MC, ebm at MIT-XX Elliot Moss and I just reassembled MIDAS on XX, and noted a few rather simple differences (.TICCA being defined properly, for instance). Not sure what was wrong with the previous assembly, but I've moved the .EXE to EE, and Moss is going to put up a new copy on SPEECH.  Date: 4 November 1980 19:49-EST From: Earl A. Killian Subject: Assembling TECO To: JPERSHING at BBNA cc: BUG-MIDAS at MIT-AI, DPACHURA at BBND Date: Tuesday, 4 November 1980 16:33-EST From: John A. Pershing Jr. To: Earl Killian Re: Assembling TECO Is MIDAS system-dependent, or is it possible to FTP the .EXE file? MIDAS is so system-indepdendent that you can use the same .EXE file on 10X, release 1, release 3, and release 4. Also, what would cause MIDAS to crap out due to symbol table full? Dave Pachura is trying to boot EMACS up on the MIS machine, and can't seem to assemble either TECO or MIDAS (same error for both). Is it perhaps loading two copies of the JSYS table (e.g. the vanilla symbols and the %-versions of the same)? They are running release 3 (vanilla DEC). A MIDAS .EXE file has all the appropriate system symbols built into it at its own assembly time. Thus, if the MIDAS.EXE on BBND assembles TECO, then the same .EXE should assemble TECO elsewhere. I'm not sure what the problem is, then, unless that MIDAS will no longer assemble TECO on BBND. Note that the MIDAS on BBND has more system symbols than on XX (being generated from MONSYM.UNV), so it is possible it assembles on XX and not on D.  JONL@MIT-MC 10/31/80 05:05:40 To: (BUG MIDAS) at MIT-MC On twenex versions, a command line like FOO.EXE_FOO.MID should cause the FOO.EXE version number to be the same as that of FOO.MID or at the verrrrry least, there should be some way to specify this.  JONL@MIT-MC 10/24/80 12:34:35 To: (BUG MIDAS) at MIT-MC Date: 24 Oct 1980 0247-PDT From: Mark Crispin Subject: SYMDSZ in MIDAS For the TNXSW version SYMDSZ should be set to 6003 not 4003. You run out of symbols otherwise. It actually has to be even higher; also increased the .SYMTA at the beginning, when assembling for a Twenex system. New sources now on XX< and just about to be on AI.  Date: 24 Oct 1980 0247-PDT From: Mark Crispin Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 Stanford-Phone: (415) 497-1407 Subject: SYMDSZ in MIDAS To: Bug-MIDAS at MIT-AI For the TNXSW version SYMDSZ should be set to 6003 not 4003. You run out of symbols otherwise. -------  Date: 16 Sep 1980 1938-PDT From: Scott J. Kramer Subject: Re: .FASL op To: KLH at MIT-AI cc: BUG-MIDAS at MIT-AI In-Reply-To: Your message of 16-Sep-80 1805-PDT Only every MacLisp autoload depends on it being ".FASL". I'll check into the access problem, you should at least be in the right user groups to get at any MIDAS code lying around. -sjk -------  Date: 16 September 1980 21:05-EDT From: Ken Harrenstien Subject: .FASL op To: Scott at SRI-KL cc: BUG-MIDAS at MIT-AI Date: 3 Sep 1980 0319-PDT From: Scott J. Kramer Files produced on Twenex using this should have ".FASL" rather than ".FAS" as their extension. Looks like a carryover from Tops-10/SAIL in its present state. -sjk ------- Why? What software depends on looking for .FASL instead of .FAS? All the DEC software is certainly restricted to 3-letter extensions. In any case, I no longer have the necessary access to maintain MIDAS on SRI-KL. Their (CR) attitudes really put a damper on any enthusiasm I might have.  Date: Tuesday, 9 September 1980 20:26-EDT Sender: EMACS at BBND From: Earl Killian To: BUG-MIDAS at MIT-AI Subject: error in PURIFY$G A little while ago I reported that PURIFYG loses executing the SPACS JSYS. I found the problem, but don't have time to fix it now. The problem is that the TNX routines double the page number and no. of pages in order to convert from ITS-size pages. However, when there are an odd number of TNX pages in the area being operated on at PURID1, this loses because it will try to hack the last non-existant page that it thinks it should be there due to the doubling.  Date: 3 September 1980 10:45-EDT From: Earl A. Killian Subject: decsav format files To: JoSH at RUTGERS cc: BUG-midas at MIT-AI MIDAS has never produced sharable files. I'm afraid you'll have to go on doing GET/SAVE.  Date: 3 Sep 1980 0319-PDT From: Scott J. Kramer Subject: .FASL op To: Bug-MIDAS at AI Files produced on Twenex using this should have ".FASL" rather than ".FAS" as their extension. Looks like a carryover from Tops-10/SAIL in its present state. -sjk -------  Date: 3 Sep 1980 0300-EDT From: JoSH Subject: decsav format files To: bug-midas at MIT-AI the .exe file midas produces on twenex doesn't seem to be sharable, causing one to have to GET and SAVE it, eg: @midas NOTPUR MIDAS.423 *foo ... @foo FOO>^C @i me ... 0-100 Private R, W, E @get foo @save foo @foo FOO>^C @i me ... 0-100 FOO.EXE.2 1-101 R, CW, E I am under the impression that Midas used to save sharably, though when I tried to check with an old version of Midas (419), it blew up. --JoSH -------  Date: Wednesday, 27 August 1980 20:34-EDT From: Earl Killian To: BUG-MIDAS at MIT-AI I just assembled MIDAS 424 on a 20X and when I said PURIFY$G, it crapped out on a SPACS JSYS. Without the PURIFY$G it seems to run ok.  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. -------  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: 31 Jul 1980 0048-EDT From: JoSH To: bug-midas at MIT-AI 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). -------  Date: 19 July 1980 2100-EDT From: Joe.Newcomer at CMU-10A Subject: MIDAS bug (?) To: (BUG MIDAS) at MIT-AI Using MIDAS.419, I have the following experience compling the AT source: r midas at.639 which produces a TOPS-10 version of AT just fine, but doing: r midas at.639(t) SITE==:CMU20FLG ^Z to produce a TOPS-20/CMU version of AT, I don't get ANY .REL file, anywhere, of any description. In fact, the .REL file I found was a couple days old, and I went thru several compile/link/try-it cycles before discovering that I had bogus (TOPS-10) code on the TOPS-20 system. What gives? How can I get a .REL file (I am going to do the obvious of putting the SITE definition in the source, but that is not what people are going to want when the source is returned) joe  Date: 19 Jul 1980 1612-PDT From: Mark Crispin Subject: interesting bug To: Bug-MIDAS at MIT-AI 777777777777_-1 returns 177777777777 but A=777777777777 then A=A_-1 returns A=377777777777  Date: 10 JUL 1980 1817-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: MIDAS on a BOTS-10 To: BUDD at MIT-MC CC: (BUG MIDAS) at MIT-AI There are a couple of pseudo-ops like .DECTWO which set up high/low segments. To switch from one to the other after this, just save your loc counter with e.g. %%FOO==. and later you can switch back with a LOC %%FOO. Lots of programs separate themselves into a pure and impure segment this way, by having two loc-counter symbols; macros make it easier. The MIDAS source itself is one example. If this isn't what you wanted to know, ask again.  BUDD@MIT-MC 07/10/80 01:33:01 Re: MIDAS on a BOTS-10 To: (BUG MIDAS) at MIT-MC How does one control "context" switching between bagbiting DEC dual segments? I showed a MACRO (archaic DEC assembler) hacker ho to do GETTABs with a .OP and *BOY* did his jaw drop! -Phil Budne  Date: 3 JUL 1980 0235-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: LISP and DDT symbols To: EB at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC To: (BUG MIDAS) at MIT-MC The problem is a LISP bug, which I analyzed and reported some time ago. I thought JONL fixed it, but perhaps my memory deceives me.  Date: 28 JUN 1980 1738-EDT From: EB at MIT-AI (Edward Barton) To: (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI, (BUG MIDAS) at MIT-AI Consider the following file: if1,.insrt lisp;.fasl defs .fasl foobar==1 .global foobar fasend If it is assembled with MIDAS and loaded into LISP with SYMBOLS set to T, the error DDT BUG: PLEASE DO :BUG DDT DESCRIBING CIRCUMSTANCES occurs.  Date: 15 Jun 1980 1822-EDT From: EBM at MIT-XX Subject: New MIDAS cons'ed To: bug-midas at MIT-AI In order to permit larger multi-line literals, I edited the MIDAS source to increase the PDL size from 500. to 1500. (The C compiler uses large multi-line literals for its branch tables, which is why I needed to do this.) The new MIDAS, version 423, is installed on NEWSYS on XX. However I did not install it on ITS because when I assembled it the resulting file was 3 blocks shorter than SYS;TS MIDAS, so I thought something might be funny. It would appear that version 422 was never installed. Would the appropriate person either do the right thing, or tell me what to do? Thanks --- -------  Date: 14 Jun 1980 1625-EDT From: EBM at MIT-XX Subject: Multi-line literals To: bug-midas at MIT-AI There is a rather low upper bound on the number of words in a multi-line literal. I have evidence that this limit is about 150 to 160 lines. This is unfortunate because the C compiler uses a construct like this for it switch statement branch tables: move reg,[ lab1 lab2 ... labn ] where n can theoretically be fairly large, and quite reasonably could be 256 or 512, for an opcode branch table. (GZ managed to exercise this problem doing just that.) Is there any possibility of this being changed, or at least having the upper bound increased by a significant factor? Thanks --- -------  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  Date: 27 Mar 1980 1651-PST From: Mark Crispin To: EKILLIAN at BBN-TENEXA, BUG-MIDAS at MIT-AI In-Reply-To: Your message of 27-Mar-80 1555-PST Earl - Try increasing SYMDSZ to 6003. I have found this necessary in the version at SCORE. Only sites that use a TNXDFS that was made by CVT probably need to do this. -- Mark -- -------  Date: Thursday, 27 March 1980 18:28-EST From: Earl Killian To: BUG-MIDAS at MIT-AI I tried assembling MIDAS 422 on BBND and found that when the result was run, it complained of a symbol table overflow as soon as a file was given to it. I suspect that this is because of the large no. of JSYS names and bits defined in release 4. I'm not sure what parameter should be bumped; will someone figure this out, bump it, and then let me know. Thanks.  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.  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: 24 MAR 1980 1713-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: RLJFN To: MRC at MIT-AI CC: (BUG MIDAS) at MIT-AI I suggest that the HALT following the RLJFN simply be replaced with a JFCL. The temporary file kludge is there because at the time I was writing the conversion code, it was a lot easier to keep things straight if I emulated the ITS code fairly closely. Now that it is all pretty stable, the code could be modified to always use the target filenames, if anyone cares to do so.  Date: 24 Mar 1980 1213-PST From: Mark Crispin Subject: Re: MIDAS bug To: MMCM at MIT-AI cc: BUG-MIDAS at MIT-AI In-Reply-To: Your message of 24-Mar-80 0737-PST Well, Release 4 must have fixed the bug that RNAMF% didn't completely flush the JFN, because you get an unassigned JFN error on that RLJFN% now. I saw that other code jumped there, but decided to ignore that fact since that case seemed to be for errors in the assembly and you weren't going to go much further with MIDAS anyway. Why does MIDAS bother with that temporary file kludge on TOPS-20 anyway? It has a purpose on ITS, but on TOPS-20 it just makes things unnecessarily more complicated. -------  Date: 24 March 1980 10:37-EST From: Mike McMahon Subject: MIDAS bug To: Admin.MRC at SU-SCORE cc: BUG-MIDAS at MIT-AI Date: 22 Mar 1980 0729-PST From: Mark Crispin Subject: MIDAS bug Remove: SYSCAL RLJFN,[A] HALT at OCLOS5. I don't understand how this ever worked, since RNAMF% is defined to release the JFN in AC1. It works because RNAMF does not completely flush the jfn, you can do an RLJFN at least afterwards. I did not just flush it since other code jumps there.  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.  Date: 22 Mar 1980 0729-PST From: Mark Crispin Subject: MIDAS bug To: Bug-MIDAS at MIT-AI Remove: SYSCAL RLJFN,[A] HALT at OCLOS5. I don't understand how this ever worked, since RNAMF% is defined to release the JFN in AC1. You know, that SYSCAL macro just makes the code infinitely harder to follow through in DDT (besides losing nice things like ERJMP/ERCAL). Also, can't there be a more reasonable error handler than HALT? At the very least, it could output the last JSYS error. -------  KLH@MIT-MC 02/20/80 22:49:18 To: (BUG MIDAS) at MIT-MC This looks like a real bug. For the insrt files KSC;OUT 105, KSc;NUUOS 167, and KSC;MACROS 72, the two test files KSC;TESTB 1 and KSC;TEST 15 respectively bomb and win. The only difference between them is that the latter, which wins, has a random macro definition that isn't referenced anywhere by anything. The lossage for TESTB is that it gets a "more constants on pass 2 than pass 1" error, plus assorted other errors about phase globality and the like. Although this is for MIDAS 419 on MC, I verified that the bin has the right patch making it equivalent to MIDAS 420, i.e. it is zeroing ILNOPT at ASSEM2+1. So this must be some other problem. I hve encountered this before, but each time it appeared as if I "fixed" the problem in some way. This is the most glaring repeatable error I've encountered... I will keep these source files around as long as possible, but they are volatile and I don't know if the bug will disappear if I move them around.  FJW@MIT-MC 02/03/80 05:44:28 To: (BUG MIDAS) at MIT-MC Exactly what must I do to bring up the latest MIDAS on a Tenex machine? Does it need to be purified? I am now using what is externally labelled MIDAS.SAV;413 and signs on as NOTPURE 416. I suspect that there is something to be gained by moving up to 420... --Frank  Date: 17 DEC 1979 2059-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: Macro question To: (BUG MIDAS) at MIT-AI Once again I am wrestling with macros that never quite do what I want. I'd like to know what might break if the syntax for "parenthesized macro calls" was modified so that the argument scanning did NOT stop upon sighting a semicolon or EOL. Currently a parenthesized call looks like this: FOO(a,b,c, ; call will stop scanning here d,e,f) ; these will be ignored. The idea is to allow a parenthesized call to handle arguments on following lines, up to the closing paren/bracket. Comments would be ignored unless part of an argument, and EOL would gobble up all following whitespace so that indentation wasn't included in the next argument. I have entertained far wilder ideas, but ths particular mod would be pretty simple. It could be tried out by means of a .mllit-style switch, unless someone knows for sure that it would break a bunch of things.  Date: 31 AUG 1979 0045-EDT From: KLH at MIT-AI (Ken Harrenstien) To: SHADOW at MIT-AI CC: (BUG MIDAS) at MIT-AI Date: 30 AUG 1979 1637-EDT From: SHADOW at MIT-AI (Richard Mark Weinapple) What's the maximum number of symbol blocks permissible (and what would be necessary to change that number?) At the moment, 40 octal, with a nesting depth limit of 8. There is no way to change that short of re-assembling a new MIDAS.  GSB@MIT-ML 08/29/79 17:06:40 To: (BUG MIDAS) at MIT-ML Why ain't ..SRND & ..RRND defined?? (..RJCL etc are.)  EAK@MIT-MC 08/17/79 21:57:27 To: (BUG MIDAS) at MIT-MC I've suddenly run into a problem assembling CRTSTY: I get the error more constants on pass 2 than pass 1. For the life of me I can't figure out what is wrong. However, if I insert a CONSTANTS pseudo at the proper place then it assembles without error. That CONSTANTS is in the source now, labelled "; debug" if you want to look at it. The source is MC:SYSENG;CRTSTY >. Oh, also, the error only happens when I assemble it for Tops-20 with TINT==1, i.e. :MIDAS SYSENG;CRTSTY >/T CRTSTY ... TTY: inserted... TINT==1 ^C System? Tops-20 I'd appreciate it if someone could figure out why its getting this error, as there is no reason to have that extra CONSTANTS in there. Also, it's a lot faster to assemble on a 20X, since you don't have to assemble the whole TWXBTS file in...  Date: 20 July 1979 02:04-EDT From: Mike McMahon Subject: .DECSAV ? NOSYMS To: EKILLIAN at BBN-TENEXE cc: BUG-MIDAS at MIT-AI, KLH at SRI-KL Date: Wednesday, 18 July 1979 21:27-EDT From: Earl Killian Re: .DECSAV ? NOSYMS .DECSAV and NOSYMS creates a file that GET complains is badly formatted. fixed in the source (MIDAS;MIDAS 418).  Date: Wednesday, 18 July 1979 21:27-EDT From: Earl Killian To: KLH at SRI-KL, BUG-MIDAS at MIT-AI Subject: .DECSAV ? NOSYMS .DECSAV and NOSYMS creates a file that GET complains is badly formatted.  Date: 9 JUL 1979 0224-EDT From: RMS at MIT-AI (Richard M. Stallman) Sent-by: ___002 at MIT-AI To: EBM at MIT-AI, (BUG MIDAS) at MIT-AI INFO;MIDAS appears to contain documentation on MIDAS command strings. At least, the one on AI does.  Date: 8 Jul 1979 1650-EDT From: EBM at MIT-XX Subject: Midas documentation To: bug-midas at MIT-AI Documentation on the command line format seems to have gone away; the info on file name defaulting, etc. is there, but nothing about the fact that you type (e.g.) midas foo.bin_foo.mid (we) or whatever. This seems to be true on ITS and XX. -------  Date: 5 Jul 1979 1727-PDT From: Rubenstein at SUMEX-AIM Subject: MIDAS 416 works here now... To: bug-midas at AI I renamed .SYMTA to be .SYMTB and it seems to assemble (and run) fine... Stew -------  Date: 5 Jul 1979 1223-PDT From: Mitsw at SUMEX-AIM To: Rubenstein, Bug-MIDAS at MIT-AI the problem with assembling midas on tenex is that TWXBTS tries to define .SYMTA, since this is a pseudo-op, it apparently only generates 1 word (the squoze) in the initial symbol table, so that all symbols after that, including all pseudo-ops, are undefined. i dont know why this only loses on tenex, but the midas.sav in here was assembled from the sources also here and seems to work alright. -------  Date: 3 Jul 1979 0923-EDT From: EBM at MIT-XX Subject: MIdas 417 on XX To: bug-midas at MIT-AI Cc: jonl at MIT-XX, mmcm at MIT-XX Under instructions from Jonl and MMcM, I reassembled Midas 417 over here. I gather that I am supposed to assemble it with the T flag, and type in TNXSW=1, which I did. TSRTNS 192 seems to have problems with it; see MIDAS.ERR.1. The output from the assembly I did, which used MIDAS 417 and TSRTNS 191, is in MIDAS.ERR.2. The binary file, which appears to work directly (does not have to be loaded then dumped), is MIDAS.EXE.417; the broken one from before is NMIDAS.EXE.417. The sources I used were all in Problems: TNXDFS is inserted instead of TWXDFS Command line hacking is still not the best; the algorithm I think will work the best is as follows: If there is RSCAN input, use it; otherwise read from the primary input; if that fails too, THEN try the controlling terminal. In cleaning up RSCAN input, all prefixes of RUN should be checked for, as well as "(program)", which may be printed by altmode completion of the r or run command, and then the program name should be stripped, leaving a good command line. Conceivably, the PRARG feature might be used for passing arguments, too, but I don't think anyone uses it now. Note that the program name part of the RSCAN buffer may not be "midas", since people might create "pseudo-links" - small bootstrap programs that load another larger program. (We use these for CLU programs all the time.) I would be happy to talk with whoever is hacking the jcl interface to explain this further, if it is confusing. Thanks! Eliot Moss -------  Date: 2 Jul 1979 1536-EDT From: EBM at MIT-XX Subject: Problem w/midas 417 To: bug-midas at MIT-AI Cc: jonl at MIT-XX, mmcm at MIT-XX We encounter the following difficulty using Midas 417: when run from exec, there is no problem; when run from our text editor TED, it gets into an infinite loop. We redirect the primary input and output to/from files, so it does NOT have the terminal; BUT it should act as if it does, because we are presenting JCL in the file. The infinite loop comes from reading NUL: (apparently). It looks like an explicit test is made on whether Midas has the terminal, which is reasonable on most systems, but not here. Midas 416 did not have this problem. I renamed MIDAS.EXE.417 to NMIDAS.EXE.417, to get it out of the way. (MIDAS -> NMIDAS because a lot of us search first). This should not be too hard to fix. -------  Date: 2 July 1979 14:57-EDT From: Mike McMahon Subject: XX versions of MIDAS To: JONL at MIT-MC cc: BUG-MIDAS at MIT-AI Date: 06/30/79 13:56:54 From: JONL at MIT-MC Re: XX versions of MIDAS R MIDAS and RUN MIDAS as commands cause MIDAS to begin assembling itself. However, MIDAS as a command wins. this is a crock in TOPS-20 rescan which MIDAS doesnt bother to compensate for. there is no good reason for having to say RUN MIDAS, it means you have SYS: defined poorly. there is no reason at all for saying R MIDAS.  JONL@MIT-MC 06/30/79 13:56:54 Re: XX versions of MIDAS To: (BUG MIDAS) at MIT-MC Rescan on TOPS-20 must be crooked - both R MIDAS and RUN MIDAS as commands cause MIDAS to begin assembling itself. However, MIDAS as a command wins. Is this a loss in the TOPS-20 rescan, or a bug in MIDAS?  Date: 15 JUN 1979 1255-EDT From: JSOL at MIT-AI (Jonathan A. Solomon) To: INFO-MIDAS at MIT-AI i have a current copy of midas.322 and i have a source copy of midas.416 i cannot compile the new version with the old version as i do not have one of the funny definition packages for midas.322 (TSRTNS MIDAS) i wonder if you can tell me where i can pick up the proper copy. i try to assemble midas, and i get errors from the new (TSRTNS) file as it is for midas.416 please respond as soon as you can. thank you /jon solomon Stevens Inst. of Tech (respond to jsol@ml)  Date: 11 JUN 1979 2025-EDT From: MMCM at MIT-AI (Mike McMahon) Subject: MIDAS To: EBM at MIT-XX CC: (BUG MIDAS) at MIT-AI Date: 11 Jun 1979 1218-EDT From: EBM at MIT-XX Re: MIDAS MIDAS does not work, but MIDAS does. An example of a failing file is SETRECLEN.MID. ------- please try MIDAS  Date: 11 Jun 1979 1429-PDT From: Rubenstein at SUMEX-AIM Subject: MIDAS 416 To: bug-midas at AI I have MIDAS 416 and TSRTNS 191, straight off ai:midas; -- the binary and sources are MIDAS.MID;416 and .SAV. The binary is patched to force fl20x to 0. Stew -------  Date: 9 Jun 1979 1414-PDT From: Rubenstein at SUMEX-AIM Subject: MIDAS 416 To: bug-midas at AI I can't seem to get it to run right here -- I got midas 412 working a while ago, and it will assemble 416 with no errors, but when I run it (after making the ppatch to fool it into thinking we're a TENEX instead of TOPS-20), it comes out with all sorts of "Syllables not seperated" and "Comma past the 3rd field" and other error messages with files that assemble just fine under midas 412. Can anyone make a guess as to what's going on? Stew -------  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: 30 MAY 1979 2229-EDT From: MMCM at MIT-AI (Mike McMahon) Subject: Very straaaaaange bug To: (BUG MIDAS) at MIT-AI, Rubenstein at SUMEX-AIM try taking the newest MIDAS;TSRTNS, which should fix the problem.  Date: 30 May 1979 0028-PDT From: Rubenstein at SUMEX-AIM Subject: Addendum to last message To: bug-midas at AI I was able to make it work by inserting a couple of CRLF's before that line... But still, gentlemen.... Stew -------  Date: 30 May 1979 0026-PDT From: Rubenstein at Sumex-AIM Subject: Very straaaaaange bug To: bug-midas at AI I tried to assemble FIND.MID;74 and MIDAS said "No end statement... Last grouping: ( at 6-025..." Well, the last word it saw of my file was the first word on (file) page 10 -- that is, characters 50000-50004 . This word contained ",(pm%", being part of the line " movsi 3,(pm%rd)" or somesuch. Why did MIDAS think this was the end of file? There is nothing wrong with the EOF pointers, or anything else, about this file. Version 73, to which I had made trivial, unrelated changes at a different place in the file, assembles fine. Stew -------  Date: Thursday, 24 May 1979 18:20-EDT From: Earl Killian To: bug-midas at MIT-AI Subject: .FVERS It should be safe to have MIDAS use .FVERS instead of .FNAM2 now; how about it?  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: 19 May 1979 1626-EDT From: EKILLIAN at BBN-TENEXE (Earl A. Killian) Subject: DEFINE line bug To: bug-midas at MIT-AI 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? 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. -------  Date: 19 MAY 1979 0207-EDT From: RMS at MIT-AI (Richard M. Stallman) To: (BUG MIDAS) at MIT-AI I have changed TSRTNS so that .FVERS will "work" on Bots-10 just as it does on ITS.  Date: 19 MAY 1979 0020-EDT From: RMS at MIT-AI (Richard M. Stallman) To: EAK at MIT-AI, (BUG MIDAS) at MIT-AI Date: Thursday, 17 May 1979 15:02-EDT From: Earl Killian It'd be really nice to have a remainder operator in MIDAS. Is that the kind of operator that runs Feline's Basement?  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: 11 May 1979 1517-EDT From: EKILLIAN at BBN-TENEXE (Earl A. Killian) Subject: .FVERS To: bug-midas at MIT-AI cc: bug-atsign at MIT-AI What do .FVERS and .IFVERS do on Tops-10s? It'd be nice if the @ program used .FVERS instead of .FNAM2, but I don't want to break Tops-10 assemblies. -------  Date: 9 May 1979 1937-PDT From: Mark Crispin Subject: (forwarded mail) To: Bug-MIDAS at MIT-AI 09-May-79 1606 Rubenstein at SUMEX-AIM LOADTB To: MRC at SU-AI Date: 9 May 1979 1607-PDT From: Rubenstein at SUMEX-AIM Subject: LOADTB To: mrc at SU-AI I did some checking around; LOADTB is only defined in Tenex's that have a pie-slice scheduler, that is, Tenex 134. We're still running (something based on) Tenex 131. There must be some other way to tell... Why don't you use the JOBDIR table instead? I think that was renamed in Tops-20. Or SNAMES, which doesn't exist on Tops-20. Stew -------  Date: 5 May 1979 0705-PDT From: Crispin at SUMEX-AIM Subject: MIDAS at SUMEX To: Rubenstein cc: Bug-MIDAS at AI MIDAS bites the bag on SUMEX because SUMEX does not have the LOADTB table defined. MIDAS uses the presence of this table as an indication that the system is Tenex and not Tops-20. It seems to be the most reliable way (two others, GETTAB and checking for KL-ness, bite the bag in other ways elsewhere). Why doesn't SUMEX have a LOADTB table? I guess it is getting time for MIDAS to divorce the Tenex and Tops-20 versions. I don't see why Tops-20 MIDAS should be held back for Tenex primitive ways of doing things. I am unhappy about MIDAS not using ERJMP/ERCAL. -------  Date: Monday, April 23, 1979 14:28:29 From: Stewart Rubenstein Subject: MIDAS for tenex To: KLH@AI CC: BUG-MIDAS@AI The same binary does not work. For one thing, somebody does an RSCAN, which is 20x only. Secondly, when I try to assemble something, I get a bunch of errors (I don't remember what they were off hand, but the same source worked fine when assembled at SRI). Stew -------  Date: 23 April 1979 11:16-EST From: Ken Harrenstien Subject: MIDAS for Tenex To: RUBENSTEIN at SUMEX-AIM cc: BUG-MIDAS at MIT-AI It's not clear if anyone answered your question, so I guess I will. You shouldn't have to assemble a new MIDAS or anything. The same binary should work on both 10X and 20X. Are you sure you weren't just shafted by the difference between 10X and 20X sharable files (SAV & EXE)? Without more details I have no more suggestions.  Date: Wednesday, April 18, 1979 16:29:42 From: Stewart Rubenstein Subject: MIDAS for Tenex To: BUG-MIDAS@AI How can I build a MIDAS for Tenex? (as opposed to 20x -- I have a .sav file snarfed from SRI-KL that doesn't work) Stew -------  Date: 10 Apr 1979 2045-EST From: Mike McMahon To: EBM at MIT-XX Cc: (BUG MIDAS) at MIT-AI, MTravers at MIT-XX a confusion in "page" sizes has been fixed in MIDAS.EXE.416. BUG assembles ok now. -------  Date: 10 APR 1979 2153-EST From: MMCM at MIT-AI (Mike McMahon) Subject: previous report To: (BUG MIDAS) at MIT-AI, EBM at MIT-XX Date: 10 Apr 1979 1442-EST From: EBM at MIT-XX To: bug-midas Re: previous report I am still waiting for some reply to my previous TOPS-20 bug report. Is there anyone out there, or are my messages going into the infinite bit bucket ???? ------- i dont know exactly what you expect to happen; everyone has more than enough to do, and someone will look at it when they get a chance.  Date: 10 Apr 1979 1442-EST From: EBM at MIT-XX Subject: previous report To: bug-midas at MIT-AI I am still waiting for some reply to my previous TOPS-20 bug report. Is there anyone out there, or are my messages going into the infinite bit bucket ???? -------  Date: 7 Apr 1979 2155-EST From: EBM at MIT-XX Subject: Previous bug report To: bug-midas at MIT-AI I would appreciate some reply about the report I made a week ago. -------  Date: 2 Apr 1979 1433-EST From: EBM at MIT-XX Subject: More on previous bug report To: bug-midas at MIT-AI The bug appears to be rather simple: Midas tries to read beyond the last word of the file, and if that happens to put in onto a non-existent page of the file, the illegal memory read error occurs. This looks like the traditional fencepost (+ or - 1) error. Note: many XX files have their size in bytes recorded, and Midas seems to do things in terms of words. Maybe this is OK (since not all text files get their byte size and length in bytes recorded exactly right). -------  Date: 2 Apr 1979 1003-EST From: EBM at MIT-XX Subject: Midas bug on XX To: bug-midas at MIT-AI I got an illegal memory read on the file bug.mid; it looks like twenex-style page mapping is not being hacked quite right by Midas. This has happened to other people before, and it is repeatable, but rare (i.e., if I change the file a little (by adding comments) the problem goes away). -------  EAK@MIT-MC 03/30/79 18:57:19 To: (BUG MIDAS) at MIT-MC Why the hell is BLOCK illegal inside <>, () or [] ?  Date: 13 MAR 1979 0233-EST From: EAK at MIT-MC (Earl A. Killian) Subject: monitor definitions To: Admin.MRC at SU-SCORE CC: (BUG MIDAS) at MIT-MC Wouldn't it be better to change IDDT to have the monitor symbols pre-defined? Does anyone know if MARC's new IDDT does this already?  Date: 12 Mar 1979 2311-PST From: Mark Crispin Subject: monitor definitions To: Bug-MIDAS at MIT-AI Oh when oh when is MIDAS going to generate the JSYS symbols in the output file's symbol table? This is a complete and total screw, since DDT (on WAITS, Tops-10, Tops-20, and Tenex) simply does not know any UUO or JSYS definitions. I agree the symbol table is enormous, but at least it can do what MACRO and FAIL do and generate the used symbols into the output file. Having to look up the number and type 104000,,n is ridiculous! -------  MOON5@MIT-MC 02/25/79 04:45:28 To: (BUG MIDAS) at MIT-MC CC: MOON at MIT-MC Is the error message obtained by assembling MC:MOON;MIDAS BUG really a win? (Barfs at formfeed in ASCII string which is in a literal)  Date: 8 JAN 1979 2214-EST From: MMCM at MIT-AI (Mike McMahon) To: EKILLIAN at BBN-TENEXE CC: (BUG MIDAS) at MIT-AI Date: Monday, 8 January 1979 16:23-EST From: Earl Killian To: Bug-MIDAS Has anyone investigated the funny behavoir I reported a while ago? I'd like to have an up-to-date MIDAS, but I can't MIDAS 412 to assemble and work. i have tried all the latest files both at MIT-XX (20X) and SRI-KA (10X), and produced things that will assemble themselves and other sample programs correctly. Are you sure one of your files isnt munged?  Date: Monday, 8 January 1979 16:23-EST From: Earl Killian To: Bug-MIDAS at MIT-AI Has anyone investigated the funny behavoir I reported a while ago? I'd like to have an up-to-date MIDAS, but I can't MIDAS 412 to assemble and work.  Date: Sunday, 31 December 1978 16:02-EST From: Earl Killian To: Bug-Midas at MIT-AI Subject: XJSYS lossage I'm having all sorts of problems creating a new MIDAS. First I tried assembling a new version from MIDAS 412, TSRTNS 188, and XJSYS 5. However everytime I tried doing so with my MIDAS 409 I'd get tons of "Multiply defined" errors on pass two. So I assembled FTP'd the sources to XX and assembled it with the MIDAS 411 there. It worked ok and I brought it over to BBNE. To test it I tried to have it assemble itself. The assembly went ok, but the thing it produced doesn't work. At SITINI it does a SYSCAL CVHST,[FNBWP A]. FNBWP contains a reasonable byte pointer, but when the CVHST JSYS is XCT'd AC 1 has 3440 in it (FNBWP=3443). Since CVHST expects a byte pointer in AC 1, it bombs out. I'd appreciate it if someone could look into this and figure out what is going on. You probably don't want to send out this version on the EMACS distribution tape, either.  Date: 18 DEC 1978 1118-EST From: EAK at MIT-MC (Earl A. Killian) Subject: rel 3 midas To: KLH at MIT-MC, MRC at MIT-MC CC: (BUG MIDAS) at MIT-MC The problem with using JRST 4,. after JSYSs is that the illegal instruction error destroys the error which caused the failure return, making debugging difficult. What's wrong with a PUSHJ (or even a JSR) to a short routine?  Date: 18 DEC 1978 0623-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: rel 3 midas To: MRC at MIT-AI CC: (BUG MIDAS) at MIT-AI I'm surprised that you are complaining about this. I thought you weren't going to do anything about improving MIDAS for rel 3 unless the XX people relented, and didn't want others to do so either. I certainly can't do it without actually using XX (since SRI-KL is still waiting until Xmas for more rel 3 work) and while I do have an account there for that purpose, it seems like a strange situation. Have you actually been screwed by any of the jrst 4,'s? Without looking at the source, I would imagine that most of them are either in op-sys independent places or follow instructions that "should never" fail, including internal checks rather than just JSYS's. I suppose there could be a place for never-fail JSYS'S (which fail) to JSR to and hack ERSTR, but note that many JSYS's will just fail with an illegal instruction interrupt anyway, particularly on TENEX.  Date: 16 DEC 1978 0418-EST From: MRC at MIT-AI (Mark Crispin) Subject: Tops-20 MIDAS To: (BUG MIDAS) at MIT-AI MIDAS STILL does not have any code for release 3 CCL commands on Tops-20. nnnMID.TMP files do NOT exist on releases after release 1. It is a real loss for the COMPILE/LOAD/EXECUTE commands not to work. I can't believe you released MIDAS in this state. C'mon guys, the code necessary is only a few lines. Another problem is that MIDAS does JRST 4,'s on JSYS failures when it should really do ERSTR hacking. JRST 4, just prints an illegal instruction message, as if you executed a 0 or something.  Date: 16 DEC 1978 0413-EST From: RG at MIT-AI (Richard Greenblatt) To: (BUG MRC) at MIT-AI, (BUG MIDAS) at MIT-AI It obviously doesn't make a tinker's damn worth of difference what the hell gets used for a nop in any program anywhere. You have just wasted more computer power sending out your stupid message than will ever be spent on slow nops.  Date: 16 DEC 1978 0408-EST From: MRC at MIT-AI (Mark Crispin) To: (BUG MIDAS) at MIT-AI MIDAS (and other ITS software) should use "NOP" instead of JFCL, and allow sites to define NOP. JFCL is disgustingly slow on KL-10's, where CAI (SAIL) or TRN (DEC) is the preferred no-op. [DEC likes TRN 'cuz TRNA is the fastest KI no-op; SAIL sticks to CAIA for KA's and hence uses CAI. Of course, on KL's TRN/TRNA and CAI/CAIA are the same].  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.  KLH@MIT-MC 12/14/78 00:20:28 To: (BUG MIDAS) at MIT-MC I suspect there is some MIDAs bug with flags or smething that causes foo==1 foo==+1 to get a "FOO multiply defined" error.  Date: 13 DEC 1978 2208-EST From: MRC at MIT-AI (Mark Crispin) To: EAK at MIT-AI, (BUG MIDAS) at MIT-AI I GUESS HAVING A SWITCH WHICH DEFAULTS TO FLUSHING NULLS IS ALRIGHT, BUT I WOULD LIKE TO PRESS FOR AN UNDERSTANDING ON THE PART OF ALL CONCERNED THAT USING SIGNIFICANT NULLS IN A PROGRAM IS A VERY VERY BAD IDEA WHICH MAKES EXPORTABILITY AND EDITABILITY OF THE FILE IN QUESTION VIRTUALLY IMPOSSIBLE.  EAK@MIT-MC 12/13/78 21:01:07 To: KLH at MIT-MC CC: (BUG MIDAS) at MIT-MC What KLH is proposing seems reasonable to me. I'd like to point out that, while most of the times I've used nulls it's been for ASCIZ delimeters, in one program I had one inside an ASCII string constant.  Date: 13 DEC 1978 2020-EST From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI, EAK at MIT-AI OK, I'm convinced there are problems associated with nulls and that if someone writes a program source file that depends on having some nulls in it, they ae apt to face lossage with respect to some 20X software. However it still seems reasonable to me to have a switch-style frob so that winners who want to win can do so and losers who want to lose can also do so (pick your choice of viewpoints and associate it with either the on or off state). It should default to flush on T10 and 20X. This sort of adds the feature that you can request nulls flushed when you're on ITS! By the way I think it's untrue that a random ^C or ^Z will halt file input. This only happens when the "eof char" is exactly at the end of the file where it was cleverly placed by MIDAS. Of course, the only use I've found for ^@ has been in macros which do ASCIZ's of their arguments, and if MIDAS ever acquires string variables, this and many other crocks will disappear anyway. So maybe it's more worthwhile to spend time wrestling with that idea, than on fighting about nulls.  Date: 13 Dec 1978 0015-PST From: Mark Crispin To: EAK at MIT-MC CC: BUG-MIDAS at MIT-AI 12-Dec-78 1657 EAK at MIT-MC (Earl A. Killian) nulls You've indicated that TNX programs flush nulls, but if there aren't any TNX programs that insert them without being told then noone will be screwed. MRC - ANY PA1050 PROGRAM WILL INSERT NULLS. TREATING NULLS AS SIGNIFICANT, AND WORSE, DEPENDING UPON THAT, IS SUCH A BAD IDEA IT SHOULD BE FLUSHED IMMEDIATELY.  Date: 12 DEC 1978 1946-EST From: EAK at MIT-MC (Earl A. Killian) Subject: nulls To: MRC at SU-AI CC: (BUG MIDAS) at MIT-MC I'd hardly call providing a pseudo-op or something to control nulls a don't-give-a-damn-about-anybody-else attitude. What's more, not ignoring nulls can only screw people who use programs which add them un-asked for (such as E). You've indicated that TNX programs flush nulls, but if there aren't any TNX programs that insert them without being told then noone will be screwed.  Date: 12 Dec 1978 1413-PST From: Mark Crispin Subject: nulls To: EAK at MIT-MC CC: Bug-MIDAS at MIT-AI Foo! This is the sort of don't-give-a-damn-about-anybody-else attitude that DEC has been accused of. Every version of TENEX TECO (yes, dear, TENEX TECO) that I've ever had the misfortune to use flushes nulls. Why don't you have your PRIVATE copy of MIDAS not flush nulls without screwing the rest of the world. If you can't think of something better to use in CRTSTY, that's your own fault. I would think that CRTSTY is a program you might want to give out to the outside world, however, which would mean NO NULLS. I think I will change MIDAS to require control-meta-linefeed for the end of file character in all versions, flushing these losing ^C and ^Z users. They steal the capability to use beta or not-equals. As for people without bucky bit terminals, why should I care? After all, we have this winning null precedent here for not giving a damn who we screw.  Date: 12 DEC 1978 1141-EST From: EAK at MIT-MC (Earl A. Killian) Subject: MIDAS on Tops-10 To: MRC at MIT-MC CC: (BUG MIDAS) at MIT-MC I don't care what MIDAS does on Tops-10, but I do care about its operation on TNX systems, which I use. So it is not necessary to tell us how badly Tops-10s and Stanford will lose since they need not be effected. Second, you mentioned ASCIZ would lose: I'd like to point out that ASCIZ was exactly where CRTSTY was using nulls, as delimeters. This is a perfect use for them because nulls are the only characters which it doesn't make sense to put in a ASCIZ string. Also, I don't see that null usage forces you to use EMACS (though on TNX I have no idea what else you'd want to use). TNX TECO seemed perfectly able to deal with nulls in files in a little test I made. Finally, you claimed that all the same problems exist on Tops-20 because they use Tops-10 software. Well if they use all Tops-10 software they should have no objection to using MIDAS under Tops-10 simulation. Basically I don't see why MIDAS has to always lower itself to the lowest common dominator of the software world. It is as silly as the Header-People who argued against lower case because some people still used TTY 33s. Also I fail to see why you object to have null ignoring controlled by a psuedo-op or something, as KLH objected. That allows people that want to lose (or are forced to by their software) to lose, and people that want to win to win.  Date: 12 DEC 1978 0331-EST From: MMCM at MIT-AI (Mike McMahon) Subject: Nulls To: KLH at MIT-AI, MRC at MIT-AI CC: RMS at MIT-AI, EAK at MIT-AI, (BUG MIDAS) at MIT-AI Date: 12 DEC 1978 0316-EST From: KLH at MIT-AI (Ken Harrenstien) Perhaps it could be made a pseudo-invocable option. Or a MIDAS source assembly option. I don't know bout T-10 or WAITS, but I've never had any trouble with 20X files, in fact I've had less than with ITS owing to more consistent byte-size/EOF handling. Just as a matter of curiousity I'd be interested in why WAITS and T-10 lose with nulls, since I really hv no experience with them. TVEDIT puts in loads of nulls to fill out everything to page boundaries and doesnt have a write-out mode that flushes them, but i doubt anybody'd ever use it to edit a MIDAS program.  Date: 12 DEC 1978 0316-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: Nulls To: MRC at MIT-AI CC: RMS at MIT-AI, EAK at MIT-AI, (BUG MIDAS) at MIT-AI Perhaps it could be made a pseudo-invocable option. Or a MIDAS source assembly option. I don't know bout T-10 or WAITS, but I've never had any trouble with 20X files, in fact I've had less than with ITS owing to more consistent byte-size/EOF handling. Just as a matter of curiousity I'd be interested in why WAITS and T-10 lose with nulls, since I really hv no experience with them.  Date: 11 Dec 1978 2134-PST From: Mark Crispin Subject: nulls in input file To: Bug-MIDAS at MIT-AI, EAK at MIT-MC Please do not make MIDAS not flush nulls in the input file. Changing that would be a gross screw.  Date: 12 DEC 1978 0016-EST From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI CC: EAK at MIT-MC Date: 8 DEC 1978 2134-EST From: EAK at MIT-MC (Earl A. Killian) Damn, TNX MIDAS seems to lose on nulls in the input file; I'm not sure, but I think it ignored them. This caused some grief when I tried to assemble a TNX CRTSTY. [KLH - I think it does ignore them. DEC midas does at least. It has something to do with crufty SOS/EDIT line-numbers... not sure what best solution is.]  Date: 5 DEC 1978 0525-EST From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI Found it!! By sheer obscure coincidence (more or less) I ran into some missing symbols frm a .DECSAV assembly which I traced back to a missing tweak in BKSRT. Those bum-an-instruction hacks may make MIDAS faster/smaller, but they sure are a pain to figure out. Anyway, that was undoubtedly why MRC's block structure assemblies blew up on LOTS; when the monitor attempted to load the .EXE it was probably hitting EOF on the file before it could satisfactorily load all the symbols that MIDAS claimed were there. MIDAS;MIDAS 412 has the fix. It is simple enough to be easily patched (see MIDAS;MIDDIF 411412).  Date: 28 Nov 1978 0339-PST From: Mark Crispin Subject: .MID To: EAK at MIT-MC, Bug-MIDAS at MIT-AI I object strongly to changing .MID for the reasons that KLH mentioned. It seems like a totally worthless change whose only advantage would be somebody's idea of what is prettier, and which has the disadvantage of several screws. Why not leave well enough alone?  Date: 28 Nov 1978 0122-PST From: Klh at SRI-KL (Ken Harrenstien) Subject: File consolidation To: bug-midas at AI One thing that would be reasonable is combining TNXDFS and TWXBTS; I suggest that the latter be incorporated into the former. Presumably one file will never be without the other. This also makes it easier to substitute a single TNXDFS file of one's own manufacture. -------  Date: 28 NOV 1978 0332-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: JONL's suggestion To: EAK at MIT-MC CC: (BUG MIDAS) at MIT-AI, JONL at MIT-MC I would counsel leaving the extension as .MID for several reasons. One is that it is already a documented extension for MIDAS (documented by DEC even) and they keep their extensions to 3 letters for the very simple reason that there is so much T-10 software running on TNX in compatibility mode. If you feel like re-writing it all to let you win with full TNX extensions, fine. For example, as a first start you have to convert ATSIGN, which could use it anyway and doesn't have DEC copyright hassles attached. Let us know when it's done...  EAK@MIT-MC 11/27/78 22:23:46 Re: JONL's suggestion To: (BUG MIDAS) at MIT-MC CC: JONL at MIT-MC I'd gladly rename my MIDAS files to get a nicer extension like .MIDAS.  JONL@MIT-MC 11/27/78 22:13:05 To: (BUG MIDAS) at MIT-MC Is it too late to have the default extension be MIDAS for twenex and MID for TOPS-10? In general, it seems better to pick a name, and not shorten it on twenex, but shorten it only by truncation for TOPS-10.  KLH@MIT-MC 11/24/78 08:02:29 To: RWK at MIT-MC CC: (BUG MIDAS) at MIT-MC Well, I tried assembling MC:SYSEN1;PWORD 1699 with MIDAS 410 and it seemed to work fine, so either it was a super random bug or someone fixed it already.  Date: 24 NOV 1978 0750-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: separate source files To: MRC at MIT-AI CC: (BUG MIDAS) at MIT-AI Personally I prefer it kept separate, since this makes it more manageable and easier to edit. Furthermore its style is different (lowercase comments) and most everything in it concerns system dependent code, which I think is best kept smewhat removed from the main, system-independent, body of MIDAS itself. Other programs may .insrt XJSYS. That was its original intent I believe. In fact I'd rather see MIDAS more modularized than more monolithic. How would you like to have ITS > in one file?  Date: 24 NOV 1978 0059-EST From: MRC at MIT-AI (Mark Crispin) To: (BUG MIDAS) at MIT-AI Say, why not flush this separate TSRTNS file? It's enough of a pain having these xxxDFS and xxxBTS files without making it any worse. I think XJSYS should be in the main MIDAS file too.  Date: 21 NOV 1978 1733-EST From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI Have fixed TNX run-off-end bug in source, TSRTNS 187. Someone (RMS I guess) has fixed the listing-file rename bug.  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. -------  Date: 21 NOV 1978 1334-EST From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI I've found a simple fix for the TNX run-over-EOF bug, but uncovered another one which I haven't yet figured out. Fix is not yet in source.  Date: 21 NOV 1978 0306-EST From: KLH at MIT-AI (Ken Harrenstien) To: MOON at MIT-AI CC: (BUG MIDAS) at MIT-AI Date: 20 NOV 1978 2238-EST From: MOON at MIT-AI (David A. Moon) Do :midas tty: .insrt nosuch file And watch it bite the bag I tried this and it very reasonably told me no such file existed, use what filename instead?  Date: 21 NOV 1978 0208-EST From: KLH at MIT-AI (Ken Harrenstien) Subject: /CREF To: ekillian at BBN-TENEXE CC: (BUG MIDAS) at MIT-AI The CREF output file format is only understood by the ITS CREF program, so it is not assembled into non-ITS MIDASes. Tell him to use the winning ATSIGN program.  Date: 20 NOV 1978 2238-EST From: MOON at MIT-AI (David A. Moon) To: (BUG MIDAS) at MIT-AI Do :midas tty: .insrt nosuch file And watch it bite the bag  Date: 19 NOV 1978 0142-EST From: MOON at MIT-AI (David A. Moon) To: (BUG MIDAS) at MIT-AI When a fatal error, no END statement, occurs in pass 2 when the /L option was used, it forgets to rename the _MIDAS LSTOUT file.  Date: 17 NOV 1978 1552-EST From: KLH at MIT-AI (Ken Harrenstien) To: RMS at MIT-AI CC: (BUG MIDAS) at MIT-AI, DANG at MIT-AI, MMCM at MIT-AI Sorry if it was a mis-understanding, but knowing that you are about to distribute a tape, I want to be sure it's not a castrated midas on the tape. In the midas bugs file, the only message about block structure not working is from MRC; previously I had said that I made it follow the documented DEC format in LINKER manual. I certainly hope that all you did was insert a flag check, rather than removing the block-structure hiar for .decsav. Anyway, I would definitely be willing to make sure that it works, if MRC can furnish his lossage example. (as I recall it was utterly weird in that the monitor GET JSYS was crapping out on attempt to load! It is probably a 20X v3 monitor difference, since I have had no trouble with my block structured hacks on our v2. This is why XX would be useful. I would like to ask Dan if that is not a sufficient reason.  Date: 16 NOV 1978 1754-EST From: KLH at MIT-AI (Ken Harrenstien) To: RMS at MIT-AI CC: MRC at MIT-AI, (BUG MIDAS) at MIT-AI Why is "block structure in .DECSAV assemblies illegal"???? I need that!!!!!!! It works for me!!!!! Nobody has yet given me a reproducible example of lossage, so how can I debug it? I spent a lot of time making it work. I will not test the new MIDAS until that is restored.  Date: 15 Nov 1978 1523-EST Sender: EKILLIAN at BBN-TENEXE Subject: /C From: Earl A. Killian To: Bug-MIDAS at MIT-AI Message-ID: <[BBN-TENEXE]15-Nov-78 15:23:32.EKILLIAN> Is the /C supposed to generate a CREF? One user here tried to get a CREF from MIDAS and couldn't.  Date: 12 NOV 1978 1622-EST From: KLH at MIT-AI (Ken Harrenstien) To: rwk at MIT-MC CC: (BUG MIDAS) at MIT-AI If no one has looked at your problem yet, can you please save PWORD 1699 and 1700 (or a srccom of latter) on AI:MIDAS; along with any insrted files, so that I or someone else can reproduce the lossage later. Thanks. It does sound like an obscure bug.  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.  RWK@MIT-MC 11/10/78 21:41:01 Re: Obscure bug in .SYMTAB allocations? To: (BUG MIDAS) at MIT-MC :MIDAS SYSEN1;PWORD 1699 Answer "No" to the question. On pass 2 at label PURIFY+3 it tries to expand my SYSCAL macro completely wrong, ends up complaining that CORBLK is undefined (that's supposed to go into the sixbit /arg1/) and tries to put the second argument inside a ASCIZ (there is no ASCIZ in the SYSCAL macro). It works right on pass 1, and in SYSCAL's before and after. Didling the .SYMTAB parameters as in PWORD 1700 fixes this.  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.  Date: 16 OCT 1978 1949-EDT From: MMCM at MIT-AI (Mike McMahon) Subject: RUN MIDAS To: KLH at MIT-AI CC: RMS at MIT-AI, (BUG MIDAS) at MIT-AI, EAK at MIT-AI Date: 15 OCT 1978 0759-EDT From: KLH at MIT-AI (Ken Harrenstien) Well, there are all these ways of invoking it like [@]MIDAS and [@]midas.EXE.500 (with recognition) and so forth, which the current algorithm (flush until space seen) handles adequately and I'd like to keep that capability. Perhaps MMCM has a suggestion. Perhaps the EXEC can be modified so that it clobbers the RSCAN string to act just like ITS JCL, making sure thre is a space at the start of the string (as normally there will be anyway). whenever the command is started with a filename, the rscan line seen by the program will contain just the FN1 of the resulting file, so both of these cases would look just like MIDAS. there is of course the problem with NMIDAS or OMIDAS. this means perhaps checking for R or RUN as the first token and flushing the command line in only those cases. the RSCAN parser maybe can share some code with the TOPS-10 one, which is probably already hacking RUN MIDAS;FOO or whatever.  Date: 15 OCT 1978 0759-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: RUN MIDAS To: RMS at MIT-AI CC: (BUG MIDAS) at MIT-AI, MMCM at MIT-AI, EAK at MIT-AI RMS@MIT-AI 10/13/78 23:18:13 Re: RUN MIDAS To: KLH at MIT-AI I think that at least MIDAS should not do JCL rescanning if it can't recognize the command that ran it as being of a type that it understands. Simplest would be that anything other than "MIDAS " as the beginning of the command would cause it to ignore the "command string". This might slightly inconvenience someone but at least it prevents anyone from being really screwed. Well, there are all these ways of invoking it like [@]MIDAS and [@]midas.EXE.500 (with recognition) and so forth, which the current algorithm (flush until space seen) handles adequately and I'd like to keep that capability. Perhaps MMCM has a suggestion. Perhaps the EXEC can be modified so that it clobbers the RSCAN string to act just like ITS JCL, making sure thre is a space at the start of the string (as normally there will be anyway).  Date: 12 OCT 1978 1822-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: JLK at MIT-MC, (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC CC: BEE at MIT-MC Why does this crock persist that (when using .FASL) .ENTRY FOO SUBR 0001 means a subr of no arguments (i.e. it is always one more than what it should be)? Is there a reason for this? The answer is that the number 0001 is the "internal format" value of the ARGS property. Niceness might have dictated a better interface, but it suffices. People write 0001 instead of 1 to remind themselves that a crock is happening.  Date: 12 OCT 1978 1634-EDT From: JONL at MIT-MC (Jon L White) Subject: .FASL format ".ENTRY FOO SUBR 0001" To: JLK at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC I think that occurs due to the ease of modifying MIDAS, when RG first put in the .FASL option.  Date: 12 OCT 1978 1632-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC CC: BEE at MIT-MC Why does this crock persist that (when using .FASL) .ENTRY FOO SUBR 0001 means a subr of no arguments (i.e. it is always one more than what it should be)? Is there a reason for this?  Date: 11 OCT 1978 2030-EDT From: MRC at MIT-AI (Mark Crispin) To: KLH at MIT-AI, (BUG MIDAS) at MIT-AI Why would ANYBODY want to use the RUN command when the obvious right thing that everybody does is DEFINE SYS: DSK:,SYS: ???  Date: 11 OCT 1978 1255-EDT From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI RMS@MIT-AI 10/11/78 02:46:36 To: KLH at MIT-AI Another bug in Twenex MIDAS is that if it is run with @RUN MIDAS then it decides to assemble MIDAS. I'd consider this more of an EXEC screw, since MIDAS has no good way of knowing all the subtleties of EXEC command line syntax, and the goddam EXEC is simply passing on the whole last-line-input to the RSCAN buffer. I have trouble believing DEC's cretinism sometimes. Anyway, poor MIDAS is throwing away the first word in the belief it is a "MIDAS" (from [@]MIDAS FOO_BAR), and then takes the rest of the line as it would ITS JCL, which explains its action for [@]RUN MIDAS. If you use RUN a lot, I guess you could kludge the RSCAN reading routine.  Date: 10 OCT 1978 2326-EDT From: KLH at MIT-AI (Ken Harrenstien) To: (BUG MIDAS) at MIT-AI There is a bug in the TNX version such that in certain circumstances the char reader can somehow manage to skip over the EOF character, and it either continues to read merrily into nothingness (or zaps the read BP to a random location, I don't know which) and spews out an amazing variety of error messages in response. I suspect the same bug may exist in the ITS version also but manages to get caught after only one or two garbage characters. I'll have to look into it sometime.  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.  RWK@MIT-MC 09/29/78 17:49:59 To: (BUG MIDAS) at MIT-MC How about fixing the BININF info saved in BIN files to say AI: or ML: etc. instead of DSK: ??  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.  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.  RWK@MIT-MC 09/24/78 19:39:16 Re: re-written file lossage To: (BUG MIDAS) at MIT-MC The lossage isn't rare with large files...I've had it happen 3 times to me today alone. If a file is large enough to take a few minutes, it's very tempting to make more changes while waiting. I'd find it very helpful if some kind soul were to fix it. On an unrelated question....what must I do to define new .BREAK 12, symbols to MIDAS? Will purifying it under the new DDT work, or do I have to put it into a table in the source? Is there anything special I have to know to create an ITS MIDAS? Are the current sources runable? Are there volunteers to do it for me?  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.  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....  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?  Date: 20 SEP 1978 0924-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: Bug I reported yesterday To: MOON at MIT-MC CC: (BUG MIDAS) at MIT-AI MOON@MIT-MC 09/19/78 23:01:59 Re: Bug I reported yesterday To: (BUG MIDAS) at MIT-MC MC:MIDAS;TSRTNS 181 fixes this bug, I believe. Could someone who knows how to assemble, purify, install, and so forth Midas do so? Or else patch OINIT+13 from TLNN to TLNE. I must say, these TSRTNS are a complete and utter pile of shit. I moved the file to AI, which is where the master copies are (I never even knew a MIDAS directory existed on MC, although I won't mind keeping masters there instead), and assembled & etc'd into AI:MIDAS;TS MIDAS which can simply be copied into SYS;TS MIDAS if it works for you. BTW, if you want to know, just assemble MIDAS (no hair is ever necessary unless you're cross-assembling), and start at PURIFY$G which valrets a pdump. Sigh, I don't claim TSRTNS is wonderful but think it stinks a lot less than the previous hackery. If you tell me why it loses maybe the next effort will be better.  MOON@MIT-MC 09/19/78 23:01:59 Re: Bug I reported yesterday To: (BUG MIDAS) at MIT-MC MC:MIDAS;TSRTNS 181 fixes this bug, I believe. Could someone who knows how to assemble, purify, install, and so forth Midas do so? Or else patch OINIT+13 from TLNN to TLNE. I must say, these TSRTNS are a complete and utter pile of shit.  MOON5@MIT-ML 09/19/78 03:29:40 To: (BUG MIDAS) at MIT-ML THE CURRENT VERSION OF MIDAS PUNCHES COMPLETE GARBAGE IF RIM10 IS USED. THE BUG HAS BEEN PRESENT SINCE AT LEAST 8/22/78. PLEASE FIX THIS AS sOON AS POSSIBLE.  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: 31 Aug 1978 1231-PDT From: MRC at SU-AI (Mark Crispin) Subject: Tops-20 EXE file format To: Bug-MIDAS at MIT-AI MIDAS's .DECSAV feature loses on programs which use block structure. If this is a permanent restriction, it should cause an error to use block structure and documented as such.  Date: 31 Aug 1978 1135-PDT From: MRC at SU-AI (Mark Crispin) Subject: MIDAS requires too many files To: Bug-MIDAS at MIT-AI Fix: Replace the .INSRT XJSYS with the contents of XJSYS.MID. Consider merging TSRTNS back into MIDAS main file.  Date: 31 Aug 1978 1133-PDT From: MRC at SU-AI (Mark Crispin) Subject: Tops-20 MIDAS bug To: Bug-MIDAS at MIT-AI MIDAS attempts to execute a CVHST JSYS, because Tops-20 always has a LHOSTN table. Fix: In TSRTNS (179), page 43,line 10, before: JUMPE B,SITIN3 ; Jump if none, not on net insert: JUMPL A,SITIN3 ; Tops-20 release 3 always has LHOSTN This makes TSRTNS 180. [End]  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.  KLH@MIT-AI 08/28/78 23:14:41 To: (BUG MIDAS) at MIT-AI Make that TSRTNS 179, I added a check to pull the site-name out of the CVHST call if possible; if not on the net it will give up and get it from SYSVER as before. Apparently there are places that put a lot of shit in SYSVER, BBN-A/B/C/D/E for one.  Date: 28 AUG 1978 1843-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: .SITE To: EKILLIAN at BBN-TENEXE CC: (BUG MIDAS) at MIT-AI Sigh, this was an outright bug on my part (gave wrong AC to GETAB call). Fixed that and also added a little check so that you get only the site name, rather than the whole cruft like "SRI-KL, Tops-20 monitor 101-B V1234 EXEC314159 etc etc". Snarf a new MIDAS;TSRTNS >. As for changing the format of .SITE I dunno. I certainly won't have the time this week or next to think about it.  KLH@MIT-AI 08/28/78 17:40:31 To: EAK at MIT-AI CC: (BUG MIDAS) at MIT-AI EAK@MIT-AI 08/27/78 14:58:11 To: (BUG MIDAS) at MIT-AI I assembled a 10X version of TECO on ITS and all went well. However it called the output file TECO BIN; wouldn't TECO SAV or TECO EXE have been better? The latest version of MIDAS (which is not yet installed on ITS) will do this.  Date: 28 Aug 1978 1113-EDT From: EKILLIAN at BBN-TENEXE (Earl A. Killian) Subject: .SITE To: Bug-MIDAS at MIT-AI Why does .SITE return "__X__X__X__X__X" on my 10X? Thats very random. 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. Sorry if this is a bit rambling. -------  EAK@MIT-AI 08/27/78 14:58:11 To: (BUG MIDAS) at MIT-AI I assembled a 10X version of TECO on ITS and all went well. However it called the output file TECO BIN; wouldn't TECO SAV or TECO EXE have been better?  KLH@MIT-AI 08/21/78 12:13:41 To: (BUG MIDAS) at MIT-AI CC: MMCM at MIT-AI MIDAS 409, TSRTNS 176 fix BLOCK -n and FOO;T_BAR respectively. Not tested or installed yet. Diffs in MIDDIF 408409 and TSRDIF 172176.  KLH@MIT-AI 08/20/78 03:20:23 To: MMCM at MIT-AI CC: (BUG MIDAS) at MIT-AI MMCM@MIT-AI 08/18/78 20:22:38 To: KLH at MIT-AI ;T in the command line does not make the output file temporary. How about that, you're right. Guess I'll look and see why. I assume the foo_bar construct in the JCL is what you wanted, though?  KLH@MIT-AI 08/18/78 18:27:05 To: MMCM at MIT-AI CC: (BUG MIDAS) at MIT-AI Anything wrong with something like [@]MIDAS foo;t_bar i.e. just specify another FN1 in the command line, and if you want "temporary" in the true sense just add ";t". I don't think the source code should specify where its output should go, even as a default. Creating a separate symbols-only file would be a more reasonable idea, but you'll still be GET'ing and SSAVE'ing the bin file, so I don't know if that would gain you anything.  MMCM@MIT-AI 08/18/78 16:49:05 To: KLH at MIT-AI, (BUG MIDAS) at MIT-AI "." IS THE ONLY CHARACTER WITH OTHER SYNTACTIC INTERPRETATIONS THAT IS LEGAL WITHIN THE <>'S OF A DIRECTORY NAME, YES, WHICH IS WHY I JUST PUT IT IN TO USE THE EXISTING ROUTINES. IT WOULD BE NICE IF .SBLK AND .DECSAV HAD A WAY TO SPECIFY THE FN1 OF THE .EXE OR BIN FILE, SINCE E.G. I DONT WANT TO WRITE A TECO.EXE, BUT RATHER SOME TEMPORARY FILE THAT WILL THEN GENERATE THE REAL (SHAREABLE) TECO.EXE.  KLH@MIT-AI 08/18/78 06:09:38 To: MMCM at MIT-AI, (BUG MIDAS) at MIT-AI I have put in the appropriate output-fn2 defaultings for SBLK, etc; DECSAV on ITS will hae FN2 of SAV; SBLK on non-ITS will hae FN2 of SBK. I am willing to make BLOCK -n generate an error if nobody objects. Mike, did you hack the directory-name parsing thing? Random things like that should be mentioned in a message; it makes it easier to figure things out, especially when some code doesn't work and it's not clear who put it in. Is "." the only strange character that might be encountered?  Date: 17 AUG 1978 1829-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: feature To: EKILLIAN at BBN-TENEXE CC: (BUG MIDAS) at MIT-AI We have mumbled in the past about system independent ways of asking for filename components, such as having .FVERS MAIN, give you version # of main input file, or some more general pseudo. As I recall this trailed off in the hope that a "string" data type would evolve, with which one could truly win. I'm not sure if preserving the version # is reasonable. What would you do if a .SAV.nn file already existed - replace it or use next higher number? What if .SAV.nn didn't exist, but .SAV.nn+m did? Just checking for such cases is a pain. Myself I rarely need such info; 20X provides directory listings sorted by creation date if you like, which is somtimes more useful. Having a version # available to the program via pseudo would help, of course.  Date: 17 Aug 1978 1652-EDT From: EKILLIAN at BBN-TENEXE (Earl A. Killian) Subject: feature To: Bug-Midas at MIT-AI It would be nice if MIDAS had something akin to TECO's FS IF VERSION, i.e. something which would be the version no. of the source file. On ITS it would be the FN2 converted to a numeric no. On TNX it would be the file's version no. Right now most programs that assemble on TNX and want their version no. ask for it (and TECO has to be called TECO.nnn instead of TECO.MID so that it will be able to get it). This would eliminate the need to ask. RMS, what does FS IF VERSION return for non-numeric FN2's on ITS? Should MIDAS do the same thing? Finally, it might be nice if MIDAS's command line hackery defaulted the output filename to FOO.SAV.nnn where nnn is the version no. of the input filename. It would save renaming FOO.SAV.1 to FOO.SAV.nnn after the assembly. -------  MMCM@MIT-AI 08/12/78 07:58:39 To: (BUG MIDAS) at MIT-AI i think the clu problem should be fixed now.  MRC@MIT-AI 08/10/78 16:24:51 To: KLH at MIT-AI, MMCM at MIT-AI CC: (BUG MIDAS) at MIT-AI KLH@MIT-AI 08/10/78 12:10:19 You can't expect us to debug anything on MIT-XX if you won't let us log into the machine. RIGHT!!!  KLH@MIT-AI 08/10/78 12:16:06 To: MMCM at MIT-AI CC: (BUG MIDAS) at MIT-AI .sblk should not generate files with the extension EXE on 20X, but rather something like SBLK Uh huh. I seem to recall there was a 3 letter extension for it listed in a 10X manual once, but I can't find it again; probably .SBK will do.  KLH@MIT-AI 08/10/78 12:10:19 To: MMCM at MIT-AI CC: (BUG MIDAS) at MIT-AI, rra at MIT-DMS MMCM@MIT-AI 08/10/78 05:27:21 To: KLH at MIT-AI CLU is exercising a 20X only bug in the new midas that causes phase errors. i have the files here since mit-xx isnt on the net very often, they are CBUF > -> CBUF.MID ALPHA > -> CLU:ALPHA.MID OMEGA > -> CLU:OMEGA.MID PASS1 > -> PASS1.MID TYPES > -> TYPES.MID COMMON > -> COMMON.MID JSYS SYSDEF -> JSYS.SYSDEF or some such mapping, if you want to try shipping them there to test it. there are infintely hairy macros involved and lots of faking out the constants area. it assembles fine under ITS. RRA might have some more ideas of what exaclty is going wrong. You can't expect us to debug anything on MIT-XX if you won't let us log into the machine; otherwise you'll have to give more information and settle for very slow debugging. What version of MIDAS was losing? There was one TNX specific bug that existed for a while which is now fixed, but I can think of one or two other ways in which the 20X version could assemble differently.  MMCM@MIT-AI 08/10/78 04:52:27 To: (BUG MIDAS) at MIT-AI .sblk should not generate files with the extension EXE on 20X, but rather something like SBLK  MMCM@MIT-AI 08/08/78 04:16:33 To: (BUG MIDAS) at MIT-AI i am not sure that just moving . is the right thing for the BLOCK pseudo to do; specifically a negative argument should perhaps cause an error. This is what FAIL does. (MACRO only checks for this error condition on pass 2 for no reason that i can figure!) the case where this arises is BLOCK 1000-<.-MUMBLE> where you've got too much code after MUMBLE.  KLH@MIT-AI 08/08/78 03:56:53 To: (BUG MIDAS) at MIT-AI OK, MIDAS 408 and TSRTNS 172 appear to work fine on SRI-KL. A srccom of differences from 405 and 171 is combined in MIDAS;MIDDIF 405408 (skipping 406). I judged it better to smash the .OSMIDAS symbol value before spreading the symbols rather than making it an "internal symbol", so as to avoid breaking programs that do .OSMIDAS==SIXBIT/FOO/. Sigh.  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. 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/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.  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.  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 -------  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).  KLH@MIT-AI 08/04/78 00:56:25 To: (BUG MIDAS) at MIT-AI A while ago I started up a MIDAS on AI to assemble a tenex version, to get an error file output etc; the result is MIDAS;MIDAS BIN (and ERR). There is one assembly error shown in ERR. I imagine it can be fixed in TWXBTS. However, the other problem is that if you use the resulting midas (on a tnx of course) to assemble a program, all jsys's have turned into 104 (instead of 104000,,x) I thin ecause the IRPS hangs up before the bit-shift operand is seen (tnxdfs file). Is there any form of IRP that will properly isolate the value? I have never had anything to do with the way initial symbols are defined so I much prefer to let the author(s) of the code in question have at it.  MRC@MIT-AI 08/03/78 19:57:49 To: (BUG MIDAS) at MIT-AI CC: EAK at MIT-AI I certainly did not do any of those losing changes to MIDAS' DEFSYMM. KLH, please fix it back (and flush that losing expression in the beginning too while you're at it.  KLH@MIT-AI 08/03/78 18:04:44 To: (BUG MIDAS) at MIT-AI CC: EAK at MIT-AI All right, who clobbered the DEFSYM macro? That screwed up assembling TNX version. Unless there is a good reason I'll just change it back. Also why were the older sources flushed? Fortunately I retained a MIDAS 402 on SRI-KL to compare 405 with; did someone's EMACS macro automatically flush older versions or smething? (This screwed Moon too when he tried to find an old MIDAS).  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?  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.  KLH@MIT-AI 08/02/78 18:08:58 Re: .OSMIDAS => TENEX/TWENEX To: (BUG MIDAS) at MIT-AI CC: eak at MIT-MC EAK@MIT-AI 08/01/78 21:58:11 Re: MIDAS To: KLH at MIT-AI How about changing MIDAS's .OSMIDAS to return either SIXBIT/TENEX/ or SIXBIT/TWENEX/. I find the current scheme where they're undifferentiated pretty bothersome. I would agree with this; 10X and 20X ARE different systems no matter how much we would like programs to remain runnable on both. There is probably more difference between 10X and 20X than between CMU and DEC. The only question is whether TENEX and TWENEX are the names we want to use. I can't think of anything better, though.  MOON@MIT-AI 07/31/78 09:22:51 Re: Yet more about how I am getting shafted by new Midas To: (BUG MIDAS) at MIT-AI I don't think putting this "debugging info" lossage after the symbol table will help. How about putting it after the second starting address, or flushing it entirely, or not starting it with an aobjn pointer, or putting it in the complete crud at the front of the file before the JRST 1. Or at least document it.  MOON@MIT-AI 07/31/78 09:17:19 Re: Previous bug To: (BUG MIDAS) at MIT-AI Aha, I found some documentation about a "debugging info block" in INFO; MIDAS ARCHIV, which didn't say anything about its format. I'm pretty sure this is what is screwing me. Please fix Midas to put this after the symbol table, instead of before, so that it will not confuse NTSDDT and DSKDMP.  MOON5@MIT-MC 07/31/78 09:11:31 To: (BUG MIDAS) at MIT-MC SOMEONE CHANGED THE FORMAT OF MIDAS OUTPUT WITHOUT ANNOUNCING IT, AND WITHOUT CREATING ANY DOCUMENTATION, AND WITHOUT LEAVING THE OLD VERSION AROUND SO I COULD SRCCOM IT. IT IS NO LONGER POSSIBLE TO ASSEMBLE ITS AND HAVE IT WORK. PLEASE CHANGE IT BACK OR DOCUMENT THE CHANGE POST HASTE.  KLH@MIT-AI 07/27/78 10:44:43 Re: Another TNX MIDAS To: (BUG MIDAS) at MIT-AI CC: EAK at MIT-AI, DANG at MIT-AI I've updated MIDAS (to 402) to reflect my current understanding of DEC symbol-table formats; this only influences people who debug .DECSAV-produced block structured programs, and to the best of my knowledge (as per DEC LINK loader reference manual) the MIDAS-produced format is in exact conformance. I also fixed a bug in the new ITS code for outputting a debug-info block (user,date,filenames); it would have clobbered stuff if actually invoked.  Date: 24 Jul 1978 2303-PDT From: MRC at SU-AI (Mark Crispin) Subject: nBm construction in MACRO and FAIL To: KLH at MIT-AI, Bug-MIDAS at MIT-AI I don't think that it is worthwhile to do this. No matter how it is done, I don't believe it can be done in a way which will avoid all the screw cases. When I converted MONSYM to TWXBTS, it was the result of many gruesome hours of thankless effort. My difficulty was excerbated by my communications link: an ADM-3A via the NYU-ELF via CRTSTY (cretins all) to EMACS, all at 300 baud. Converting from version 1 to version 2 was done by making a SRCCOM of the two MONSYMs, then MANUALLY typing in the new entries (with, as you may have noted, the GETAB mnemonics commented out since DEC wisely called one of them .SYMTAB!!!!). I would like to see a version 3 version of TWXBTS, but I sure as hell don't intend to do it this time. --m  Date: 24 Jul 1978 2252-PDT From: MRC at SU-AI (Mark Crispin) Subject: additional instructions in MIDAS To: MMcM at MIT-AI, Bug-MIDAS at MIT-AI Not everybody has castrated their microcode, and in this day and age KA's are just about obsolete; it's enough that MIDAS will still run on them. I in fact have accounts on uncastrated KL's which are soon going to get the multiple-field capability. I haven't yet had the need for a core image greater than 256K, but the extended instructions are winners: CMPSE is an especial winner in this respect. Even though it is hopeless to get the world to convert from MACRO to MIDAS, there is no reason why we should give them any reason to use MACRO other than "DEC supports MACRO" (titter, giggle, chuckle, guffaw...).  Date: 24 JUL 1978 1947-EDT From: MMCM at MIT-AI (Mike McMahon) To: (BUG MIDAS) at MIT-AI, EKILLIAN at BBN-TENEXE Date: 23 Jul 1978 2011-EDT From: EKILLIAN at BBN-TENEXE (Earl A. Killian) To: Bug-TECO at MIT-AI Assembling TECO 656 with MIDAS 400 gets an error because TECO uses "EDIT" as an instruction label. Either TECO should use another name or a IF1 EXPUNGE EDIT should be added at the beginning. ------- i really dont see why all the kl EXTENDed instrs should be included at all.  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?  KLH@MIT-AI 07/18/78 20:20:22 Re: PDUMP, DMP files etc To: RMS at MIT-AI, MRC at MIT-AI, eak at MIT-MC CC: KLH at MIT-AI Of course, if anyone really wanted MIDAS to produce PDUMP or sharable 10X/20X files it won't be too hard. All that is necessary is a page mapped into an inferior process which you then deposit into, changing the mapping as necessary, and finally wrapping it up with a PDUMP (or SAVE) call, making it unnecessary to know very much about sharable file format. EAK has suggested that it could evven be purified with suitable macros before PDUMPing. I wonder if this would be any faster than current output scheme, probably insignificant. Can think of a nmber of more useful things to do anyway. I doubt if producing a DMP file for SAIL will ever be reasonable, likewise SHR fils for T10, because you can't have an inferior address space to deposit into (unless you do strange things with random access writes to a file). The .DECSAV format writes out to .SAV on T10 and 10X, .EXE on 20X, and should be runnable on all - but not sharable of course. In this respect it is just like ITS where you have to e.g. do a PURIFY$G and then :PDUMP it back out. One other thing about it is that it eliminates the space taken up by intermediate .REL files, which isn't trivial for large programs and tight quotas (grumble grumble). Incidentally does anyone happen to know why it turns out that ITS and DEC symbol table formats are so different - apart from the fact that DEC right-justifies its SQUOZE, the structuring of symbols for blocks is almost exactly the reverse of ITS's (I think). There are also a couple f minor inconsistencies with respect to program names and block names. I wonder where this all started.  RMS@MIT-AI 07/17/78 22:55:23 To: KLH at MIT-AI I am surprised that you are working on .DECSAV. I do not think it should be the default. I certainly don't think that the meaning of any of the mode-selecting pseudos should depend on the system you are using. It is just as easy for people to say .DECREL as it is to say RELOCATABLE.  Date: 17 Jul 1978 1956-PDT From: MRC at SU-AI (Mark Crispin) Subject: MIDAS SAV stuff To: KLH at MIT-AI, RMS at MIT-AI, MMCM at MIT-AI To: DANG at MIT-DMS, HIC at MIT-MC, EAK at MIT-MC ... Absolute assemblies should select .DECSAV; relocatable ones should select .DECREL. ... -------  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. The symbol "." will probably still have to refer to the location outside the literal.  Date: 22 JUL 1978 0536-EDT From: KLH at MIT-AI (Ken Harrenstien) Subject: Sorry but... To: TAPPAN at BBN-TENEXA CC: (BUG MIDAS) at MIT-AI if you examine the info file on midas, on the third page of the menu item "Invoke", is a chauvanistic, uncalled for, and as it happens untrue, attack on the t(w)enex GTJFN scheme. No, it's true that Twenex cannot provide this defaulting if you try to GTJFN the filename from the terminal directly. Remember all of these specs are on a single line and you don't have the default for the output until after you've read the input filespec! I didn't write that documentation, but I did write the TNX code.  Date: 19 Jul 1978 2018-EDT From: TAPPAN at BBN-TENEXA (dan tappan) Subject: a slight idea To: klh at AI cc: bug-midas at AI -- Messages from file: [BBN-TENEXA]MAIL.TXT.1 -- Wednesday, July 19, 1978 13:35:14 -- Mail from MIT-MC rcvd at 19-Jul-78 0414-EDT KLH@MIT-AI 07/19/78 04:14:20 To: TRAPR at MIT-MC CC: (BUG MIDAS) at MIT-AI TRAPR@MIT-MC 07/18/78 23:28:26 To: (BUG MIDAS) at MIT-MC just a note to whoever wrote the info file, twenex can default whatever you like (assuming you write the program right) I am reasonably sure that none of us understands in the slightest what you are talking about... at least I don't. ___________ if you examine the info file on midas, on the third page of the menu item "Invoke", is a chauvanistic, uncalled for, and as it happens untrue, attack on the t(w)enex GTJFN scheme. this really isn't something that belongs in a self-respecting documentation file. (in sending this as a bug i've been assuming that documentation is written by someone who knows something about the program, i.e. a maintainer. if in actuality there's someone out there writing documentation with no such connection then i apologize for bothering you with it) dan -------  KLH@MIT-AI 07/19/78 04:14:20 To: TRAPR at MIT-MC CC: (BUG MIDAS) at MIT-AI TRAPR@MIT-MC 07/18/78 23:28:26 To: (BUG MIDAS) at MIT-MC just a note to whoever wrote the info file, twenex can default whatever you like (assuming you write the program right) I am reasonably sure that none of us understands in the slightest what you are talking about... at least I don't.  TRAPR@MIT-MC 07/18/78 23:28:26 To: (BUG MIDAS) at MIT-MC just a note to whoever wrote the info file, twenex can default whatever you like (assuming you write the program right)  ---------------------------------------------------------------- Messages about MIDAS bugs from RMS' mail. 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. -------  DATE: 3 APR 1977 1121-EST FROM: AS at MIT-DMS SUBJECT: FEATURE MIDAS ACTION-TO: (FEATURE MIDAS) at MIT-DMS MESSAGE-ID: <[MIT-DMS].49455> I would like a way to make IRP not strip off [] brackets around elements of a list. Is there an easy way to do this? Perhaps, one should be able to write IRP [D],,[1,[2,3],4] where the [D] guides the scan, as for real macro dummy arguments, so that D gets bound to "1", "[2,3]", and "4".  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.   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.