github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-01-11 23:53:12 +00:00
Code Issues Releases Wiki Activity
PDP-10.its/doc/midas/midas.bugs
Lars Brinkhoff c7d4f5d0f1 Add documentation in MIDAS directory.
2017-02-05 08:08:22 -08:00

5655 lines
200 KiB
Plaintext
Executable File
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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: <SRA.12310075961.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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 <KLH@SRI-NIC.ARPA>
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 <KLH@SRI-NIC.ARPA>
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 <BUDNE at MRFORT>
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 <MRC@SIMTEL20.ARPA>
Subject: Re: system bits
To: CSTACY@MIT-MC.ARPA
cc: BUG-MIDAS@MIT-MC.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY@MIT-MC.ARPA>" 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 <CSTACY@MIT-MC.ARPA>
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 <Gumby@MIT-MC.ARPA>
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:<sys.midas>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 <MRC@SU-SCORE.ARPA>
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 <GUMBY@MIT-MC>" 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 <GUMBY@MIT-MC>
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 <KLH>
Message-ID: <[MIT-MC].449503.850410.GUMBY>
Date: Mon, 8 Apr 85 16:36:02 EST
From: Ken Harrenstien <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....
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 <KLH@MIT-MC>
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 <MRC@SU-SCORE.ARPA>
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 <GUMBY@MIT-MC>" 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 <n> (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 <GUMBY@MIT-MC>
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 <MRC at SU-SCORE.ARPA>
Message-ID: <[MIT-MC].446043.850407210413.GUMBY>
Date: Sun 7 Apr 85 13:47:38-PST
From: Mark Crispin <MRC at SCORE>
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 <MRC at SCORE>
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 <MRC@SU-SCORE.ARPA>
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 <GUMBY@MIT-MC>" 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 <MRC@SU-SCORE.ARPA>
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 <GUMBY@MIT-MC>" 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 <GUMBY@MIT-MC>
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 <KLH@SRI-NIC.ARPA>
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 <HEDRICK@RUTGERS.ARPA>" 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 <HEDRICK@RUTGERS.ARPA>
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 <KLH@SRI-NIC.ARPA>" 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 <KLH@SRI-NIC.ARPA>
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 <HEDRICK@RUTGERS.ARPA>" 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 <ALAN @ MIT-MC>
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 <HEDRICK at RUTGERS>
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 <HEDRICK@RUTGERS.ARPA>
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 <GZ@MIT-XX.ARPA>
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 <ALAN @ MIT-MC>
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 <DEVON>
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 <DEVON @ MIT-MC>
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 <Ian@SRI-NIC>
To: "Frank J. Wancho" <WANCHO@SIMTEL20>
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:<EMACS>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: <WANCHO.12072757962.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
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:<EMACS>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:<EMACS>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 <RMS @ MIT-MC>
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: <HEDRICK@RUTGERS.ARPA>
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 <HEDRICK@RUTGERS.ARPA>
Subject: MIDAS bug
To: tops-20@SU-SCORE.ARPA
ReSent-Date: Mon 26 Nov 84 01:45:14-PST
ReSent-From: Mark Crispin <MRC@SU-SCORE.ARPA>
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: <GZ.12061697842.BABYL@MIT-OZ>
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
To: Alan Bawden <ALAN@MIT-MC>
Cc: BUG-MIDAS@MIT-MC
Subject: .ASCII
In-reply-to: Msg of 7 Nov 1984 01:51-EST from Alan Bawden <ALAN at MIT-MC>
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/!<ADJSP P,FOO> "
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 <ALAN @ MIT-MC>
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 <GZ%MIT-OZ at MIT-MC.ARPA>
Date: Tue, 6 Nov 1984 20:23 EST
From: Gail Zacharias <GZ at OZ>
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/!<PUSHJ P,FOO>"
where the value of FOO isn't known until later in the first pass. This
generates no phase errors because the value of <PUSHJ P,FOO> 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: <GZ.12061522790.BABYL@MIT-OZ>
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
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: <GZ.12043713619.BABYL@MIT-OZ>
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
To: Ken Harrenstien <KLH@MIT-MC>
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 <KLH at MIT-MC>
[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 <KLH @ MIT-MC>
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 <GZ%MIT-OZ@MIT-MC.ARPA>
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 <KLH @ MIT-MC>
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 <JTW%MIT-SPEECH@MIT-MC.ARPA>
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 <Ian@SRI-NIC.ARPA>
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 <JTW%MIT-SPEECH@MIT-MC.ARPA>
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 <IAN%MIT-OZ@MIT-MC.ARPA>
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 <Ian@SRI-NIC>
To: Ken Harrenstien <KLH@MIT-MC>
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 <KLH at MIT-MC>
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 <KLH @ MIT-MC>
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 <IAN%MIT-OZ@MIT-MC.ARPA>
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 <IAN%MIT-OZ@MIT-MC.ARPA>
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 <KLH@SRI-NIC.ARPA>
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 <FOO>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 <KLH @ MIT-MC>
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 <IAN%MIT-OZ@MIT-MC.ARPA>
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 <ALAN @ MIT-MC>
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 <Ian at SRI-NIC>
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 <Ian@SRI-NIC>
To: Alan Bawden <ALAN@MIT-MC>
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 <ALAN at MIT-MC>
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 <ALAN @ MIT-MC>
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 <Ian at SRI-NIC>
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 <Ian@SRI-NIC>
To: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
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 <GZ%MIT-OZ at MIT-MC.ARPA>
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: <GZ.12024999491.BABYL@MIT-OZ>
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
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 <Moon at SCRC-TENEX>
Date: Wednesday, 20 June 1984, 04:36-EDT
From: David A. Moon <Moon at SCRC-TENEX>
...
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 <Ian@SRI-NIC>
To: E Gordon Strong <GS@MIT-EECS>
Cc: bug-midas@MIT-OZ
Subject: a question
In-reply-to: Msg of 20 Jan 1984 12:01-PST from E Gordon Strong <GS at MIT-EECS>
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 <GS at MIT-EECS>
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 <KLH @ MIT-MC>
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 <KLH@SRI-NIC>
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 <GZ%MIT-OZ@MIT-MC.ARPA>
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 <KLH@SRI-NIC>
Subject: Re: Midas improvements.
To: G.EGK@SU-SCORE, info-midas@MIT-MC
cc: KLH@SRI-NIC
In-Reply-To: Message from "Edjik <G.EGK@SU-SCORE.ARPA>" of Sun 2 Oct 83 17:15:13-PDT
ReSent-date: Thu 13 Oct 83 00:21:40-PDT
ReSent-from: Ken Harrenstien <KLH@SRI-NIC>
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 <Ian%MIT-OZ@MIT-ML.ARPA>
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 <Ian%MIT-OZ@MIT-ML.ARPA>
To: Ken Harrenstien <KLH@MIT-MC.ARPA>
Cc: BUG-MIDAS@MIT-MC.ARPA
Subject: IF1,[ .INSRT foo ]
In-reply-to: Msg of 11 Oct 1983 15:19-EDT from Ken Harrenstien <KLH at MIT-MC>
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 <KLH @ MIT-MC>
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 <Ian%MIT-OZ@MIT-MC.ARPA>
To: Ken Harrenstien <KLH@MIT-MC.ARPA>
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 <KLH @ MIT-MC>
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 <IAN%MIT-OZ@MIT-MC.ARPA>
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 <G.EGK@SU-SCORE.ARPA>
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 <KLH@SRI-NIC>
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 <KLH @ MIT-MC>
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 <Ian@MIT-OZ>
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:<ARCHIVE>MIDAS.ARCHIVE Gumby egk GZ-OZ GS

Date: 16 September 1983 01:29 EDT
From: Alan Bawden <ALAN @ MIT-MC>
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 <KLH>
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 <KLH @ MIT-MC>
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 <MARTY@MIT-OZ>
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:<SYS.SUBSYS>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:<SYS.SUBSYS>, Account AI, TTY1
!midas midas /t
MIDAS
TTY: .INSRTed, end input with ^Z
CVTSW==0
TNXSW==1
^Z
SS:<SYS.SUBSYS>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:<SYS.SUBSYS>TSRTNS.MID.194
422644 0. 54-032 DEFSTR Non-macro made macro
in DEFINE Starting at 54-025
Pure pages = 14
ST = 13271
SS:<SYS.SUBSYS>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:<SYS.SUBSYS>, 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:<SYS.SUBSYS>
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:<SYS.SUBSYS>
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:<sys.system>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 <MARTY@MIT-OZ>
To: David A. Moon <Moon@SCRC-TENEX>
Cc: bug-file@MIT-OZ, BUG-LISPM@MIT-OZ, bug-midas@MIT-OZ,
Ken Haase <KwH@MIT-OZ>, 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 <Moon at SCRC-TENEX>
Date: Tuesday, 30 August 1983, 15:09-EDT
From: David A. Moon <Moon at SCRC-TENEX>
To: Ken Haase <KwH>
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 <KwH@MIT-OZ>
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:<KWH.RLL>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:<SYS.SYSTEM>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:<SUBSYS>.
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 <Moon@SCRC-TENEX>
Subject: Options needed on file write.
To: Ken Haase <KwH@MIT-OZ>
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 <KwH at OZ>
Date: Tuesday, 30 August 1983, 14:38-EDT
From: Ken Haase <KwH@MIT-OZ>
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:<KWH.RLL>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:<SYS.SYSTEM>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 <Moon@SCRC-TENEX>
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 <Moon at SCRC-TENEX>
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 <KLH @ MIT-MC>
To: BUG-MIDAS @ MIT-MC
Just testing, ignore this message.

Date: 26 May 1983 17:55 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
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 <IAN@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...
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 <IAN@MIT-OZ>
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 <MRC@SU-SCORE.ARPA>
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 <Ian@MIT-OZ>
To: Bug-Midas@MIT-OZ
Subject: [NCP.EGK: How Does one ...]
Date: Mon 2 May 83 10:34:29-PDT
From: Edjik <NCP.EGK at GSB-HOW>
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 <Ian@MIT-OZ>
To: Ken Harrenstien <KLH@MIT-MC>
Cc: BUG-MIDAS@MIT-MC
Subject: MIDAS 433
In-reply-to: Msg of 6 Apr 1983 16:16 EST from Ken Harrenstien <KLH at MIT-MC>
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 <MRC@SU-SCORE.ARPA>
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:<UTILITIES>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 <KLH @ MIT-MC>
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 <Ian@MIT-OZ>
To: Ken Harrenstien <KLH@MIT-MC>
Cc: BUG-MIDAS@MIT-MC
Subject: MIDAS 433
In-reply-to: Msg of 5 Apr 1983 16:26 EST from Ken Harrenstien <KLH at MIT-MC>
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 <KLH @ MIT-MC>
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 <CSTACY @ MIT-MC>
To: BUG-MIDAS @ MIT-MC
Test

Date: 5 April 1983 13:38 EST
From: Ken Harrenstien <KLH @ MIT-MC>
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 <KLOTZ@MIT-OZ>
To: Edjik <NCP.EG%U-GSB-HOW@SU-SCORE>
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 <NCP.EGK at SU-GSB-HOW at SU-SCORE>
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 <NCP.EG%U-GSB-HOW@SU-SCORE>
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 <NCP.EGK at SU-GSB-HOW at SU-SCORE>
Date: Mon 4 Apr 83 11:41:35-PST
From: Edjik <NCP.EGK at SU-GSB-HOW at SU-SCORE>
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 <ALAN @ MIT-MC>
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 <MARTY at MIT-OZ>
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 <DCP @ MIT-MC>
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 <NCP.EGK@SU-GSB-HOW at SU-SCORE>
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 <Ian@MIT-OZ>
To: Ken Harrenstien <KLH@MIT-MC>
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 <KLH at MIT-MC>
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 <KLH @ MIT-MC>
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 <KLH @ MIT-MC>
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 <Ian%MIT-OZ@MIT-MC>
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 <GUMBY @ MIT-MC>
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 <some-symbol-that-has-the-same-value-as-the-jsys-number>
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 <KLOTZ at MIT-MC>
To: Sam <fHsu at BBNG>
cc: Bug-midas at MIT-OZ
Subject: ?NIB errors
In-reply-to: The message of 20 Dec 1982 23:19-EST () from Sam <fHsu at BBNG>
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 <FHsu at BBNA>
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 <MT at MIT-OZ at MIT-MC>
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 <RSH at MIT-MC>
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 <KLH at MIT-AI>
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 <MACRAK at MIT-MC>
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 <var>'
construct don't define symbols as labels, but rather
as some form of parameter assignment? The effect of
this is that saying .SCALAR FOO in one part of an
assembly, and .SCALAR FOO in a different part, will
give you NO error message, and who knows where the
references are going to point.
This seems counter-intuitive and this behavior,
as far as I can see, is not described in MIDAS INFO.
Is there some problem with defining those symbols in such
a way that a second occurrence in the SAME pass will
print a multiply-defined warning message?
-------

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 <DCP at MIT-AI>
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
<symbol>=<expression>
sets <symbol>'s value to <expression>'s.
If there are undefined symbols in <expression> 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=<BAR=1> 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 <PTF at MIT-AI>
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 <EAK at MIT-MC>
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 <Scott at SRI-KL>
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 <Scott at SRI-KL>
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 <NEWSYS>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 <EAK at MIT-MC>
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. <JPERSHING at BBNA>
To: Earl Killian <EAK>
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 <Admin.MRC at SU-SCORE>
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 <Admin.MRC at SU-SCORE>
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 <Scott at SRI-KL>
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 <KLH at MIT-AI>
Subject: .FASL op
To: Scott at SRI-KL
cc: BUG-MIDAS at MIT-AI
Date: 3 Sep 1980 0319-PDT
From: Scott J. Kramer <Scott at SRI-KL>
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 <EKILLIAN at BBNA>
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 <EAK at MIT-MC>
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 <Scott at SRI-KL>
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 <JoSH at RUTGERS>
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 <EKILLIAN at BBNA>
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 <Admin.MRC at SU-SCORE>
Subject: constants area printing
To: JoSH at RUTGERS
cc: Bug-MIDAS at MIT-AI
Actually, if MIDAS is invoked with a CCL start then there is no problem.
It's just that nobody has fixed MIDAS to work with CCL in release 3/4.
-------

Date: 12 August 1980 04:46-EDT
From: Ken Harrenstien <KLH at MIT-AI>
To: JoSH at RUTGERS
cc: BUG-MIDAS at MIT-AI
Date: 31 Jul 1980 0048-EDT
From: JoSH <JoSH at RUTGERS>
is there any way to prevent midas' printing the constants areas when
it finishes? I mean the double column of addresses it dumps on the
tty. I have lots of these (to keep references on the same page) so it
spits a long list at me which is most annoying. I would prefer still
to see the rest of the stuff (ie run time etc).
-------
No. I sympathize, though; for certain programs like CRTSTY this is
pretty bad. Rather than introduce a new pseudo, anyone object
to merely printing the (1) # of constants areas, and (2) total # of wds
used by these areas? If a programmer really needed to know the
locations, a simple typeout macro would do it.

Date: 31 Jul 1980 0048-EDT
From: JoSH <JoSH at RUTGERS>
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 <MRC at SU-AI>
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 <Admin.MRC at SU-SCORE>
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 <EKILLIAN at BBN-TENEXA>
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 <Admin.MRC at SU-SCORE>
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 <MMCM at MIT-AI>
Subject: MIDAS bug
To: Admin.MRC at SU-SCORE
cc: BUG-MIDAS at MIT-AI
Date: 22 Mar 1980 0729-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
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 <Admin.MRC at SU-SCORE>
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 <MMCM at MIT-AI>
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 <EKILLIAN at BBN-TENEXE>
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 <EKILLIAN at BBN-TENEXE>
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 <MITSW> 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
<SOURCES.UNSUPPORTED>MIDAS.ERR.1. The output from the assembly I did, which
used MIDAS 417 and TSRTNS 191, is in <SOURCES.UNSUPPORTED>MIDAS.ERR.2.
The binary file, which appears to work directly (does not have to be loaded
then dumped), is <NEWSYS>MIDAS.EXE.417; the broken one from before is
<NEWSYS>NMIDAS.EXE.417. The sources I used were all in <SOURCES.UNSUPPORTED>
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 <SUBSYS>MIDAS.EXE.417 to <NEWSYS>NMIDAS.EXE.417, to
get it out of the way. (MIDAS -> NMIDAS because a lot of us search
<NEWSYS> first). This should not be too hard to fix.
-------

Date: 2 July 1979 14:57-EDT
From: Mike McMahon <MMCM at MIT-AI>
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
<SUBSYS>MIDAS does not work, but <CLU>MIDAS does.
An example of a failing file is <CLU.SUBSYS>SETRECLEN.MID.
-------
please try <NEWSYS>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 <SOURCES>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 <RUBENSTEIN>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 <EKILLIAN at BBN-TENEXE>
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 <EKILLIAN at BBN-TENEXE>
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 <EKILLIAN at BBN-TENEXE>
To: bug-midas at MIT-AI
Subject: feature
It'd be really nice to have a remainder operator in MIDAS.

Date: 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 <MRC at SU-AI>
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 <RUBENSTEIN at SUMEX-AIM>
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 <KLH at MIT-AI>
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 <RUBENSTEIN at SUMEX-AIM>
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 <MMcM at MIT-XX>
To: EBM at MIT-XX
Cc: (BUG MIDAS) at MIT-AI, MTravers at MIT-XX
a confusion in "page" sizes has been fixed in <NEWSYS>MIDAS.EXE.416.
<EBM>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 <ebm>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 <Admin.MRC at SU-SCORE>
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 <EKILLIAN at BBN-TENEXE>
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 <EKILLIAN at BBN-TENEXE>
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 <EKILLIAN at BBN-TENEXE>
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==<bar==foo>+1
does the right thing, but
foo==1 ? foo==<bar==: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==<bar==: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 <MRC at SU-AI>
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 <MRC at SU-AI>
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 <MRC at SU-AI>
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 <MRC at SU-AI>
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 <EKillian at BBN-TENEXE>
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 [@]<NEW>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 [@]<NEW>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 <MRC at SU-AI>
Subject: Command line scanning
To: Bug-MIDAS at MIT-AI
Tops-20 MIDAS seems to slurp command lines when run manually in the same
losing way as Tenex MIDAS does. How about making it use RDTTY and/or
GTJFN hackery so display stuff (and maybe recognition) will win?

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 <foo.bar> 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 > -> <CLU>PASS1.MID
TYPES > -> <CLU>TYPES.MID
COMMON > -> <CLU>COMMON.MID
JSYS SYSDEF -> <CLU>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 <SUBSYS>STENEX.UNV instead). I think it is safe to assume that this
file would be present.
What to do about the DEC systems is a bit harder. The true right thing to
do at SAIL is to get them from the monitor. Look at the CALLIT UUO writeup
on page 113 of the UUO manual, and low core location 272 on page 260 (in
Appendix 3). FAIL knows about the UUO's and gets the CALLI's only, but it
is possible using CALLIT to get all the UUO's with appropriate heuristics.
An alternative way is to do a CALLIT on any symbol which would be otherwise
undefined; this of course means a system call has to be done for every UUO
(or undefined symbol) in the program. Actually no matter what you do it is
almost too horrible to comtemplate, depending on where your values are.
On Bottoms-10, you would try to snarf UNV:UUOSYM.UNV. If that fails, try
UNV:C.UNV. If that fails, try device SYS: instead of UNV:.
As for the cases where you can't get at the file, well, on Tenex and Twenex
I think it is safe to assume the file would exist. Bottoms-10 is another
story (unfortunately); some cretinous business systems actually have deleted
the files (to my unending chagrin). A safe alternative is to continue the
basic DFS files (both DECBTS and TWXBTS are out of date by now), to at least
provide in a bare MIDAS what MACRO provides. If we go the universal file
route, I do have a universal file for ITS on DECSYS;SITS MAC and SITS UNV--
DFTP uses it, although no ITS bits are included in it.
An alternative approach is to continue as we have done, except that we will
attempt to get up to date copies of UUOSYM and MONSYM from DEC to update our
files. That may end up as the best way.
One last note before I end this over-long message; in any case, MIDAS should
dump out its symbol table in the system-dependant crud since there is no
hope of fixing DDT.
-- m
-------

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 -<relocatable value> loses with DEC's
LINK? A program of mine needs to compute the number of bytes accumulated
in a buffer from the byte pointer and does a MOVEI AC,-START(PNTR) to get
the number of words to start off with. I ended up making the program an
absolute assembly since it's a Twenex program (so relocatability doesn't
matter!) and it turned out I wanted to do LOCs to start on different pages,
but it would be nice to know if the restriction is still necessary. Or is
it a MIDAS loss?

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]<TAPPAN>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,,[<tab>] IRPs once, with FOO bound to just tab. So the effect
is that a line containing just an indented comment, being picked up
by a whole-line type macro and decommentified by IRPW, appears to
contain something and screws up the macro which is expecting to
IRP over symbols.


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.

Reference in New Issue View Git Blame Copy Permalink