From c7d4f5d0f1fe10eed6909cf112f62ce1655a234f Mon Sep 17 00:00:00 2001 From: Lars Brinkhoff Date: Sun, 5 Feb 2017 15:01:21 +0100 Subject: [PATCH] Add documentation in MIDAS directory. --- doc/midas/-read-.-this- | 6 + doc/midas/ideas.30 | Bin 0 -> 62512 bytes doc/midas/info.mins | 118 + doc/midas/midas.bugs | 5654 +++++++++++++++++++++++++++++++++++++++ doc/midas/midas.macro | 4398 ++++++++++++++++++++++++++++++ 5 files changed, 10176 insertions(+) create mode 100755 doc/midas/-read-.-this- create mode 100755 doc/midas/ideas.30 create mode 100755 doc/midas/info.mins create mode 100755 doc/midas/midas.bugs create mode 100755 doc/midas/midas.macro diff --git a/doc/midas/-read-.-this- b/doc/midas/-read-.-this- new file mode 100755 index 00000000..7bf87bfb --- /dev/null +++ b/doc/midas/-read-.-this- @@ -0,0 +1,6 @@ + +THIS DIRECTORY IS NECESSARY FOR THE SPEEDY AND PROPER +PREPARATION OF MAGTAPES WHICH WILL CARRY MACLISP AND MIDAS +SYSTEMS TO OTHER PDP10 INSTALLATIONS. PLEASE DO NOT TAKE IT +UPON YOURSELF TO DELETE THE FILES IN THIS DIRECTORY. + \ No newline at end of file diff --git a/doc/midas/ideas.30 b/doc/midas/ideas.30 new file mode 100755 index 0000000000000000000000000000000000000000..bd0e15b6685d059989ae0524666407b9f7929d35 GIT binary patch literal 62512 zcmb@vdskamn(n**WsM$Ve}rD4FTqtH19oBu-&%mM6>}>|j-8}4b_58lGDwspVv|1I zpZ)xv=bdvc2|Lxj&p0(I2Bfv-<(=>SHhb@f)AD?HIVdNC>&aj`7|o_-zdUH~HoN8W zY`k_hUM??((^;b|+q3d?Jeu`~BOW=O-SjVulbehC=Y#(2X5stt&kIu^J;J3k~e_4*t_2hI=_B{}vF!Hqg_~l=sBXzurt|Z0K}+c{w

i;$#o|Tv5Df_(|o-xq%WPAaX zro-O`#mNLnl#}tST|H58A!8gPmXED4w);TO7#qQa}?-+4NLTj&80_ z29sjS^lXU47{gXwI# zRTP~;0Di0N&&uuQ>t?4M3L5O8KPsEuS382r^`hIwx&|^Aa(>zlw zv69*3b~w7w8}Iw4AIeATYbT8MTmO>jn0_X}dgR-W{o5yHTY#8xvKK<8@y)DQ`uLu8 z%!Hw*;W=XyM3mRQ9L z{#Pt@<47vZVZd|Hn~9nI(cJ(3&)S9%;OypF_)t^L|h)oew8G=k*9JFZpM*S`Hc)jq>T*#&ga2aXk4j zUFA4Or$ANUFk()NC1JwZWPH6gdp|M$fsk=-KuKTf%<|b6+cy_m<=*g9**kofD4fSM zI+M=cm&cuE=jFeYJ3IU3$`23!T=q8CLDA#M_%{%$?6#VnomWP{PU|mk+MSlbG`t+n zZduyZ@UlPA*&H-?I!91u`|A2~a0NRl8^_(&PR}nkT8F#G-LgL|S?Ju8OffK*(Ft+% z*Ecgjd(hcQXYNPWX1CY%Q{qIE@nx~p>Aw26gZ$ump9L`n-<}OcO8v`eIf6u488q@y zKp9T-^-P?Obsh{ypvT{Ch9@VNgRSytRJMEFRp{!HH(BLy#A1R&iZ^Mj^UIs*d)QB@ zr-7w8*=`Hsct5xm2jd&9{XP543~mCifimG}w+U(cWB z-WG<8SjS|h?-eqo#5H=VDi3yJr!*m z)B8aB))*7C%7L*9W5eFjQKR*))%a8Se@cEYUlc_*Nhk4~4`u&^MW>Mjp#CY$!c6NN zjEb!=DgeE@9*=~BtHsg)>Vrj?2ss_S_gjB5)!|9@nVV%AgEw51jlCaQoh}sAKIC-} z;R30Z-%OGLUh^4L2D4MZy~nsGgVEp|?#WZ9lbf@%+foR;yW3k$^jG#-u2JFp?vGvb z>9g_*K{XpAZf>tm#+OsjqbGJG0Vgps1o6P3{#m9yiMv_}5hA@9LY~Mv zhE1qzY>#10H)R>H6X&URYKb@_4gf+8_Pcv37;TK{$ z5lK-rFQ&e5q^*Bu<$r|GBYh3EMxJjxTSR zx<8!`u1-7$L?gwAaduhMR(UW+wrxBrj}WgL-#va%mg|qU)*qFv-CnVWy0}%ogn^eo z^-tfUrttRDmp}cB6rrP^{w?&OMzeF=d|q^KPX3BIw^g2?Gkp;10}J$q(5TK)_QuH3 z3(*A-E|-DIYbRGow->&-?&z^0puk%;qWN^VI-}k|vzwzf34F|y% z5ApW^tV&-NKf@chfHV}qxnB=B%##5}2{Vk>?*GObMa1leBN>m&s~hy$P-b-2jhFjJ z+s%CokhAgVYw1Me59Q7EJUMW3VAkcWsSV8tPF8VoF`=(RLz5gYPREl8bEbz`nD@(x zv304>=0xy7>(9*7_yv`)JCJHDg>iOseja*zt+T^KE~OhDbbSQPHfMH!qT=*Dn(&B4ZzuGDF-sUj>L@WV8y#Pu7_S24OoPdK5oph_(NGXs*QmUP z1UEpE%S*%>7!#kAn?NqhLgf5tAkox^F+;^?gBdtbKN|DQuTu;VDLXhT`oRrCviHw^ z>xW*-ma_eFI=(@{f^5#gx_TBA15^$VDs}>ZXOII>HRBsXs#QAY{Q*Mhmv+MJ};I6jtq9c z+NO{XkZNi{69JQXcxE&0VkzdiMgGr?E=@P%hzT#_!WjhL1Njn)E;p8eJ%YX(86@IQ z>smnE0$At)z>Dg1(Qr&GK8275aQK6xqr-|rJh;F4`2M4B;q_Y&zukK9ZP|hQ?!rNTO2<>%CnoRE9BJ{j2HnV&L{I0&K94;-Q}JTIa=*3^5=Yj z5@lOAG|{BPAop0u;EeNtOT)8cU>S*Q2<)WWdQ-D&P)w98@__9dQ_Se%$NUX?XG86a-W zs*5(9SPx$gaU}p6;J~+eu#BzJ?*NS~x~Bm4`PT@Wq=Y17Ptyf%F#{%swT4w&#EdKx zg-^{xrA6t`uKN>odNB(~ABTnL+d9jj9GstmcUDaV#RXm+3zoy9q@!JlL0$}EkdN=jP!`o<$;p{1UDQ{@QKOyAW(!mM6bfM z!-PdM#dUT9PO{zbr?n6Fu(jI)j2M;yD^iw%Yn~e7-$D!#lgQqJcZwzgC%2`eGgPaPbw0QLF-iEfJoS}3cZA^wc9NzjVqXN+Qbyg;9mM3 zSqrl>43ed&{j-6@R@m@Xxo-I3_gIc+mMg`ccTw0rgCFl--dtS^`(-yv@JP)Rr6E0G z<5*pCYeHi(*^;WEflh9Qmou0`^6IROrDMi%NyiQGp23KYkGd8v279#p zf{@|j6O_6}QOfd@0lDMy?q8W( z$+G7=8!+ZLNjOa4Qp@6ve7hWrM~~7p<8x-n-yNyk(ZSMs=P0Q6HMZqCBM3T#7rgr`@1 zyYmFFR(N89yC!P3+afW$K_++1-%uDz@nDYWG?6SOh*^6%_=KH(%4%^tu~hqogxo?m zJ~hwB`(-6ppKAydUGQ*tR@>o1?66%zGYcf=eVvtu6S*6=EqLS_$G2Vp04t!7KIqgR zjmEce5R4b!c%6#(=$tFHAo1=-#k(`}-YlCp7mB5zkgS*M57Fz^YP0<{k z!QeX7ZAsqzV#p2L6R8$D*`U^gfmvh8Y16`U&_0$NDKQM;VKTFw>ZG9 zG`+FiKQaohP<&A37tV5J<6iksg72L}4Ys?oi7Xh;aH9E{k7v_xd1LX%c^Cn7*5^!~ zmd`X2+_K{2M}d}fXmC8eQ<+9^1^AmhYyg#Lg?zzbIRsO~!Hshw)7IMB0&yiY-&}vV zc3kha+}zsyZfo;f?{Niw5=*|9 z4V;4=D{@ek!i{J7JY{XjOKA~ZdCi`Pa;+d$>^e>p+EB0pwi9Z>h_=- zm}n(o0ZMq40ZE=ok``^m_aZW7LLJ^CUa%_)3%DECBom@#e~MbFES4V|5YI6P-VsakmAXZ(>YIHE!2 ziWtkiV(FS#SGlpeNl3Rp`AQ%18A^&j3LCb5kw>Z*tM4@S*3w_$hfMTf^=FU%JK7ve z{;PtYzcbx0#S%ZZmhi9ESMUnd7)R@&L$ZqQmVNJGJrJX02c-y7-0DWQ?~@rHc$#LHoj@lxgO@4dg7OiA3Z z%l`niXX85-UT%D|wZ1v0JGAQUEXzj;X?&jwD zyrQ#UYnCe=@>67>95l)<66KPkyXO;`-$v*)tK}EC6Q1%=S3=*>#2HQ--)_dlwZ1by zXbqck#Sm;ZG7!OIy@U9|C_)PPuie&O`>^Gp`k8K=^_*W}bv0<@iH1VlNCr!#TnCU+YJKy&$Lj z)29Psu03&H7^QSER2+qR83vmb@+uLB!b(zzD(Nui5V<0ZaE2=sk*q6cfavpOpH*I!FsY~xdznLNWz-QE!@Mlf zw5%4eEZdV1Af%7MZ~fHh;1cf*q9PXZtWHdnI7=+G7>Vc1|W&;l$6o+d)#^BjpUu)gyEl-Z03J{wc2&dn~4uM(cb7;3bWvQAgALHK*a%!wvs-*xF5=R*+1YH1f@rbLJ>R3o37M1_V^DZb`SYS6_KY!OTI< z>QgYT2RM|`STx&Pn4wP^+eZi6q|QZlm9m|VUdu3Zo{u=3k|+A5*0ORqE=W7wKma#ghv(QMV?+2%*7iY-{M0~pQ>a{hku-voXqcl8HC=X0F7dk;* z0xQEN(Gvn5IbPVS&~Rnx=~=P|NDAnu#`%HPYos5_-2@GV^#sonZ9}x=dURU* zI)Xy_0sG>UZu18pN_TtzwPd0^0SO>^V8 z`?g$B(2z8_{tfA>I-BtPBk)f@+)JPmf4n*2m`As!5xg|hhydCtC4^`7GCFW@te3X~ zqy*@{!rF*75%|`V z0oVZNHatz|Q=|h72CU;qGBKR-I3;Go{^js@yP^^LIghC?zZ;GurDKSD13Un)#8w0B z*|T*U=*j}LCqy||l~vz)`}*IkaPO2G8}~QX9p~Rb(cF5l`A3W^*;w1{!{bg5)H!!T z5)1}J5FkcGcw|A6LS}w{Huz0S8AtH@V1lAt#mJq(C7*efJKXF2xRugtz@_AogIAy6 zOfGl3ugSk4=Wu6B-nfJPEhoB3Jb<2%8uL4c6dN4QIKbVSy_q)hk_o76x0=_HokF&v zdEMp%cwOz}`k(54f1u~}zz$+aYvdt0T#xB?iw_5XQ8=_4?Zd9XCs{U1j!!mByh(T^ zCs0aR6LIRJF^H|H$$;W=s#kB$*KPROJPl$R>ZWj`%oW%ndvTmsuzhVWooeCQX zWCDkk8^bur{i0%^VAut_olniO58W}bDl@uvO=uZpX*zXJ-mS!sb4vBN;XOn&4JHEQ znI2urkzl+#q<@5NNT5+Wsz55GFvNjqfRhYg5sX@ z8t7^V)Rx%^cM7Vs-gxKSJQ&vCgGXDN5B-4Ts0Zw|c8=zJAzw5?m_{0~rqVL&xmHWK zLH(znYJZIx6>J~65u#x%YZm!UBoY$;74NPvQUJ$-#ukLtXs#YmOMW7=C#iSs{3-|y zt;4tucH~ccE%}sYhy-vC0Xs?AAi@KuwBO=rcjQ(10rrk14uqG=FIBZ?d2xUh^og_g71(ROuwF7PVrV>^%`5 zj?3{#46bbM#3o6%-Tj`g=aTon@)%gk5Jo!Wtp8Ffc8=|9k?{qXHC-5rE)j3xmhny87#!DNKGl??oxJ5N{ zik>m{ffEWWNZDx!mn?mL!I4!!b`ptWV&S9xAhWB~r>dw@e026!L|4e4G&7W#B$4xo1kmf@d2U9v)7Q z!^z}D#N-iJc33M1M8gFgTa(P8jsQ*W0udK{25$=b8YCXcge)~Nd(X_VC$BKHRpm5iiLw000u}Xm|)26^Y=lV5%wwk(_X{zj38f zL|{!!Fs@{Xm$5J|BNa7;o zumqXuAA0`n=29aljO9~fl`Df!rvx}SH@+v3Oyr5pC<_Mfz*%@Y72vo{GdeLctJOrK za9sDx@AnQR&2`)n5<)DL~cj;Sz@C>=3!0Q8z?>Rbnw+Z;c#&wcOaxf4s6c2 z+T1L=MB%cTyZ(n^m^uK{Y|lksaLeQWqhL%5o^s2C{V?Zb)oy}?7KAR^638pg6M($*+tP?5b&wn3+TP%eJN+Vv^s+x+J^ z)|;$YS_;?=rGfr-Sv5SWcB5Z-Og^TZuao_T_BMuZcJr|!;0Zf6ND`_A!vEMWTRE#6 z-FC0_$9Rz|3eYQ3=79NP&<-q=6ZQy>oH>UeGi7mhDaV{ctB8= zm*vik4H)AM1f2JhN*HZ%D=MLxVmH_YY0YF=3@el&uTOe-pTMcY=0Plz{>Gjh&JMYU}&9} zw(CTJj}ry1Z%}Em_3#hvIw%l!#L>S!db7V-CpyM zXxH1L&THIU?Zc8#O>?_@wEw2pVrSjf!S?=-#D00RS9V`{te5Q{TIG*NZ_3`QR=Iz) z)9ke|Gk8~j*JCybu$6CLwK}c%;!UU1I_wqQ-chIdvZX0^%eO>_w6^0ny_#>=gt_@( zePf<&SCMicu`(Y^pL5Z6ULw8OBWTzEd(0YZ=w&vB7|y&Kg_U|>C4nfqsXTq1tLho# zUWn zT}+s{y#Fj(!W4GaLa2(uwRxl#i*ydFGAm97D=*0T*q*E8;A^oG=ZHg5VjO5rYftAl zX2N?Oj*Zv{s`=N`V!wSTF59eJFnIgW`IKg#>QV$m6%c7vQP(V=#R*m&Fd{1zZ?!1c z^q!=D?I_Y?+4vJgLzGa-e)L1DjRm&42Ih8pE60buj`BZ5IHt9FrbO0=UMDt;sf7_) zi6>COrkoF)4|P#UwGpw}JH=1gtvQrt*e`n@EsV4CX$4kUfh;O$CHUaoR7j|L4IM>W z0M=sEOe`@N5vkx{IAozCFsxcE+_s8!$yY>Op;UFT1|ts~n<8_7o6=TL$OUJm{Y-{Y zN5<*K(N?^Rtsg1d)G3n*i=+)AoKl&rr5iDjNo2>as4UC20 zEr28Icjx8gAiGhF!&1sCJ|xaxzyR%3iUodTOH;V3S^#;@_84^Vsqc(~vl|ywR*&hG zQGvbW8hV)qDa$3#&BTnPV0Qw(Jk5>nk1jHvmJh!9<}rvc9@+0Mxp~ZYT>+sBOR%c6 zmgKSLGjL{FB=?1#R#bGJ10uo&BS&l%!{zLiu>z1PZ|gs4i7o_W65y)gvo9r~s(kln zIKUA!O5k7!zuks8T*zY`9#k#R+WEqoWPv#aNYP$0W+~A_WI?zWQo!w@6}w_+a5FN3 z9Kpk3pxmK^xAGF%_mB~o(nFkVN;3i*Dqw>$8Q|~=^`-!@K98WD$Vt0PrmBN9OaKdH zAdwoyj1_efMnYQv43`S9u~voq;jl#3(V0FVgR-_O#~y`o;n>^UdhpHG!^fo(*c06} z6aoM@U~#68IWGbZxa_;1%NfDOwN{pL1#=81^sWSHS$@(Rw8*M1Ts&Fo2w2P!rQmhW zZw{wdV2!|t5;do?r%i;{|H0MtCtt?Y%=14DkIBVUqa>qhFL-rs9!2tHF+v zp9hh(oHBA0EbbXUp*`|YTp^yYEopkPb}$oNU7n)l^SQECNw+A{#G0XFK)F{ev5Z*R z-s;a}05z0n1bf(TzI^tKuPM?wXdf0)7X6Po8}Hk!Pdp;cZ2g=6TYUmMFOEFv_lscz zs|{h{%;6jh-(_`LEftba--4SZR#8-?A`---E2@G6Hvo-s)(iKT+KtSy6> z%JeuZf6W9cV|qpkz2u0py>U;Z+}>bFfHJ!eaNHIt8614BB0&e^@hG$SmEHZf_pD3e zn{rv#rrgcm;g@oF+h1Ra>3|M$NJ-Q{VP?>ffA}vF1!-SCUT{%450HN6_$}_ZA=O@d zrj$muh>(DIA$rOQ9YZ3>Hzf5I5CN|F*qAJ4AQ}B-7|SILt3N;G{pY`^q)ZXkQw34w zq$L9ba}YkMxh#-)4$yWZRuPJLScOoPJ0CNe8vhBasYXHn3}%79#XI& z#X<2(<*Q?EMFhy*ECQFUu8@-Dh10Qx7kFB5;H)StRxbb?y=hweMa6w0v)w00l1J1G z&l3mmCZ{5WfO%iQu!Af~CJy@_iX9bkfhti^LgA1a!DQhsc0eiLLnT@w+`rk}+K4ls z!|4>HxEndJyVK#t%3F!}Kl&iQ6b#(?jyOB;*C7*7Ox5myB8pU5NyTIwig_8r^yl@} z)i)1*DHOLu8L&*e5^Q{M61Q(21bd*uo+>z>`p-?0Cit9x9{$o$n+eP1sB@A}G4N7u zGE$s>{^Tjb<#9H8q@0ncpf$y)NMA8*a6mpNHxWsYLy-5unPw%@wZ+`GfwUUUs{47h|?!Gxwpz*@ssMaZMPxZtbu>PcO&t$RtQr5?Xh4I-Tv4Tb75&OtGIOK+i~ zbe6Dy(CVibH_)uGxNueW#0UXK=R)NY+2ofu* z6K*HXhm9nf!zLkeCuR;$3r;GX0*0pbhB^yojp$$Cav`6EJSpO!YEY!}fGw$E4nVdu z!)g=x1_q2G^OaxrdW=>CTDo@0F}=Fm&|LOIn5|lX7*-IJ(4tmGz%r*G0YzbtXx?@P ziShQ^iJ!-z)FW6Oq(0mlJo>0Yx6DD2s)Ou~k{gdVEFUUOAH52J0LO5F_4&`x!@Q;_*!Nt` zw^VAlP^=#XE+>(j7tSF?G_+w-k0xSt(Lo>g$BzfS<~G?=s=2eaRzp}ZS*6?mt^@|F z4wZ}D>hhdmaDCkx$`xp-Rvtc~GNp`$s9>FdgQ_xV;9)>79%mee1Hqy}V$lUmS4#8Q zEg24^ZSZj_N|)|?M1`UKq;EPkjyP3)G5cX z&NgJgH0(9$&ttMq#0zuftIkvMRP(`P)w+k)F)Fh|9B1xg;uPhgGHb~ZF3~!8o&O>Y zQ0-GrKWKU=HE=BEHK9`Y<9rjd$$Thu=ZLh2?Uz^-}FDL1Ba(ftB2TZcJ{RJZ;b!^Z*>5M1hP$LWPGE zZ{bMEtRrP9kOQO_iAup{g2)V-^PIp-hG1PQ0hGtS23~?IWzupLO7Y=Eq0kj{k1i$_ z1h>J`ffKE2WF=9-@#tTYBAtpXmCN!~Cx3w7cex#7p{xA)8*#xG%UW9@B$hmKwvRZd zd_Fi#ta#{boUglWY2wn0+(511MUrMi19B~6;#e8tLTattBXd4Vh&5K=$ARezknoCt z(775psizxkd7(=Pii0aOs1-wZc<}fOR!@x&iMS$)1wMxWnqzQmE1EB`4kiY=siH8F zXX?xzs9Ste;)#dA*(fZ{M2~I3hU$~^aBlbDDa}WRPGq2a9O&dz6XI7)Oj-Z}UM@D{ zyd7TFUc!Nt1ku8T6~(!M70@)-rj$VE7@Ib2vU99?k_YW;vWBX2$YWXYHy==yfVCf| z)!>W>G4NGNt&nb`4j@?+QGGzsyHfZ=E5B9%Z!k(d@DN1A`FY;AL)> zVSi5ksIXE|sbeXNS&XS3BF%@YkkMsR;}u|t+9M_LYe3Y&Y3*Zq7ROF?`% z90-5F4Z>{Agr1xZ#fmdF=x+nt+RQA%3@O=(I?!m8x$NC7r(}vb0C?o7YgF5F%-Z!V z-cr_Oz*8ITnUF-58o$c7Ur8j0lmSz0P*`UxH{8I~@rZkH?z-nIKv&9$xuK*^ai%go zDvZu6TUAbB{=6nEgkFHyj`Okaivx%BQ=$U33(7A9>|k8BHP^f{qxNKU?r$XgMP#T+$8JVv!kPRkN}Bm^DU9DGvM zM94WaBkUq3t>h2nLw&9+Mxq4&^~MlTnu#&;@Bh5fiFb zCiwXbt-7XfWd|^?ii#!uD%lyOzWx>iLd(U-%dCRA-=;9GEE{WpQUP*9T|91b#Z>!G zI|p5=u{^TO(@31L&ehX0jO8*3(2r6r^!Q{-a}_+btZ*ZpXwt2nrG?A9F#+)%7i^c8? zJ~Rw^&rwW@LhF-v7m!e*)r;duJRQ#sZzLCA?gcG)q{hO4TL>_xW}4$fv?Yj6Y3yrN z#e@K2dJ;Rv&a_~IzuD0ptbX43$@@kvBc0xcaqiD(@3CoHxY6#`N2H#kpso3mIS0Ez z8s)nDjH%WYEn}btJQp97_8)PTRq1}JKyi_}Cpjg9PDGwe3Sp@^4~>;@X$XiG*eiHN z+@96S!JHW=kTxA*P4pcwa%NZ*yh{Rdif(-ZZXi&Y?#^OiMgp8xBqK{tEZCazF7ai7 zQFx-%da5}IOaxLJ zVrOkSyM^(<+)^X2RP6Yoc#6yUdHHmF{rp+^RE2)emuv|!`BHqx=hZXm5oJM%dromr zV7cUE(0EShk}G)aH`Jjo%bov>8twIEB2YW-W0fPU)U3OJFq(s=U?B=Oz2(K=$lOqK zSrOZOaqw2TeE+@%+l7=b8RI>@XF{2F@f>UmBasZg)gq^C(gp-C+d{i>zBiml<^6w7 z828Ucs*;o!3eZUwydHe@mAjXMjbM7P3TFz*IjR7FXd`s2>>S|Gg14rsCPMznNJjpE zAj+XavjAz;fSy5bM*ZIitOTk_c3_aOY{?H)3_VK8m;w`a_%gay^6P5(|Ad?QzhF=+ z|6yeOPk*KU7sednN)~b$?L=yXd1_|{aptluv@;H6A(cgHQ5Y_cL~5zb8XIOzCC}nB zl=nnoFB5t+uVy~I$Dv4nc#{CpXmxjXUUfLG6;TU4CRw0>>88pB$3U6Xq5APCUMiC> zw5WFpY#5)nm=Tlg=u4y z#kbgKyrc<_p^$$CsF7bdzP5ug2Cy&319+jY_x8JUFLpTh+5K?2WOyyi)9t<9ZyheY z;YpINq?{4=gpqGB)=B$40P^~W^v=`a*(dF(6N?j>bB9FQUA?$QxxQMi;ZJu^c&U?H zPz&l8)Scl+^d@w3KmwV76(Ea$6=+_fe+F5Y(U9@}4>Z6(>KMod7tCDPyY35JnR{drBnnNB8;7--B;CwHZG-rn({b25 z5M~@96U0x$6&)I*42demJ*||~izw7yo^dG4A|ZBlPUA3;!8-V|>;ZX1#P>jHYEPd% zYot}(*IV~_X?_tb71T^m@c8QDQ_%=Qr|jG*B(?Vf3mF9~PRgg`6h;}aQIr|Q2p<| zgrKt0EVijCB@Qn47nnafn{ERU`AH+r8p36oLKTwRD~J$KM_VCh#Fz7WX)uFT3xXCNtggypgUKW9prxfkX^K? zOS_ecu@Zy${sH&8y(eIib3zbQw+#fTW=is&y+S>HY+JKPmC%4wh8oWxfWrSY2v?!MWEd6iG$d$3iC zL7%VI)3~IVXDN?Hi{cRTi=iUybq}Nxpj^b6rSUm3?f^+ybDX*EKw<$un>qcv*ky}4 zz&DY|jMC9OZb4DqC}b;>8X`HuAXuZ9rDPdu9)2UocsLC0flsXL0Jx``4+LvkvlpIwHQ&*n5f&0{gZ4kVUGfNxDpe1nXnF zB%p3paR~)enia75hr+k7lt8LHZg#q@j(CT1rGsctlX%>UI%FyHA~ITKy-jZ5fs(X% z))f^a+%HWTfQHo`IPD5z7#V&}(tDIrV6@k0%g~Qvw#%WY;<`c$UoGZ4XL+!}+S!nt zSKC*z+*E6vC=T_o?da85oz5izH0~H%U|A z5xvXn6__YN68JLO8d26!~PmP%xu`d)33a`N}epY#GGq|Bh^ z>gvxufk*$3OK+?#;yB?U^5z2L?lcP+u7lNIpX|qM>o;p+dExjV<|4ZkI1yIWbuJUk1fh}fLnqEP22LOX>@w+; zwl$X`;b9`NB%>Oc*E|+=_X{t>$+;QCLM`3XvbcyjOi35tDAr2sj60ul2zqXzu|y?; z3a@>v!8?_6=JJ7ir{GDUivoG_c49TG-Vr-FLM(xawmK>oZF>`&E+*-zGrfjjV zHyWA*0qN8BDC@AV212Oelx*>Ei1`fE5+=zRvB|9AfF?)umgSDk0yD_{gMvt z&*dr+rD*d_ln&Tg20+cP`&g=Y;_-wqEC_=x70@teaAfXyFx8v;dtxDhZN3X^ly`L$FY$ zv%|=`17gVxC8JJ5SWHJ#0{vVfSAxoGy&sPW%S3`UcBx%Kc8SD`a&UQuYNyd&EvI&& zY`|sAQEDcWlan;6hvpWc{(JwU6Oh#r01RP>9}Nn!<%4njCzkB6KCn~y0%yexNc6aO z$!_s<$Jk^o_$DNOaiaq2B>+U0mLfn}xC%Eh6rGk~#RPhmzfLwt_zH0BcID=$Js)C2B zoph6%>08V?GVbLI6qU;$(oD-Vv4G*HI}6kZ9g^g(f?|p3!yOq%kx^kWADPUv87u># zqbw$_x>!2UN{ycZUe52#3u? zZ*n6?om!ZLJk+PwrK$cxCl)MaQmo2$Zy5zb_eGDO-k4#0oYyni7ZwDBXIS}-WJYNAPNHYaF?mRyi zig4m;FeMaCICgZG1%;|RP%QQ7HXtR@VYrZ_Mz;K>AkRsNnV+emPrARmBG|PZF5Fa@ zD|~RQQGUd_<)8Zct*xbH!|Gs)^MfaU0*mtKtt0xx*|i~-nD~;;k)2YQC#QpNvN86_ z>x;uj9jG%q#{Rww}x?)SRhiM7D%@(uHX_rg1ayFOpZI9%VL)_moi=$0$HI8JG)*iTbg-+FISyi-L8Ig2^d2w>=(vx%%oJ4=wByV)Sekzemu4 ze3CwxYL%u)Ztnq&UVGWX1vsbgEdVm_C-m}{H%C3vyyTc%hOqAXB^50LTsoyiU~u59 zn^~9Lk~W0ZvaeTR50qGPkBTZyLz&UOAouEA>NS0Wk0D|ELseXJYbM%$?huCWW6#dQswO6Y(#kK4Ju70 zgf2M-I0HVByUWty{gE{r(L3-3r?My!youBqsk}VP<`}%stI@!I%?m77mJ{*mg^W~s zQnLZcWR%GNiz>U!>pX-2WAO%$PHN^(!lWBB<-!`k%2wkg(4Omq`vULC>hjC|H`|Q7YX@*9 zXT=fCqvXS?I9<|kBdSa-GO*-L2r2L=O1=jRC!SCgotj&JK^W;$;_QH%SG7u~PerV$ zKBo|np;Kc^qH9>|mG$J~;9Yi){~@9Q3C{W07PtAY%m3<~rj35@3$f+OhHk28Z}h~- zD!jFBA;KK;YNw{R%nkr~&gb{yz^%ZN?H4W<* zqk}&fC-plYV-1*-L`JMMYsCUwcq2Vfq%SH0h#o^_0||{9e>v#wyi(ItlufAz$JR_` z1er*gO^ zI-%Rz1zHf6?_}>g_T+G;K(nd>^AO)gahXqWv^BCl3Cv~{-MkxWya)YLUDzW6uK*Vm2P6O^D@Fpd9>%5q$T9%V{tlg>yh~R=o2NCSi z?jcJtd&^a%rbG-II$4ES=I-oD{VsL4249zaN;4aCn#{CSSzGQG^Ah z$w#V6_!?Y1!ZJ2+f?GKgg>V?oH(i}zUcj=!#PL>jPMb-wck#S!!hvJrzjwI3?E z{4%=(*pfl6coixdB4W&@0N&V#k-#gJ&H(O{x z_fv$93{QY(phk%0$Z_a$bjP}FgKgn&!{V^R@#TIO9U=7(OHE?oTGiFA-*0!ea+Pm= z?co3QZ|WR;poDe2M9wu;kSFd>IC3h9Q$RVM%HKz1n)rjVkimp79R-j|7ziX>cW@A) z9==KKsZn5*gngm}Y7Pa;;;cv)NSaab5@cRX{_5&V63ThrQmS4sq&)IuGAO;k1z5NP zy?X9kvPx&QJ2*sjhc^XX^a|HWn$4+d5K_~E!{;TGkg<|fkUMX8)dR*QzK(gQ6eyi2 zTBbW3q~#uX8d>mSBlR0vHk_|o4)mP@Ym$4lE(iF*65lCd(+q$smOvw9FHHF2^;hsw z%vOW%tB5BtVu~?0{+Z^v@`#|91R#Hu&2nqQWj>@!IF7fQbn$ynJ~vfwxEJy(;?m;Q zi5S8KEAM&KaBDG!VyAW7YWC!*E*k_F4trpPt}@jLg{0(B1!`vRwbcL3O$fT4&$mZB z-rQUQ#mjQZM<@;8SJds?Wew~Wu(=#3m2H%zo~}OX!S-zG=M={vIaOqdH>9t~98y#K zSnaRBV!cGIsB#>LsptmsB+%w8CvETA_tz)s^B@0(C`pyO3|Nf)#y}rjQS?OwGc@Z) z(FC&z^!B+>2sKuhp{mf8cIU~lX{A<4>43zoFBxIBFbpkWG4t^4~FD%Y+4Lc;vY`@e4Co($VH=^{n| z+`JSE)_}H*Gs1dBiayfVQe`aM_*P9M09v4fs#Ld`dLib!`z8ArM91>TYk0S|`RlLh ztRpD}rdvA@OR}uXK@{+MO7{dYkNl#&ze#!5rs_znL>Swv6b*_MIT+Adul_sV{QIw- z)s8|*bx##`D*hZ@6>5hG0U~L`+>%%$T!R1bzqttW zpg&oo|0vywH@;ii>m6?;`bk~ES6<%SmbB#U&Ia)F)$;pE<6ar@kE!V}U1jo!O{rXq zq1M+IE>HOH$E)v8IB>Yr6nu^k7LF;xgIiTcXNDU>c+!A?-jx`>hS>4E)f@3LWQ1_i8 z+&`eT5s;(*RTb~M8D-1YhlvPSiuJ-ZWHhN?;ny85UF;mA zL?P<#!L(E~rzf%=H@CM)oytcC+89`l113{6EPq|ZS2$1J4qj3T>0p1U(hlj(zWaM7 ztHJ_Qx&lg`OLR4_GzdwIx`9W%a%@o4P0kcDz}438O? zt&QZK6@CE%|E-g_W39@s#a?qpTp?8HW~NM_HZHzZ-Z8)y5mb*dxD6leCK{gzr;32Q zOV$$Nw!?t}wPT?6YJ(635^LwF}uUXPv#_3-&17B+$h; zxrtVS+u5Z5QJFumG~MpBAWj%JT^F}i@U3bd=*O$VBtav)oHUh!o#-C?=2S5)HoGzs ziK=y<0F&RsU#FU6Z%~37Zh&%44v^keH7-*GBjyb-$0-4J#%q5l&Fuy>B)alAg6|lG zraFK;4`-?S^*B+lk??Mc1vA9HV!8{kOCXBscbx)hQW)T&8)EQ?!G~YgEqQ9Uy%Eot zBt#C!fjgXBiRzQlYz}LlV!9T8V9`neD#ss3Ai!uqm_qRk>nE{&)|XuXbBq-)33^W` zn@UEKlM$W1qTKL6&@NK-g%)hG$5C6vDig}RwW>rk+#8izv;Yf;X->oCe2ht)4G}Y) zBo1xb_dq!4=}9o<&OID+a(8p;L58d$@k5RxyK0@cAzO|H(>^|#$N7MqpDivMAVF@+ zkh93v^j{pKdN+JMap@^jS1o1o1F~4>{J}&^o{_?|y7TPkF8xW5_R1z{PY8k3CQM3T zi7RPu=}E2%$e*n0NQIw+lH=0z29IKCSRtse%rJZ)gZ91Sh5dF0$|z{!>wVe1`1A4A&m$nsI@ zH4`C0BS*)QM=qNzxHuFsQU1&2AVMdem=^Ys{*)vPR3b?wmaG?8cXGENXQZ)3hPM*m zL`RjNVOyXOnC2D-0wPR%AI$qlw;boMcqa`Tr|0?uetB%)m^ z;yl`=tr=o)r%@%KrV&tydN!JiDMH|Eq25}2E*}~! zMeo^-99AePZ1(W7-NuSIu${iSs9&Dj$;wyOz%t}u9iqfd(HypL_s1!Jb4~0^_XR@NE@A0 zI+XCca^L`%s@R{6N|+>9y=-Nf0W62X5k!`hBY7#v9ind}k|S6rCHIH?CZGWdK71c=9{j}mf4Wv4H_?0iDU;5FgjEFOyRmODF;%ipEZ1z$hBp4 za88MoEWSYAz?lE|FDX<{pUZN$fXYOyT>uX)42hqeT5>dK5xigZ<5o%u&Ga}bNm+dx zZqB6N_sjp_*kFqghek{dWA*D?xYlZ2JU~;^XfYNFbq<_LB>O&AF*?oU*sLteTk_)G ztL1ap7~;1%zb%R;IYx*-VoQ;UWTz6D7G|Nsg)@id?Qj6 zls>|AE3fi}GwETGxD0wYBLET$R~7~9nL$zbFQzGP5sIjiA(&C#X0C8VHBy1{B?PC_ z&3_Bt%YpbXow$zs46=tTD4kPirdcU95+k*oI+X$ohYn1THEiNklO6?w1Wb+6!o-m{ zmk=_a>8H*6P_ZT)PDv0v!!vmls1Z7mWKd=BMx<~4_58LDMcOw#n&lCbe=!W0Fp)VS zq>O=*lHk-IPXdzL3I zA~_%V1iodF=T=LxL`(^zI$YNZrY7<;Ko5U_l)1a}X_!nFQkq?CUHc1TLDP>m6mU4` z!qG65LngAfDmgf*sg!ndB;rDFx9Dsl@VS@VS|Yb%DYC^l&cH)^;R05S2Rk;48J|Qa zKfBANqcfeGRFT%EF0bJMk>--}jH-wMkT&17$r{)oZbKw7cMDKKR5r^-Yu4^X&=_g@ z3k^VicT+zX7H2uV5(p$;09(kZNBHaRu!cA=KBQNwFD|j{CAn3mt~ezXP);6&YQx*^ z$g1~=snL&I-^ix2R<506UC@EdD^Lj&+&tx)BvR%P1r9;Io#-0DaqAp1aNzCgQ!Ffu z$lMtLT@w8e!C5_WU?iVN9nseAlu#v4hZsZzg5}Ncs_LMQI9c0^HUd>ih8<+VUP8ET z6~5nPjA4aa3o_s{37pYKR#5N_50lc~DT4DduZ=%VV;JdheK=MMZZjfvonN_>veq!LVej zsIWlqZRDJ$RHp{kNxjh8qZb@FAKnD2YET_HD#;%;s8{kXQhCuExt55!Bae; zR@{=d01SbLU<{Jm&GSS~9W;|Q8u>%c*Y3u=drDhPwL7m`XuwxA7Em&EXUv0b*QhrXDx7 zu!ib#54Q^nNF*%?9(Qdy2P?6a26h9LS0Hu3KncV+QV32ynhTk%M{pAC{qMsinQbZT zrzC{HorEX3>)qq|Fv|MoT-UpW@JIQju*{t>%HNyM5thH6AWG+BrwdaM^tBVsCJu+G zGz1Jh%sDFxm4gzrF`-5C)9LWj9Nh+WRI)5+)2g2pk%)h%q#lwy=%vSzhGPQ4GcB#a zFu>Hg=MnH!9jWj@=PUinD@sNw3*|mn3 zM=3=7_fzH*xORRL3B+3Yvi?Ipp*0z9shsPY$broR2!;xnWI;&K>o-SySL^h~k!6tXsEUKeLzFJY+ z{qrxqE^A&b`N>8S{y~fp_@y*oz3H#rq0=mfc{Ii-4WbMyiVi%Wz=U!GbVH)b{~(V= z7!RJgW&?pH>BXmv@@L-Wo^ES8a%1WK<)qdkh7g+=?j*rD&n-E01p#=3Rd*VH1*Fpu zpi4{c$89!vcLq zbB&Zj&%TS<7xI3q-7To=Hb)4-gtP@bQR<=s*xkyZm{xT*a;S~OwwXRV`AD#%xGHAshp-nmO?G8I5Ee# z(W3z}PG(@mR6Pr=#cF zPw7}CF=vG5Q^|DKCa^42taE%f(g})gcqu9emX>`NgZi!Vc z%pla#QPBs9aw`EEHXE+wz!~6vt0vlvbSuBV{i;+h1qahxd38C3ZG+CKIXIjY?}aIq za*fpZ_N%n3jI*LTSwxXImlj()hN4A7;)qZKH#bC7a$0=r3DM>4b%aH)miyzrP$!Aa zxCb#-k+aN&odT0-b&CF>gl8JtZ<61N36gFzI&u)~CMEGp)R&_L#o8ef`{3z)CE>VxL!O0Bv#!yZOmA2J))U7>jnYc zJMwt<%>n5OUG9f!iH5io_nrw2=Xz?0QKz=FRR$4j^{L1bO)-7hP0%UBDnhL+QGj<*`79dFxB(B=XG>|4JWlK)mx#*Xm!61kp znc#RGD!dghwckUh0>fuTTnY*s09P5FTEi5qGDLF|t0dD&#TY2sj-8iWJ`AT6D*oXx zxlC9Le*dVsd;evt7aUp)3O=flr5dV&PJ{rrF_`Zg$N=AuI7+JPbYz$3QWTt>x-tLYRa~FXTyy*br?DL#8S+#2E+<$#;Ct!DoVHzhhOO zZ~^r&wF&@1v5k0M_{M)0E2+9kQUewmx@l0QQoj_?&n<7cgcAynrU15_G_yJfPG^c$ zBG@3oy~U=CsHZ7~IYXf*yi~}s*1TY2LbGtMG>(peYshJSFZT|PJIc~j^xttT74=AC zPIVVg@ITD=Y>ZQAvp)Ha!hYP?``*2~U~9YlC68OTwiF6}WA`b6>; zzd9?XpX$CR(Y};#0m*q@34}sfDzL4^5HeEElQLDZ)^CKzrIE&0?LYg)Vv091;sXKe z0|Rb6n$Q{CIiAb$Ofv_ci@DZ$2Tsw&pVMrvJ>2-_yPdV(0k=YN%vv12?qccLv$E}0 z^GZs$Wx=%B_sZA!qhwhTeu(Y4x0_GGAdDUG-c`9`zZzNWe}WIy8e{lJZJQ*oXR!pQ zI^?v}r5rW6(`o)#PJjON3$rz%V_!L4`E;*vWtSuJ%dFFX{#5_j;L_Xn%foWII$iz5 zkkSXj5AE(-E1lMUGS{5kzp=iq5#JmicUs*p&&%k@HejU(!xJE1adY^`X0gp>pRdbL zOPYTB$6l*EA>6PEdhotAk%m5%OFTNr>>M2&P^IqY>AQ7sKspO!Yi}=fIi{kC;cH1> zhWT`Nt(z>hvD4vVziFE6tzyz-X(}wfO2aq4-DB((ta1t|Nu@*WNP}OGyGxJ& z4LPS=P|9xPIVw+QlXC8qH#hI`RZ)<@rYkWpI`?iUv1Qe_H+9>QgCV&)H(v39RaPmVHAeG!Mbv?ad+MA+J-ZPNl?kad6w9Na$Q9O)~xZGATSUh5qaXf z9W`M2!aF;D2~(ulr}FjlGnzA*+;8_CPeDDp>Dfg6JE!`Jf|y%yPeu|}3w|-Tykimb zh`0eF>T)~*q5%~g9WGVqka$b_J7sdd)6=}-H~7)&H21qqefZi`08n0#UVvBa^NEAh zy-FrMg8yh%g9mj=EQF=WHkAO)Drx9bAMcy>p=hYRGRgFuTmv;ET~#M(EBk{%(V`8K z#!=@b7l*g>QPDWqyNm1Tj+14Vx=DWZXX-U*N)Uzy859Tma4G}GO%t9yTh~X2^Pg-K zFa|jdD++z}T9>8!&*Jb1gLCl&sp1jAh=bwV&65^Ku!>Lr4L?3Q2Ay#!TG@#zFX@IR zmqJ?(m>Rg{ia;x^2*(D@U`^(VKvaR{xcL%hJkJ0=47ts6jBQN9jV`mM>q@t~$!=ei z8~U{jwyI~AEg_es3#vu~O%d%X=+> z3t}HhN_<-5(<6v8A@?)uiqa6J2G7f@y@HfR7i05a|9uhX&|jQ zN1H(utur3PT2KQysh{?{6e*;wd?YY7{k5z=pYC+__nt4)n%b-$kJ?9+kw4M3Tq~2d zn7#<@usD9h3M)*3^S_~YO+uCM28OcX-@jRB!&6aar~8+m{5xtB>7XhMTT^s6LML6? zb^O$76vp;1VnA~KN>~~N!ny%p?(q`kLa)I>?=2}Xr8l?Cm#!E5RPm@>%k*jWXNiGd zibkjPmp8NuF{IeIwXiS-=k6n1U^$NG75F}NqZ0fiwq}j?%bbPhT#m^?eWa}>`rnS@uq?p%!NXkhv9l*@)etSC^ z;T+L4Qf)HYb~`;YiC8y6MqM9$do2>@H# zPX0sgF!6)Y=}Mtf1ZRt!d}E1K_RaM`fyCv!8LGtj$-i$7f8bwkTi)``%1YxfzNClw zqIHPsvsqZ>Cr0SWu=hJHb@I8Y_>+AF&ak8?AyuOGmx?E?0 zciIMg_;qOMsmDKkDxYc_dWcrlU;5Se=PJ!AHcRf2(u5>2L65Y?3@rQ1A|1|vNsppi zla7XSM2@Cr=o<0aysF{JW!#D&(4Opz#t(m|8DE-fjrpBSBx0!s%YhrDS@<)LUN&YSIg#r@-Qw80B~~Z6l#0?6k;bXyUJ6jYGqLgsu>HE&(VRhizS@?u|u{a z+s{sA2-je^+gOD()C?(ZFtF2^9cYnmqoD<7G}Gq^yZvSKg>-XGX~N!eWrs#D)3uD%^t@jR)Jn1VPzV+P3XTQZXl_n3iXojp zpwcxn>(IH;Z0DJcI@C!$60?&hKVrfrBM$|I*W@Aan<30=$?UUON_DkPWiXOi*^;X> z;6!0OVDjVa8u(g{_q}{%LjH7!Y{`-}kOCyv7;~2aYM89l2JRveavGYR zO&RThP2%PZ3|=u^3))XP9E=)_4l129j%4zRYruf2vlK6iBdPg7J}!2wsADi8vXpRN zo>t?5-UQ4(s?;vt*DguC;Rn;qA1N@^K0%M9kb2L-se+;srDt^wbPG;{j6=_|2Y@cJ z>aHgRBgH{({!ig!_1zF+`k@3o%LJ7hsB?ZY1r##Hb%f=`=vA$t z2`ilyr%PKx-~zAGnmt&^5?X*Q>7!VCN^h$W1KlKX55G6JQfDn`T6>=BS(z#jO)p$Y z3xVS};*;@>Do(?gv*N5(6{03qHE*ja3ikLJMZrFa*JOe!R~FwDU);&}R0}L~@DL^N za%PI!bcQ;&5wMJ^Br;Gej-Oy%#&Esi%!tLhwP-T3a|w`<3w%kRM_x60R-l!%hC z-D$7Armga8Q2SM%b`7v&nwI08x$$jcTjh$vejio82AAgwz!GoCcuQRXu7+p*=@b8p zwRti9MFY}1iwqkcvj@`6w93ipZ}84p`EZTZs6)`kcMrbvT4I?Ct90+0~)!ZvXlzsKpSL6{ywSb-!W4ik+ECmBZml>&q7`8Nm z8RWa7>0e;B2)B$9S@r;nsj}9bYk6z%E5mt&heC@@ z8uTFz!x3~=;ZOv7BpQ9vkub9a7u_Iy$t|nU29>kZM*k)76sN#Cnu*^)KNG#hF5Z@~N($`my`G+iM-R-ZeB~(uSPyFMi|eSj8}> zeLxL6fsH6!ZrLt=gpnuX)u;hX!47FjFzdHcNO%Er-{N$2a`u4K0x|g$6g* z;qszg(Zc~6J`k{M zI!HZ0({Qn_re|O@Pz}j~LlyOk_)r#dxFF)T+bT0Ia>CQX(^jRs)Z>LkGhD#Gyn3}L(WJT2sW2xkt6LGeftqd?$cm%G1 za49uZ4MpD5-v^>MV!|qwb9YIC{i3BJ3g$4K0h!b#L@gM4G%B~pv)TA+>aJs&B%qM` zMNA3f%h>&4i!I0o;8zyuWG@ix93g|E%ftB6f7sgj!>`eN?D7O)b3^IG=$M(p#WT+7qz=4$qaa z>6##EVh{(-JhHxPqzj7@SAQ~#m+e2mh_$t1m(GO}PI80J31DbKFSry+OPx2Q@t1-~i?na6R}J9qKoL4+ z8*x5ZJ2mWAS(%zPa|} zFbsNzMh%TN8&Jm?918i$(GyZiuV|3&!#~(*2IgNj6OX z2dPbDDzH?p4Y{H=A!)wooSmJ23(xADC-%Fo_4TcX53LA(Sq+R=BJ*148(3!ts_ccz z1W(L5oFk;R!iDdcvAi91a^a-X1`}tksZuHr2f@i9gKB5i_*w=G)Qf|rLaP)<4sa+t z9%QJ-NX~EnjOwu2JCeE*@?U-C|zH)TQ1Avl`K_J5*Qfh^mf%cW-JV;VrO?RiSe9KvH zt9B8{=28by1k@=gLWiLOhcvCpZHGS&54G!z(qzMsA`0>fkkH*xOP7 zTzn%gnY;=kHCOx^n7RhGK06SG+TZQ+}IIE3@#>x>eChPP+dQBkqDtWCjJ@<8h5w_a)7 zBA=8f8^of|e3Ys~nW^MSbnlFAm>0AzEw+JUCap0Dc1+i2Boab;{-J-AuL!X)FGjw( zuP)W!Y(0Fu_06}XBED}H0~}w{Jr)AN#m){+wmn_4_p=Y}NgUnwo0r{RsCCEz<7k?b zYZ|kaD{|+ec1df2PK;m5Z{15B9YijYDK}fztwoi1i7j!dYzakjh7_=Z+<=2ia`+)z zF=|@H`T`P*$Sx)cvaW_m&gd&DjMWG3Bvo9MO5j9Z3Nl&4(p#A$a~kX1sV5aNYG>8M zfgR%Ntz;F1tFmO2%0lT!=o#9%NfnC_hi_ejAEcGY738yXWJ0I2Bm!JQ5F$)-Af9WL z3|v>ZM=J+sjQL5M!_`Oa3T+lrR9Xvc?CtOF=5!o~@T6X=0ia}wXo|E%a_psa;jVp2 z6iE>`xwo?C2FmDP^?wI2u?6JTR4xQ11L1E*UXN}S9Fe`nF)IKEgPk8CQJ-dvGXN?+ z0O{Xq5F1D4{x6p5dJ^u=LWDi~%dlFTMw9ERB+FNX$>;_4C<#TNnTqH$%5hB9;pQWS z>xcbpl2QoXtBOw20*O?L|hMw3!Dq-)WcIx)!@wl8x9gU@0taatp2 ze|1{(`C~9Mt;lW-%#zHenKL^{m_t z(m%`bVaVSd+k>0-Z}8+OM?Y#brBp$3lAaa#o!&fu{oDOb)d5~&cMU^Z3*o~Eh3O(q5@92*dN*5Dpzg#rUW2fVb z(NN?jbRY)2w6aNtge9aPn-w*9K(DnU2PGOpn$&?Nt1`Sw;1+i}TBM_YIkLs6=%kzz z(Ll^57oOh~^Ch}xmX%_LV1twc33DN5C=ZEoA^V9UszaOlSQ=0yc{^`9WBH8T*4ZehQfas>q$4CdtbP-S$%^ONK8{A$ckEu?+LxR50u(2 ziyzi**CvqHUg>n1OU$iZ*TfbGW-FsUG~nNXuC$CAb0aFv0+Y`-uI#qcP!DEdG^c`z z(TOh!1B{(8QuSy-PUF*EQ=V=reh`A^xMZ+ixT6{qB2dMCfuJ7IC6lt$B}AmNX5E8D zDKnsoeJYutDxD4TT%jv;s3hnwq5OLUHOG}^o7xC_tqxV!3zo>O0TxbRtp?P<`!rLL zdntFH9G?X|O_+hnoV)BXpSs3??3Z|}fCjN;BhT#SnhLx~s%#Yhh)3YAOTfAu*?XIh z_`mhG1s?$B=zIbn&R+W#XeUEsHDd>I8nmd&Nq|yN@}larY6-lkVkKIyWCe~A^nHjN zL~{#-O4qerWf_D{z{aHU@n0H%`Ge_@^4PPNs^%i1K%|TVL|Q2FS58|I=i=TKP_$cWs>qgND=)@ElW(&?FC!2zqemqo@Kd}D3 z1TNZtS6*!f5#@>fbFLyi5ft;|E5I8Rg@5S2?!2A(k9e!@L6K!p(FP>wRa?WeIbi%6 z>B4TaH@9$YwQztjBrVp8b3b{>^Q4ls;qS(gcnw+KOyuMOA%q4 zblFJ+WU%3gmuQNZ;-jp%(;S+HV-a26uNo&oUG;w(Q;vZvvBKq}(S)Wp1vo=HJJu6% zODxg||HC%Ys@8q^$wV+qr#n`iMaMMiw8|CDESC&wiZ0ClTjZ6VmQ@N9Hl*5j`yxt* z7!0Xwn|607WdoR6jm;FO{voF`)F^nxFXk~C-%Gl+uY(_?U0>Z7u?{=qpVIE)*egxV zvit--2`^)%2^cb(y&odbzP{?ilXFUCwvrqIj5O-TLi!C2eb}2n*sm{#^*NZcBk>DQ?%C#VC#cL&5Z^{6wzFkVfIfIx#Q_n-LW(fetRN8mT}JnewUX9s+iEScMbd_S5nY5=7XV literal 0 HcmV?d00001 diff --git a/doc/midas/info.mins b/doc/midas/info.mins new file mode 100755 index 00000000..d72a5d92 --- /dev/null +++ b/doc/midas/info.mins @@ -0,0 +1,118 @@ +Received: from MIT-JIMI by MIT-MC via Chaosnet; 1 JUN 85 18:49:39 EDT +Date: Sat, 1 Jun 85 18:48 EDT +From: David Vinayak Wallace +Subject: new midas for twenex +To: info-midas@MIT-MC.ARPA +Message-ID: <850601184814.1.GUMBY@JIMI> + +Twenex Midas now kills itself (via PRARG) when done. I think this will +only affect MIT users, but if any other site's exec recognises the same +PRARG options, ftp the file oz:ss:TSRTNS.MID.232. + +david + +Mail-From: KLH created at 4-Oct-83 13:49:28 +Date: Tue 4 Oct 83 13:49:27-PDT +From: Ken Harrenstien +Subject: Re: Midas improvements. +To: G.EGK@SU-SCORE, info-midas@MIT-MC +cc: KLH@SRI-NIC +In-Reply-To: Message from "Edjik " of Sun 2 Oct 83 17:15:13-PDT +ReSent-date: Thu 13 Oct 83 00:21:40-PDT +ReSent-from: Ken Harrenstien +ReSent-to: info-midas@MIT-MC + +MIDAS does have this ability (FOO=BAR"), however it (and many other +such features) exist only for the ITS STINK relocatable format, rather +than the LINK format. I am looking at what would be required to +provide functionality similar to STINK, but this is somewhat difficult as +there are a bunch of things that STINK format allows, which LINK doesn't, +so it requires really understanding what is going on in order to let only +the LINK-allowable things happen. The person who did .DECREL originally +took the easy way out by requiring things to be assembled more or less +pseudo-absolutely. I haven't given up, but it's tough going as very +little of the STINK format is documented. Fortunately a lot of it is +extremely similar to LINK, and they are doubtless related far back in +the dim past. +------- + +Date: Sun 2 Oct 83 00:25:46-PDT +From: Edjik +Subject: Midas improvements. +To: info-midas@MIT-MC.ARPA + +One thing I've noticed MIDAS missing that MACRO has, is the ability to +have external symbols in equals (=). This is quite handy and makes +writing modules easier. Dunno how hard it would be to make MIDAS +generate the appropriate LINK record but it probably is worth it. + +--E+ +------- + +Date: Wed 28 Sep 83 18:12:33-PDT +From: Ken Harrenstien +Subject: Some questions +To: info-midas@MIT-MC +cc: klh@SRI-NIC + +I have a few questions about some things I found in the MIDAS BUGS +file. I seem to be in a mood to fix them, depending on the kind +of answers I get... + +1. .FAS or .FASL? + Some people claim that on TOPS-20, output files generated with +the .FASL pseudo-op should have the extension .FASL rather than .FAS. +Is this true? Is this also true for TENEX? + +2. TOPS-20 CCL? + This purportedly no longer works for V3+. Where do I find +out how it should work? Should compatibility with V2- be retained? + +3. MIDAS .INSRT library? + I would like to provide a system-independent way of allowing +programs to .INSRT commonly used files. For this purpose I am thinking +of adding a new pseudo called .INSLIB which would act exactly like +.INSRT with the difference that the device/directory names would default +to a place containing standard, public, or useful MIDAS .INSRT +packages. This place can be defined on a per-system basis. If it was +ever desired to change these defaults for a single assembly, this +could be done by giving an .INSLIB specification with an explicit +device/directory and no filename. Comments welcomed. + +4. Others? + If you have some ideas which have never been sent to +BUG-MIDAS, now is a good time, not because I plan to try doing +anything but because I am interested in seeing whether other people +have found undocumented bugs or have hidden wish lists. I have a +loooong list of MIDAS ideas as well as bugs, which will be available +in MIDAS;IDEAS > (plus MIDAS BUGS), for those who care to avoid +reiteration. The usual warning: very few such items ever +get implemented. +------- + +Date: 27 September 1983 13:44 EDT +From: Ken Harrenstien +Subject: Mailing list on OZ... +To: Ian @ MIT-OZ +cc: INFO-MIDAS @ MIT-MC + +Yes, merge it (you can just point to it if you want to keep an OZ-specific +group)... + +Latest version of MIDAS (not back on MC yet) fixes the various +problems with building new MIDASes. I am currently +scanning MIDAS BUGS (archive of bug-midas mail) to see if there +are any interesting things that are easy to add before installing +it. + +Date: 27 Sep 1983 03:29 EDT (Tue) +Message-ID: <[MIT-OZ].IAN.27-Sep-83 03:29:17> +From: Ian Macky +To: Info-MIDAS@MIT-OZ +Subject: Mailing list on OZ... + +There's this list here... maybe it should be merged? It's mostly to do +with 20-only stuff, usually OZ-only, like new packages and junk. + +MIDAS-USERS=Ian Jeh ZZZ Marty *SS:MIDAS.ARCHIVE Gumby egk GZ-OZ GS + diff --git a/doc/midas/midas.bugs b/doc/midas/midas.bugs new file mode 100755 index 00000000..bb8e0f8f --- /dev/null +++ b/doc/midas/midas.bugs @@ -0,0 +1,5654 @@ +Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 87 01:09:13 EDT +Date: Sat, 13 Jun 1987 01:06 EDT +Message-ID: +From: Rob Austein +To: Bug-MIDAS@AI.AI.MIT.EDU +Subject: TSRTNS.MID.233 (20X @COMPILE command support) + +I added support for the crufty PRARG%/TMPCOR CCL kludge to MIDAS, so +that @COMPILE will work right on MIDAS files on Twenex. I installed +TSRTNS.MID.233 on XX, OZ, and AI, installed new MIDAS.EXE on XX only. +Support for MIDAS has been in the Stanford EXEC for ages, I just added +it to the MIT EXEC as of version MIT160. + +Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Oct 85 06:49:06 EDT +Date: Fri 18 Oct 85 03:51:31-PDT +From: Ken Harrenstien +Subject: * and & in macro defs +To: bug-midas@MIT-MC.ARPA +Message-ID: <12152065869.17.KLH@SRI-NIC.ARPA> + +There is a possible bug in the way * and & (and perhaps other such +switches) are implemented, or at least in the way they are documented. +One is given the impression that there are several orthogonal attributes +an argument can have, and that once you turn on a certain attribute, that +applies to all following arguments until explicitly turned off again. +However, it appears that for some (most?) cases the "turn-off" switch actually +does a global reset back to type "normal" instead of merely turning off +its specific attribute. I found this when trying to figure out why +a macro definition of this form + + DEFINE FOO ?BAR,&STR&,ETC,ETC2 + +resulted in ETC and ETC2 being normal-syntax instead of balanced. +Really screws one up when FOO is invoked as a parenthesized call with +2 args! During the debug process I stared at the documentation +several times without catching on. + +MIDAS macro syntax is so baroque that it would probably be handy to +have a pseudo-op like .DEFINE which acted like DEFINE but which also +generated, in the listing output, a readable description of its +arguments so that you know exactly what MIDAS thinks you did. +.DEFINE'd macros could also have additional helpful listing output +when being expanded. Oh well, who's going to bother anyway. +------- + +Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Oct 85 06:49:06 EDT +Date: Fri 18 Oct 85 03:51:31-PDT +From: Ken Harrenstien +Subject: * and & in macro defs +To: bug-midas@MIT-MC.ARPA +Message-ID: <12152065869.17.KLH@SRI-NIC.ARPA> + +There is a possible bug in the way * and & (and perhaps other such +switches) are implemented, or at least in the way they are documented. +One is given the impression that there are several orthogonal attributes +an argument can have, and that once you turn on a certain attribute, that +applies to all following arguments until explicitly turned off again. +However, it appears that for some (most?) cases the "turn-off" switch actually +does a global reset back to type "normal" instead of merely turning off +its specific attribute. I found this when trying to figure out why +a macro definition of this form + + DEFINE FOO ?BAR,&STR&,ETC,ETC2 + +resulted in ETC and ETC2 being normal-syntax instead of balanced. +Really screws one up when FOO is invoked as a parenthesized call with +2 args! During the debug process I stared at the documentation +several times without catching on. + +MIDAS macro syntax is so baroque that it would probably be handy to +have a pseudo-op like .DEFINE which acted like DEFINE but which also +generated, in the listing output, a readable description of its +arguments so that you know exactly what MIDAS thinks you did. +.DEFINE'd macros could also have additional helpful listing output +when being expanded. Oh well, who's going to bother anyway. +------- + +Received: from decwrl.ARPA by MIT-MC.ARPA 4 Aug 85 18:36:09 EDT +Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34) + id AA03542; Sun, 4 Aug 85 15:36:11 pdt +Message-Id: <8508042236.AA03542@decwrl.ARPA> +Date: Sunday, 4 Aug 1985 15:35:23-PDT +From: budne%mrfort.DEC@decwrl.ARPA (Phil Budne) +To: bug-midas@mit-mc.ARPA +Subject: New program CVTUUO + + + ----- Delivered by TOPS-20 Message Services --- +Date: 4 Aug 1985 1830-EDT +From: Phil Budne +To: """bug-midas@mit-mc.arpa""" at DECWRL +Subject: New program CVTUUO +Message-ID: <"MS11(2411)+GLXLIB5(0)" 12132532256.137.48.52511 at MRFORT> + +MC: GUEST0; BUDD CVTUUO contains a version of MRC's CVT program +that runs under TOPS-10, and sucks in UNV:UUOSYM.UNV and UNV:MACTEN.UNV +to produce DECDFS.MID. + +-Phil Budne + -------- + +Received: from SIMTEL20.ARPA by MIT-MC.ARPA 19 Jun 85 21:20:35 EST +Date: Wed 19 Jun 85 06:51:18-MDT +From: Mark Crispin +Subject: Re: system bits +To: CSTACY@MIT-MC.ARPA +cc: BUG-MIDAS@MIT-MC.ARPA +In-Reply-To: Message from "Christopher C. Stacy " of Tue 18 Jun 85 22:37:21-MDT + +I was under the (perhaps mistaken) impression that system definitions +are snarfed from the operating system, which would imply that you +would need to install a new version of ITS. At least that's the way +FAIL on WAITS gets UUO definitions, and I thought MIDAS on ITS worked +the same way. +------- + +Date: Wed, 19 Jun 85 00:33:28 EDT +From: Christopher C. Stacy +Subject: system bits +To: BUG-MIDAS@MIT-MC.ARPA +Message-ID: <[MIT-MC.ARPA].549329.850619.CSTACY> + +I was writing an init file for someone today and I wanted to make use +the the ITS bit named %TYRLM. The bit is defined in SYSTEM;BITS but +DDT did not know about it. DDT does not appear to explicitly include +the BITS, so I assume it guess it gets its system symbols from MIDAS. + +MIDAS did not know about my bit either, and there seem to have been +many changes to MIDAS lately, so I went to assemble a new MIDAS. +I found and fixed two trivial MIDAS bugs in the TSRTNS module. +The CORGET routine had an ill-formed system call, and the CMD routine +was confused about JCL handling. I did not audit the numerous changes +which have been made, and did NOT install MIDAS 458, which at least +seems to work now. + +However, the %TYRLM bit is still not known to MIDAS (or a TS DDT +assembled by same). I am not familiar with MIDAS at all. +What do I need to do to get this bit known by MIDAS? + + +Received: from MIT-JIMI by MIT-MC via Chaosnet; 1 JUN 85 18:49:39 EDT +Date: Sat, 1 Jun 85 18:48 EDT +From: David Vinayak Wallace +Subject: new midas for twenex +To: info-midas@MIT-MC.ARPA +Message-ID: <850601184814.1.GUMBY@JIMI> + +Twenex Midas now kills itself (via PRARG) when done. I think this will +only affect MIT users, but if any other site's exec recognises the same +PRARG options, ftp the file oz:ss:TSRTNS.MID.232. + +david + +Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 10 APR 85 02:48:11 EST +Date: Tue 9 Apr 85 23:31:50-PST +From: Mark Crispin +Subject: Re: should midas kill itself +To: GUMBY@MIT-MC.ARPA +cc: KLH@MIT-MC.ARPA, BUG-MIDAS@MIT-MC.ARPA +In-Reply-To: Message from "David Vinayak Wallace " of Tue 9 Apr 85 23:18:20-PST +Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 +Phone: 1 (415) 968-1052 + +No, the COMPILE commands do not RSCAN% the filename to MIDAS. They use +PRARG% which for TOPS-10 compilers is used by PA1050's support of the +TOPS-20 TMPCOR UUO. +------- + +Date: Wed,10 Apr 85 01:56:35 EST +From: David Vinayak Wallace +Subject: should midas kill itself +To: KLH@MIT-MC +cc: BUG-MIDAS@MIT-MC +In-reply-to: Msg of Mon 8 Apr 85 16:36:02 EST from Ken Harrenstien +Message-ID: <[MIT-MC].449503.850410.GUMBY> + + Date: Mon, 8 Apr 85 16:36:02 EST + From: Ken Harrenstien + + If there is some safe way of making this happen, I suppose it is all + right. The problem is that I have never seen any documentation which + explains the standard conventions for using PRARG%. I tried to find this once, + so I could make MIDAS work with COMPILE-class commands, but gave up; + that is one of the most obscure pieces of mumbo-jumbo I have + encountered in quite a while. Now you are talking about PRARG% in the + OTHER direction too? Argh... give me a .break.... + +I don't see what the hassle is for that...the COMPILE commands just RSCAN% +the filename to MIDAS? + +Date: Mon, 8 Apr 85 16:36:02 EST +From: Ken Harrenstien +Subject: should midas kill itself +To: GUMBY@MIT-MC +cc: BUG-MIDAS@MIT-MC +Message-ID: <[MIT-MC].447245.850408163630.KLH> + +If there is some safe way of making this happen, I suppose it is all +right. The problem is that I have never seen any documentation which +explains the standard conventions for using PRARG%. I tried to find this once, +so I could make MIDAS work with COMPILE-class commands, but gave up; +that is one of the most obscure pieces of mumbo-jumbo I have +encountered in quite a while. Now you are talking about PRARG% in the +OTHER direction too? Argh... give me a .break.... + +Received: from MIT-OZ by MIT-MC via Chaosnet; 8 APR 85 00:20:56 EST +Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Apr 85 00:20-EST +Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 8 APR 85 00:20:26 EST +Date: Sun 7 Apr 85 21:19:51-PST +From: Mark Crispin +Subject: Re: should midas kill itself +To: GUMBY@MIT-MC.ARPA +cc: bug-midas%MIT-OZ@MIT-XX.ARPA +In-Reply-To: Message from "David Vinayak Wallace " of Sun 7 Apr 85 18:06:54-PST +Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 +Phone: 1 (415) 968-1052 + + Okay, at least you are talking about PRARG% instead of +RSCAN%. I still remember the day I did a SEND on OZ and found +that some wonderful (sic) person had "improved" SEND to RSCAN% +out a RESET...since my environment ran it ephemerally it reset my +EMACS. That was the last day I tried to do anything serious on +OZ... + + Re: "PCL is bogus". The implementation is bogus, but +certainly something of that functionality is needed. Or are you +happy only when you are modifying the internals of the operating +system and command decoder? + + You needn't tell me "VALRET is bogus". I remember when on +ITS that was the only way to communicate between a program and +DDT. .BREAK (I forget the value of n) was an improvement, +but it was still bogus. I bugged RMS for something better, and +one day .LOGOUT 1, appeared... + + "What if the compilation terminates abnormally?"...well I +don't see how the MIDAS fork is useful, unless you mean MIDAS +blowing up. I didn't think MIDAS did that any more. +------- + +Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 21:04:43 EST +Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 21:04-EST +Date: Sun, 7 Apr 85 21:04:10 EST +From: David Vinayak Wallace +Subject: should midas kill itself +To: MRC@SU-SCORE +cc: bug-midas@MIT-OZ +In-reply-to: Msg of Sun 7 Apr 85 13:49:00-PST from Mark Crispin +Message-ID: <[MIT-MC].446043.850407210413.GUMBY> + + Date: Sun 7 Apr 85 13:47:38-PST + From: Mark Crispin + + What do you mean "kill itself off when done"? If you mean to RSCAN% + back a RESET command a number of people will be quite pissed, since + very often MIDAS is run ephemerally or (in my environment) from a PCL + command file. That RSCAN%'ing hack causes some other fork to be smashed! + + Date: Sun 7 Apr 85 13:49:00-PST + From: Mark Crispin + + Why don't you write a PCL procedure to invoke MIDAS. You can even get + it to grok filename completion that way. There is also the SET PROGRAM + EPHEMERAL feature. Let's not have any more programs which magically + RSCAN% stuff back to the EXEC. + +VALRET (i.e. RSCAN%) is bogus. So is PCL. What's wrong with using PRARG +(the TNX equivalent of .BREAK)? Those systems whose execs ignore it won't +notice; the MIT-exec at least will do the right thing. + +Setting it ephemeral is NOT the right thing! What if the compilation +terminates abnormally? + +Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 16:55:03 EST +Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 16:54-EST +Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 7 APR 85 16:49:34 EST +Date: Sun 7 Apr 85 13:49:00-PST +From: Mark Crispin +Subject: Re: should midas kill itself +To: GUMBY@MIT-MC.ARPA +cc: bug-midas%MIT-OZ@MIT-XX.ARPA +In-Reply-To: Message from "David Vinayak Wallace " of Sun 7 Apr 85 01:22:08-PST +Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 +Phone: 1 (415) 968-1052 + +Why don't you write a PCL procedure to invoke MIDAS. You can even get it +to grok filename completion that way. There is also the SET PROGRAM EPHEMERAL +feature. Let's not have any more programs which magically RSCAN% stuff +back to the EXEC. +------- + +Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 16:48:31 EST +Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 16:47-EST +Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 7 APR 85 16:48:10 EST +Date: Sun 7 Apr 85 13:47:38-PST +From: Mark Crispin +Subject: Re: should midas kill itself +To: GUMBY@MIT-MC.ARPA +cc: bug-midas%MIT-OZ@MIT-XX.ARPA +In-Reply-To: Message from "David Vinayak Wallace " of Sun 7 Apr 85 01:22:08-PST +Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869 +Phone: 1 (415) 968-1052 + +What do you mean "kill itself off when done"? If you mean to RSCAN% +back a RESET command a number of people will be quite pissed, since +very often MIDAS is run ephemerally or (in my environment) from a PCL +command file. That RSCAN%'ing hack causes some other fork to be smashed! +------- + +Received: from MIT-OZ by MIT-MC via Chaosnet; 6 APR 85 20:28:49 EST +Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Apr 85 20:28-EST +Date: Sat, 6 Apr 85 20:28:10 EST +From: David Vinayak Wallace +Subject: should midas kill itself +To: bug-midas@MIT-OZ +Message-ID: <[MIT-MC].445177.850406202842.GUMBY> + +Would anyone complain if I changed twenex midas to kill itself off when +done if invoked with jcl? I like this behaviour on ITS. + +Date: Fri 1 Mar 85 15:29:13-PST +From: Ken Harrenstien +Subject: Re: more help needed from a midas wizard +To: HEDRICK@RUTGERS.ARPA +cc: bug-midas@MIT-MC.ARPA, KLH@SRI-NIC.ARPA +In-Reply-To: Message from "Charles Hedrick " of Fri 22 Feb 85 20:59:30-PST + +Have you been able to check the fix yet? +------- + +Date: 22 Feb 85 20:59:30 EST +From: Charles Hedrick +Subject: Re: more help needed from a midas wizard +To: KLH@SRI-NIC.ARPA +cc: bug-midas@MIT-MC.ARPA +In-Reply-To: Message from "Ken Harrenstien " of 22 Feb 85 19:07:18 EST + +Thanks. It will be a couple of days before I have time to check it. +I'll tell you either way. +------- + +Date: Fri 22 Feb 85 16:07:18-PST +From: Ken Harrenstien +Subject: Re: more help needed from a midas wizard +To: HEDRICK@RUTGERS.ARPA +cc: KLH@SRI-NIC.ARPA, bug-midas@MIT-MC.ARPA +In-Reply-To: Message from "Charles Hedrick " of Tue 19 Feb 85 21:15:34-PST + +Try this patch, and tell me if it cures your problem. More importantly, +tell me if it causes new problems! It fixes the test case, but I need to +make sure it does not break anything else before firmly installing the +change in the source. + + at ASMOT4+1, change the value PBY5 to BYTINR. + at ASMOT4+2, ditto. + +If you want an explanation: the constants-optimization code tries to +make sure that the constant does not contain still-undefined global +quantities. However, when byte mode popped out of angle brackets, it +was resetting the global-link table as if it had popped out of square +brackets. Thus when the constant was stored, it appeared as if there +were no undefined globals involved. I suspect this was just a mental +spaz by whoever wrote the code. +------- + +Date: 20 February 1985 15:15-EST +From: Alan Bawden +Subject: more help needed from a midas wizard +To: HEDRICK @ RUTGERS +cc: BUG-MIDAS @ MIT-MC, tops-20 @ SU-SCORE + + Date: 16 Feb 85 21:18:13 EST + From: Charles Hedrick + Could someone tell me why the following code generates an error + complaining that there are more constants in pass 2 than pass 1? I + assume this is a bug in Midas. + + title test + + loc 140 + + define object(type,val) + <.byte 6,30. ? type ? val> termin + + move 1,[object 3,<4,,a>] + move 1,[object 3,<4,,b>] + + a: 1 + b: 2 + + end + + If you replace the macro calls to OBJECT with their definition, the + error does not occur. Putting () around the call does not help. + +I replaced the macros calls to OBJECT to obtain the following: + + title test + + loc 140 + + move 1,[<.byte 6,30. ? 3 ? <4,,a>>] + move 1,[<.byte 6,30. ? 3 ? <4,,b>>] + +a: 1 +b: 2 + + end + +Which also gets the "more constants on pass 2" error, so I don't think that +the macro has anything to do with it. (You must have spazzed when you +performed the expansion manually.) Your problem would seem to be just +another instance of a perennial midas screw. This one has probably shafted +everybody at least once. + +What is happening is that on pass 1 Midas uses 0 as the value of as-yet +undefined symbols, such as A and B in your example. This causes both +literals to look like they will contain the same one-word quantity. Midas +tries to be clever and optimize one-word literals to share the same +storage. Then on pass 2 they turn out to be different and Midas hasn't +allocated enough constants space. + +I don't understand why this one doesn't shaft people -more- than it does +now. Big programs generally generate enough noise in their constants +between pass 1 and pass 2 that they don't get screwed, only small programs +get bit. I guess I would advocate putting in a switch to turn the +constant-sharing hack off so that people can work around this screw when it +happens. Clearly there are better solutions, but that would be sufficient. + +Return-Path: <@SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA> +Received: from SU-SCORE.ARPA by MIT-XX.ARPA with TCP; Sat 16 Feb 85 21:24:15-EST +Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sat 16 Feb 85 18:19:55-PST +Date: 16 Feb 85 21:18:13 EST +From: Charles Hedrick +Subject: more help needed from a midas wizard +To: tops-20@SU-SCORE.ARPA +ReSent-date: Tue 19 Feb 85 13:47:12-EST +ReSent-from: Gail Zacharias +ReSent-to: bug-midas@MIT-MC.ARPA + +Could someone tell me why the following code generates an error +complaining that there are more constants in pass 2 than pass 1? I +assume this is a bug in Midas. + + title test + + loc 140 + +define object(type,val) + <.byte 6,30. ? type ? val> termin + + move 1,[object 3,<4,,a>] + move 1,[object 3,<4,,b>] + +a: 1 +b: 2 + + end + +If you replace the macro calls to OBJECT with their definition, the +error does not occur. Putting () around the call does not help. +------- + +Date: 10 February 1985 01:46-EST +From: Alan Bawden +Subject: IFSE poorly documented? +To: DEVON @ MIT-MC +cc: BUG-MIDAS @ MIT-MC +In-reply-to: Msg of 9 Feb 1985 16:54-EST from Devon S. McCullough + +Well, IFSE has nothing to do with it. What you are trying to say seems to +be that the way MIDAS parses normal arguments (to macros, conditionals, +etc.) is confusing. That's certainly true, but I don't think the +documentation could be any clearer on the point. There certainly are +enough examples scattered throughout the documentation that are explicitly +designed to get the reader thinking about this issue. For example, the +documentation for IFSE reminds you that + + IFSE FOO,[BAR][BLETCH] + +conditionalizes "BLETCH" while + + IFSE FOO,[BAR],[BLETCH] + +conditionalizes ",[BLETCH]". You just have to learn to keep the silly +rules in mind whenever you read anything written in MIDAS. + +Date: 9 February 1985 16:54-EST +From: Devon S. McCullough +Subject: IFSE poorly documented? +To: BUG-MIDAS @ MIT-MC, DEVON @ MIT-MC + +I experimentally determined the meaning of the following construct + +ifse [arg],[asciz/arg null/] +.else [asciz/arg not null/] +end + +after looking at :info programming midas cond, and not getting any info. +Maybe if I were more familiar with other aspects of Midas it would be +obvious, but I think this should be documented since it is used. +I would rather not fix the doc myself for various reasons, mainly my +inexperience with Midas. + +Date: 19 Dec 1984 14:43 PST (Wed) +Message-ID: <[SRI-NIC].IAN.19-Dec-84 14:43:58> +From: Ian Macky +To: "Frank J. Wancho" +Cc: BUG-MIDAS@MC +Subject: Can't build TECO... + + ERRRST+4 1604 0. 3-006 1B1 Undefined in = + ERRRST+4 1604 0. 3-007 1B2 Undefined in = + +"nBm" is a MACRO construct, sort of like .DPB - what's it doing in +that Midas file? 1B1 is 400000,,0 and 1B2 is 200000,,0 + + PS:TECO.MID.1206 + GILLTB+23 50340 0. 337-023 Symbol table full + +Well, looks like you need to up the arguments to the .SYMTAB op at +the top of the file, which defines how much storage to allocate for +the symbol table and constants areas. They should be primes... + + Unterminated successful bracketed conditionals + The first was at 285-002 of file TECO + Error is fatal. + Run time = 50.02 + 8001 Symbols including initial ones (100% used) + +Eh... Err... + +Date: 19 Dec 1984 15:00 MST (Wed) +Message-ID: +From: "Frank J. Wancho" +To: BUG-MIDAS@MC +cc: WANCHO@SIMTEL20 +Subject: Can't build TECO... + +MIDAS 436 and now MIDAS 458 work fine, except that I can no longer +build the same TECO I was able to build successfully a year ago with a +"NOTPUR" MIDAS 429. Also, never saw mention of VTSDEF in the log +before: + +@midas +MIDAS.436 +**temp_teco +TECO +PS:VTSDEF.MID.3 +ERRRST+4 1604 0. 3-006 1B1 Undefined in = +ERRRST+4 1604 0. 3-007 1B2 Undefined in = +END OF LOW IMPURE = 4023 +PS:TECO.MID.1206 +GILLTB+23 50340 0. 337-023 Symbol table full +Unterminated successful bracketed conditionals +The first was at 285-002 of file TECO +Error is fatal. +Run time = 50.02 +8001 Symbols including initial ones (100% used) + $ $ + +Date: 26 November 1984 17:39-EST +From: Richard M. Stallman +Subject: MIDAS bug +To: HEDRICK @ RUTGERS +cc: BUG-MIDAS @ MIT-MC + +I have a suspicion that DOCAR is a macro. +Your problem is due to the fact that ? +does not terminate macro arguments. +You could put a newline in place of the ? +or you could make the arguments balanced +and put some sort of parentheses around the call +or various other things. But I don't think that +changing the definition of MIDAS macro calls so that +? will terminate one is an available alternative. + +Return-Path: +Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 20 Nov 84 17:27:35-PST +Date: 20 Nov 84 20:33:48 EST +From: Charles Hedrick +Subject: MIDAS bug +To: tops-20@SU-SCORE.ARPA +ReSent-Date: Mon 26 Nov 84 01:45:14-PST +ReSent-From: Mark Crispin +ReSent-To: BUG-MIDAS@MIT-MC.ARPA + +Does anyone have source to Midas? Our Common Lisp was giving +incorrect results for MINUSP. It turns out that the code + jrst [docar o1,o1 ? jrst minusp] +was assembling into + jrst [garbage] +When I replace docar o1,o1 with move o1,(o1) [which is its +expansion] the code is correct. I would like to fix this problem, +since I find the concept of an assembler that produces bad code very scary. +------- + +Date: Wed, 7 Nov 1984 12:25 EST +Message-ID: +From: Gail Zacharias +To: Alan Bawden +Cc: BUG-MIDAS@MIT-MC +Subject: .ASCII +In-reply-to: Msg of 7 Nov 1984 01:51-EST from Alan Bawden + +Well, there are certainly other situations where Midas gives undefined +errors on pass 1 even though things might turn out to work out alright in +the end due to special circumstances. The solution then is to either +ignore the warning or do something by hand that takes advantage of the +special circumstances. In fact your second example can be trivially +modified to work with an .ASCII which requires everything to be defined on +pass 1, so making .ASCII complain on pass 1 wouldn't be a fundamental +limitation. If it gave a warning but then proceeded the way it does now, +then it wouldn't be a limitation at all. You'd have to ignore the warning +in your case, but I think that's fair enough, it's certainly a matter of +luck and a very rare case where it happens to work out. Your hack only +works because the high octal digit of instructions is non-zero. That +wouldn't necessarily be the case in another radix, e.g. + RADIX 10. + .ASCII "10/! " +gives phase errors. So in a sense it would be more robust for you to do +the allocation by hand as in your second example, and I think a warning is +perfectly reasonable. + +The problem with the way it works now is that phase errors are such a pain to +track down, especially if they're caused by something Midas silently did +for you that you might not even be aware of. + +Maybe there should be two .ascii-style pseudo-ops (or a single pseudo-op +and a switch), one that allocated the maximum number of characters for each +value and then padded the string with 0 words on pass 2, and another that +required everything to be defined on pass 1. + +Date: 7 November 1984 01:51-EST +From: Alan Bawden +Subject: .ASCII +To: GZ @ MIT-OZ +cc: BUG-MIDAS @ MIT-MC +In-reply-to: Msg of Tue 6 Nov 1984 20:23 EST from Gail Zacharias + + Date: Tue, 6 Nov 1984 20:23 EST + From: Gail Zacharias + Trying to assemble + + .scalar x + .ascii "x=!x " + + results in all sorts of phase errors. I understand why I can't do this, + but Midas really should give me an "undefined" error right away rather than + trying to fake it and failing obscurely. + +Let me get this straight, you propose to make Midas generate an error if it +finds something undefined while evaluating an expression after a "!" in a +.ASCII? If that is what you mean, I claim that would be a screw. I have +code that does: + +.ASCII "259/!" + +where the value of FOO isn't known until later in the first pass. This +generates no phase errors because the value of has the same +number of characters in either case. Why should I be bothered by +unnecessary error messages? In fact I originally wrote + +.ASCII "259/PUSHJ P,!FOO" + +and lost in exactly the way you did. If I hadn't found that hack I would +have protected myself by doing: + +.ASCII "259/PUSHJ P,!FOO" +IF1, LOC .+17 +IF2, IFG .-QAZ, .ERR 17 is too small. +IF2, LOC QAZ +QAZ: + +Date: Tue, 6 Nov 1984 20:23 EST +Message-ID: +From: Gail Zacharias +To: bug-midas@MIT-MC +Subject: .ASCII + +Trying to assemble + + .scalar x + .ascii "x=!x " + +results in all sorts of phase errors. I understand why I can't do this, +but Midas really should give me an "undefined" error right away rather than +trying to fake it and failing obscurely. + +Date: Thu, 30 Aug 1984 22:54 EDT +Message-ID: +From: Gail Zacharias +To: Ken Harrenstien +Cc: bug-midas%MIT-OZ@MIT-MC.ARPA +Subject: .decrel format +In-reply-to: Msg of 30 Aug 1984 19:17-EDT from Ken Harrenstien + +[PHOTO: Recording initiated Thu 30-Aug-84 10:45pm] + + MIT TOPS-20 Command Processor 5(712115)-2 +@type foolib.mid + title FOOLIB + +foo: hrroi 1,[asciz " +foo foo +"] + PSOUT% + popj 17, + + end +@midas foolib +FOOLIB +FOOLIB +Constants area inclusive +From To +3 5 +Run time = 0.56 +4728 Symbols including initial ones (59% used) +@type test.mac + title test + search monsym,macsym + .require foolib + extern foo + +pdl: block 100 + +begin: reset% + move 17,[-100,,pdl-1] + pushj 17,foo + haltf% + jrst begin +end begin +@load test +MACRO: test +LINK: Loading +?LNKUGS 1 undefined global symbol + FOO 242 + +EXIT +@rename foolib.rel midas-foolib.rel + FOOLIB.REL.1 => MIDAS-FOOLIB.REL.1 [OK] +@type foolib.mac + title FOOLIB + + search monsym + +foo:: hrroi 1,[asciz " +foo foo +"] + PSOUT% + popj 17, + + end +@compile foolib.mac +MACRO: FOOLIB + +EXIT +@del test.rel + TEST.REL.1 [OK] +@load test +MACRO: test +LINK: Loading + +EXIT +@typrel + +Output file= tty: + +Rel file= midas-foolib.rel + +Type Data Total + +6 2 4 NAME FOOLIB +1 4 6 PROG +1 4 6 PROG +2 2 4 SYM +5 2 4 LAST '6 + +0 0 1 NIL + +Total file length (decimal words) = 25 + + +Done. +@typrel + +Output file= tty: + +Rel file= foolib.rel + +Type Data Total + + +4 0 2 ENTRY +6 2 4 NAME FOOLIB +1 7 11 PROG +2 4 6 SYM +5 2 4 LAST '6 + +Total file length (decimal words) = 25 + + +Done. +@pop + +[PHOTO: Recording terminated Thu 30-Aug-84 10:48pm] + +Received: from MIT-MC by MIT-OZ via Chaosnet; 30 Aug 84 19:36-EDT +Date: 30 August 1984 19:17-EDT +From: Ken Harrenstien +Subject: .decrel format +To: GZ @ MIT-OZ +cc: bug-midas @ MIT-OZ + +.DECREL works here. You are probably omitting something, but I haven't +the faintest idea what it might be (without anything to look at -- hint, hint). + +Date: Tue 28 Aug 84 19:56-EDT +From: Gail Zacharias +Subject: .decrel format +To: bug-midas@MIT-OZ +CC: gs@MIT-OZ + +How can I get midas to generate .REL files which are intended to be linked +into other programs. When I try it, the linker can't find any of the +symbols. I'm not too familiar with the formats, but comparing Midas +and Macro produced files, it seems that Midas is not putting out any "ENTRY" +blocks. Is there any way to make it do so? + +Date: 27 August 1984 21:04-EDT +From: Ken Harrenstien +Subject: Is there some reason... +To: JTW @ MIT-SPEECH +cc: BUG-MIDAS @ MIT-MC + + Date: Sun 26 Aug 84 20:18:32-EDT + From: John Wroclawski + + that DECSAV on 20X dumps .EXE files in non-sharable save format + instead of sharable save format? Seems a bit dumb... + +Only the same reason that SBLK on ITS dumps BIN files in non-sharable +SBLK format instead of sharable PDUMP format. It is not an +impossible feature to add, but it would take a fair amount of work. + +Date: Mon 27 Aug 84 13:27:28-PDT +From: Ian Macky +Subject: can't specify filename +To: bug-midas@MIT-MC.ARPA + +I had a filenamed (don't complain) 7^V%.MID, which worked fine everywhere +except for Midas, which simply would not allow me to specify that filename, +no matter how I quoted it. It either came out with 7.MID or 7%%.MID +but never just 7%.MID +------- + +Date: Sun 26 Aug 84 20:18:32-EDT +From: John Wroclawski +Subject: Is there some reason... +To: bug-midas@MIT-MC + + +that DECSAV on 20X dumps .EXE files in non-sharable save format +instead of sharable save format? Seems a bit dumb... +------- + +Date: Mon 6 Aug 84 16:33-EDT +From: Ian Macky +Subject: !@(*&^%#$ +To: bug-midas@MIT-OZ + +Once again MIDAS died of a "Fatal MIDAS internal error!" and couldn't even +pull off printing out where it died, which is a bug. It was ephemeral, so +I couldn't dump it. + +Received: from MIT-MC by MIT-OZ via Chaosnet; 20 Jul 84 13:18-EDT +Date: 20 Jul 1984 10:13 PDT (Fri) +Message-ID: <[SRI-NIC].IAN.20-Jul-84 10:13:49> +From: Ian Macky +To: Ken Harrenstien +Cc: bug-midas@MIT-OZ +Subject: I just got ===== Fatal MIDAS internal error! ===== +In-reply-to: Msg of 19 Jul 1984 23:33-PDT from Ken Harrenstien + +I couldn't reproduce it. Yes, there's nothing you can do, but I thought +I ought to report it anyhow... + +Received: from MIT-MC by MIT-OZ via Chaosnet; 20 Jul 84 02:32-EDT +Date: 20 July 1984 02:33-EDT +From: Ken Harrenstien +Subject: I just got ===== Fatal MIDAS internal error! ===== +To: IAN @ MIT-OZ +cc: bug-midas @ MIT-OZ + + Date: Wed 18 Jul 84 12:54-EDT + From: Ian Macky + Subject: I just got ===== Fatal MIDAS internal error! ===== + + etc, with no location printed ("Error was at location:" then nothing). + This was after 2nd pass, after it was displayed constats area... It + was ephemeral, so I couldn't dump it out. Not much else to say... + +Well, you could at least say how to reproduce it. How would you like +to try fixing MIDAS given only the above information? + +Date: Wed 18 Jul 84 12:54-EDT +From: Ian Macky +Subject: I just got ===== Fatal MIDAS internal error! ===== +To: bug-midas@MIT-OZ + +etc, with no location printed ("Error was at location:" then nothing). +This was after 2nd pass, after it was displayed constats area... It +was ephemeral, so I couldn't dump it out. Not much else to say... + +Date: Mon 9 Jul 84 14:58:01-PDT +From: Ken Harrenstien +Subject: MIDAS info blocks +To: ian@SRI-NIC.ARPA +cc: klh@SRI-NIC.ARPA, bug-midas@MIT-MC.ARPA + +OK, I have looked at the stuff and have the following comments. + +(1) I think it would be better to define a completely new sub-block +type (3 is currently the highest unused) which we can use as the "new +improved MIDAS-info block". The old info-block format would become +obsolete and only BINPRT would need to remember how to parse it. Then +ITS programs can take advantage of the expanded format, as well as DEC +programs, without breaking existing stuff. The key feature of this +block is that it can use your new method of including long strings. +I'd want the following items: + Count of stuff (so it's expandable) + Flag/value - Machine type assembled for (KA, KL, KS, *, etc) + Flag/value - System assembled for (ITS, 20X, etc) + Value/string - Date/Time of assembly (sys-dep or sys-indep format?) + String - System host name (eg SRI-NIC, MIT-MC) + String(s) - Source filename + (including dev, dir, fn1, fn2, etc...) + (by components, or as one single string, or either?) + String - User who assembled + String - Comments (arbitrary, furnished by program or loader) + + Anything else? Would it be useful to include info about + the program that created the binary file (MIDAS, DDT, LINK, etc) + or is this so esoteric it should be part of a comment? + +(2) I still don't think it is necessary to have a new sub-block type +just for the purpose of specifying a "linked" filename. My gut +feeling is that we should avoid unnecessary proliferation of new types +(which lots of programs will need to know about) and this sort of +stray information should be a comment, such as "This program just runs +the file BAR.EXE". There aren't that many "boot" programs and it +isn't clear what is ever going to need to look at this information +besides BINPRT (which will just print it out, same as a comment). +Now, if the EXEC were modified so that it scanned assembly sub-blocks, +found such a block, and did the loading itself (thus making it +unnecessary to have anything executable in the boot program at all) +then it would make sense to have this sort of explicit specification. +Of course that is not a good approach to the TOPS-20 filesystem link +problem, but it demonstrates the kind of rationale for having +sub-block types. + +You could perhaps argue in a similar way against most of the other +things in the assembly-info sub-block (that is, why aren't they just +part of a single large comment?) but I think more people would agree +that they are of general interest to a wider range of software. Certainly +the machine and system info must be rigidly specified, for example. + +Well, those are my thoughts. +------- + +Received: from MIT-MC by MIT-OZ via Chaosnet; 29 Jun 84 17:13-EDT +Date: 29 June 1984 17:14-EDT +From: Ken Harrenstien +Subject: apparent bug around inch53... +To: IAN @ MIT-OZ +cc: BUG-midas @ MIT-OZ + +Fixed (not yet installed pending final touches to Ian's info-block additions) + +Date: Thu 28 Jun 84 04:03-EDT +From: Ian Macky +Subject: apparent bug around inch53... +To: BUG-midas@MIT-OZ + +if the input file is an even number of pages, inch53 seems to screw +up in trying to figure out the last byte in the buffer, and points +to a byte in the next page, causing an npx error when pure... + +reproducable, if ya wanna see it. + +Date: 20 June 1984 18:28-EDT +From: Alan Bawden +Subject: @BINPRT +To: Ian @ SRI-NIC +cc: BUG-MIDAS @ MIT-MC, GZ @ MIT-OZ, Moon @ SCRC-TENEX +In-reply-to: Msg of 20 Jun 1984 15:15 PDT (Wed) from Ian Macky + +I presume that the right thing to do is do the analogous thing to ITS SBLK +format and have a general mechanism for putting typed info blocks after the +entry vector word. Perhaps even a duplicate entry vector word at the end +of the file to terminate it? + +Heck, then you could hack Midas to put the symbol table there as well. + +And then a version of DDT that new how to eat the symbols from those info +blocks... + + +Date: 20 Jun 1984 15:15 PDT (Wed) +Message-ID: <[SRI-NIC].IAN.20-Jun-84 15:15:37> +From: Ian Macky +To: Alan Bawden +Cc: BUG-MIDAS@MIT-MC, GZ@MIT-OZ, Moon@SCRC-TENEX +Subject: @BINPRT +In-reply-to: Msg of 20 Jun 1984 14:25-PDT from Alan Bawden + +I looked at the GETSAV module that does GET, and looks like it'll +work. Once it finds the entry-vector word (positive LH) it stops +reading and finishes up. A practical test via FILDDT showed it +works in practice, too! + +OK, so who's going to fix Midas? + +Date: 20 June 1984 17:25-EDT +From: Alan Bawden +Subject: @BINPRT +To: Ian @ SRI-NIC +cc: BUG-MIDAS @ MIT-MC, GZ @ MIT-OZ, Moon @ SCRC-TENEX +In-reply-to: Msg of 20 Jun 1984 13:04 PDT (Wed) from Ian Macky + +OK, so somebody try an experiment. What happens if there is additional +words beyond the entry vector XWD at the end of the file? + +Date: 20 Jun 1984 13:04 PDT (Wed) +Message-ID: <[SRI-NIC].IAN.20-Jun-84 13:04:27> +From: Ian Macky +To: Gail Zacharias +Cc: bug-midas@MIT-MC, Moon%SCRC-TENEX@MIT-MC.ARPA +Subject: @BINPRT +In-reply-to: Msg of 20 Jun 1984 10:35-PDT from Gail Zacharias + +We could do it the same way as on ITS, have one of the SBLKs just be +an information block. Of course, it would have to be flagged as such +and the GET call would have to know not to try and load it. + +Or, I suppose, it *could* be data and let it be loaded, but at some +fixed offset, that you would look for as the key, to know this was the +description block. + +From the JSYS manual: + + The format of a nonsharable save file is as follows: + + IOWD length, address at which to put "length" data words + + "length" data words + + IOWD length, address at which to put "length" data words + + "length" data words + + . + + . + + . + + XWD length of entry vector, pointer to first word of + entry vector + + +And that's all there is to it. + +Date: Wed, 20 Jun 1984 13:35 EDT +Message-ID: +From: Gail Zacharias +To: bug-midas@MIT-MC, Moon%SCRC-TENEX@MIT-MC.ARPA +Subject: @BINPRT +In-reply-to: Msg of 20 Jun 1984 04:36-EDT from David A. Moon + + Date: Wednesday, 20 June 1984, 04:36-EDT + From: David A. Moon + ... + I wish I knew how to do :BINPRT on Twenex. + +I've often wished this too. I believe Midas doesn't put the necessary +info in .EXE files. Is it because there is no place to put it or because +nobody has bothered? How hard would it be at least put the source filename +(and site) somewhere? + +Received: from MIT-MC by MIT-OZ via Chaosnet; 20 Jan 84 15:23-EST +Date: 20 Jan 1984 12:18 PST (Fri) +Message-ID: <[SRI-NIC].IAN.20-Jan-84 12:18:11> +From: Ian Macky +To: E Gordon Strong +Cc: bug-midas@MIT-OZ +Subject: a question +In-reply-to: Msg of 20 Jan 1984 12:01-PST from E Gordon Strong + +Yes, there is a .BYTE psuedo. You can do something like + + .BYTE 8. ? byte ? byte ? byte ? .BYTE + +which will pack "byte"s into 8.-bit chaos-style bytes; you can also do +like + + .BYTE x,y,z ? byte1 ? byte2 ? byte3 ? .BYTE + +which packs byte1 into an x-bit byte, then byte2 into a y-bit byte, +etc. All this stuff is documented in the MIDAS INFO node; there is +a leaf on pseudos. + +For version numbers, you can also just use the MACROS.MID file on OZ +(and probably on EE also), which has VERSION defined (as:) + +Define VERSION who,maj,min,edit + Field(who,<700000,,0>)+Field(maj,<77700,,0>)+Field(min,<77,,0>)+edit +Termin + +Hmm, actually, that would probably be better as a .BYTE construct... + +Received: from MIT-EECS by MIT-OZ via Chaosnet; 20 Jan 84 15:02-EST +Date: 20 Jan 1984 1501-EST +From: E Gordon Strong +Subject: a question +To: bug-midas at MIT-OZ + +Is there a MIDAS pseudo-op analogous to BYTE in MACRO? +Since the "correct" way to code Tops-20 programs is to +use entry vectors, I wish to store the version information +in the third word, as is done in several macro programs. +I really dislike the macro assembler, but would like to use +this feature in my midas programs. I would rather not construct +the version information by hand. + +Thanks, + +Gordon +------- + +Date: 24 November 1983 05:42 EST +From: Ken Harrenstien +Subject: midas libraries +To: GZ @ MIT-MC +cc: BUG-MIDAS @ MIT-MC + + GZ@MIT-MC 11/15/83 13:54:36 Re: midas libraries + I have this library on OZ, LIB:MACSYM.MID which translates many of the + macros in MACSYM.MAC. I like to use it in programs I write, but with OZ + being off the net, it's hard for me to tell people how to get hold of this + library. Is there some place I could put it, like MIDAS; or something, + so it goes out with Midas? It seems at least as general/useful as + MIDAS;XJSYS ... + +Putting it in MC:MIDAS; is reasonable. I can include a pointer to it +in the comments which describe how to install MIDAS on TOPS-20. +If you do so, however, I would recommend that the MC version be considered +the "canonical" version, so any changes made on OZ would have to be +copied over quickly. That sound OK? + +Date: Mon 17 Oct 83 16:58:16-PDT +From: Ken Harrenstien +Subject: .SCALAR bug +To: "gz@oz"@MIT-MC +cc: bug-midas@MIT-MC + +That appears to be a real bug. The code for .SCALAR/.VECTOR shares +a lot of code with .GLOBAL and consequently is not looking up the +symbol properly. I don't know if I understand it well enough to +fix it, but in the meantime, you can win if you use the old +single-quote construct such as inqpag'. +------- + +Date: Mon, 17 Oct 1983 07:07 EDT +Message-ID: <[MIT-OZ].GZ.17-Oct-83 07:07:22> +From: Gail Zacharias +Subject: block structure +To: bug-midas@MIT-MC.ARPA + +The following gets a "multiply defined" error: + + inqpag==100 + + .begin hakinq + .scalar inqpag + .end hakinq + +Mail-From: KLH created at 4-Oct-83 13:49:28 +Date: Tue 4 Oct 83 13:49:27-PDT +From: Ken Harrenstien +Subject: Re: Midas improvements. +To: G.EGK@SU-SCORE, info-midas@MIT-MC +cc: KLH@SRI-NIC +In-Reply-To: Message from "Edjik " of Sun 2 Oct 83 17:15:13-PDT +ReSent-date: Thu 13 Oct 83 00:21:40-PDT +ReSent-from: Ken Harrenstien +ReSent-to: info-midas@MIT-MC + +MIDAS does have this ability (FOO=BAR"), however it (and many other +such features) exist only for the ITS STINK relocatable format, rather +than the LINK format. I am looking at what would be required to +provide functionality similar to STINK, but this is somewhat difficult as +there are a bunch of things that STINK format allows, which LINK doesn't, +so it requires really understanding what is going on in order to let only +the LINK-allowable things happen. The person who did .DECREL originally +took the easy way out by requiring things to be assembled more or less +pseudo-absolutely. I haven't given up, but it's tough going as very +little of the STINK format is documented. Fortunately a lot of it is +extremely similar to LINK, and they are doubtless related far back in +the dim past. +------- + +Date: 12 Oct 1983 10:33 EDT (Wed) +Message-ID: <[MIT-OZ].IAN.12-Oct-83 10:33:21> +From: Ian Macky +To: Bug-MIDAS@MIT-MC.ARPA +CC: GZ%MIT-OZ@MIT-ML.ARPA, RWK%MIT-OZ@MIT-ML.ARPA + +The following will die horribly: + +IRP ac,,[T,TT,A,B] + IFNDEF ac,.FATAL ac is not defined + IFLE ac-4,.FATAL ac must be not 1-4 +TERMIN + +giving "TERMIN longer than 6 chars" (and a long string of other +nasty message, eventually killing it), because of the "DEFINE". + +If I change it to + +IRP ac,,[T,TT,A,B] + IFNDEF ac,.FATAL ac is undefined + IFLE ac-4,.FATAL ac must be not 1-4 +TERMIN + +then it works. + +Date: 11 Oct 1983 15:47 EDT (Tue) +Message-ID: <[MIT-OZ].IAN.11-Oct-83 15:47:16> +From: Ian Macky +To: Ken Harrenstien +Cc: BUG-MIDAS@MIT-MC.ARPA +Subject: IF1,[ .INSRT foo ] +In-reply-to: Msg of 11 Oct 1983 15:19-EDT from Ken Harrenstien + +Nope, no storage is defined... it's just macros. The file is +[OZ]LIB:MACROS.MID if you want to look. + +Date: 11 October 1983 15:19 EDT +From: Ken Harrenstien +Subject: IF1,[ .INSRT foo ] +To: Ian @ MIT-OZ +cc: BUG-MIDAS @ MIT-MC + +I bet you will find that the .INSRT'd file is defining sme storage words. +Either re-insert it on pass2, or find the code in it which is +(presumably unexpectedly) screwing you. + +Date: 11 Oct 1983 02:05 EDT (Tue) +Message-ID: <[MIT-OZ].IAN.11-Oct-83 02:05:31> +From: Ian Macky +To: Ken Harrenstien +Cc: BUG-MIDAS@MIT-MC.ARPA +Subject: IF1,[ .INSRT foo ] + +Well, actually, what I was doing was + +IF1,[ + +.INSRT file + +DEFINE ... +TERMIN + +DEFINE ... +TERMIN + +];End IF1 + +There was just no way I could make it work... what happens is this: + +[PHOTO: Recording initiated Tue 11-Oct-83 2:00AM] + + TOPS-20 Command Processor 5(742)-2 + [Commands] +!h: +!midas tfinger +@FINGER +@FINGER +CHNTAB+3 212 0. 3-028 OUTJFN Multiply defined +CHNTAB+4 213 0. 3-029 HSTJFN Multiply defined +CHNTAB+5 214 0. 3-030 PLNJFN Multiply defined +CHNTAB+6 215 0. 3-031 MAIJFN Multiply defined +CHNTAB+7 216 0. 3-032 CHAJFN Multiply defined +CHNTAB+10 217 0. 3-033 TTLJFN Multiply defined +CHNTAB+11 220 0. 3-034 PURJFN Multiply defined +CHNTAB+12 221 0. 3-035 LLOJFN Multiply defined +CHNTAB+13 222 0. 3-036 LMJFNS Multiply defined +CHNTAB+25 234 0. 3-038 NOW Multiply defined +CHNTAB+26 235 0. 3-039 ELAPSE Multiply defined +CHNTAB+27 236 0. 3-040 RUNT Multiply defined +CHNTA^C +! + +and from there on everything defined with a : get's Multiply-defined +errors. + +Date: 10 October 1983 16:38 EDT +From: Ken Harrenstien +Subject: IF1,[ .INSRT foo ] +To: IAN @ MIT-OZ +cc: BUG-MIDAS @ MIT-MC + +I recommend using: + IF1, .INSRT FOO +or if you like brackets: + IF1,[ + .INSRT FOO + ] +I haven't tried the following but it may also work: + IF1,[ .INSRT FOO ;] + +The problem is that the .INSRT filename reader gobbles the whole line +except for comments. At best you will get a filename parsing error, +or a message about unbalanced brackets starting at the IF1. +Conditionals are not like macros, they do not first gobble their +arguments and then do something with them. They just set flags and +dispatch to the appropriate stuff (regular assembly if successful, +flush-conditional-text if unsuccessful). + +Date: Mon 10 Oct 83 09:44-EDT +From: Ian Macky +Subject: IF1,[ .INSRT foo ] +To: BUG-MIDAS@MIT-OZ + +Is there something wrong with doing that? I tried to put an IF1 +around an .INSRT of a macro library and it died... putting the +IF1 in the macro file itself died the same way (I can send details +if you don't know the symptoms) + +Date: Sun 2 Oct 83 00:25:46-PDT +From: Edjik +Subject: Midas improvements. +To: info-midas@MIT-MC.ARPA + +One thing I've noticed MIDAS missing that MACRO has, is the ability to +have external symbols in equals (=). This is quite handy and makes +writing modules easier. Dunno how hard it would be to make MIDAS +generate the appropriate LINK record but it probably is worth it. + +--E+ +------- + +Date: Wed 28 Sep 83 18:12:33-PDT +From: Ken Harrenstien +Subject: Some questions +To: info-midas@MIT-MC +cc: klh@SRI-NIC + +I have a few questions about some things I found in the MIDAS BUGS +file. I seem to be in a mood to fix them, depending on the kind +of answers I get... + +1. .FAS or .FASL? + Some people claim that on TOPS-20, output files generated with +the .FASL pseudo-op should have the extension .FASL rather than .FAS. +Is this true? Is this also true for TENEX? + +2. TOPS-20 CCL? + This purportedly no longer works for V3+. Where do I find +out how it should work? Should compatibility with V2- be retained? + +3. MIDAS .INSRT library? + I would like to provide a system-independent way of allowing +programs to .INSRT commonly used files. For this purpose I am thinking +of adding a new pseudo called .INSLIB which would act exactly like +.INSRT with the difference that the device/directory names would default +to a place containing standard, public, or useful MIDAS .INSRT +packages. This place can be defined on a per-system basis. If it was +ever desired to change these defaults for a single assembly, this +could be done by giving an .INSLIB specification with an explicit +device/directory and no filename. Comments welcomed. + +4. Others? + If you have some ideas which have never been sent to +BUG-MIDAS, now is a good time, not because I plan to try doing +anything but because I am interested in seeing whether other people +have found undocumented bugs or have hidden wish lists. I have a +loooong list of MIDAS ideas as well as bugs, which will be available +in MIDAS;IDEAS > (plus MIDAS BUGS), for those who care to avoid +reiteration. The usual warning: very few such items ever +get implemented. +------- + +Date: 27 September 1983 13:44 EDT +From: Ken Harrenstien +Subject: Mailing list on OZ... +To: Ian @ MIT-OZ +cc: INFO-MIDAS @ MIT-MC + +Yes, merge it (you can just point to it if you want to keep an OZ-specific +group)... + +Latest version of MIDAS (not back on MC yet) fixes the various +problems with building new MIDASes. I am currently +scanning MIDAS BUGS (archive of bug-midas mail) to see if there +are any interesting things that are easy to add before installing +it. + +Date: 27 Sep 1983 03:29 EDT (Tue) +Message-ID: <[MIT-OZ].IAN.27-Sep-83 03:29:17> +From: Ian Macky +To: Info-MIDAS@MIT-OZ +Subject: Mailing list on OZ... + +There's this list here... maybe it should be merged? It's mostly to do +with 20-only stuff, usually OZ-only, like new packages and junk. + +MIDAS-USERS=Ian Jeh ZZZ Marty *SS:MIDAS.ARCHIVE Gumby egk GZ-OZ GS + +Date: 16 September 1983 01:29 EDT +From: Alan Bawden +Subject: Adventures assembling MIDAS +To: KLH @ MIT-MC +cc: BUG-MIDAS @ MIT-MC +In-reply-to: Msg of 15 Sep 1983 04:20 EDT from Ken Harrenstien + +Since you mentioned INFO-MIDAS, and since there was no such mailing list on +MC, I hunted it down in the old AI:.MAIL.;NAMES > file kept on MC:KSC; and +created it on MC. (Yes, I did check to see that it wasn't on OZ first.) +Info-MIDAS used to be archived in AI:MIDAS;INFO MINS, a file we no longer +have. + +Date: 15 September 1983 04:20 EDT +From: Ken Harrenstien +Subject: Adventures assembling MIDAS +To: MARTY @ MIT-OZ +cc: BUG-MIDAS @ MIT-MC, ALAN @ MIT-MC, Moon @ SCRC-TENEX + +Yes, the proper method of putting together a T-20 MIDAS is not +well documented. I am now fixing that, as well as making the +purification code really work (all it is useful for on T20 +is catching bugs, however). When done the new version will +be available as usual from the canonical MC:MIDAS; location +and announced to info-midas. + +Date: 31 Aug 1983 21:48 EDT (Wed) +Message-ID: <[MIT-OZ].MARTY.31-Aug-83 21:48:44> +From: Martin David Connor +To: Bug-Midas@MIT-MC +Cc: Alan@MIT-MC, Moon@SCRC-TENEX +Subject: Adventures assembling MIDAS + + +A funny thing happened on my way to fixing a file server... + +First I consed up a TWXBTS file from UNV:MONSYM.MAC +following the instructions in SS:TWXBTS.CONSING. +Then I tried to compile, with the CVTSW off. + + [PHOTO: Recording initiated Wed 31-Aug-83 9:16PM] + + TOPS-20 Command Processor 5(742)-2 + [COMAND] + !i j + Job 15, User MARTY, SS:, Account AI, TTY1 + !midas midas /t + MIDAS + TTY: .INSRTed, end input with ^Z + CVTSW==0 + TNXSW==1 + ^Z + SS:TWXBTS.MID.10 + 1 0. 6-054 + Comma past the 3rd field of a word + 1 0. 6-054 Undefined format + 2 0. 6-056 + Comma past the 3rd field of a word + + .... + + 2 0. 6-056 Undefined format + 3 0. 6-081 + Comma past the 3rd field of a word + 3 0. 6-081 Undefined format + 4 0. 6-083 + + .... + + SS:TSRTNS.MID.194 + 422644 0. 54-032 DEFSTR Non-macro made macro + in DEFINE Starting at 54-025 + Pure pages = 14 + ST = 13271 + SS:TWXBTS.MID.10 + EISYM1+1725 101255 1. 6-056 + Garbage in ASCIZ-style macro arg + in DEFSTR Starting at 6-054 + EISYM1+1726 101256 1. 6-056 %%FNLC Undefined in LOC + 101256 0. 6-056 Stray ) + 101256 0. 6-056 Undefined format + 101325 1. 6-083 + + ..... + + Garbage in ASCIZ-style macro arg + in DEFSTR Starting at 6-081 + 101326 0. 6-083 Stray ) + 101326 0. 6-083 Undefined format + 101331 1. 6-090 + Garbage in ASCIZ-style macro arg + ..... + + ^C + !;sigh. + !pop + + [PHOTO: Recording terminated Wed 31-Aug-83 9:19PM] + +My, my, someone call a priest. + +Then I found the program CVT which I used to conse up a TNXDFS.MID +file: + + [PHOTO: Recording initiated Wed 31-Aug-83 9:20PM] + + TOPS-20 Command Processor 5(742)-2 + [COMAND] + !i j + Job 15, User MARTY, SS:, Account AI, TTY1 + !midas midas /t + MIDAS + TTY: .INSRTed, end input with ^Z + CVTSW==1 + TNXSW==1 + ^Z + Pure pages = 14 + ST = 13271 + 22206 words initialization coding. + MINPUR-MAXMAC = 7 + MIDAS + Constants area inclusive + From To + 423146 426002 + 76453 76532 + Run time = 1:07.57 + 7094 Symbols including initial ones (70% used) + +Well, it assembles, let's try purifying it. + + !v midas + SS: + MIDAS.CONSING.1;P777752 1 1173(7) 31-Aug-83 20:20:37 MARTY + .DIF.1;P777752 1 2284(7) 31-Aug-83 02:14:09 MARTY + .EXE.1;P777752 68 34699(36) 31-Aug-83 21:20:28 MARTY + .MID.433;P777752 127 64841(36) 5-Apr-83 18:16:05 IAN + .435;P777752 127 324202(7) 31-Aug-83 02:20:18 MARTY + + Total of 324 pages in 5 files + + !get midas.exe.1 + !start purify + ?Illegal instruction 256006,,0 at 417757 + ?Invalid access requested + +Can't fool me, just barfed trying to do a SPACS call on a page that +wasn't yours. + + !continue + Purified, now SAVE + +Yes sir! + + !save midas + MIDAS.EXE.2 Saved + !v midas.exe + + SS: + MIDAS.EXE.1;P777752 68 34699(36) 31-Aug-83 21:20:28 MARTY + .2;P777752 47 24064(36) 31-Aug-83 21:27:14 MARTY + + Total of 115 pages in 2 files + !get midas.exe.2 + !i mem + + 46. pages, Entry vector loc 420074 len 254000 + + Section 0 R, W, E, Private + 0-3 MIDAS.EXE.2 1-4 R, CW, E + 76-120 MIDAS.EXE.2 5-27 R, CW, E + 400-426 MIDAS.EXE.2 30-56 R, E + + !;looks good, but will it assemble? + + !midas ss:file + FILE JOB FOR TOPS-20 + (OZ's munched on version) + NETWRK.MID included in this assembly. + FILE JOB FOR TOPS-20 + (OZ's munched on version) + NETWRK.MID included in this assembly. + END OF IMPURE=2770 + START OF PURE=3000 + END OF PURE=15570 + FIRST BUFFER LOC=22000 + Constants area inclusive + From To + 13740 15567 + Run time = 9.74 + 5639 Symbols including initial ones (71% used) + !;works fine. + !pop + + [PHOTO: Recording terminated Wed 31-Aug-83 9:29PM] + +Now, I said all that to say that for my money MACCNV (or the +instructions on how to use it) are broken, because the TWXBTS file that +it generates is not assemblable. + +Perhaps someone would like to look into this. CVT seems to do fine. +Maybe there is no need. + + +Date: 31 Aug 1983 02:52 EDT (Wed) +Message-ID: <[MIT-OZ].MARTY.31-Aug-83 02:52:18> +From: Martin David Connor +To: David A. Moon +Cc: bug-file@MIT-OZ, BUG-LISPM@MIT-OZ, bug-midas@MIT-OZ, + Ken Haase , bug-system@MIT-OZ +Subject: Options needed on file write. +In-reply-to: Msg of 30 Aug 1983 15:09-EDT from David A. Moon + + Date: Tuesday, 30 August 1983, 15:09-EDT + From: David A. Moon + To: Ken Haase + cc: BUG-LISPM, bug-file, bug-midas + Re: Options needed on file write. + Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS; + Tue 30-Aug-83 15:15:01-EDT + + Date: Tuesday, 30 August 1983, 14:38-EDT + From: Ken Haase + In Release 4.4, Experimental LMRLL 11.0, FEP 12, + site configuration 58, on Lisp Machine Janis Joplin: + + This should offer to run DIRED or CLEAN Directory. + + >>Error: File system bug on host MIT-OZ: + Disk structure completely full (at 6021 inside FILE server) + For OZ:PS:RLL.LISP + + It would have if the Lisp machine had known that this error meant + "disk structure completely full". As you can see, it says "File + system bug." I've reported this at least once before: the bug is + that MIDAS is broken on OZ; it assembles the wrong system error + codes into the FILE server. I don't remember now the exact error + code that is wrong (or, more likely, undefined). Someone at OZ + should fix MIDAS and reassemble SS:FILE.MID and start + the resulting binary at PURIFY, which will dump it into + SYSTEM:CHAOS.FILE. + +Fixed. The file server should now know all about IOX34 (Disk structure +completely full). + +Fixing MIDAS was a pain. + +The TWXBTS file on OZ seems to be missing some things. I ended up +getting the TNXBTS file from XX, and SRCCOMing XX's version of MIDAS +with OZ's. What we have now is a MIDAS that is basically a TENEX +version, but it seems to have everything defined properly. + +Also, starting MIDAS PURIFY barfs it when it tries to set the page +access of a the core image (did I say CORE), but if CONTINUED it seems +to win. There is a pure version now on PS:. + +If anybody *really* knows how to assemble a TOPS-20 version of MIDAS +that uses TWXBTS, please spill your guts. MACCNV sort of works, but +what it produced would not compile properly. + + +Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS; Tue 30-Aug-83 15:15:01-EDT +Date: Tuesday, 30 August 1983, 15:09-EDT +From: David A. Moon +Subject: Options needed on file write. +To: Ken Haase +Cc: BUG-LISPM@MIT-OZ, bug-file@MIT-OZ, bug-midas@MIT-OZ +In-reply-to: The message of 30 Aug 83 14:38-EDT from Ken Haase + + Date: Tuesday, 30 August 1983, 14:38-EDT + From: Ken Haase + In Release 4.4, Experimental LMRLL 11.0, FEP 12, site configuration 58, on Lisp Machine Janis Joplin: + + This should offer to run DIRED or CLEAN Directory. + + >>Error: File system bug on host MIT-OZ: + Disk structure completely full (at 6021 inside FILE server) + For OZ:PS:RLL.LISP + +It would have if the Lisp machine had known that this error meant "disk structure +completely full". As you can see, it says "File system bug." I've reported this +at least once before: the bug is that MIDAS is broken on OZ; it assembles the +wrong system error codes into the FILE server. I don't remember now the exact +error code that is wrong (or, more likely, undefined). Someone at OZ should +fix MIDAS and reassemble SS:FILE.MID and start the resulting binary +at PURIFY, which will dump it into SYSTEM:CHAOS.FILE. + +Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 31-Jul-83 21:03:14-EDT +Date: Sunday, 31 July 1983, 21:01-EDT +From: David A. Moon +Subject: Re: disk full error should give space-making proceed options +To: bug-midas@MIT-OZ +Cc: JTW@MIT-MC, Zvona@MIT-OZ, bug-twenex@MIT-OZ, BUG-LISPM@MIT-OZ, + bug-file@MIT-OZ +In-reply-to: The message of 31 Jul 83 19:44-EDT from David A. Moon + +IOX34 and IOX35 are undefined in Midas on OZ. Hence the FILE server +installed there is misassembled. + +Date: 2 June 1983 15:35 EDT +From: Ken Harrenstien +To: BUG-MIDAS @ MIT-MC + +Just testing, ignore this message. + +Date: 26 May 1983 17:55 EDT +From: Ken Harrenstien +Subject: Building a new MIDAS for 20X +To: IAN @ MIT-OZ +cc: BUG-MIDAS @ MIT-MC + + Date: Thursday, May 26, 1983 3:27PM-EDT + From: Ian Macky + + After I've assembled one up, do I need to purify it? PURIFY$G and it + bombs out on a SPACS with illegal access requested. Anyone know what's + going on? More details on request... + +No, don't bother purifying it. That stuff was for debugging but never +really got debugged. + +Date: Thursday, May 26, 1983 3:27PM-EDT +From: Ian Macky +Subject: Building a new MIDAS for 20X +To: Bug-MIDAS at MIT-OZ + +After I've assembled one up, do I need to purify it? PURIFY$G and it +bombs out on a SPACS with illegal access requested. Anyone know what's +going on? More details on request... + +Date: Mon 2 May 83 15:38:33-PDT +From: Mark Crispin +Subject: non-zero sections +To: Ian%MIT-OZ@MIT-MC.ARPA, Marty%MIT-OZ@MIT-MC.ARPA, + Bug-MIDAS%MIT-OZ@MIT-MC.ARPA, NCP.EGK@GSB-HOW +Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 +Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) + + There is absolutely no way to get MIDAS to do a DECSAV with a +non-zero section, just as there is no way to get PSECTs out of MIDAS. +Your best bet is to do it the release-4 way; that is, have your code +all boot in section 0, then SMAP% itself up into section 1. This isn't +too bad since very few programs require more than 256K for code; it's +generally data structures that get so big. + + MIDAS was a real nice assembler. Too bad it's fallen so far behind +the times. We've abandoned FAIL for much the same reasons0. +------- + +Date: 2 May 1983 15:21 EDT (Mon) +From: Ian Macky +To: Bug-Midas@MIT-OZ +Subject: [NCP.EGK: How Does one ...] + +Date: Mon 2 May 83 10:34:29-PDT +From: Edjik +To: Ian%oz%MC at SCORE, Marty%OZ%MC at SCORE +Re: How Does one ... +Received: from GSB-HOW by SCORE with Pup; Mon 2 May 83 10:35:03-PDT + +Get midas to do a DECSAV with a non zero section? + +Date: 6 Apr 1983 16:30 EST (Wed) +From: Ian Macky +To: Ken Harrenstien +Cc: BUG-MIDAS@MIT-MC +Subject: MIDAS 433 +In-reply-to: Msg of 6 Apr 1983 16:16 EST from Ken Harrenstien + +MACCNV is a Teco library that does MONSYM->TWXBTS in the current +buffer (and fails trying); Hmm, creation day of the original was +in '80 sometime, last mod by MT. Hmmpf. + +;UNGETting the current system Midas after the patch results in one +that's 4 pages longer; it works, tho. I'll try it on that WATSON +program once I rearrange it again and let you know. + +Date: Wed 6 Apr 83 13:43:55-PST +From: Mark Crispin +Subject: Re: MIDAS 433 +To: KLH@MIT-MC.ARPA +cc: Ian@MIT-OZ.ARPA, BUG-MIDAS@MIT-MC.ARPA +Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 +Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) +In-Reply-To: Your message of Wed 6 Apr 83 16:16:00-PST + +I officially provided CVT to MIT years ago. The dispute which +prevented its redistribution was resolved to everybody's satisfaction. +If you can't find it, grab MRC:CVT.MID. CVT reads in the +SYS:MONSYM.UNV and SYS:MACSYM.UNV files and makes a TNXDFS from it. +This reads the UNVs, not the sources. +------- + +Date: 6 April 1983 16:16 EST +From: Ken Harrenstien +Subject: MIDAS 433 +To: Ian @ MIT-OZ +cc: BUG-MIDAS @ MIT-MC + +What is MACCNV? Is it a frob to gobble MONSYM and output TWXBTS? +MRC had such a program, but didn't want it re-distributed; is this the +same one? + +Don't bother explicitly purifying MIDAS on 20X, the TNX purify stuff +was basically for debugging. Just patch it and dump it back with +;Unget. + +Date: 5 Apr 1983 18:52 EST (Tue) +From: Ian Macky +To: Ken Harrenstien +Cc: BUG-MIDAS@MIT-MC +Subject: MIDAS 433 +In-reply-to: Msg of 5 Apr 1983 16:26 EST from Ken Harrenstien + +Sigh. I grabbed the latest source from AI, and the TXWBTS and TNXDFS +files needed to assemble it, but I can't get MACCNV to do anything +reasonable with out MONSYM... the warning says to remove the INFDEF +FOR,< ... >'s, which I do, but then it dies (Search failed) along the +way... it dies if you leave them in, too. Anyone know how to make +this work? I can't patch the .EXE we have since FILDDT doesn't +believe it's a real .EXE file, and if I ;Yank it into an NDDT and then +;Unyank it out, and then try and purify it, MIDAS dies in an SPACS +trying to set access to a non-existant page... this is pretty grim. + +Date: 5 April 1983 16:26 EST +From: Ken Harrenstien +Subject: MIDAS 433 +To: IAN @ MIT-MC +cc: BUG-MIDAS @ MIT-MC + +I think I fixed your problem. You can either gobble MIDAS 433 from AI, +or patch MINUS+3 to a JFCL. This shouldn't break anything that +previously worked, but stay alert just in case. +New MIDAS installed on *ITS:SYS;TS MIDAS. + +Date: 5 April 1983 13:43 EST +From: Christopher C. Stacy +To: BUG-MIDAS @ MIT-MC + +Test + +Date: 5 April 1983 13:38 EST +From: Ken Harrenstien +Subject: WATSON bug +To: IAN @ MIT-MC +cc: BUG-MIDAS @ MIT-MC + +Well after all that, how could I not look at the bug? You seem +to have made a pragmatic fix in WATSON already, but I was able to +write a small test program that tickled it. It's about what +I expected; MIDAS is being confused by seeing both [a,,b] +and [-a,,b] where a and b are not yet defined, and is doing +constants optimization which tries to produce only one unique +constantt whenever possible. On pass 2 it discovers its +mistake and complains with a straight face. + +The fix for now is to define those symbols ahead of the constants +reference. It is a real MIDAS bug, though. Will see if I can +grovel over the optimization code. + + +Date: Tue, 5 Apr 1983 04:45 EST +From: Leigh L. Klotz +To: Edjik +Cc: BUG-ITS@MIT-MC, BUG-MIDAS%OZ@MIT-MC, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC, + KLH@MIT-MC +Subject: Gross OZ lossage +In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik + +KLH knows more about midas than most people, including you. Please keep +your nitbrained views to yourself. + + +Date: Tue, 5 Apr 1983 03:26 EST +From: PGS@MIT-OZ +To: Edjik +Cc: BUG-MIDAS@MIT-MC, KLH@MIT-MC +Subject: Gross OZ lossage +In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik + + Date: Mon 4 Apr 83 11:41:35-PST + From: Edjik + + Gosh, I wonder just how many people on the 6 mailing lists that KLH + shotgunned his msg to really give a ff about where the MIDAS sources + live. Probably damn few. Oz is the successor to AI. Moving mailing + lists and sources of system programs to it from AI seems natural to me. + Since KLH got the msg Ian sent, he still is on the new offical list at + oz, so why gripe? His talk of "sacrilege" conjures up images of the + inquisition. Is KLH the defender of the ITS faith? Probably KLH's main + gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20 + site to look at the sources. If he uses it for TOPS-20 and 10X + software, why does he need it on ITS? + + I hope the people in charge of the MIDAS mailing list and sources + do the appropriate thing in response to KLH's flame, ie. ignore it. + + -- Edjik + +KLH is the only person who maintains MIDAS these days. Thus it is good to +keep the sources in a place where he finds it convenient to access them. If +he wanted to keep them in his back pocket it would be fine by me and most +people here, so long as the rest of the world could get at them there. It +seems to me completely bizarre and unpleasant of you to send a message like +this about something you have nothing to do with. + + +Date: 5 April 1983 01:43 EST +From: Alan Bawden +Subject: Gross OZ lossage +To: MARTY @ MIT-OZ +cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, DCP @ MIT-MC, + KLH @ MIT-MC +In-reply-to: Msg of 4 Apr 1983 23:19 EST (Mon) from Martin David Connor + +What is all this flaming horseshit in my mailbox?!?! Is there anyone who +will argue that it was correct that there were TWO BUG-MIDAS mailing lists? +No. Have we fixed that? Yes. (Thank you Ian.) + +Now is there somebody out there who can actually claim to be maintaining +MIDAS to a greater extent than KLH? If so, then lets hear from them. If +not, then everyone shut the hell up. + + +Date: 5 April 1983 00:57 EST +From: David C. Plummer +Subject: Gross 8 inch spikes in various people's heads +To: MARTY @ MIT-OZ +cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, KLH @ MIT-MC, + BUG-MIDAS @ MIT-OZ + +And you, Mr. Conner, have as much to learn as I. + +Reactionary is not bullshit. Go read a history book someday and +notice how progress is often achieved by reactionaries and their +ideas. + +As for the local history of OZ, there were several people willing +(and eager) to help in creating another ITS. Moon was willing to +hack microcode and oversee changes needed to the system (e.g., +for disk support) which I was willing to help with. As I recall, +you were against the idea of ITS on OZ. Several other people +attended the Wars of Futility where it was decided to run 20X. +These people warned about all the features that 20X was lacking +and many of the problems it had. But the wars were futile; the +decision was out of our hands. + +So now our only recourse is to sit back and be little brats about +the whole thing. "Nah, nah, I told you so..." I, for one, am +proud to be one of these brats. + + For god's sake bring up a machine because it is the Right Thing, not + because you hate another machine so much. +Wrong. Both are often true. In fact, this is how TWENEX was +developed. The history told to me was that BBN disliked Bots-10 so +much they went off and wrote TENEX. DEC started seeing the light +and bought it from them and made it work on a 20. + Learn from the mistakes of + another attempt, ... +If TWENEX only could. + + Plummer, ... until you learn to work FOR A GOAL instead of + AGAINST AN ALTERNATIVE you will be counterproductive to the + causes you Support. +Goal: Help build better Lisp Machines. I think I am working for +this goal. Goal: help MIT when I have the time. I think I do a +fair job here. Goal: convince people they lost completely when +they decided to run TWENEX on OZ. Perhaps this is a subconsious +goal. How actively I work toward it is not clear. I would hope +to think I keep such discussions among (ITS) friends except when +something blatant happens. If you didn't blindly defend the +obvious problems, OZ would probably be a lot nicer. + + Penny, I already know I will regret sending this, because so many + minds are already closed, but I had to try. Forgive me. +Mine is closed just enough so that spikes cannot penetrate. I +know who does the real TWENEX development at MIT, and they have +often responded to the requests of others for (ITS-like) +features. I hope they also understand the spirit in which I +write these flames. + +Marty, you earned your second spike. + + +Received: from GSB-HOW with Pup; Mon 4 Apr 83 11:42:17-PST +Date: Mon 4 Apr 83 11:41:35-PST +From: Edjik +Subject: Re: Gross OZ lossage +To: KLH@MIT-MC +cc: BUG-OZ@MIT-MC, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC, BUG-MIDAS%OZ@MIT-MC +In-Reply-To: Your message of Mon 4 Apr 83 13:53:00-PST + +Gosh, I wonder just how many people on the 6 mailing lists that KLH +shotgunned his msg to really give a ff about where the MIDAS sources +live. Probably damn few. Oz is the successor to AI. Moving mailing +lists and sources of system programs to it from AI seems natural to me. +Since KLH got the msg Ian sent, he still is on the new offical list at +oz, so why gripe? His talk of "sacrilege" conjures up images of the +inquisition. Is KLH the defender of the ITS faith? Probably KLH's main +gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20 +site to look at the sources. If he uses it for TOPS-20 and 10X +software, why does he need it on ITS? + +I hope the people in charge of the MIDAS mailing list and sources +do the appropriate thing in response to KLH's flame, ie. ignore it. + +-- Edjik +------- + +Date: 4 Apr 1983 15:31 EST (Mon) +From: Ian Macky +To: Ken Harrenstien +Cc: BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, bug-mail@MIT-OZ, BUG-MIDAS@MIT-MC, + BUG-OZ@MIT-MC +Subject: Gross OZ lossage +In-reply-to: Msg of 4 Apr 1983 13:53 EST from Ken Harrenstien + +Hmm. Since you obviously have strong feelings about this, and since +that mailing list was screwed up by their being two parallel versions +(one on OZ and one on AI), I have done as you asked (insisted) and +merged the two and put the now official list on MC, with appropriate +pointers all around. + +Date: 4 April 1983 13:53 EST +From: Ken Harrenstien +Subject: Gross OZ lossage +To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC, + BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ + +I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ. +This implies that OZ has a BUG-MIDAS mailing list, and furthermore +that this list is NOT the same as the official list on AI. + +This reminds me of the BUG-ATSIGN lossage. + +I consider myself one of those people who now and then maintain MIDAS. +For the list to be moved without notice is reprehensible. For it to +not be on an ITS is sacrilege. I must insist that either AI or MC +be the official home of MIDAS sources and mailing lists. This +should probably apply to all ITS developed software. Since I was the +person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly +use it for 10X/20X software, you can hardly say my viewpoint is +wedged. + + +Date: 4 April 1983 13:53 EST +From: Ken Harrenstien +Subject: Gross OZ lossage +To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC, + BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ + +I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ. +This implies that OZ has a BUG-MIDAS mailing list, and furthermore +that this list is NOT the same as the official list on AI. + +This reminds me of the BUG-ATSIGN lossage. + +I consider myself one of those people who now and then maintain MIDAS. +For the list to be moved without notice is reprehensible. For it to +not be on an ITS is sacrilege. I must insist that either AI or MC +be the official home of MIDAS sources and mailing lists. This +should probably apply to all ITS developed software. Since I was the +person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly +use it for 10X/20X software, you can hardly say my viewpoint is +wedged. + + +Date: 4 Apr 1983 12:28 EST (Mon) +From: Ian Macky +To: Bug-Midas%MIT-OZ@MIT-MC + + +This table assembles fine as is: + +CmdTab: nCmnds,,nCmnds + [Asciz "All"],,[AHelp,,All] + [Asciz "Brief"],,[BHelp,,Brief] + [CM%INV ? Asciz "Display"],,[-SHelp,,Show] + [Asciz "Done"],,[DHelp,,Done] + [Asciz "Edit"],,[EHelp,,EditIt] +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + [CM%INV ? Asciz "Exit"],,[-SHelp,,Show] +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + [Asciz "Fast"],,[FsHelp,,Fast] + [Asciz "Help"],,[HHelp,,Help] + [Asciz "Kill"],,[KHelp,,Kill] + [Asciz "List"],,[LHelp,,Show] + [Asciz "New"],,[NHelp,,New] + [Asciz "Old"],,[OHelp,,Old] + [Asciz "Quit"],,[QHelp,,Quit] + [CM%INV ? Asciz "Show"],,[-SHelp,,Show] + [Asciz "Slow"],,[SHelp,,Slow] + [Asciz "Verbose"],,[VHelp,,Verby] + [Asciz "Zero"],,[ZHelp,,Zero] +nCmnds==.-CmdTab-1 + +and changing the bounded line to + + [CM%INV ? Asciz "Exit"],,foo + +where foo was defined previously as + +FOO: -DHelp,,Done + +works too, but if you do + + [CM%INV ? Asciz "Exit"],,[-DHelp,,Done] + +then I get a "More constants on pass 2 than pass 1" after the CONSTANTS +op at the bottom of the program. The program is [OZ]SUB:WATSON.MID + + +Date: 10 February 1983 06:39-EST (Thursday) +Sender: GUMBY @ MIT-OZ +From: David Vinayak Wallace +To: bug-midas @ MIT-OZ +Subject: .FASL + +Files assembled under twenex with the .FASL pseudo-op end up with +filetype FAS. this is OK for tenex, but no good for me. + + +Date: 5 Feb 1983 0116-EST +From: EGK at MIT-OZ at MIT-MC (Edjik) +Subject: MIDAS does NOT put JSYS Names in Symbol Table +To: Bug-Midas at MIT-OZ at MIT-MC + +This bug has been buggin' me for a long time. Since most of the people +I've spoken to privately seem to not think this is a bug, I'm sending +this to the "official" bug list. + +The bug: + MIDAS does NOT put JSYS Names in Symbol Table + +The Symptom: + + When DDTing a program written in MIDAS, Jsi appear as: + JSYS + + instead of: + PSOUT% or GTJFN% or etc. + +The Cure: + + Make Midas put the JSYS names in the programs symbol table. Note + saying, "Use NDDT" is not a fix. NDDT knows about jsys names. + DDT knows only about whats in the symbol table. Everyone + has DDT. Only a fortunate few have NDDT. DDT is supported + by DEC. NDDT is NOT. Not fixing Midas will only hasten + its death. Its too winning an assembler to castrate it by + not saveing JSYS names! + +Cheers, +-- Edjik +------- + + +Date: Tuesday, 21 December 1982 08:12-EST +Sender: KLOTZ at MIT-OZ +From: Leigh L. Klotz +To: Sam +cc: Bug-midas at MIT-OZ +Subject: ?NIB errors +In-reply-to: The message of 20 Dec 1982 23:19-EST () from Sam + +I just remembered that the problem with MTOPR was that MIDAS +in its current dump thinks that MTOPR is different from what +it is or something. I think it needs to be redumped with the +V5 symbols read in. + +Leigh. + + +Date: 15 Nov 1982 2041-EST +From: Sam Hsu +Subject: System defs +To: Bug-Midas at MIT-MC +cc: CLamb at BBNA, Tappan at BBNA + +is there a way in Midas to get the equivalent of Macro's +.SEARCH MONSYM,MACSYM and .REQUIRE MACREL? i'd like for it +to get the system symbols in monsym, and the macros from +macsym. is the way to do this .INSRT MONSYM.MID that was +generated using MACCNV or CVT.EXE? + +that sounds right - i could use the SYSTEM.MID package? +how about the MACSYM stuff? how can i get access to those +macros defined in there? + +any help would be appreciated. + +sam +------- + + +Date: 26 Oct 1982 0214-EDT +From: Michael Travers +Subject: Problem parsing twenex JCL +To: bug-midas at MIT-OZ at MIT-MC + +If you invoke midas by saying "r sys:midas" to the EXEC, it will interpret +the "sys:midas" as the file to assemble. +------- + + +Date: Tuesday, 3 August 1982 04:34-EDT +Sender: GREN at MIT-OZ +From: GREN at MIT-MC +To: BUG-MIDAS at MIT-MC +CC: RMS at MIT-MC +Subject: MIDAS bug + + +The main program: +------- +20X==1 + +IFN 20X,[ + +.INSRT ME:FOO + +];20X + +BEGIN: HALTF + + END BEGIN +------- +the file it inserts: +------- +IFNDEF $$SYMGET, $$SYMGET==0 + + .BEGIN DIEGO + +IFN $$SYMGET,[ +;[ +] ;END IFN $$SYMGET + + .END DIEGO +------- +and it loses horribly. + +Why? The open bracket in the conditionalized comment line is not seen as +a comment, but as a real open-bracket of some sort. If I change the line +from + +;[ + +to + +;[] + +then it wins. *SIGH* + + --gren (after a long night) +------- + +Date: 16 May 1982 04:19-EDT +From: Richard S. Hall +To: BUG-MIDAS at MIT-MC + +Is there a way to suppress the listing of false conditionals in Midas +assembly listings? I like to produce listing files to see if my macros +are expanding properly, but if all the failing conditionals are listed +it produces a cluttered and extremely large file. Surely there must be +some way around this but I have been unable to find any information on +this (or much else about listing control) in the on-line doc. + + Thanks, + Rick Hall + + + +dcp,alan@MIT-MC (Sent by DCP@MIT-MC) 03/19/82 00:45:04 Re: MIDAS outsmarting itself with undifined constants in literals +To: (BUG MIDAS) at MIT-MC + + title midas bug + + go: move 1,[foobar/2,,0] ;these are uniquized to + ;the same thing on pass one + move 1,[-foobar,,0] ;but on pass 2... + + constants + foobar: + + end go + +gives the following dialog: + + midas bug + midas bug + GO+4 104 0. 1-008 More constants on pass 2 than 1 + Constants area inclusive + From To + 102 102 + Run time = 0.13 + 1378 Symbols including initial ones (50% used) + + +Date: 2 March 1982 02:03-EST +From: Ken Harrenstien +Subject: literals in = +To: GZ at MIT-MC +cc: BUG-MIDAS at MIT-AI + +Sorry, that is how a two-pass assembler must work. It cannot +assign the address for [...bar...] until it knows where it is +going to put the literal, which isn't until later. Suggest +that you simply make a macro out of it, as in + define foo + [...bar...] termin + +Or give it a real location, as in + foo: ...bar... + +Depending on your tastes. MIDAS will merge all references +to literals of the same value, which is why the macro above is +still efficient. + +GZ@MIT-MC 02/09/82 04:22:26 Re: literals in = +To: (BUG MIDAS) at MIT-MC +Doing something like foo=[... bar ...] where bar is not defined until later, +gives an error (on pass 1 only of course) of "Undefined in =". This is +annoying, since it is obviously not an error (everything needed to define foo +is there on the first pass, and it does assemble correctly), and forces you to +start ignoring some error messages, a dangerous thing. + + +Date: 28 January 1982 14:14-EST +From: Stavros M. Macrakis +Subject: :info Midas +To: BUG-INFO at MIT-MC, BUG-MIDAS at MIT-MC + +Ideally, of course, the Midas info should be fully formattted for use in +Info. But as an interim step, it would be nice if section numbers in +headings were complete (e.g. B.3.b) so that string search will find +sections. + +Date: 18 Jan 1982 2130-PST +From: KLH at SRI-NIC +Subject: minor bug +To: bug-midas at MIT-AI + +TSRTNS 195 on SRI-NIC has the SKIPE T,CMPTR at CMD: changed +to SKIPLE T,CMPTR. This fixes a bug wherein 10X JCL was ignoring +switches (/T in particular). I will install on AI when there +is enough disk; just noting it here to avoid forgetfulness. +------- + +Date: 17 Jan 1982 1247-PST +From: KLH at SRI-NIC +Subject: Re: .SCALAR doesn't define labels +To: RMS at MIT-AI +cc: bug-midas at MIT-AI +In-Reply-To: Your message of 16-Jan-82 1313-PST + +The reason why a second declaration of .SCALAR FOO should be flagged +is the same as the reason why a second label definition should be +flagged; the hacker is probably doing something wrong. It used to +be that FOO' was a convenient way to assign a location for FOO, and +allowing several occurrences of FOO' meant you didn't have to remember +whether you'd already given one (the little ' is hard to spot). But +when using .SCALAR, I think most people (me for sure) think of +it as a better way of saying FOO: 0. It's "better" because it is +a convenient way of lumping all variables into an impure section, and is +a built-in pseudo-op so that you don't have to worry about .insrt'ing +this or that library. + The main thing is that I got screwed because I was working on a big +program and adding code here and there, "knowing" that if I goofed and +re-used a symbol for some variable, MIDAS would tell me. It didn't, and +it took me a while to figure out why I was losing and why something kept +getting smashed. + Either MIDAS should flag multiple .SCALARs, or the INFO doc should +have an explicit note about the way it behaves. If the doc had said +something, I might still think it was the wrong thing to do, but +I won't be so annoyed and I won't have sent a bug-midas message. +------- + +Date: 16 Jan 1982 0338-PST +From: KLH at SRI-NIC +Subject: .SCALAR doesn't define labels +To: bug-midas at MIT-AI + +Is it deliberate that .SCALAR and the equivalent ' +construct don't define symbols as labels, but rather +as some form of parameter assignment? The effect of +this is that saying .SCALAR FOO in one part of an +assembly, and .SCALAR FOO in a different part, will +give you NO error message, and who knows where the +references are going to point. + This seems counter-intuitive and this behavior, +as far as I can see, is not described in MIDAS INFO. +Is there some problem with defining those symbols in such +a way that a second occurrence in the SAME pass will +print a multiply-defined warning message? +------- + +KLH@MIT-AI 12/18/81 06:36:47 +To: DCP at MIT-MC +CC: (BUG MIDAS) at MIT-MC +I don't think the GAPFLS$G is ever necessary... + + + +DCP@MIT-MC 12/12/81 18:43:09 +To: (BUG MIDAS) at MIT-MC +CC: DCP at MIT-MC +Finally, + :rename ai:sys;ts omidas,ts oomidas + :rename ai:sys;ts midas ,ts omidas + :link ai:sys;ts midas ,ts omidas + :job midas + :load midas;ts mid430 + gapflsG + purifyG + :install ai:sys;ts midas + --DM was down-- I will do be hand later. + +I have not deleted any files, in case I did something wrong. (It +is hard to tell, since there aren't any directions.) + + +DCP@MIT-MC 12/12/81 04:05:00 Re: .value --> .lose +To: (BUG MIDAS) at MIT-MC +I changed the two .VALUEs in TSYMGT to .LOSE %LSSYS as +threatened. I tried to assemble it, but I now give up. +AI:MIDAS;MIDAS 430 is the version I created. MIDDIF 429430 is the +comparison, TS MID430 is the assembled version, and TS ERR is the +error file, which contains + MIDAS + Pure pages = 13 + ST = 12335 + 2076 words initialization coding. + 46000 0. 197-062 Pure too low. + MINPUR-MAXMAC = 777777777767 + MIDAS + 46000 0. 197-062 Pure too low. + Constants area inclusive + From To + 362162 364455 + 37075 37134 + Run time = 2:05.76 + 3635 Symbols including initial ones (36% used) + +I have now idea if that is a an OK response, and I'm not awake +enough to decide if it is or isn't. I'm not going to run it +either, for fear it will bash the current installed MIDAS when it +purifies itself, and I don't want to have to rename the current +good one and go through all that junk in case something does go +wrong. It would be nice if there were more documentation on how +to assemble the damn assembler. (Some of us haven't been around +for n years and therefore don't know all these things.) + + + +Date: 9 December 1981 16:34-EST +From: David C. Plummer +Subject: Shouldn't this .LOSE instead of .VALUE +To: BUG-MIDAS at MIT-AI + + +The following is from the MIDAS assembler: + + TSYMGT: MOVE AA,[MXICLR-MXIMAC,,MXICLR] + .CALL INITSB ;GET MACTAB PAGES NNOT LOADED INTO. + .VALUE + IFN PURESW,[ + MOVE AA,[MINBNK-MINMAC,,MINBNK] + .CALL INITSB ;GET PAGES FOR BLANK CODE & SYMTAB. + .VALUE + +INITSB is a CORBLK request. My question: Why, if the CORBLK fails, +does this .VALUE instead of .LOSE 1000? If CORBLK fails it is likely +due to system bloat, and it is probably restartable. .VALUE does not +let it restart, while a .LOSE does. If I hear no objections, I will +change this and install it in a couple days; so if there is a really +good reason why it should be .VALUE, please tell me now! + +DCP@MIT-MC 09/15/81 22:25:12 Re: HUH?? +To: (BUG MIDAS) at MIT-MC +The program + + title foobar + a=b + b=2 + end + +gives the error file + + foobar + 100 0. 1-002 B Undefined in = + foobar + Run time = 0.14 + 1347 Symbols including initial ones (49% used) + +The INFO documentation reads + + = + sets 's value to 's. + If there are undefined symbols in the + assignment is not performed. + This construct is illegal where a value is needed, + but if it is the last thing in a grouping it does + supply the value of the grouping. Thus, + FOO= is legal, though FOO=BAR=1 is not. + +Is this an error or a warning? (Notice the message is only for +pass 1; it seems to be happy on pass 2.) Is it a bug to print the +message on pass 1, or is it (in my opinion) a misfeature? The +word assembler (the one who will convert MOVE A,B into a PDP-10 +word) only complains on pass 2 that MOVE, A or B is undefined. +Why should this be different? + + +Date: 1 May 1981 03:33-EDT +From: Paul T. Friedl +To: BUG-MIDAS at MIT-AI + + Would it be possible for me to get a symbolic listing of a large MIDAS +program. I wish to use it as a model for my MIDAS programming. + Thanks... + Paul + +Date: 2 February 1981 02:32-PST (Monday) +From: WANCHO at DARCOM-KA +To: BUG-MIDAS at AI +Subject: MIDAS 428 +cc: WANCHO at DARCOM-KA + +Well, you can half-cancel my previous MIDAS bootstrap request. I +imported MIDAS.EXE.428 from XX and it seems to work. However, for +future reference, I would like to know how to generate a new MIDAS for +this TENEX machine. I now have the following: + +MACROS.MID;39 +SYSTEM.MID;13 (from XX - I used to have ;8) +TNXDFS.MID;6 +TSRTNS.MID;194 (from AI - had ;192) +TWXBTS.MID;12 (from AI - had ;3) +XJSYS.MID;5 + +I tried regenerating a new MIDAS using the MIDAS from XX and the +source from AI. All seemed to go well, except the generated version +was 64 disk pages instead of the 68 that the XX MIDAS has. Also, when +trying to generate a new CRTSTY using the generated MIDAS, .ICIFT, +.ICILI, and .ICPOV show up as Undefined. The MIDAS from XX doesn't +generate these Undefines. Why? What am I doing wrong, or better yet, +what should I do? If you tell me that there is no Tenex dependencies +and I can go ahead and use the versions found on XX, I will quietly go +away. + +Thanks, +Frank + +Date: 1 February 1981 22:13-PST (Sunday) +From: WANCHO at DARCOM-KA +Subject: MIDAS 428 +To: BUG-MIDAS at AI +cc: WANCHO at DARCOM-KA + +Some time ago I tried to compile the latest CRTSTY and it bombed. EAK +said that I would need the latest MIDAS (we have 416). So I brought +over MIDAS 428 from AI and it bombed with: + + 0 0. 1-003 .SYMTAB 1st arg too big +Error is fatal. + +Anybody have any idea how to boot up to 428? + +--Frank + +Date: 13 January 1981 19:25-EST +From: Earl A. Killian +Subject: [LARSON: midas] +To: Scott at SRI-KL +cc: BUG-MIDAS at MIT-AI + +Any ideas? Yes, use ATSIGN. + + +Date: 13 Jan 1981 1044-PST +From: Scott J. Kramer +Subject: [LARSON: midas] +To: Bug-MIDAS at MIT-AI + +It apparently doesn't like /C, am using the latest Twenex version here +(ie, same as on XX & EE). -sjk + --------------- +Date: 8 Jan 1981 2007-PST +From: LARSON +Subject: midas +To: Scott + + I cannot get it to make a cref listing for me. Here is what I +said to it: + midas + temp_teco/T/C + EMCSDV==1 + INFODV==1 + COMNDF==1 + ^Z + +Any ideas? + Alan +------- + --------------- +------- + +Date: 10 Dec 1980 1556-PST +From: Scott J. Kramer +Subject: Re: MIDAS bug found and fixed +To: EBM at MIT-XX, taa at MIT-XX, pdl at MIT-XX, clr at MIT-XX, + bug-twenex at MIT-XX, bug-midas at MIT-AI +In-Reply-To: Your message of 10-Dec-80 0953-PST + +In case anyone's interested, the fixed MIDAS is now installed as MIDAS +at EECS. -sjk +------- + +Date: 10 Dec 1980 1253-EST +From: EBM at MIT-XX +Subject: MIDAS bug found and fixed +To: taa at MIT-XX, pdl at MIT-XX, clr at MIT-XX, bug-twenex at MIT-XX, +To: bug-midas at MIT-AI + +MIDAS broke some time ago, when all the MONSYM symbols were added. +First, there were symbol table size problems, but JONL managed to get +around that. The symptom that had been tripping me up was that a +particular MONSYM symbol, .TICCA, was no longer defined. I have tracked +this down, and fixed it, and have installed the working MIDAS into +SUBSYS. The previous version is in SUBSYS, too, in case there are other +bugs that nobody has found yet. The problem was: + +In TWXBTS, some symbols (.ICxxx, the interrupt channels) were to be done +in decimal instead of octal; this continued through the .TICxx codes, +and a little bit later, the radix was again set to octal. It turns out +that setting the radix overall does not work for the second insertion of +initial symbols, because one line in the DEFSYM macro reads: + SQUOZE 10,Z +where Z is the symbol being defined. The radix change changes the 10 +from 8. to 10., and manages to destory the values of the symbols. By +some simple fixes to TWXBTS (by hand), I got around this difficulty. + +Suggestion: either MIDAS or the TECO macro that converts MONSYM.MAC into +TWXBTS.MID be changed to recognize this difficulty. I also noticed that +the TECO macro sometimes output ".RADIX10." instead of ".RADIX 10.", if +that tends to make any difference. + +------- + +Date: 17 NOV 1980 1459-EST +From: JONL at MIT-MC (Jon L White) +To: JIS at MIT-MC, SJK at MIT-MC +CC: (BUG MIDAS) at MIT-MC, CPR at MIT-MC, ebm at MIT-XX + +Elliot Moss and I just reassembled MIDAS on XX, and noted a few +rather simple differences (.TICCA being defined properly, for +instance). Not sure what was wrong with the previous assembly, +but I've moved the .EXE to EE, and Moss is going to put up a new +copy on SPEECH. + + +Date: 4 November 1980 19:49-EST +From: Earl A. Killian +Subject: Assembling TECO +To: JPERSHING at BBNA +cc: BUG-MIDAS at MIT-AI, DPACHURA at BBND + + Date: Tuesday, 4 November 1980 16:33-EST + From: John A. Pershing Jr. + To: Earl Killian + Re: Assembling TECO + + Is MIDAS system-dependent, or is it possible to FTP the .EXE file? + +MIDAS is so system-indepdendent that you can use the same .EXE +file on 10X, release 1, release 3, and release 4. + + Also, what would cause MIDAS to crap out due to symbol table full? Dave + Pachura is trying to boot EMACS up on the MIS machine, and can't seem to + assemble either TECO or MIDAS (same error for both). Is it perhaps + loading two copies of the JSYS table (e.g. the vanilla symbols and the + %-versions of the same)? They are running release 3 (vanilla DEC). + +A MIDAS .EXE file has all the appropriate system symbols built +into it at its own assembly time. Thus, if the MIDAS.EXE on BBND +assembles TECO, then the same .EXE should assemble TECO +elsewhere. I'm not sure what the problem is, then, unless that +MIDAS will no longer assemble TECO on BBND. Note that the MIDAS +on BBND has more system symbols than on XX (being generated from +MONSYM.UNV), so it is possible it assembles on XX and not on D. + + +JONL@MIT-MC 10/31/80 05:05:40 +To: (BUG MIDAS) at MIT-MC +On twenex versions, a command line like +FOO.EXE_FOO.MID +should cause the FOO.EXE version number to be the same as that of FOO.MID +or at the verrrrry least, there should be some way to specify this. + + +JONL@MIT-MC 10/24/80 12:34:35 +To: (BUG MIDAS) at MIT-MC + Date: 24 Oct 1980 0247-PDT + From: Mark Crispin + Subject: SYMDSZ in MIDAS + For the TNXSW version SYMDSZ should be set to 6003 not 4003. You + run out of symbols otherwise. +It actually has to be even higher; also increased the .SYMTA at +the beginning, when assembling for a Twenex system. New sources +now on XX< and just about to be on AI. + + +Date: 24 Oct 1980 0247-PDT +From: Mark Crispin +Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022 +Stanford-Phone: (415) 497-1407 +Subject: SYMDSZ in MIDAS +To: Bug-MIDAS at MIT-AI + +For the TNXSW version SYMDSZ should be set to 6003 not 4003. You +run out of symbols otherwise. +------- + +Date: 16 Sep 1980 1938-PDT +From: Scott J. Kramer +Subject: Re: .FASL op +To: KLH at MIT-AI +cc: BUG-MIDAS at MIT-AI +In-Reply-To: Your message of 16-Sep-80 1805-PDT + +Only every MacLisp autoload depends on it being ".FASL". I'll check +into the access problem, you should at least be in the right user +groups to get at any MIDAS code lying around. -sjk +------- + +Date: 16 September 1980 21:05-EDT +From: Ken Harrenstien +Subject: .FASL op +To: Scott at SRI-KL +cc: BUG-MIDAS at MIT-AI + + Date: 3 Sep 1980 0319-PDT + From: Scott J. Kramer + + Files produced on Twenex using this should have ".FASL" rather than ".FAS" + as their extension. Looks like a carryover from Tops-10/SAIL in its present + state. -sjk + ------- + +Why? What software depends on looking for .FASL instead of .FAS? All +the DEC software is certainly restricted to 3-letter extensions. + +In any case, I no longer have the necessary access to maintain MIDAS +on SRI-KL. Their (CR) attitudes really put a damper on any +enthusiasm I might have. + +Date: Tuesday, 9 September 1980 20:26-EDT +Sender: EMACS at BBND +From: Earl Killian +To: BUG-MIDAS at MIT-AI +Subject: error in PURIFY$G + +A little while ago I reported that PURIFYG loses executing the +SPACS JSYS. I found the problem, but don't have time to fix it +now. The problem is that the TNX routines double the page number +and no. of pages in order to convert from ITS-size pages. +However, when there are an odd number of TNX pages in the area +being operated on at PURID1, this loses because it will try to +hack the last non-existant page that it thinks it should be there +due to the doubling. + +Date: 3 September 1980 10:45-EDT +From: Earl A. Killian +Subject: decsav format files +To: JoSH at RUTGERS +cc: BUG-midas at MIT-AI + +MIDAS has never produced sharable files. I'm afraid you'll have +to go on doing GET/SAVE. + + +Date: 3 Sep 1980 0319-PDT +From: Scott J. Kramer +Subject: .FASL op +To: Bug-MIDAS at AI + +Files produced on Twenex using this should have ".FASL" rather than ".FAS" +as their extension. Looks like a carryover from Tops-10/SAIL in its present +state. -sjk +------- + +Date: 3 Sep 1980 0300-EDT +From: JoSH +Subject: decsav format files +To: bug-midas at MIT-AI + +the .exe file midas produces on twenex doesn't seem to be +sharable, causing one to have to GET and SAVE it, eg: +@midas +NOTPUR MIDAS.423 +*foo +... +@foo +FOO>^C +@i me +... +0-100 Private R, W, E +@get foo +@save foo +@foo +FOO>^C +@i me +... +0-100 FOO.EXE.2 1-101 R, CW, E + +I am under the impression that Midas used to save sharably, +though when I tried to check with an old version of Midas (419), +it blew up. +--JoSH +------- + +Date: Wednesday, 27 August 1980 20:34-EDT +From: Earl Killian +To: BUG-MIDAS at MIT-AI + +I just assembled MIDAS 424 on a 20X and when I said PURIFY$G, it +crapped out on a SPACS JSYS. Without the PURIFY$G it seems to +run ok. + +Date: 12 Aug 1980 0204-PDT +From: Mark Crispin +Subject: constants area printing +To: JoSH at RUTGERS +cc: Bug-MIDAS at MIT-AI + +Actually, if MIDAS is invoked with a CCL start then there is no problem. +It's just that nobody has fixed MIDAS to work with CCL in release 3/4. +------- + +Date: 12 August 1980 04:46-EDT +From: Ken Harrenstien +To: JoSH at RUTGERS +cc: BUG-MIDAS at MIT-AI + + Date: 31 Jul 1980 0048-EDT + From: JoSH + + is there any way to prevent midas' printing the constants areas when + it finishes? I mean the double column of addresses it dumps on the + tty. I have lots of these (to keep references on the same page) so it + spits a long list at me which is most annoying. I would prefer still + to see the rest of the stuff (ie run time etc). + ------- + +No. I sympathize, though; for certain programs like CRTSTY this is +pretty bad. Rather than introduce a new pseudo, anyone object +to merely printing the (1) # of constants areas, and (2) total # of wds +used by these areas? If a programmer really needed to know the +locations, a simple typeout macro would do it. + +Date: 31 Jul 1980 0048-EDT +From: JoSH +To: bug-midas at MIT-AI + +is there any way to prevent midas' printing the constants areas when +it finishes? I mean the double column of addresses it dumps on the +tty. I have lots of these (to keep references on the same page) so it +spits a long list at me which is most annoying. I would prefer still +to see the rest of the stuff (ie run time etc). +------- + +Date: 19 July 1980 2100-EDT +From: Joe.Newcomer at CMU-10A +Subject: MIDAS bug (?) +To: (BUG MIDAS) at MIT-AI + +Using MIDAS.419, I have the following experience compling the AT source: + +r midas +at.639 + +which produces a TOPS-10 version of AT just fine, but doing: + +r midas +at.639(t) +SITE==:CMU20FLG +^Z + +to produce a TOPS-20/CMU version of AT, I don't get ANY .REL file, anywhere, +of any description. In fact, the .REL file I found was a couple days old, +and I went thru several compile/link/try-it cycles before discovering that +I had bogus (TOPS-10) code on the TOPS-20 system. What gives? How can +I get a .REL file (I am going to do the obvious of putting the SITE definition in +the source, but that is not what people are going to want when the +source is returned) + joe + +Date: 19 Jul 1980 1612-PDT +From: Mark Crispin +Subject: interesting bug +To: Bug-MIDAS at MIT-AI + +777777777777_-1 returns 177777777777 +but A=777777777777 then A=A_-1 returns A=377777777777 + + + +Date: 10 JUL 1980 1817-EDT +From: KLH at MIT-AI (Ken Harrenstien) +Subject: MIDAS on a BOTS-10 +To: BUDD at MIT-MC +CC: (BUG MIDAS) at MIT-AI + +There are a couple of pseudo-ops like .DECTWO which set up +high/low segments. To switch from one to the other after +this, just save your loc counter with e.g. %%FOO==. and +later you can switch back with a LOC %%FOO. Lots of +programs separate themselves into a pure and impure segment this way, +by having two loc-counter symbols; macros make it easier. +The MIDAS source itself is one example. + +If this isn't what you wanted to know, ask again. + +BUDD@MIT-MC 07/10/80 01:33:01 Re: MIDAS on a BOTS-10 +To: (BUG MIDAS) at MIT-MC +How does one control "context" switching between bagbiting DEC +dual segments? + +I showed a MACRO (archaic DEC assembler) hacker ho to do GETTABs +with a .OP and *BOY* did his jaw drop! + +-Phil Budne + + +Date: 3 JUL 1980 0235-EDT +From: RWK at MIT-MC (Robert W. Kerns) +Subject: LISP and DDT symbols +To: EB at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC +To: (BUG MIDAS) at MIT-MC + +The problem is a LISP bug, which I analyzed and reported some time ago. I +thought JONL fixed it, but perhaps my memory deceives me. + + +Date: 28 JUN 1980 1738-EDT +From: EB at MIT-AI (Edward Barton) +To: (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI, (BUG MIDAS) at MIT-AI + +Consider the following file: +if1,.insrt lisp;.fasl defs +.fasl +foobar==1 +.global foobar +fasend +If it is assembled with MIDAS and loaded into LISP with SYMBOLS set to T, +the error DDT BUG: PLEASE DO :BUG DDT DESCRIBING CIRCUMSTANCES occurs. + +Date: 15 Jun 1980 1822-EDT +From: EBM at MIT-XX +Subject: New MIDAS cons'ed +To: bug-midas at MIT-AI + +In order to permit larger multi-line literals, I edited the MIDAS +source to increase the PDL size from 500. to 1500. (The C compiler +uses large multi-line literals for its branch tables, which is why +I needed to do this.) The new MIDAS, version 423, is installed on +NEWSYS on XX. However I did not install it on ITS because when I +assembled it the resulting file was 3 blocks shorter than SYS;TS MIDAS, +so I thought something might be funny. It would appear that version +422 was never installed. Would the appropriate person either do +the right thing, or tell me what to do? Thanks --- +------- + +Date: 14 Jun 1980 1625-EDT +From: EBM at MIT-XX +Subject: Multi-line literals +To: bug-midas at MIT-AI + +There is a rather low upper bound on the number of words in +a multi-line literal. I have evidence that this limit is about +150 to 160 lines. This is unfortunate because the C compiler +uses a construct like this for it switch statement branch tables: + move reg,[ + lab1 + lab2 + ... + labn + ] +where n can theoretically be fairly large, and quite reasonably +could be 256 or 512, for an opcode branch table. (GZ managed to +exercise this problem doing just that.) Is there any possibility +of this being changed, or at least having the upper bound increased +by a significant factor? Thanks --- +------- + +MOON@MIT-MC 05/16/80 22:29:26 +To: (BUG MIDAS) at MIT-MC +The enclosed program assembles incorrectly; it was about the simplest case +I could find that did. The bug is that the JRST is assembled before the +POP rather than after. This broke the mailer; I will change Comsat to +rplace the ? with a carriage return, which assembles correctly. + + title test + + define foo (list) + push 1,2 + bar!list + pop 1,2 + termin + + define bar (list) + termin + + test: jumple 3,[foo (zot) ? jrst zoo ] + zoo: end + + +Date: 27 Mar 1980 1651-PST +From: Mark Crispin +To: EKILLIAN at BBN-TENEXA, BUG-MIDAS at MIT-AI +In-Reply-To: Your message of 27-Mar-80 1555-PST + +Earl - + +Try increasing SYMDSZ to 6003. I have found this necessary in +the version at SCORE. Only sites that use a TNXDFS that was +made by CVT probably need to do this. + +-- Mark -- +------- + +Date: Thursday, 27 March 1980 18:28-EST +From: Earl Killian +To: BUG-MIDAS at MIT-AI + +I tried assembling MIDAS 422 on BBND and found that when the +result was run, it complained of a symbol table overflow as soon +as a file was given to it. I suspect that this is because of the +large no. of JSYS names and bits defined in release 4. I'm not +sure what parameter should be bumped; will someone figure this +out, bump it, and then let me know. Thanks. + +Date: 26 MAR 1980 1427-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: more ideas about constants bug finding +To: RMS at MIT-AI +CC: (BUG MIDAS) at MIT-AI + +Well, I wasn't actually thinking of matching up the values, +which is clearly impossible. +Rather the idea is to remember in some fashion what the constants +area size is for each time a constant is seen. That is, you +would identify constants not by their value but by their +place in the sequence of constants seen. If on pass 2 the +n'th constant causes an expansion of the constants area, but +on pass 1 the n'th constant didn't, that's an error, but it +might not be necessary to flag it if the constants area size +at that point is equal to or less than its value on pass 1; +pass2 collapse of literals that were distinct on pass1 might have +saved you. This error would only happen once for each constants +area; it might even be postponed until the constants pseudo is +seen and MIDAS can tell for sure whether something will be screwed +(again, pass2 optimization after the first "error" might have +saved things). + It could be made even simpler by just remembering the sequence +(possibly as a string of 1-bit bytes), although this may have more +danger of getting out of phase and would definitely only be +reported if a larger-on-pass2 error happens. + One alternative (or supplemental) hack might be to let the CONSTA +pseudo take an argument specifying how many extra words to reserve on +pass 1 beyond those needed for the constants seen thus far. Then on +pass 2 MIDAS would ignore the argument and just compare the size this +pass with the total size reserved on pass 1. When it DOES barf, it +should say by how many words the reserved size was exceeded. This +will allow certain obscure pass1-pass2 hacks to win which currently +lose. The error message would in any case provide a little more information +to help track down the problem (or solve it with appropriate extra +allocation). Of course if this feature was requested for a constants +area, the sequential-checking hack may not do what you want, but +could still provide useful information when the size IS exceeded. + +One other thing. If lots of constant areas are sprinkled around, +they reduce the scope of errors and even eliminate some (by +flushing optimization). As it happens, the main objection to using +lots of constant areas is not the loss of optimization but the +verbosity of the printout!! I think it would be reasonable to +simply say how many constants areas there were and how large the +total sizes are and what the size of the largest area is. +If a particular constants area is in error, the err message for it +would say where it is and how big it is, which is about the only +time you need to know this thing. + +It would be interesting to have a pseudo to disable optimization +altogether and see how much storage was lost. I don't think it +is such a significant factor nowadays as it used to be, except +for moby hacks like ITS. + + +RMS@MIT-AI 03/26/80 04:02:38 +To: KLH at MIT-MC +Constants tables can't be saved from pass 1 because they are re-used +when a program contains more than one constants area. +Even if they were saved, it isn't clear how that could be used, since +the values of words in the constants are not the same on pass 2, and +can't even be matched up with the constant words they mapped into on +pass 1! The pass 1 constants data does not supply enough information +to figure out, on pass 2, what the value would have been! +FOO*BAR on pass 1 becomes "0 and don't optimize me". On pass 2 it +will be just a number. + + Date: 24 MAR 1980 1713-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: RLJFN +To: MRC at MIT-AI +CC: (BUG MIDAS) at MIT-AI + +I suggest that the HALT following the RLJFN simply be replaced with a JFCL. + +The temporary file kludge is there because at the time I was +writing the conversion code, it was a lot easier to keep things +straight if I emulated the ITS code fairly closely. Now that +it is all pretty stable, the code could be modified to always use +the target filenames, if anyone cares to do so. + +Date: 24 Mar 1980 1213-PST +From: Mark Crispin +Subject: Re: MIDAS bug +To: MMCM at MIT-AI +cc: BUG-MIDAS at MIT-AI +In-Reply-To: Your message of 24-Mar-80 0737-PST + +Well, Release 4 must have fixed the bug that RNAMF% didn't completely +flush the JFN, because you get an unassigned JFN error on that RLJFN% +now. I saw that other code jumped there, but decided to ignore that +fact since that case seemed to be for errors in the assembly and you +weren't going to go much further with MIDAS anyway. + +Why does MIDAS bother with that temporary file kludge on TOPS-20 +anyway? It has a purpose on ITS, but on TOPS-20 it just makes things +unnecessarily more complicated. +------- + +Date: 24 March 1980 10:37-EST +From: Mike McMahon +Subject: MIDAS bug +To: Admin.MRC at SU-SCORE +cc: BUG-MIDAS at MIT-AI + + Date: 22 Mar 1980 0729-PST + From: Mark Crispin + Subject: MIDAS bug + Remove: + SYSCAL RLJFN,[A] + HALT + at OCLOS5. I don't understand how this ever worked, since RNAMF% is + defined to release the JFN in AC1. +It works because RNAMF does not completely flush the jfn, you can do an RLJFN +at least afterwards. I did not just flush it since other code jumps there. + +KLH@MIT-MC 03/24/80 02:52:17 +To: RMS at MIT-MC +CC: MOON at MIT-MC, (BUG midas) at MIT-AI +Okay, so after several hours of lossage I found that the [0,,U3] +was getting mapped to the U3 in a SYSCAL FOO,[A ? U3 ? U4]. +On the second pass this became [x,,U3] so didn7t collapse, and +caused a larger constants area. Apparently, something in +the old NLISTS DID collapse on the second pass but not the first, +so that it all evened out, and never caused an error until +I unknowingly got rid of the literal in NLISTS which saved the world. +The big problem was mostly being completely misguided by +most debugging principles (eg look at changes, assuming +previous stuff was winning). + +So... no MIDAS bug in the strict sense. But somehow it seems +there ought to be some kind of help for the poor loser +who is trying to figure out WHERE the constants area actually +becomes bigger and starts losing. If the constants tables +could retain their info from pass 1, it would be easy to +catch funnyness by flagging any places where a literal that +DID formerly collapse DOESN'T do so on the second pass. +If necessary, this could be invoked by a debugging pseudo at +the same time a .SYMTAB declares the constant area sizes. +This might be done as part of label-inside-constant feature, +and is plausible since the constants tables are all set +up for dynamic allocation. + Or maybe a pseudo turning off optimization altogether, just +so that in such cases the program could still be forced to +assemble a working version, even if not the most compact. + Maybe there are simpler hacks that would still help pinpoint +the problem better, but I'm done. Constants lossage is really +a sort of unusual problem since the error is only caught +at a point far removed from the original location; most other +errors will barf instantly and you at least know where it is. +Even if you're not quite sure at the moment how to fix it, you +can ask someone else "why doesn't the code at FOO+5 win?" and +stand a good chance of being helped. But nobody wants to +tangle with a constants problem for the good reason there's +no locality and few clues. + + +Date: 22 Mar 1980 0729-PST +From: Mark Crispin +Subject: MIDAS bug +To: Bug-MIDAS at MIT-AI + +Remove: + SYSCAL RLJFN,[A] + HALT +at OCLOS5. I don't understand how this ever worked, since RNAMF% is +defined to release the JFN in AC1. You know, that SYSCAL macro just +makes the code infinitely harder to follow through in DDT (besides +losing nice things like ERJMP/ERCAL). Also, can't there be a more +reasonable error handler than HALT? At the very least, it could +output the last JSYS error. +------- + +KLH@MIT-MC 02/20/80 22:49:18 +To: (BUG MIDAS) at MIT-MC +This looks like a real bug. For the insrt files KSC;OUT 105, +KSc;NUUOS 167, and KSC;MACROS 72, the two test files +KSC;TESTB 1 and KSC;TEST 15 respectively bomb and win. +The only difference between them is that the latter, which +wins, has a random macro definition that isn't referenced anywhere +by anything. The lossage for TESTB is that it gets a "more constants +on pass 2 than pass 1" error, plus assorted other errors about +phase globality and the like. + +Although this is for MIDAS 419 on MC, I verified that the bin +has the right patch making it equivalent to MIDAS 420, i.e. +it is zeroing ILNOPT at ASSEM2+1. So this must be some +other problem. + +I hve encountered this before, but each time it appeared as if +I "fixed" the problem in some way. This is the most glaring +repeatable error I've encountered... I will keep these source +files around as long as possible, but they are volatile and +I don't know if the bug will disappear if I move them around. + + +FJW@MIT-MC 02/03/80 05:44:28 +To: (BUG MIDAS) at MIT-MC +Exactly what must I do to bring up the latest MIDAS on a Tenex +machine? Does it need to be purified? I am now using what is +externally labelled MIDAS.SAV;413 and signs on as NOTPURE 416. I +suspect that there is something to be gained by moving up to 420... + +--Frank + + +Date: 17 DEC 1979 2059-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: Macro question +To: (BUG MIDAS) at MIT-AI + +Once again I am wrestling with macros that never quite do what +I want. I'd like to know what might break if the syntax +for "parenthesized macro calls" was modified so that the argument +scanning did NOT stop upon sighting a semicolon or EOL. +Currently a parenthesized call looks like this: + FOO(a,b,c, ; call will stop scanning here + d,e,f) ; these will be ignored. + +The idea is to allow a parenthesized call to handle arguments on +following lines, up to the closing paren/bracket. Comments would +be ignored unless part of an argument, and EOL would gobble up +all following whitespace so that indentation wasn't included in +the next argument. + I have entertained far wilder ideas, but ths particular +mod would be pretty simple. It could be tried out by means of a +.mllit-style switch, unless someone knows for sure that it would +break a bunch of things. + +Date: 31 AUG 1979 0045-EDT +From: KLH at MIT-AI (Ken Harrenstien) +To: SHADOW at MIT-AI +CC: (BUG MIDAS) at MIT-AI + + Date: 30 AUG 1979 1637-EDT + From: SHADOW at MIT-AI (Richard Mark Weinapple) + + What's the maximum number of symbol blocks permissible (and + what would be necessary to change that number?) + +At the moment, 40 octal, with a nesting depth limit of 8. +There is no way to change that short of re-assembling a new +MIDAS. + +GSB@MIT-ML 08/29/79 17:06:40 +To: (BUG MIDAS) at MIT-ML +Why ain't ..SRND & ..RRND defined?? (..RJCL etc are.) + + +EAK@MIT-MC 08/17/79 21:57:27 +To: (BUG MIDAS) at MIT-MC +I've suddenly run into a problem assembling CRTSTY: I get the error +more constants on pass 2 than pass 1. For the life of me I can't +figure out what is wrong. However, if I insert a CONSTANTS pseudo +at the proper place then it assembles without error. That CONSTANTS +is in the source now, labelled "; debug" if you want to look at it. +The source is MC:SYSENG;CRTSTY >. Oh, also, the error only happens +when I assemble it for Tops-20 with TINT==1, i.e. +:MIDAS SYSENG;CRTSTY >/T +CRTSTY ... +TTY: inserted... +TINT==1 +^C +System? Tops-20 + +I'd appreciate it if someone could figure out why its getting this +error, as there is no reason to have that extra CONSTANTS in there. +Also, it's a lot faster to assemble on a 20X, since you don't have to +assemble the whole TWXBTS file in... + +Date: 20 July 1979 02:04-EDT +From: Mike McMahon +Subject: .DECSAV ? NOSYMS +To: EKILLIAN at BBN-TENEXE +cc: BUG-MIDAS at MIT-AI, KLH at SRI-KL + + Date: Wednesday, 18 July 1979 21:27-EDT + From: Earl Killian + Re: .DECSAV ? NOSYMS + + .DECSAV and NOSYMS creates a file that GET complains is badly + formatted. +fixed in the source (MIDAS;MIDAS 418). + +Date: Wednesday, 18 July 1979 21:27-EDT +From: Earl Killian +To: KLH at SRI-KL, BUG-MIDAS at MIT-AI +Subject: .DECSAV ? NOSYMS + +.DECSAV and NOSYMS creates a file that GET complains is badly +formatted. + +Date: 9 JUL 1979 0224-EDT +From: RMS at MIT-AI (Richard M. Stallman) +Sent-by: ___002 at MIT-AI +To: EBM at MIT-AI, (BUG MIDAS) at MIT-AI + +INFO;MIDAS appears to contain documentation on MIDAS +command strings. At least, the one on AI does. + +Date: 8 Jul 1979 1650-EDT +From: EBM at MIT-XX +Subject: Midas documentation +To: bug-midas at MIT-AI + +Documentation on the command line format seems to have gone away; +the info on file name defaulting, etc. is there, but nothing about +the fact that you type (e.g.) + midas foo.bin_foo.mid (we) +or whatever. This seems to be true on ITS and XX. +------- + +Date: 5 Jul 1979 1727-PDT +From: Rubenstein at SUMEX-AIM +Subject: MIDAS 416 works here now... +To: bug-midas at AI + +I renamed .SYMTA to be .SYMTB and it seems to assemble (and run) +fine... + +Stew +------- + +Date: 5 Jul 1979 1223-PDT +From: Mitsw at SUMEX-AIM +To: Rubenstein, Bug-MIDAS at MIT-AI + +the problem with assembling midas on tenex is that TWXBTS tries to define .SYMTA, +since this is a pseudo-op, it apparently only generates 1 word (the squoze) in +the initial symbol table, so that all symbols after that, including +all pseudo-ops, are undefined. i dont know why this only loses on tenex, but +the midas.sav in here was assembled from the sources also here +and seems to work alright. +------- + +Date: 3 Jul 1979 0923-EDT +From: EBM at MIT-XX +Subject: MIdas 417 on XX +To: bug-midas at MIT-AI +Cc: jonl at MIT-XX, mmcm at MIT-XX + +Under instructions from Jonl and MMcM, I reassembled Midas 417 over here. +I gather that I am supposed to assemble it with the T flag, and type in +TNXSW=1, which I did. TSRTNS 192 seems to have problems with it; see +MIDAS.ERR.1. The output from the assembly I did, which +used MIDAS 417 and TSRTNS 191, is in MIDAS.ERR.2. +The binary file, which appears to work directly (does not have to be loaded +then dumped), is MIDAS.EXE.417; the broken one from before is +NMIDAS.EXE.417. The sources I used were all in + +Problems: TNXDFS is inserted instead of TWXDFS + Command line hacking is still not the best; the algorithm I think +will work the best is as follows: + If there is RSCAN input, use it; otherwise read from the primary +input; if that fails too, THEN try the controlling terminal. In cleaning +up RSCAN input, all prefixes of RUN should be checked for, as well as +"(program)", which may be printed by altmode completion of the r or run +command, and then the program name should be stripped, leaving a good +command line. Conceivably, the PRARG feature might be used for passing +arguments, too, but I don't think anyone uses it now. Note that the +program name part of the RSCAN buffer may not be "midas", since people +might create "pseudo-links" - small bootstrap programs that load another +larger program. (We use these for CLU programs all the time.) + I would be happy to talk with whoever is hacking the jcl interface +to explain this further, if it is confusing. Thanks! Eliot Moss +------- + +Date: 2 Jul 1979 1536-EDT +From: EBM at MIT-XX +Subject: Problem w/midas 417 +To: bug-midas at MIT-AI +Cc: jonl at MIT-XX, mmcm at MIT-XX + +We encounter the following difficulty using Midas 417: +when run from exec, there is no problem; when run from our +text editor TED, it gets into an infinite loop. We redirect +the primary input and output to/from files, so it does NOT +have the terminal; BUT it should act as if it does, because +we are presenting JCL in the file. The infinite loop comes from +reading NUL: (apparently). It looks like an explicit test is +made on whether Midas has the terminal, which is reasonable on +most systems, but not here. Midas 416 did not have this problem. +I renamed MIDAS.EXE.417 to NMIDAS.EXE.417, to +get it out of the way. (MIDAS -> NMIDAS because a lot of us search + first). This should not be too hard to fix. +------- + +Date: 2 July 1979 14:57-EDT +From: Mike McMahon +Subject: XX versions of MIDAS +To: JONL at MIT-MC +cc: BUG-MIDAS at MIT-AI + + Date: 06/30/79 13:56:54 + From: JONL at MIT-MC + Re: XX versions of MIDAS + + R MIDAS and + RUN MIDAS + as commands cause MIDAS to begin assembling itself. However, + MIDAS + as a command wins. +this is a crock in TOPS-20 rescan which MIDAS doesnt bother to compensate for. +there is no good reason for having to say RUN MIDAS, it means you have SYS: +defined poorly. there is no reason at all for saying R MIDAS. + +JONL@MIT-MC 06/30/79 13:56:54 Re: XX versions of MIDAS +To: (BUG MIDAS) at MIT-MC +Rescan on TOPS-20 must be crooked - both +R MIDAS and +RUN MIDAS +as commands cause MIDAS to begin assembling itself. However, +MIDAS +as a command wins. Is this a loss in the TOPS-20 rescan, or a +bug in MIDAS? + + +Date: 15 JUN 1979 1255-EDT +From: JSOL at MIT-AI (Jonathan A. Solomon) +To: INFO-MIDAS at MIT-AI + +i have a current copy of midas.322 and i have a source +copy of midas.416 i cannot compile the new version with the +old version as i do not have one of the funny definition +packages for midas.322 (TSRTNS MIDAS) i wonder if you can tell +me where i can pick up the proper copy. i try to assemble +midas, and i get errors from the new (TSRTNS) file as +it is for midas.416 please respond as soon as you can. +thank you + /jon solomon + Stevens Inst. of Tech + (respond to jsol@ml) + +Date: 11 JUN 1979 2025-EDT +From: MMCM at MIT-AI (Mike McMahon) +Subject: MIDAS +To: EBM at MIT-XX +CC: (BUG MIDAS) at MIT-AI + + Date: 11 Jun 1979 1218-EDT + From: EBM at MIT-XX + Re: MIDAS + + MIDAS does not work, but MIDAS does. + An example of a failing file is SETRECLEN.MID. + ------- +please try MIDAS + +Date: 11 Jun 1979 1429-PDT +From: Rubenstein at SUMEX-AIM +Subject: MIDAS 416 +To: bug-midas at AI + +I have MIDAS 416 and TSRTNS 191, straight off ai:midas; -- the +binary and sources are MIDAS.MID;416 and .SAV. The +binary is patched to force fl20x to 0. + +Stew +------- + +Date: 9 Jun 1979 1414-PDT +From: Rubenstein at SUMEX-AIM +Subject: MIDAS 416 +To: bug-midas at AI + +I can't seem to get it to run right here -- I got midas 412 +working a while ago, and it will assemble 416 with no errors, +but when I run it (after making the ppatch to fool it into +thinking we're a TENEX instead of TOPS-20), it comes out +with all sorts of "Syllables not seperated" and "Comma past +the 3rd field" and other error messages with files that assemble +just fine under midas 412. Can anyone make a guess as to +what's going on? + +Stew +------- + +JONL@MIT-MC 06/05/79 10:18:45 +To: (BUG MIDAS) at MIT-MC +The .FASL option does not recogize vertical-bar as a symbol quoter, +while it does recognize slash as a character quoter. + + +Date: 30 MAY 1979 2229-EDT +From: MMCM at MIT-AI (Mike McMahon) +Subject: Very straaaaaange bug +To: (BUG MIDAS) at MIT-AI, Rubenstein at SUMEX-AIM + +try taking the newest MIDAS;TSRTNS, which should fix the problem. + +Date: 30 May 1979 0028-PDT +From: Rubenstein at SUMEX-AIM +Subject: Addendum to last message +To: bug-midas at AI + +I was able to make it work by inserting a couple of CRLF's before +that line... But still, gentlemen.... + +Stew +------- + +Date: 30 May 1979 0026-PDT +From: Rubenstein at Sumex-AIM +Subject: Very straaaaaange bug +To: bug-midas at AI + +I tried to assemble FIND.MID;74 and MIDAS said +"No end statement... Last grouping: ( at 6-025..." +Well, the last word it saw of my file was the first word +on (file) page 10 -- that is, characters 50000-50004 . +This word contained ",(pm%", being part of the line +" movsi 3,(pm%rd)" or somesuch. Why did MIDAS think +this was the end of file? There is nothing wrong with +the EOF pointers, or anything else, about this file. +Version 73, to which I had made trivial, unrelated changes +at a different place in the file, assembles fine. + +Stew +------- + +Date: Thursday, 24 May 1979 18:20-EDT +From: Earl Killian +To: bug-midas at MIT-AI +Subject: .FVERS + +It should be safe to have MIDAS use .FVERS instead of .FNAM2 now; how +about it? + +Date: 19 MAY 1979 2206-EDT +From: RMS at MIT-AI (Richard M. Stallman) +To: EKILLIAN at MIT-AI, (BUG MIDAS) at MIT-AI + + + Date: 19 May 1979 1626-EDT + From: EKILLIAN at BBN-TENEXE (Earl A. Killian) + + If I type + DEFINE FOO #(A,B) + then A and B are made balanced but not evaluated. If I type + DEFINE FOO (#A,B) + then A and B are evaluated, but not balanced. How do I get + both of these options at once? + +That is meaningless. You can't have two different ways of parsing +specified. + + The only reason I want the arguments balanced is so I can + call the macro with the parenthesized call syntax: + FOO(N,5) + which doesn't work unless A and B are balanced. + ------- +I don't think this desire is unreasonable, but it can't be achieved in +any such simple fashion as marking the argument as "both balanced and +evaluated". Evaluated args work by just reading in an expression, +evaluating it. What must be done is to make this do something +reasonable when it comes across an extra unmatched closeparen. + +Date: 19 May 1979 1626-EDT +From: EKILLIAN at BBN-TENEXE (Earl A. Killian) +Subject: DEFINE line bug +To: bug-midas at MIT-AI + +If I type +DEFINE FOO #(A,B) +then A and B are made balanced but not evaluated. If I type +DEFINE FOO (#A,B) +then A and B are evaluated, but not balanced. How do I get +both of these options at once? + +The only reason I want the arguments balanced is so I can +call the macro with the parenthesized call syntax: +FOO(N,5) +which doesn't work unless A and B are balanced. +------- + +Date: 19 MAY 1979 0207-EDT +From: RMS at MIT-AI (Richard M. Stallman) +To: (BUG MIDAS) at MIT-AI + +I have changed TSRTNS so that .FVERS will "work" on +Bots-10 just as it does on ITS. + +Date: 19 MAY 1979 0020-EDT +From: RMS at MIT-AI (Richard M. Stallman) +To: EAK at MIT-AI, (BUG MIDAS) at MIT-AI + + + Date: Thursday, 17 May 1979 15:02-EDT + From: Earl Killian + + It'd be really nice to have a remainder operator in MIDAS. + +Is that the kind of operator that runs Feline's Basement? + +Date: Thursday, 17 May 1979 15:02-EDT +From: Earl Killian +To: bug-midas at MIT-AI +Subject: feature + +It'd be really nice to have a remainder operator in MIDAS. + +Date: 11 May 1979 1517-EDT +From: EKILLIAN at BBN-TENEXE (Earl A. Killian) +Subject: .FVERS +To: bug-midas at MIT-AI +cc: bug-atsign at MIT-AI + +What do .FVERS and .IFVERS do on Tops-10s? It'd be nice if the @ +program used .FVERS instead of .FNAM2, but I don't want to break +Tops-10 assemblies. +------- + +Date: 9 May 1979 1937-PDT +From: Mark Crispin +Subject: (forwarded mail) +To: Bug-MIDAS at MIT-AI + + 09-May-79 1606 Rubenstein at SUMEX-AIM LOADTB +To: MRC at SU-AI +Date: 9 May 1979 1607-PDT +From: Rubenstein at SUMEX-AIM +Subject: LOADTB +To: mrc at SU-AI + +I did some checking around; LOADTB is only defined in Tenex's that +have a pie-slice scheduler, that is, Tenex 134. We're still +running (something based on) Tenex 131. There must be some other +way to tell... Why don't you use the JOBDIR table instead? I +think that was renamed in Tops-20. Or SNAMES, which doesn't +exist on Tops-20. + +Stew +------- + + + +Date: 5 May 1979 0705-PDT +From: Crispin at SUMEX-AIM +Subject: MIDAS at SUMEX +To: Rubenstein +cc: Bug-MIDAS at AI + +MIDAS bites the bag on SUMEX because SUMEX does not have the LOADTB +table defined. MIDAS uses the presence of this table as an indication +that the system is Tenex and not Tops-20. It seems to be the most +reliable way (two others, GETTAB and checking for KL-ness, bite the +bag in other ways elsewhere). + +Why doesn't SUMEX have a LOADTB table? + +I guess it is getting time for MIDAS to divorce the Tenex and Tops-20 +versions. I don't see why Tops-20 MIDAS should be held back for Tenex +primitive ways of doing things. I am unhappy about MIDAS not using +ERJMP/ERCAL. +------- + +Date: Monday, April 23, 1979 14:28:29 +From: Stewart Rubenstein +Subject: MIDAS for tenex +To: KLH@AI +CC: BUG-MIDAS@AI + +The same binary does not work. For one thing, somebody does an +RSCAN, which is 20x only. Secondly, when I try to assemble +something, I get a bunch of errors (I don't remember what they +were off hand, but the same source worked fine when assembled at +SRI). + +Stew + +------- + +Date: 23 April 1979 11:16-EST +From: Ken Harrenstien +Subject: MIDAS for Tenex +To: RUBENSTEIN at SUMEX-AIM +cc: BUG-MIDAS at MIT-AI + +It's not clear if anyone answered your question, so I guess I will. +You shouldn't have to assemble a new MIDAS or anything. The +same binary should work on both 10X and 20X. Are you sure +you weren't just shafted by the difference between 10X and 20X +sharable files (SAV & EXE)? Without more details I have no more +suggestions. + +Date: Wednesday, April 18, 1979 16:29:42 +From: Stewart Rubenstein +Subject: MIDAS for Tenex +To: BUG-MIDAS@AI + +How can I build a MIDAS for Tenex? (as opposed to 20x -- I have +a .sav file snarfed from SRI-KL that doesn't work) + +Stew + +------- + +Date: 10 Apr 1979 2045-EST +From: Mike McMahon +To: EBM at MIT-XX +Cc: (BUG MIDAS) at MIT-AI, MTravers at MIT-XX + +a confusion in "page" sizes has been fixed in MIDAS.EXE.416. +BUG assembles ok now. +------- + +Date: 10 APR 1979 2153-EST +From: MMCM at MIT-AI (Mike McMahon) +Subject: previous report +To: (BUG MIDAS) at MIT-AI, EBM at MIT-XX + + Date: 10 Apr 1979 1442-EST + From: EBM at MIT-XX + To: bug-midas + Re: previous report + + I am still waiting for some reply to my previous + TOPS-20 bug report. Is there anyone out there, + or are my messages going into the infinite bit + bucket ???? + ------- +i dont know exactly what you expect to happen; everyone has more than enough to +do, and someone will look at it when they get a chance. + +Date: 10 Apr 1979 1442-EST +From: EBM at MIT-XX +Subject: previous report +To: bug-midas at MIT-AI + +I am still waiting for some reply to my previous +TOPS-20 bug report. Is there anyone out there, +or are my messages going into the infinite bit +bucket ???? +------- + +Date: 7 Apr 1979 2155-EST +From: EBM at MIT-XX +Subject: Previous bug report +To: bug-midas at MIT-AI + +I would appreciate some reply about the report I made a week ago. +------- + +Date: 2 Apr 1979 1433-EST +From: EBM at MIT-XX +Subject: More on previous bug report +To: bug-midas at MIT-AI + +The bug appears to be rather simple: Midas tries to read beyond the +last word of the file, and if that happens to put in onto a non-existent +page of the file, the illegal memory read error occurs. This looks like +the traditional fencepost (+ or - 1) error. Note: many XX files have +their size in bytes recorded, and Midas seems to do things in terms of +words. Maybe this is OK (since not all text files get their byte size +and length in bytes recorded exactly right). +------- + +Date: 2 Apr 1979 1003-EST +From: EBM at MIT-XX +Subject: Midas bug on XX +To: bug-midas at MIT-AI + +I got an illegal memory read on the file bug.mid; +it looks like twenex-style page mapping is not being hacked +quite right by Midas. This has happened to other people +before, and it is repeatable, but rare (i.e., if I change the file a little +(by adding comments) the problem goes away). +------- + +EAK@MIT-MC 03/30/79 18:57:19 +To: (BUG MIDAS) at MIT-MC +Why the hell is BLOCK illegal inside <>, () or [] +? + +Date: 13 MAR 1979 0233-EST +From: EAK at MIT-MC (Earl A. Killian) +Subject: monitor definitions +To: Admin.MRC at SU-SCORE +CC: (BUG MIDAS) at MIT-MC + +Wouldn't it be better to change IDDT to have the monitor symbols +pre-defined? + +Does anyone know if MARC's new IDDT does this already? + +Date: 12 Mar 1979 2311-PST +From: Mark Crispin +Subject: monitor definitions +To: Bug-MIDAS at MIT-AI + +Oh when oh when is MIDAS going to generate the JSYS symbols in the +output file's symbol table? This is a complete and total screw, since +DDT (on WAITS, Tops-10, Tops-20, and Tenex) simply does not know any +UUO or JSYS definitions. I agree the symbol table is enormous, but at +least it can do what MACRO and FAIL do and generate the used symbols +into the output file. Having to look up the number and type 104000,,n +is ridiculous! +------- + +MOON5@MIT-MC 02/25/79 04:45:28 +To: (BUG MIDAS) at MIT-MC +CC: MOON at MIT-MC +Is the error message obtained by assembling MC:MOON;MIDAS BUG really a win? +(Barfs at formfeed in ASCII string which is in a literal) + + +Date: 8 JAN 1979 2214-EST +From: MMCM at MIT-AI (Mike McMahon) +To: EKILLIAN at BBN-TENEXE +CC: (BUG MIDAS) at MIT-AI + + Date: Monday, 8 January 1979 16:23-EST + From: Earl Killian + To: Bug-MIDAS + + Has anyone investigated the funny behavoir I reported a while ago? + I'd like to have an up-to-date MIDAS, but I can't MIDAS 412 to + assemble and work. +i have tried all the latest files both at MIT-XX (20X) and SRI-KA (10X), +and produced things that will assemble themselves and other sample programs +correctly. Are you sure one of your files isnt munged? + + +Date: Monday, 8 January 1979 16:23-EST +From: Earl Killian +To: Bug-MIDAS at MIT-AI + +Has anyone investigated the funny behavoir I reported a while ago? +I'd like to have an up-to-date MIDAS, but I can't MIDAS 412 to +assemble and work. + +Date: Sunday, 31 December 1978 16:02-EST +From: Earl Killian +To: Bug-Midas at MIT-AI +Subject: XJSYS lossage + +I'm having all sorts of problems creating a new MIDAS. First I tried +assembling a new version from MIDAS 412, TSRTNS 188, and XJSYS 5. However +everytime I tried doing so with my MIDAS 409 I'd get tons of "Multiply +defined" errors on pass two. So I assembled FTP'd the sources to XX and +assembled it with the MIDAS 411 there. It worked ok and I brought it over to +BBNE. To test it I tried to have it assemble itself. The assembly went ok, +but the thing it produced doesn't work. At SITINI it does a SYSCAL +CVHST,[FNBWP A]. FNBWP contains a reasonable byte pointer, but when the +CVHST JSYS is XCT'd AC 1 has 3440 in it (FNBWP=3443). Since CVHST expects a +byte pointer in AC 1, it bombs out. + +I'd appreciate it if someone could look into this and figure out what is +going on. You probably don't want to send out this version on the EMACS +distribution tape, either. + +Date: 18 DEC 1978 1118-EST +From: EAK at MIT-MC (Earl A. Killian) +Subject: rel 3 midas +To: KLH at MIT-MC, MRC at MIT-MC +CC: (BUG MIDAS) at MIT-MC + +The problem with using JRST 4,. after JSYSs is that the illegal instruction +error destroys the error which caused the failure return, making debugging +difficult. What's wrong with a PUSHJ (or even a JSR) to a short routine? + +Date: 18 DEC 1978 0623-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: rel 3 midas +To: MRC at MIT-AI +CC: (BUG MIDAS) at MIT-AI + +I'm surprised that you are complaining about this. I thought +you weren't going to do anything about improving MIDAS for +rel 3 unless the XX people relented, and didn't want others +to do so either. I certainly can't do it without actually +using XX (since SRI-KL is still waiting until Xmas for more +rel 3 work) and while I do have an account there for that +purpose, it seems like a strange situation. + +Have you actually been screwed by any of the jrst 4,'s? +Without looking at the source, I would imagine that most of them +are either in op-sys independent places or follow instructions +that "should never" fail, including internal checks rather than +just JSYS's. I suppose there could be a place for never-fail +JSYS'S (which fail) to JSR to and hack ERSTR, but note that +many JSYS's will just fail with an illegal instruction interrupt +anyway, particularly on TENEX. + +Date: 16 DEC 1978 0418-EST +From: MRC at MIT-AI (Mark Crispin) +Subject: Tops-20 MIDAS +To: (BUG MIDAS) at MIT-AI + +MIDAS STILL does not have any code for release 3 CCL commands on Tops-20. +nnnMID.TMP files do NOT exist on releases after release 1. It is a real +loss for the COMPILE/LOAD/EXECUTE commands not to work. I can't believe +you released MIDAS in this state. C'mon guys, the code necessary is only +a few lines. + +Another problem is that MIDAS does JRST 4,'s on JSYS failures when it should +really do ERSTR hacking. JRST 4, just prints an illegal instruction message, +as if you executed a 0 or something. + +Date: 16 DEC 1978 0413-EST +From: RG at MIT-AI (Richard Greenblatt) +To: (BUG MRC) at MIT-AI, (BUG MIDAS) at MIT-AI + +It obviously doesn't make a tinker's damn worth of difference what the hell +gets used for a nop in any program anywhere. You have just wasted more computer +power sending out your stupid message than will ever be spent on slow nops. + +Date: 16 DEC 1978 0408-EST +From: MRC at MIT-AI (Mark Crispin) +To: (BUG MIDAS) at MIT-AI + +MIDAS (and other ITS software) should use "NOP" instead of JFCL, and +allow sites to define NOP. JFCL is disgustingly slow on KL-10's, where +CAI (SAIL) or TRN (DEC) is the preferred no-op. [DEC likes TRN 'cuz +TRNA is the fastest KI no-op; SAIL sticks to CAIA for KA's and hence +uses CAI. Of course, on KL's TRN/TRNA and CAI/CAIA are the same]. + +Date: 14 DEC 1978 0420-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: multiply defined bug +To: (BUG MIDAS) at MIT-AI + +Yeah, the sequence + foo==1 ? foo==+1 +does the right thing, but + foo==1 ? foo==+1 +gives a multiply-defined error for FOO. + +KLH@MIT-MC 12/14/78 00:20:28 +To: (BUG MIDAS) at MIT-MC +I suspect there is some MIDAs bug with flags or smething that causes +foo==1 +foo==+1 +to get a "FOO multiply defined" error. + + +Date: 13 DEC 1978 2208-EST +From: MRC at MIT-AI (Mark Crispin) +To: EAK at MIT-AI, (BUG MIDAS) at MIT-AI + +I GUESS HAVING A SWITCH WHICH DEFAULTS TO FLUSHING NULLS IS ALRIGHT, +BUT I WOULD LIKE TO PRESS FOR AN UNDERSTANDING ON THE PART OF ALL +CONCERNED THAT USING SIGNIFICANT NULLS IN A PROGRAM IS A VERY VERY +BAD IDEA WHICH MAKES EXPORTABILITY AND EDITABILITY OF THE FILE IN +QUESTION VIRTUALLY IMPOSSIBLE. + +EAK@MIT-MC 12/13/78 21:01:07 +To: KLH at MIT-MC +CC: (BUG MIDAS) at MIT-MC +What KLH is proposing seems reasonable to me. I'd like to point out that, +while most of the times I've used nulls it's been for ASCIZ delimeters, +in one program I had one inside an ASCII string constant. + +Date: 13 DEC 1978 2020-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI, EAK at MIT-AI + +OK, I'm convinced there are problems associated with nulls +and that if someone writes a program source file that depends +on having some nulls in it, they ae apt to face lossage with +respect to some 20X software. However it still seems +reasonable to me to have a switch-style frob so that +winners who want to win can do so and losers who want to +lose can also do so (pick your choice of viewpoints and +associate it with either the on or off state). It should +default to flush on T10 and 20X. This sort of adds the +feature that you can request nulls flushed when you're on ITS! + +By the way I think it's untrue that a random ^C or ^Z will +halt file input. This only happens when the "eof char" is +exactly at the end of the file where it was cleverly placed +by MIDAS. + +Of course, the only use I've found for ^@ has been in macros +which do ASCIZ's of their arguments, and if MIDAS ever acquires +string variables, this and many other crocks will disappear anyway. +So maybe it's more worthwhile to spend time wrestling with that +idea, than on fighting about nulls. + +Date: 13 Dec 1978 0015-PST +From: Mark Crispin +To: EAK at MIT-MC +CC: BUG-MIDAS at MIT-AI + +12-Dec-78 1657 EAK at MIT-MC (Earl A. Killian) nulls +You've indicated that TNX programs flush nulls, but if there +aren't any TNX programs that insert them without being told then noone will +be screwed. + +MRC - ANY PA1050 PROGRAM WILL INSERT NULLS. TREATING NULLS AS SIGNIFICANT, +AND WORSE, DEPENDING UPON THAT, IS SUCH A BAD IDEA IT SHOULD BE FLUSHED +IMMEDIATELY. + + + +Date: 12 DEC 1978 1946-EST +From: EAK at MIT-MC (Earl A. Killian) +Subject: nulls +To: MRC at SU-AI +CC: (BUG MIDAS) at MIT-MC + +I'd hardly call providing a pseudo-op or something to control nulls a +don't-give-a-damn-about-anybody-else attitude. What's more, not ignoring +nulls can only screw people who use programs which add them un-asked for +(such as E). You've indicated that TNX programs flush nulls, but if there +aren't any TNX programs that insert them without being told then noone will +be screwed. + +Date: 12 Dec 1978 1413-PST +From: Mark Crispin +Subject: nulls +To: EAK at MIT-MC +CC: Bug-MIDAS at MIT-AI + +Foo! This is the sort of don't-give-a-damn-about-anybody-else attitude +that DEC has been accused of. Every version of TENEX TECO (yes, dear, +TENEX TECO) that I've ever had the misfortune to use flushes nulls. Why +don't you have your PRIVATE copy of MIDAS not flush nulls without screwing +the rest of the world. + +If you can't think of something better to use in CRTSTY, that's your own +fault. I would think that CRTSTY is a program you might want to give out +to the outside world, however, which would mean NO NULLS. + +I think I will change MIDAS to require control-meta-linefeed for the end +of file character in all versions, flushing these losing ^C and ^Z users. +They steal the capability to use beta or not-equals. As for people without +bucky bit terminals, why should I care? After all, we have this winning +null precedent here for not giving a damn who we screw. + + + +Date: 12 DEC 1978 1141-EST +From: EAK at MIT-MC (Earl A. Killian) +Subject: MIDAS on Tops-10 +To: MRC at MIT-MC +CC: (BUG MIDAS) at MIT-MC + + I don't care what MIDAS does on Tops-10, but I do care about its +operation on TNX systems, which I use. So it is not necessary to tell us how +badly Tops-10s and Stanford will lose since they need not be effected. + + Second, you mentioned ASCIZ would lose: I'd like to point out that ASCIZ +was exactly where CRTSTY was using nulls, as delimeters. This is a perfect +use for them because nulls are the only characters which it doesn't make +sense to put in a ASCIZ string. + + Also, I don't see that null usage forces you to use EMACS (though on TNX +I have no idea what else you'd want to use). TNX TECO seemed perfectly able +to deal with nulls in files in a little test I made. + + Finally, you claimed that all the same problems exist on Tops-20 because +they use Tops-10 software. Well if they use all Tops-10 software they should +have no objection to using MIDAS under Tops-10 simulation. Basically I don't +see why MIDAS has to always lower itself to the lowest common dominator of +the software world. It is as silly as the Header-People who argued against +lower case because some people still used TTY 33s. Also I fail to see why +you object to have null ignoring controlled by a psuedo-op or something, as +KLH objected. That allows people that want to lose (or are forced to by +their software) to lose, and people that want to win to win. + +Date: 12 DEC 1978 0331-EST +From: MMCM at MIT-AI (Mike McMahon) +Subject: Nulls +To: KLH at MIT-AI, MRC at MIT-AI +CC: RMS at MIT-AI, EAK at MIT-AI, (BUG MIDAS) at MIT-AI + + + Date: 12 DEC 1978 0316-EST + From: KLH at MIT-AI (Ken Harrenstien) + + Perhaps it could be made a pseudo-invocable option. Or + a MIDAS source assembly option. I don't know bout T-10 + or WAITS, but I've never had any trouble with 20X files, + in fact I've had less than with ITS owing to more + consistent byte-size/EOF handling. Just as a matter of + curiousity I'd be interested in why WAITS and T-10 lose + with nulls, since I really hv no experience with them. +TVEDIT puts in loads of nulls to fill out everything to page boundaries +and doesnt have a write-out mode that flushes them, but i doubt anybody'd +ever use it to edit a MIDAS program. + +Date: 12 DEC 1978 0316-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: Nulls +To: MRC at MIT-AI +CC: RMS at MIT-AI, EAK at MIT-AI, (BUG MIDAS) at MIT-AI + +Perhaps it could be made a pseudo-invocable option. Or +a MIDAS source assembly option. I don't know bout T-10 +or WAITS, but I've never had any trouble with 20X files, +in fact I've had less than with ITS owing to more +consistent byte-size/EOF handling. Just as a matter of +curiousity I'd be interested in why WAITS and T-10 lose +with nulls, since I really hv no experience with them. + +Date: 11 Dec 1978 2134-PST +From: Mark Crispin +Subject: nulls in input file +To: Bug-MIDAS at MIT-AI, EAK at MIT-MC + +Please do not make MIDAS not flush nulls in the input file. Changing that +would be a gross screw. + + + +Date: 12 DEC 1978 0016-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI +CC: EAK at MIT-MC + + +Date: 8 DEC 1978 2134-EST +From: EAK at MIT-MC (Earl A. Killian) + +Damn, TNX MIDAS seems to lose on nulls in the input file; I'm not sure, but +I think it ignored them. This caused some grief when I tried to assemble +a TNX CRTSTY. + +[KLH - I think it does ignore them. DEC midas does at least. It has +something to do with crufty SOS/EDIT line-numbers... not sure what +best solution is.] + +Date: 5 DEC 1978 0525-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI + +Found it!! By sheer obscure coincidence (more or less) I ran +into some missing symbols frm a .DECSAV assembly which I +traced back to a missing tweak in BKSRT. Those bum-an-instruction +hacks may make MIDAS faster/smaller, but they sure are a pain to +figure out. Anyway, that was undoubtedly why MRC's block structure +assemblies blew up on LOTS; when the monitor attempted to +load the .EXE it was probably hitting EOF on the file before +it could satisfactorily load all the symbols that MIDAS claimed were +there. + MIDAS;MIDAS 412 has the fix. It is simple enough to be +easily patched (see MIDAS;MIDDIF 411412). + +Date: 28 Nov 1978 0339-PST +From: Mark Crispin +Subject: .MID +To: EAK at MIT-MC, Bug-MIDAS at MIT-AI + +I object strongly to changing .MID for the reasons that KLH +mentioned. It seems like a totally worthless change whose +only advantage would be somebody's idea of what is prettier, +and which has the disadvantage of several screws. Why not +leave well enough alone? + + + +Date: 28 Nov 1978 0122-PST +From: Klh at SRI-KL (Ken Harrenstien) +Subject: File consolidation +To: bug-midas at AI + +One thing that would be reasonable is combining TNXDFS and TWXBTS; +I suggest that the latter be incorporated into the former. Presumably +one file will never be without the other. This also makes it +easier to substitute a single TNXDFS file of one's own manufacture. +------- + +Date: 28 NOV 1978 0332-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: JONL's suggestion +To: EAK at MIT-MC +CC: (BUG MIDAS) at MIT-AI, JONL at MIT-MC + +I would counsel leaving the extension as .MID for several +reasons. One is that it is already a documented extension +for MIDAS (documented by DEC even) and they keep their +extensions to 3 letters for the very simple reason that +there is so much T-10 software running on TNX in compatibility +mode. If you feel like re-writing it all to let you win with +full TNX extensions, fine. For example, as a first start +you have to convert ATSIGN, which could use it anyway and doesn't +have DEC copyright hassles attached. +Let us know when it's done... + + +EAK@MIT-MC 11/27/78 22:23:46 Re: JONL's suggestion +To: (BUG MIDAS) at MIT-MC +CC: JONL at MIT-MC +I'd gladly rename my MIDAS files to get a nicer extension like .MIDAS. + + +JONL@MIT-MC 11/27/78 22:13:05 +To: (BUG MIDAS) at MIT-MC +Is it too late to have the default extension be +MIDAS for twenex and MID for TOPS-10? In general, it +seems better to pick a name, and not shorten it on twenex, +but shorten it only by truncation for TOPS-10. + + +KLH@MIT-MC 11/24/78 08:02:29 +To: RWK at MIT-MC +CC: (BUG MIDAS) at MIT-MC +Well, I tried assembling MC:SYSEN1;PWORD 1699 with +MIDAS 410 and it seemed to work fine, so either it was +a super random bug or someone fixed it already. + + +Date: 24 NOV 1978 0750-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: separate source files +To: MRC at MIT-AI +CC: (BUG MIDAS) at MIT-AI + +Personally I prefer it kept separate, since this makes it +more manageable and easier to edit. Furthermore its style +is different (lowercase comments) and most everything in +it concerns system dependent code, which I think is best +kept smewhat removed from the main, system-independent, +body of MIDAS itself. +Other programs may .insrt XJSYS. That was its original intent +I believe. +In fact I'd rather see MIDAS more modularized than more +monolithic. How would you like to have ITS > in one file? + +Date: 24 NOV 1978 0059-EST +From: MRC at MIT-AI (Mark Crispin) +To: (BUG MIDAS) at MIT-AI + +Say, why not flush this separate TSRTNS file? It's enough of a pain +having these xxxDFS and xxxBTS files without making it any worse. I +think XJSYS should be in the main MIDAS file too. + +Date: 21 NOV 1978 1733-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI + +Have fixed TNX run-off-end bug in source, TSRTNS 187. +Someone (RMS I guess) has fixed the listing-file rename bug. + +Date: 21 Nov 1978 1417-PST +From: Klh at SRI-KL (Ken Harrenstien) +Subject: OUTUPD and OUTN1 and NED error on TNX +To: bug-midas at AI + +Well, the mysteriousity remains mysterious. The file +AI:KLH;.BOMB > will work OK on ITS, but get a NED (No +END statement) error on TNX. The reason it does this is +that the NED checking logic at NEDCHK tests the variable OUTN1 +which is only bumped by the OUTUPD routine, which is only +called by output-format-selecting pseudos such as DECREL and +FASL. DECSAV and SBLK in particular do NOT call it. I +can't figure out what the hell any of it is supposed to mean, +especially since most of this NED-hacking stuff is conditionalized +by A1PSW (pass-1 auto-reassembly hack) which I doubt anything +has ever used for at least 10 years. + +(incidentally don't be fooled by the fact that the source file +selects DECSAV format; MIDAS helpfully does an automatic DECREL +selection as part of the pass initialization) + +Perhaps a good solution is to set A1PSW==0 for TNX midases. +------- + +Date: 21 NOV 1978 1334-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI + +I've found a simple fix for the TNX run-over-EOF bug, +but uncovered another one which I haven't yet figured +out. + Fix is not yet in source. + +Date: 21 NOV 1978 0306-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: MOON at MIT-AI +CC: (BUG MIDAS) at MIT-AI + + + Date: 20 NOV 1978 2238-EST + From: MOON at MIT-AI (David A. Moon) + + Do :midas tty: + .insrt nosuch file + + And watch it bite the bag + +I tried this and it very reasonably told me no such file +existed, use what filename instead? + +Date: 21 NOV 1978 0208-EST +From: KLH at MIT-AI (Ken Harrenstien) +Subject: /CREF +To: ekillian at BBN-TENEXE +CC: (BUG MIDAS) at MIT-AI + +The CREF output file format is only understood by the ITS CREF program, +so it is not assembled into non-ITS MIDASes. Tell him to use the +winning ATSIGN program. + +Date: 20 NOV 1978 2238-EST +From: MOON at MIT-AI (David A. Moon) +To: (BUG MIDAS) at MIT-AI + +Do :midas tty: +.insrt nosuch file + +And watch it bite the bag + +Date: 19 NOV 1978 0142-EST +From: MOON at MIT-AI (David A. Moon) +To: (BUG MIDAS) at MIT-AI + +When a fatal error, no END statement, occurs in pass 2 +when the /L option was used, it forgets to rename the _MIDAS LSTOUT file. + +Date: 17 NOV 1978 1552-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: RMS at MIT-AI +CC: (BUG MIDAS) at MIT-AI, DANG at MIT-AI, MMCM at MIT-AI + +Sorry if it was a mis-understanding, but knowing that you are about +to distribute a tape, I want to be sure it's not a castrated midas on +the tape. In the midas bugs file, the only message about block +structure not working is from MRC; previously I had said that I +made it follow the documented DEC format in LINKER manual. + I certainly hope that all you did was insert a flag check, rather than +removing the block-structure hiar for .decsav. Anyway, I would +definitely be willing to make sure that it works, if MRC can furnish +his lossage example. (as I recall it was utterly weird in that +the monitor GET JSYS was crapping out on attempt to load! It is +probably a 20X v3 monitor difference, since I have had no trouble +with my block structured hacks on our v2. This is why XX would +be useful. I would like to ask Dan if that is not a sufficient reason. + +Date: 16 NOV 1978 1754-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: RMS at MIT-AI +CC: MRC at MIT-AI, (BUG MIDAS) at MIT-AI + +Why is "block structure in .DECSAV assemblies illegal"???? +I need that!!!!!!! It works for me!!!!! Nobody has yet given +me a reproducible example of lossage, so how can I debug it? +I spent a lot of time making it work. + +I will not test the new MIDAS until that is restored. + +Date: 15 Nov 1978 1523-EST +Sender: EKILLIAN at BBN-TENEXE +Subject: /C +From: Earl A. Killian +To: Bug-MIDAS at MIT-AI +Message-ID: <[BBN-TENEXE]15-Nov-78 15:23:32.EKILLIAN> + +Is the /C supposed to generate a CREF? One user here tried to get a CREF +from MIDAS and couldn't. + +Date: 12 NOV 1978 1622-EST +From: KLH at MIT-AI (Ken Harrenstien) +To: rwk at MIT-MC +CC: (BUG MIDAS) at MIT-AI + +If no one has looked at your problem yet, can you please save PWORD 1699 and 1700 +(or a srccom of latter) on AI:MIDAS; along with any insrted files, so that +I or someone else can reproduce the lossage later. Thanks. It does sound +like an obscure bug. + +RWK@MIT-MC 11/10/78 21:45:32 +To: (BUG MIDAS) at MIT-MC +The BINPRT info gets all filenames including device as zero, when the input +is from the TTY: +Also, it should clobber DSK: to MC: or ML:, so one can tell what machine +a program was assembled on. + + +RWK@MIT-MC 11/10/78 21:41:01 Re: Obscure bug in .SYMTAB allocations? +To: (BUG MIDAS) at MIT-MC +:MIDAS SYSEN1;PWORD 1699 +Answer "No" to the question. +On pass 2 at label PURIFY+3 it tries to expand my SYSCAL macro completely +wrong, ends up complaining that CORBLK is undefined (that's supposed to go into +the sixbit /arg1/) +and tries to put the second argument inside a ASCIZ (there is no ASCIZ in the +SYSCAL macro). It works right on pass 1, and in SYSCAL's before and after. +Didling the .SYMTAB parameters as in PWORD 1700 fixes this. + + +Date: 27 OCT 1978 2317-EDT +From: RMS at MIT-AI (Richard M. Stallman) +To: (BUG MIDAS) at MIT-AI + +The who-line display loses +when .INSRT is done. It shows the page number in the .insrt'ed file correctly +but with the filename of the main file. + +Date: 16 OCT 1978 1949-EDT +From: MMCM at MIT-AI (Mike McMahon) +Subject: RUN MIDAS +To: KLH at MIT-AI +CC: RMS at MIT-AI, (BUG MIDAS) at MIT-AI, EAK at MIT-AI + + + Date: 15 OCT 1978 0759-EDT + From: KLH at MIT-AI (Ken Harrenstien) + + Well, there are all these ways of invoking it like [@]MIDAS + and [@]midas.EXE.500 (with recognition) and so forth, which + the current algorithm (flush until space seen) handles adequately + and I'd like to keep that capability. Perhaps MMCM has a + suggestion. Perhaps the EXEC can be modified so that it clobbers + the RSCAN string to act just like ITS JCL, making sure thre is a + space at the start of the string (as normally there will be anyway). +whenever the command is started with a filename, the rscan +line seen by the program will contain just the FN1 of the +resulting file, so both of these cases would look just like +MIDAS. there is of course the problem with NMIDAS or +OMIDAS. this means perhaps checking for R or RUN as the +first token and flushing the command line in only those +cases. the RSCAN parser maybe can share some code with the +TOPS-10 one, which is probably already hacking RUN MIDAS;FOO +or whatever. + +Date: 15 OCT 1978 0759-EDT +From: KLH at MIT-AI (Ken Harrenstien) +Subject: RUN MIDAS +To: RMS at MIT-AI +CC: (BUG MIDAS) at MIT-AI, MMCM at MIT-AI, EAK at MIT-AI + + + RMS@MIT-AI 10/13/78 23:18:13 Re: RUN MIDAS + To: KLH at MIT-AI + I think that at least MIDAS should not do JCL rescanning + if it can't recognize the command that ran it as being + of a type that it understands. Simplest would be that + anything other than "MIDAS " as the beginning of the command + would cause it to ignore the "command string". + This might slightly inconvenience someone but at least + it prevents anyone from being really screwed. + +Well, there are all these ways of invoking it like [@]MIDAS +and [@]midas.EXE.500 (with recognition) and so forth, which +the current algorithm (flush until space seen) handles adequately +and I'd like to keep that capability. Perhaps MMCM has a +suggestion. Perhaps the EXEC can be modified so that it clobbers +the RSCAN string to act just like ITS JCL, making sure thre is a +space at the start of the string (as normally there will be anyway). + +Date: 12 OCT 1978 1822-EDT +From: GLS at MIT-MC (Guy L. Steele, Jr.) +To: JLK at MIT-MC, (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC +CC: BEE at MIT-MC + + Why does this crock persist that (when using .FASL) + .ENTRY FOO SUBR 0001 + means a subr of no arguments (i.e. it is always one more than what it + should be)? Is there a reason for this? +The answer is that the number 0001 is the "internal format" +value of the ARGS property. Niceness might have dictated +a better interface, but it suffices. People write 0001 +instead of 1 to remind themselves that a crock is happening. + + +Date: 12 OCT 1978 1634-EDT +From: JONL at MIT-MC (Jon L White) +Subject: .FASL format ".ENTRY FOO SUBR 0001" +To: JLK at MIT-MC +CC: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC + +I think that occurs due to the ease of modifying MIDAS, when RG first +put in the .FASL option. + + +Date: 12 OCT 1978 1632-EDT +From: JLK at MIT-MC (John L. Kulp) +To: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC +CC: BEE at MIT-MC + +Why does this crock persist that (when using .FASL) +.ENTRY FOO SUBR 0001 +means a subr of no arguments (i.e. it is always one more than what it +should be)? Is there a reason for this? + + +Date: 11 OCT 1978 2030-EDT +From: MRC at MIT-AI (Mark Crispin) +To: KLH at MIT-AI, (BUG MIDAS) at MIT-AI + +Why would ANYBODY want to use the RUN command when the obvious right +thing that everybody does is DEFINE SYS: DSK:,SYS: ??? + +Date: 11 OCT 1978 1255-EDT +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI + + + RMS@MIT-AI 10/11/78 02:46:36 + To: KLH at MIT-AI + Another bug in Twenex MIDAS is that if it is run with + @RUN MIDAS + then it decides to assemble MIDAS. + +I'd consider this more of an EXEC screw, since MIDAS has no good +way of knowing all the subtleties of EXEC command line syntax, +and the goddam EXEC is simply passing on the whole last-line-input +to the RSCAN buffer. I have trouble believing DEC's cretinism +sometimes. Anyway, poor MIDAS is throwing away the first word in +the belief it is a "MIDAS" (from [@]MIDAS FOO_BAR), and then +takes the rest of the line as it would ITS JCL, which explains +its action for [@]RUN MIDAS. + If you use RUN a lot, I guess you could kludge the RSCAN reading +routine. + +Date: 10 OCT 1978 2326-EDT +From: KLH at MIT-AI (Ken Harrenstien) +To: (BUG MIDAS) at MIT-AI + +There is a bug in the TNX version such that in certain circumstances +the char reader can somehow manage to skip over the EOF character, +and it either continues to read merrily into nothingness (or zaps +the read BP to a random location, I don't know which) and spews +out an amazing variety of error messages in response. I suspect +the same bug may exist in the ITS version also but manages to +get caught after only one or two garbage characters. +I'll have to look into it sometime. + +EAK@MIT-MC 09/29/78 19:30:34 +To: (BUG MIDAS) at MIT-MC +MIDAS should put the filenames of all .INSRT'd files into the binary +information block. If I remember correctly its all setup to take +variable length information so there should be no problem there. +Sometimes the version no.s of some packages are more important than +the main file so this info is needed. + +RWK@MIT-MC 09/29/78 17:49:59 +To: (BUG MIDAS) at MIT-MC +How about fixing the BININF info saved in BIN files to say AI: or ML: etc. +instead of DSK: ?? + + +MOON@MIT-MC 09/28/78 21:38:19 +To: (BUG MIDAS) at MIT-MC +CC: EAK at MIT-MC + EAK@MIT-MC 09/28/78 18:37:24 + To: (BUG TECO) at MIT-MC, (BUG MIDAS) at MIT-MC + CC: MOON at MIT-MC, RWK at MIT-MC + I've figured out why TECO wasn't assembling correctly these days. + The problem is that I assembled it on MC, a KL. TECO wants to + increment various byte pointers so it does: + .AOP IBP,0,XX + which on a KA leaves an incremented byte pointer in .AVAL2. On a + KL, however, an IBP with a nonzero AC is the ADJBP instruction! + Thus it was doing the wrong thing. One solution would be to + use + .AOP IBP,1,XX + and if .AVAL2 is not equal to XX then use it, otherwise use .AVAL1. +Probably it would be better if Midas used AC 0 for assembly-time +instructions, or let the user specify. + +I always knew someone would be shafted by the crockish way DEC +put in ADJBP, but I never suspected it would happen in this fashion. + +EAK@MIT-MC 09/28/78 18:37:24 +To: (BUG TECO) at MIT-MC, (BUG MIDAS) at MIT-MC +CC: MOON at MIT-MC, RWK at MIT-MC +I've figured out why TECO wasn't assembling correctly these days. +The problem is that I assembled it on MC, a KL. TECO wants to +increment various byte pointers so it does: +.AOP IBP,0,XX +which on a KA leaves an incremented byte pointer in .AVAL2. On a +KL, however, an IBP with a nonzero AC is the ADJBP instruction! +Thus it was doing the wrong thing. One solution would be to +use +.AOP IBP,1,XX +and if .AVAL2 is not equal to XX then use it, otherwise use .AVAL1. + + +RWK@MIT-MC 09/24/78 19:39:16 Re: re-written file lossage +To: (BUG MIDAS) at MIT-MC +The lossage isn't rare with large files...I've had it happen 3 times to +me today alone. If a file is large enough to take a few minutes, it's +very tempting to make more changes while waiting. I'd find it very +helpful if some kind soul were to fix it. + +On an unrelated question....what must I do to define new .BREAK 12, symbols +to MIDAS? Will purifying it under the new DDT work, or do I have to put +it into a table in the source? Is there anything special I have to know +to create an ITS MIDAS? Are the current sources runable? Are there volunteers +to do it for me? + + +Date: 24 SEP 1978 1930-EDT +From: KLH at MIT-AI (Ken Harrenstien) +To: RWK at MIT-MC +CC: (BUG MIDAS) at MIT-AI + + + RWK@MIT-MC 09/24/78 16:09:06 + To: (BUG MIDAS) at MIT-MC + On ITS, where it is possible to win, MIDAS shouldn't close and + re-open the file between the two passes, but should just position back + to the beginning, so if you've written a > file with a minor change + in between passes you don't have to start MIDAS all over again. + Maybe on other sites the file is closed at EOF, so it may not be possible + to win elsewhere, but that's no reason to lose here.... + +This might be accomplished for the main file, and perhaps on TNX for +all files, but in general you can't win this way, because .INSRT +files are equally vulnerable to this (exceedingly rare) lossage +and ITS simply can't save anything like a JFN. I've thought about +doing this for TNX just as a means of improving efficiency (with +large PMAP buffers, moderately-sized files would only be read once!) but +gave it up. + +RWK@MIT-MC 09/24/78 16:09:06 +To: (BUG MIDAS) at MIT-MC +On ITS, where it is possible to win, MIDAS shouldn't close and +re-open the file between the two passes, but should just position back +to the beginning, so if you've written a > file with a minor change +in between passes you don't have to start MIDAS all over again. +Maybe on other sites the file is closed at EOF, so it may not be possible +to win elsewhere, but that's no reason to lose here.... + + +Date: 22 Sep 1978 1410-PDT +From: Mark Crispin +Subject: Command line scanning +To: Bug-MIDAS at MIT-AI + +Tops-20 MIDAS seems to slurp command lines when run manually in the same +losing way as Tenex MIDAS does. How about making it use RDTTY and/or +GTJFN hackery so display stuff (and maybe recognition) will win? + + + +Date: 20 SEP 1978 0924-EDT +From: KLH at MIT-AI (Ken Harrenstien) +Subject: Bug I reported yesterday +To: MOON at MIT-MC +CC: (BUG MIDAS) at MIT-AI + + + MOON@MIT-MC 09/19/78 23:01:59 Re: Bug I reported yesterday + To: (BUG MIDAS) at MIT-MC + MC:MIDAS;TSRTNS 181 fixes this bug, I believe. Could someone who knows + how to assemble, purify, install, and so forth Midas do so? Or else + patch OINIT+13 from TLNN to TLNE. I must say, these TSRTNS are a + complete and utter pile of shit. + +I moved the file to AI, which is where the master copies are (I never +even knew a MIDAS directory existed on MC, although I won't mind +keeping masters there instead), and assembled & etc'd into AI:MIDAS;TS MIDAS +which can simply be copied into SYS;TS MIDAS if it works for you. +BTW, if you want to know, just assemble MIDAS (no hair is ever necessary unless +you're cross-assembling), and start at PURIFY$G which valrets a +pdump. + Sigh, I don't claim TSRTNS is wonderful but think it +stinks a lot less than the previous hackery. If you tell me why it +loses maybe the next effort will be better. + +MOON@MIT-MC 09/19/78 23:01:59 Re: Bug I reported yesterday +To: (BUG MIDAS) at MIT-MC +MC:MIDAS;TSRTNS 181 fixes this bug, I believe. Could someone who knows +how to assemble, purify, install, and so forth Midas do so? Or else +patch OINIT+13 from TLNN to TLNE. I must say, these TSRTNS are a +complete and utter pile of shit. + +MOON5@MIT-ML 09/19/78 03:29:40 +To: (BUG MIDAS) at MIT-ML +THE CURRENT VERSION OF MIDAS PUNCHES COMPLETE GARBAGE IF RIM10 +IS USED. THE BUG HAS BEEN PRESENT SINCE AT LEAST 8/22/78. +PLEASE FIX THIS AS sOON AS POSSIBLE. + +EAK@MIT-AI 09/03/78 16:10:29 +To: (BUG MIDAS) at MIT-AI +Why does MIDAS print out "SBLK Encountered", "RIM Encountered", or +"RIM10 Encountered"? And why is there both .SBLK and SBLK? What +is the difference? + +Date: 31 Aug 1978 1231-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: Tops-20 EXE file format +To: Bug-MIDAS at MIT-AI + +MIDAS's .DECSAV feature loses on programs which use block structure. +If this is a permanent restriction, it should cause an error to use +block structure and documented as such. + + + +Date: 31 Aug 1978 1135-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: MIDAS requires too many files +To: Bug-MIDAS at MIT-AI + +Fix: Replace the .INSRT XJSYS with the contents of XJSYS.MID. Consider +merging TSRTNS back into MIDAS main file. + + + +Date: 31 Aug 1978 1133-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: Tops-20 MIDAS bug +To: Bug-MIDAS at MIT-AI + +MIDAS attempts to execute a CVHST JSYS, because Tops-20 always has a +LHOSTN table. +Fix: +In TSRTNS (179), page 43,line 10, before: + JUMPE B,SITIN3 ; Jump if none, not on net +insert: + JUMPL A,SITIN3 ; Tops-20 release 3 always has LHOSTN +This makes TSRTNS 180. + +[End] + + + +RMS@MIT-AI 08/31/78 01:23:07 +To: (BUG MIDAS) at MIT-AI +I have put a new TWXBTS > on AI:SYS; +It was made from MIDAS;MONSYM > by using Convert MONSYM +and then deleting some things (jsys defs) and adding the first and +last pages. +Please check it over. + +KLH@MIT-AI 08/28/78 23:14:41 +To: (BUG MIDAS) at MIT-AI +Make that TSRTNS 179, I added a check to pull the site-name out +of the CVHST call if possible; if not on the net it will +give up and get it from SYSVER as before. Apparently there +are places that put a lot of shit in SYSVER, BBN-A/B/C/D/E for one. + +Date: 28 AUG 1978 1843-EDT +From: KLH at MIT-AI (Ken Harrenstien) +Subject: .SITE +To: EKILLIAN at BBN-TENEXE +CC: (BUG MIDAS) at MIT-AI + +Sigh, this was an outright bug on my part (gave wrong AC to GETAB call). +Fixed that and also added a little check so that you get only +the site name, rather than the whole cruft like "SRI-KL, + Tops-20 monitor 101-B V1234 EXEC314159 etc etc". +Snarf a new MIDAS;TSRTNS >. +As for changing the format of .SITE I dunno. I certainly won't have the +time this week or next to think about it. + +KLH@MIT-AI 08/28/78 17:40:31 +To: EAK at MIT-AI +CC: (BUG MIDAS) at MIT-AI + + EAK@MIT-AI 08/27/78 14:58:11 + To: (BUG MIDAS) at MIT-AI + I assembled a 10X version of TECO on ITS and all went well. However it + called the output file TECO BIN; wouldn't TECO SAV or TECO EXE have been + better? + +The latest version of MIDAS (which is not yet installed on ITS) will +do this. + +Date: 28 Aug 1978 1113-EDT +From: EKILLIAN at BBN-TENEXE (Earl A. Killian) +Subject: .SITE +To: Bug-MIDAS at MIT-AI + +Why does .SITE return +"__X__X__X__X__X" +on my 10X? Thats very random. + +Also, how about changing the way .SITE works. It shouldn't take an +argument, it should just return the whole thing like SIXBIT does. +You could use .NTHWRD to be like .SITE n. Also you could then do +.SITE and get the whole thing. +Thus, .SITE would be identical to SIXBIT/SITE-NAME/. If you used it +in an expression the value would be truncated to one word, just like +SIXBIT. If you used it to generate storage words then it would take +as many as necessary, like SIXBIT and ASCII. Finally if you wanted +the effect of .SITE n then you could trivially get it with .NTHWRD. + +Sorry if this is a bit rambling. +------- + +EAK@MIT-AI 08/27/78 14:58:11 +To: (BUG MIDAS) at MIT-AI +I assembled a 10X version of TECO on ITS and all went well. However it +called the output file TECO BIN; wouldn't TECO SAV or TECO EXE have been +better? + +KLH@MIT-AI 08/21/78 12:13:41 +To: (BUG MIDAS) at MIT-AI +CC: MMCM at MIT-AI +MIDAS 409, TSRTNS 176 fix BLOCK -n and FOO;T_BAR +respectively. Not tested or installed yet. +Diffs in MIDDIF 408409 and TSRDIF 172176. + +KLH@MIT-AI 08/20/78 03:20:23 +To: MMCM at MIT-AI +CC: (BUG MIDAS) at MIT-AI + + MMCM@MIT-AI 08/18/78 20:22:38 + To: KLH at MIT-AI + ;T in the command line does not make the output file temporary. + +How about that, you're right. Guess I'll look and see why. +I assume the foo_bar construct in the JCL is what you wanted, though? + +KLH@MIT-AI 08/18/78 18:27:05 +To: MMCM at MIT-AI +CC: (BUG MIDAS) at MIT-AI +Anything wrong with something like +[@]MIDAS foo;t_bar +i.e. just specify another FN1 in the command line, and if you +want "temporary" in the true sense just add ";t". +I don't think the source code should specify where its output should go, +even as a default. +Creating a separate symbols-only file would be a more reasonable idea, +but you'll still be GET'ing and SSAVE'ing the bin file, so I don't +know if that would gain you anything. + +MMCM@MIT-AI 08/18/78 16:49:05 +To: KLH at MIT-AI, (BUG MIDAS) at MIT-AI +"." IS THE ONLY CHARACTER WITH OTHER SYNTACTIC INTERPRETATIONS THAT IS +LEGAL WITHIN THE <>'S OF A DIRECTORY NAME, YES, WHICH IS WHY I JUST +PUT IT IN TO USE THE EXISTING ROUTINES. +IT WOULD BE NICE IF .SBLK AND .DECSAV HAD A WAY TO SPECIFY THE FN1 OF +THE .EXE OR BIN FILE, SINCE E.G. I DONT WANT TO WRITE A TECO.EXE, BUT +RATHER SOME TEMPORARY FILE THAT WILL THEN GENERATE THE REAL (SHAREABLE) +TECO.EXE. + +KLH@MIT-AI 08/18/78 06:09:38 +To: MMCM at MIT-AI, (BUG MIDAS) at MIT-AI +I have put in the appropriate output-fn2 defaultings for SBLK, etc; +DECSAV on ITS will hae FN2 of SAV; SBLK on non-ITS will hae FN2 of SBK. + +I am willing to make BLOCK -n generate an error if nobody objects. + +Mike, did you hack the directory-name parsing thing? +Random things like that should be mentioned in a message; it makes it +easier to figure things out, especially when some code doesn't work +and it's not clear who put it in. Is "." the only strange character +that might be encountered? + +Date: 17 AUG 1978 1829-EDT +From: KLH at MIT-AI (Ken Harrenstien) +Subject: feature +To: EKILLIAN at BBN-TENEXE +CC: (BUG MIDAS) at MIT-AI + +We have mumbled in the past about system independent ways of +asking for filename components, such as having .FVERS MAIN, +give you version # of main input file, or some more general +pseudo. As I recall this trailed off in the hope that a +"string" data type would evolve, with which one could truly win. + I'm not sure if preserving the version # is reasonable. +What would you do if a .SAV.nn file already existed - replace +it or use next higher number? What if .SAV.nn didn't exist, but +.SAV.nn+m did? Just checking for such cases is a pain. Myself +I rarely need such info; 20X provides directory listings sorted +by creation date if you like, which is somtimes more useful. +Having a version # available to the program via pseudo would +help, of course. + +Date: 17 Aug 1978 1652-EDT +From: EKILLIAN at BBN-TENEXE (Earl A. Killian) +Subject: feature +To: Bug-Midas at MIT-AI + +It would be nice if MIDAS had something akin to TECO's FS IF VERSION, i.e. +something which would be the version no. of the source file. On ITS it +would be the FN2 converted to a numeric no. On TNX it would be the file's +version no. + +Right now most programs that assemble on TNX and want their version no. +ask for it (and TECO has to be called TECO.nnn instead of TECO.MID so +that it will be able to get it). This would eliminate the need to ask. + +RMS, what does FS IF VERSION return for non-numeric FN2's on ITS? Should +MIDAS do the same thing? + +Finally, it might be nice if MIDAS's command line hackery defaulted the +output filename to FOO.SAV.nnn where nnn is the version no. of the input +filename. It would save renaming FOO.SAV.1 to FOO.SAV.nnn after the +assembly. +------- + +MMCM@MIT-AI 08/12/78 07:58:39 +To: (BUG MIDAS) at MIT-AI +i think the clu problem should be fixed now. + +MRC@MIT-AI 08/10/78 16:24:51 +To: KLH at MIT-AI, MMCM at MIT-AI +CC: (BUG MIDAS) at MIT-AI + + KLH@MIT-AI 08/10/78 12:10:19 + + You can't expect us to debug anything on MIT-XX if you won't let + us log into the machine. + +RIGHT!!! + +KLH@MIT-AI 08/10/78 12:16:06 +To: MMCM at MIT-AI +CC: (BUG MIDAS) at MIT-AI + .sblk should not generate files with the extension EXE on 20X, but rather something + like SBLK + +Uh huh. I seem to recall there was a 3 letter extension for it listed +in a 10X manual once, but I can't find it again; probably .SBK will +do. + +KLH@MIT-AI 08/10/78 12:10:19 +To: MMCM at MIT-AI +CC: (BUG MIDAS) at MIT-AI, rra at MIT-DMS + + MMCM@MIT-AI 08/10/78 05:27:21 + To: KLH at MIT-AI + CLU is exercising a 20X only bug in the new midas that causes phase errors. + i have the files here since mit-xx isnt on the net very often, they are + CBUF > -> CBUF.MID + ALPHA > -> CLU:ALPHA.MID + OMEGA > -> CLU:OMEGA.MID + PASS1 > -> PASS1.MID + TYPES > -> TYPES.MID + COMMON > -> COMMON.MID + JSYS SYSDEF -> JSYS.SYSDEF + or some such mapping, if you want to try shipping them there to test it. there are + infintely hairy macros involved and lots of faking out the constants area. it assembles + fine under ITS. RRA might have some more ideas of what exaclty is going wrong. + +You can't expect us to debug anything on MIT-XX if you won't let +us log into the machine; otherwise you'll have to give more information +and settle for very slow debugging. + What version of MIDAS was losing? There was one TNX specific bug +that existed for a while which is now fixed, but I can think of +one or two other ways in which the 20X version could assemble +differently. + +MMCM@MIT-AI 08/10/78 04:52:27 +To: (BUG MIDAS) at MIT-AI +.sblk should not generate files with the extension EXE on 20X, but rather something +like SBLK + +MMCM@MIT-AI 08/08/78 04:16:33 +To: (BUG MIDAS) at MIT-AI +i am not sure that just moving . is the right thing for the BLOCK pseudo to do; +specifically a negative argument should perhaps cause an error. This is what +FAIL does. (MACRO only checks for this error condition on pass 2 for no reason +that i can figure!) +the case where this arises is BLOCK 1000-<.-MUMBLE> where you've got too much +code after MUMBLE. + +KLH@MIT-AI 08/08/78 03:56:53 +To: (BUG MIDAS) at MIT-AI +OK, MIDAS 408 and TSRTNS 172 appear to work fine on SRI-KL. +A srccom of differences from 405 and 171 is combined in +MIDAS;MIDDIF 405408 (skipping 406). I judged it better +to smash the .OSMIDAS symbol value before spreading +the symbols rather than making it an "internal symbol", +so as to avoid breaking programs that do .OSMIDAS==SIXBIT/FOO/. +Sigh. + + +RMS@MIT-AI 08/05/78 18:27:27 +To: KLH at MIT-AI, MRC at MIT-AI +I don't agree that, in processing a MACRO universal file, +not understanding macros would be a significant disadvantage. +So what if there are macros in MONSYM? Those macros are not +present in DECBTS or TWXBTS, so the lack of them can't be too bad, +and won't make things any worse than they are now. +If we make MIDAS able to read and write MACRO universal files +(actually we can do without writing), ordinary numeric symbols only, +that will make things a lot more convenient for us. It could be +smart enough to detect conflicts between symbols in the universal +file and predefined MIDAS symbols, and prefer the latter. Then there +would be no trouble with .SYMTAB. Since some losing sites delete the +universal files supplied by DEC, we can just supply copies of them +with MIDAS. + +Alternatively, I think we should use a TECO macro to convert a MACRO +file into a MIDAS one. Making MIDAS understand the mBn construct +would not eliminate the need for this, since we would still have +to put in the calls to DEFSYM. It would make the TECO macro simpler, +but we would still need to perform a conversion. So we might as +well put it all in the TECO macro and not change MIDAS. I will +write the macro now. + +Of course, reading universal files is only for the future. +Right now the problem has to be fixed some other way, so you might +as well just do so the way you plan to, without further discussion. + +If we decide we really want to provide some macros as well as +symbols, we can always have a .INSRT file which defines the macros +and then gobbles the DEC universal file for the other symbols. +KLH@MIT-AI 08/05/78 05:48:56 Re: Universal files +To: RMS at MIT-AI, MRC at MIT-AI +CC: (FILE [MIDAS;MIDAS BUGS]) at MIT-AI +I've thought about this too, but there ae a number of problems +which would need solving. + First, as far as understanding DEC's universal file format, +FAIL doesn't and MIDAS would have a lot of problems doing so, +because the symbol table structure is so different. Also it +turns out to be fairly important that macros be preserved, since +DEC defines some which are used a lot in user programs (prime +example is .FLDDB which sets up args for the COMND JSYS). +Granted it would be an amazingly impressive hack, if anyone bothered. + So it would be better for MIDAS to have its own format +not only for speed but for macro-saving capability as well. But +here again there are problems because we can't just run MIDAS +over the DEC MONSYM source file; it uses various macros and +lots of nBm value constructs and the like. This is why MRC +consed up the equivalent for MIDAS by hand (!!). Naturally this +is not what we want to do either. + + My suggestion here would be to concentrae on the immediate +problem (getting symbol definitions into MIDAS) and worry about +universal file capability later, by making it easier to snarf +DEC symbol definition files into MIDAS-readable format; the more automatic +this can be made, the less hassle we'll have. Basically I have +two suggestions: + (1) define a pseudo which enables MIDAS to read nBm values, + and likewise to stop recognizing them. + (2) write and document a TECO macro which will make the + minor changes necessry to MONSYM.MAC; this will need + to be changed only when the MACRO macros are + substantially modified. This teco macro will also + insert DEFSYM's in the appropriate places. + +Then we .insrt the file twice into MIDAS, once for the definitions +and once for the symbols alone, not bothering to evaluate them +the second time but just using the scheme of storing the value as +defined on the first .insrt. This avoids the pain of trying to +change the monsym.mac format so that DEFSYM can pluck out the value alone, +making it much easier to write this teco macro. + +Reading nBm values will of course break existing programs, which is +why we will make it a normally-off switch and let the source +code turn it on and off. I haven't thought of a reasonable name +for the pseudo(s) but that shouldn't take long. +This will also make it a lot easier to snarf and convert TNX routines +by the way, not that I'm in love with the stupid syntax. + + +RMS@MIT-AI 08/04/78 20:42:21 +To: MRC at MIT-AI, KLH at MIT-AI +Looking at the comparison of MIDAS with FAIL and MACRO, +it seems to me that FAIL and MACRO win in that the way +to specify which symbols to use is independent of whether +you are assembling on the same system of a different one. +But they lose in that only the symbols you use +are defined in DDT. Clearly, they should all be in DDT. + +So, unless people can fix DDT (unlikely), MIDAS should put +all of the system symbols in the binary, for best results. + +However, since any user can request this for himself by +doing the .insrt, we need not put this in MIDAS. We should +just change the documentation to point out that this is possible. + +The other possible advantage of FAIL and MACRO is that universal +files are at least potentially much faster than .insrt files, +especially .insrt files which are being parsed by DEFSYM. +So maybe we should make MIDAS able to read and write universal +files. It would read them by looking at them and putting the +data in the regular symbol table. Of course, macros wouldn't +have to be made to work, and macros in universal files written +by MACRO almost certainly wouldn't work, but that doesn't matter +as long as they are ignored reasonably. + +Then users would write in MIDAS just as they write in FAIL or MACRO, +except that the symbols would go in the user symbol table, which is +even better (of course, there could be an option saying whether to +.KILL the symbols being gobbled). An additional advantage would +be that we would not have to maintain any more defs files. +We could just copy DEC's defs files. + +MRC@MIT-AI 08/04/78 19:00:44 +To: RMS at MIT-AI, KLH at MIT-AI +FAIL and MACRO only put into the symbol table those system symbols and +bits which the program actually used. UUO's which are opcodes are +included always since DDT knows about them, but it doesn't know about +extended things. In other words, JSYS, CALLI, and OPEN are known, but +OUTSTR or SOUT or EXIT aren't known unless the program does one, which +is quite a screw. I suspect it is DEC trying to bum a K or two. Sigh. + +FAIL and Stanford DDT should know better, but they don't. + Date: 4 Aug 1978 1946-PDT +From: Klh at SRI-KL (Ken Harrenstien) +Subject: ( Forwarded Mail ) +To: [midas;midas bugs] at AI + +Mail from SU-AI rcvd at 4-Aug-78 1939-PDT +Date: 4 Aug 1978 1938-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: universal files in MIDAS +To: RMS at MIT-AI, KLH at SRI-KL + +[just a side note, MIDAS compiles TWXBTS faster than MACRO searches (reads +a universal file) MONSYM!!!] + +Well, reading a universal file sounds like a win, although I would prefer +that it would be done intelligently. In particular, DEC cretinously +introduced a symbol called .SYMTAB into MONSYM. Its purpose in life isn't +terribly justifiable, and in fact it should NOT be used on Tenex at all, so +I flushed it when I made TWXBTS. Another problem is that I would prefer not +to have to say .SEARCH MONSYM in my programs; SYS:MONSYM.UNV should always +be read in (and, I guess, dumped out) in the Twenex version (in Tenex, you +read STENEX.UNV instead). I think it is safe to assume that this +file would be present. + +What to do about the DEC systems is a bit harder. The true right thing to +do at SAIL is to get them from the monitor. Look at the CALLIT UUO writeup +on page 113 of the UUO manual, and low core location 272 on page 260 (in +Appendix 3). FAIL knows about the UUO's and gets the CALLI's only, but it +is possible using CALLIT to get all the UUO's with appropriate heuristics. +An alternative way is to do a CALLIT on any symbol which would be otherwise +undefined; this of course means a system call has to be done for every UUO +(or undefined symbol) in the program. Actually no matter what you do it is +almost too horrible to comtemplate, depending on where your values are. + +On Bottoms-10, you would try to snarf UNV:UUOSYM.UNV. If that fails, try +UNV:C.UNV. If that fails, try device SYS: instead of UNV:. + +As for the cases where you can't get at the file, well, on Tenex and Twenex +I think it is safe to assume the file would exist. Bottoms-10 is another +story (unfortunately); some cretinous business systems actually have deleted +the files (to my unending chagrin). A safe alternative is to continue the +basic DFS files (both DECBTS and TWXBTS are out of date by now), to at least +provide in a bare MIDAS what MACRO provides. If we go the universal file +route, I do have a universal file for ITS on DECSYS;SITS MAC and SITS UNV-- +DFTP uses it, although no ITS bits are included in it. + +An alternative approach is to continue as we have done, except that we will +attempt to get up to date copies of UUOSYM and MONSYM from DEC to update our +files. That may end up as the best way. + +One last note before I end this over-long message; in any case, MIDAS should +dump out its symbol table in the system-dependant crud since there is no +hope of fixing DDT. + +-- m + + +------- + +KLH@MIT-AI 08/04/78 18:40:17 Re: symbols +To: MRC at MIT-AI, RMS at MIT-AI +CC: (BUG MIDAS) at MIT-AI +Let me see if I can get things straight. This is only a +first pass, is incomplete with respect to comparisons with FAIL/MACRO, +and has no conclusions. Comments welcome. + +Case IA: User program to run on assembly system. + + This is the majority of cases; for example, assembling + FOO on ITS to run on ITS, or BAR on 20X to run on 20X. + The MIDAS philosophy seems to be that no system symbols + should have to be .insrt'd, and they shouldn't be written + out in the program's symbols. + FAIL and MACRO, on the other hand, make use of UNIVERSAL + files (extension .FUN and .UNV respectively) which are + explicitly requested by the user program with a SEARCH pseudo. + Hence the "SEARCH MONSYM" you see for Macro programs. Read + up on these in MACRO or FAIL documentation. Any symbols + which are used by the program are written out in its symbol + table; unreferenced ones are not. + +Case IB: User program to run at another system. (Cross-assembly) + + MIDAS requires the user program to .insrt one of + the standard sets of symbol definitions, depending on + what system one is assembling for. These symbols are + included in the outputted symbol table for the program, + unless .KILL'd. + For FAIL and MACRO one just SEARCH's the appropriate + universal files instead of the normal MONSYM or MACSYM. + Essentially this is no different from case IA. + +Case IIA: MIDAS to run on assembly system. + + The basic difference between MIDAS and a random user program + is that during the assembly the symbols which are to be pre-defined + must be assembled into the initial symbol table. This + is why DEFSYM exists, so that one can deposit symbol names and + values into the storage area reserved for initial symbols. + + Since by definition in case IA MIDAS has all of the + system symbols pre-defined, one could get away with just knowing the + symbol names, and letting the assembling MIDAS furnish the + values. This will work unless some new symbols have + been added or some values have changed. Thus it is + still necessary for DEFSYM to pull out the value, and if + the MIDAS being assembled uss one of the new symbols, it is + also necessary to define them at start of assembly, just as for + a cross-assembly. + +Case IIB: MIDAS to run on another system. (cross-assembly) + + Clearly it is necessary to both .insrt the symbols as + a means of defining them (so that the code will assemble properly) + and to put them in the initial symtab area of the assembled + MIDAS. In this case, it is reasonable for the DEFSYM macro + to let the assembling MIDAS furnish the value (since the symbol has + been defined by the first .insrt). + +KLH@MIT-AI 08/04/78 00:56:25 +To: (BUG MIDAS) at MIT-AI +A while ago I started up a MIDAS on AI to assemble a tenex version, +to get an error file output etc; the result is MIDAS;MIDAS BIN +(and ERR). There is one assembly error shown in ERR. I imagine +it can be fixed in TWXBTS. However, the other problem is that +if you use the resulting midas (on a tnx of course) to assemble +a program, all jsys's have turned into 104 (instead of 104000,,x) +I thin ecause the IRPS hangs up before the bit-shift operand +is seen (tnxdfs file). Is there any form of IRP that will +properly isolate the value? I have never had anything to do +with the way initial symbols are defined so I much prefer to +let the author(s) of the code in question have at it. + +MRC@MIT-AI 08/03/78 19:57:49 +To: (BUG MIDAS) at MIT-AI +CC: EAK at MIT-AI +I certainly did not do any of those losing changes to MIDAS' DEFSYMM. +KLH, please fix it back (and flush that losing expression in the beginning too +while you're at it. + +KLH@MIT-AI 08/03/78 18:04:44 +To: (BUG MIDAS) at MIT-AI +CC: EAK at MIT-AI +All right, who clobbered the DEFSYM macro? That screwed up assembling +TNX version. Unless there is a good reason I'll just change it back. +Also why were the older sources flushed? Fortunately I retained a +MIDAS 402 on SRI-KL to compare 405 with; did someone's EMACS macro automatically +flush older versions or smething? (This screwed Moon too when +he tried to find an old MIDAS). + +Date: 2 Aug 1978 2301-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: RG's $. idea +To: Bug-MIDAS at MIT-AI, RG at MIT-AI + +I agree completely. FAIL has this feature in relocatable assemblies and +wins just fine with it, and I would think absolute assemblies would be +easier since on pass 2 MIDAS should know where the storage word is going +to be(?). +By the way, is it still true that - loses with DEC's +LINK? A program of mine needs to compute the number of bytes accumulated +in a buffer from the byte pointer and does a MOVEI AC,-START(PNTR) to get +the number of words to start off with. I ended up making the program an +absolute assembly since it's a Twenex program (so relocatability doesn't +matter!) and it turned out I wanted to do LOCs to start on different pages, +but it would be nice to know if the restriction is still necessary. Or is +it a MIDAS loss? + + + +RG@MIT-AI 08/03/78 01:07:44 +To: (BUG MIDAS) at MIT-AI + IT WOULD BE NICE IF $. INSIDE CONSTANTS WORKED IN AN ABSOLUTE ASSEMBLY. +IE IT SHOULD GIVE YOU THE LOCATION IN THE CONSTANTS AREA WHERE THE CURRENT +STORAGE WORD WILL BE PUT. + +KLH@MIT-AI 08/02/78 18:08:58 Re: .OSMIDAS => TENEX/TWENEX +To: (BUG MIDAS) at MIT-AI +CC: eak at MIT-MC + + EAK@MIT-AI 08/01/78 21:58:11 Re: MIDAS + To: KLH at MIT-AI + How about changing MIDAS's .OSMIDAS to return either SIXBIT/TENEX/ or + SIXBIT/TWENEX/. I find the current scheme where they're undifferentiated + pretty bothersome. + +I would agree with this; 10X and 20X ARE different systems no matter how +much we would like programs to remain runnable on both. There is probably more +difference between 10X and 20X than between CMU and DEC. +The only question is whether TENEX and TWENEX are the names we want to +use. I can't think of anything better, though. + +MOON@MIT-AI 07/31/78 09:22:51 Re: Yet more about how I am getting shafted by new Midas +To: (BUG MIDAS) at MIT-AI +I don't think putting this "debugging info" lossage after the symbol table +will help. How about putting it after the second starting address, or flushing +it entirely, or not starting it with an aobjn pointer, or putting it in the +complete crud at the front of the file before the JRST 1. Or at least document it. + +MOON@MIT-AI 07/31/78 09:17:19 Re: Previous bug +To: (BUG MIDAS) at MIT-AI +Aha, I found some documentation about a "debugging info block" +in INFO; MIDAS ARCHIV, which didn't say anything about its format. +I'm pretty sure this is what is screwing me. Please fix Midas to +put this after the symbol table, instead of before, so that it will +not confuse NTSDDT and DSKDMP. + +MOON5@MIT-MC 07/31/78 09:11:31 +To: (BUG MIDAS) at MIT-MC +SOMEONE CHANGED THE FORMAT OF MIDAS OUTPUT WITHOUT +ANNOUNCING IT, AND WITHOUT CREATING ANY DOCUMENTATION, +AND WITHOUT LEAVING THE OLD VERSION AROUND SO I COULD +SRCCOM IT. IT IS NO LONGER POSSIBLE TO ASSEMBLE ITS +AND HAVE IT WORK. PLEASE CHANGE IT BACK OR DOCUMENT +THE CHANGE POST HASTE. + +KLH@MIT-AI 07/27/78 10:44:43 Re: Another TNX MIDAS +To: (BUG MIDAS) at MIT-AI +CC: EAK at MIT-AI, DANG at MIT-AI +I've updated MIDAS (to 402) to reflect my current understanding +of DEC symbol-table formats; this only influences people who +debug .DECSAV-produced block structured programs, and to the +best of my knowledge (as per DEC LINK loader reference manual) +the MIDAS-produced format is in exact conformance. + I also fixed a bug in the new ITS code for outputting a debug-info +block (user,date,filenames); it would have clobbered stuff if +actually invoked. + +Date: 24 Jul 1978 2303-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: nBm construction in MACRO and FAIL +To: KLH at MIT-AI, Bug-MIDAS at MIT-AI + +I don't think that it is worthwhile to do this. No matter how it is done, +I don't believe it can be done in a way which will avoid all the screw +cases. + +When I converted MONSYM to TWXBTS, it was the result of many gruesome hours +of thankless effort. My difficulty was excerbated by my communications link: +an ADM-3A via the NYU-ELF via CRTSTY (cretins all) to EMACS, all at 300 baud. +Converting from version 1 to version 2 was done by making a SRCCOM of the +two MONSYMs, then MANUALLY typing in the new entries (with, as you may have +noted, the GETAB mnemonics commented out since DEC wisely called one of them +.SYMTAB!!!!). + +I would like to see a version 3 version of TWXBTS, but I sure as hell don't +intend to do it this time. + +--m + + + +Date: 24 Jul 1978 2252-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: additional instructions in MIDAS +To: MMcM at MIT-AI, Bug-MIDAS at MIT-AI + +Not everybody has castrated their microcode, and in this day and age KA's +are just about obsolete; it's enough that MIDAS will still run on them. +I in fact have accounts on uncastrated KL's which are soon going to get +the multiple-field capability. I haven't yet had the need for a core +image greater than 256K, but the extended instructions are winners: +CMPSE is an especial winner in this respect. + +Even though it is hopeless to get the world to convert from MACRO to +MIDAS, there is no reason why we should give them any reason to use +MACRO other than "DEC supports MACRO" (titter, giggle, chuckle, guffaw...). + + + +Date: 24 JUL 1978 1947-EDT +From: MMCM at MIT-AI (Mike McMahon) +To: (BUG MIDAS) at MIT-AI, EKILLIAN at BBN-TENEXE + + + Date: 23 Jul 1978 2011-EDT + From: EKILLIAN at BBN-TENEXE (Earl A. Killian) + To: Bug-TECO at MIT-AI + + Assembling TECO 656 with MIDAS 400 gets an error because TECO uses "EDIT" + as an instruction label. Either TECO should use another name or a + IF1 EXPUNGE EDIT should be added at the beginning. + ------- +i really dont see why all the kl EXTENDed instrs should be included at all. + +KLH@MIT-AI 07/23/78 02:26:37 +To: (BUG MIDAS) at MIT-AI +By the way, just for the record, the # of symbols that gets printed +out at end of assembly is a lie. For example during assembly of an +ITS verson of MIDAS, the # syms as returned by A.SYMC was 3558 upon +calling PSYMS to punch out the symbols, and 4787 afterwards; apparently +the symbol table compaction/sorting done for SBLK and DECSAV formats +leaves some cruft around. I noticed this when the # syms reported +for various programs suddenly jumped when I began assembling with +DECSAV format. + It's not a crucial bug but can easily be fixed sometime. +It would probably be nice also to print out the # o symbols actually +punched out; for absolute assemblies this is trivial, for relocatable +ones slightly harder I think. + + +EAK@MIT-MC 07/18/78 22:35:48 Re: MIDAS .SAV output +To: KLH at MIT-MC +Perhaps instead of having lots of pseudos like .DECSAV you want +one pseudo that takes an argument saying which format to use? + + +KLH@MIT-AI 07/18/78 20:20:22 Re: PDUMP, DMP files etc +To: RMS at MIT-AI, MRC at MIT-AI, eak at MIT-MC +CC: KLH at MIT-AI +Of course, if anyone really wanted MIDAS to produce PDUMP or +sharable 10X/20X files it won't be too hard. All that is +necessary is a page mapped into an inferior process which +you then deposit into, changing the mapping as necessary, +and finally wrapping it up with a PDUMP (or SAVE) call, making it +unnecessary to know very much about sharable file format. EAK +has suggested that it could evven be purified with suitable macros +before PDUMPing. + I wonder if this would be any faster than current output scheme, +probably insignificant. Can think of a nmber of more useful things to +do anyway. + I doubt if producing a DMP file for SAIL will ever be reasonable, +likewise SHR fils for T10, because you can't have an inferior address +space to deposit into (unless you do strange things with random +access writes to a file). + The .DECSAV format writes out to .SAV on T10 and 10X, .EXE on 20X, +and should be runnable on all - but not sharable of course. In +this respect it is just like ITS where you have to e.g. do a PURIFY$G +and then :PDUMP it back out. One other thing about it is that it +eliminates the space taken up by intermediate .REL files, which isn't +trivial for large programs and tight quotas (grumble grumble). + Incidentally does anyone happen to know why it turns out that +ITS and DEC symbol table formats are so different - apart from the +fact that DEC right-justifies its SQUOZE, the structuring of symbols +for blocks is almost exactly the reverse of ITS's (I think). There +are also a couple f minor inconsistencies with respect to program names +and block names. I wonder where this all started. + +RMS@MIT-AI 07/17/78 22:55:23 +To: KLH at MIT-AI +I am surprised that you are working on .DECSAV. +I do not think it should be the default. +I certainly don't think that the meaning of +any of the mode-selecting pseudos should depend +on the system you are using. It is just as easy +for people to say .DECREL as it is to say RELOCATABLE. + +Date: 17 Jul 1978 1956-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: MIDAS SAV stuff +To: KLH at MIT-AI, RMS at MIT-AI, MMCM at MIT-AI +To: DANG at MIT-DMS, HIC at MIT-MC, EAK at MIT-MC + + ... +Absolute assemblies should select .DECSAV; relocatable ones should +select .DECREL. + ... +------- + +RMS@MIT-AI 07/17/78 23:05:39 +To: KLH at MIT-AI +By the way, there are several things in my RMAIL file from +you and other people about MIDAS, if you are in the mood to +hack it. One thing that might be doable would be labels +inside literals, by making them save up some sort of reminder +to define the symbol later when the location of the literal is +chosen. Because it can legitimately happen that literals +which are distinct on pass1 collapse on pass 2, it would be +necessary to detect on pass 2 that the literal contained +a label, and advance the location counter if necessary to +make the label match up with its pass 1 value. If you had +to decrement the location counter, that would be an error,: +since that shouldn't ever be necessary, and if it were necessary +it could cause lossage as things are now. +The symbol "." will probably still have to refer to the +location outside the literal. + Date: 22 JUL 1978 0536-EDT +From: KLH at MIT-AI (Ken Harrenstien) +Subject: Sorry but... +To: TAPPAN at BBN-TENEXA +CC: (BUG MIDAS) at MIT-AI + + if you examine the info file on midas, on the third page of + the menu item "Invoke", is a chauvanistic, uncalled for, + and as it happens untrue, attack on the t(w)enex + GTJFN scheme. + +No, it's true that Twenex cannot provide this defaulting if you +try to GTJFN the filename from the terminal directly. Remember +all of these specs are on a single line and you don't have +the default for the output until after you've read the input filespec! +I didn't write that documentation, but I did write the TNX code. + +Date: 19 Jul 1978 2018-EDT +From: TAPPAN at BBN-TENEXA (dan tappan) +Subject: a slight idea +To: klh at AI +cc: bug-midas at AI + + -- Messages from file: [BBN-TENEXA]MAIL.TXT.1 + -- Wednesday, July 19, 1978 13:35:14 -- + +Mail from MIT-MC rcvd at 19-Jul-78 0414-EDT +KLH@MIT-AI 07/19/78 04:14:20 +To: TRAPR at MIT-MC +CC: (BUG MIDAS) at MIT-AI + + TRAPR@MIT-MC 07/18/78 23:28:26 + To: (BUG MIDAS) at MIT-MC + just a note to whoever wrote the info file, twenex can default + whatever you like (assuming you write the program right) + +I am reasonably sure that none of us understands in the slightest what +you are talking about... at least I don't. + + +___________ + +if you examine the info file on midas, on the third page of +the menu item "Invoke", is a chauvanistic, uncalled for, +and as it happens untrue, attack on the t(w)enex +GTJFN scheme. this really isn't something that belongs +in a self-respecting documentation file. +(in sending this as a bug i've been assuming that +documentation is written by someone who knows something +about the program, i.e. a maintainer. if in actuality +there's someone out there writing documentation +with no such connection then i apologize for bothering +you with it) + +dan +------- + +KLH@MIT-AI 07/19/78 04:14:20 +To: TRAPR at MIT-MC +CC: (BUG MIDAS) at MIT-AI + + TRAPR@MIT-MC 07/18/78 23:28:26 + To: (BUG MIDAS) at MIT-MC + just a note to whoever wrote the info file, twenex can default + whatever you like (assuming you write the program right) + +I am reasonably sure that none of us understands in the slightest what +you are talking about... at least I don't. + +TRAPR@MIT-MC 07/18/78 23:28:26 +To: (BUG MIDAS) at MIT-MC +just a note to whoever wrote the info file, twenex can default +whatever you like (assuming you write the program right) + + +---------------------------------------------------------------- +Messages about MIDAS bugs from RMS' mail. + +EAK@MIT-MC 07/10/78 23:14:42 +To: (BUG MIDAS) at MIT-MC +Why does IFNDEF 0 succeed? I would think that no.s would always be +"defined". This was a screw when I used it in a macro which did +something like: + .TTYMAC F + IFNDEF F,[ ... ] + FLAG==F + TERMIN +etc. + + +Date: 16 Aug 1977 0505-PDT +From: MRC at SU-AI (Mark Crispin) +Subject: Bug MIDAS +To: RMS at MIT-AI + +MIDAS treats grave accent (`) as question mark, ie, it says new word. I +accidently typed ` when I meant ' and got no message, and in general was +screwed. + +------- + +DATE: 3 APR 1977 1121-EST +FROM: AS at MIT-DMS +SUBJECT: FEATURE MIDAS +ACTION-TO: (FEATURE MIDAS) at MIT-DMS +MESSAGE-ID: <[MIT-DMS].49455> + +I would like a way to make IRP not strip off [] brackets +around elements of a list. Is there an easy way to do +this? Perhaps, one should be able to write + + IRP [D],,[1,[2,3],4] + +where the [D] guides the scan, as for real macro dummy +arguments, so that D gets bound to "1", "[2,3]", and "4". + + +Moon@MIT-AI (DLW) 08/04/76 17:28:37 +To: BUG-MIDAS at MIT-AI +I'm not sure if this is a bug, but I think it used to work. +IRPW fails to consider tabs preceding semicolon as part of the comment, +and IRP FOO,,[] IRPs once, with FOO bound to just tab. So the effect +is that a line containing just an indented comment, being picked up +by a whole-line type macro and decommentified by IRPW, appears to +contain something and screws up the macro which is expecting to +IRP over symbols. + + + +MOON@MIT-AI 03/28/76 17:46:36 Re: Feature MIDAS +To: RMS at MIT-AI +How about IRPM: IRPM dummies:calls considers dummies a list of macro +dummies of various syntaxes and repeatedly scans calls for their values. + +Need 2 more macro dummy syntaxes: SYLLABLE and SINGLE CHARACTER. +SYLLABLE should re-read its terminator. + diff --git a/doc/midas/midas.macro b/doc/midas/midas.macro new file mode 100755 index 00000000..2af03d6b --- /dev/null +++ b/doc/midas/midas.macro @@ -0,0 +1,4398 @@ +-*-Text-*- + +MIDAS Node: Top, Up: (DIR), Next: Invoke + +Overview of MIDAS + + MIDAS is a PDP-10 assembler. It takes as its input an ASCII file, +and produces a binary file in any of several formats (*Note Out: Output.) + +NOTE: Numbers used in this document are assumed to be octal, unless +followed by a "." in which case they are decimal. E.G. 12 = 10. = ten. + +* Menu: + +* Invoke:: How to invoke MIDAS. Commands strings. +* Switches:: MIDAS command string switches. +* Interrupts:: Terminal Interrupt Characters. +* Basic:: Introduction to MIDAS input syntax. +* Example:: Simple example of MIDAS code. +* Frame:: The beginning and end of a MIDAS program. +* Words:: Syntax of the "Word" -- the fundamental MIDAS construct. +* Fields:: Words are made up of fields, which are made of syllables. +* Syllables:: A syllable is a number, symbol, etc. +* LocnCtr:: The "location counter" is used to assign storage locations + to the words which MIDAS assembled. +* Output:: Output formats. +* Relocation:: Relocatable assemblies. +* Symbols:: Defining symbols. +* DDT:: Communicating to DDT. +* Numbers:: Hairy ways of writing numbers. +* LIterals:: Generating constants in memory where you want to use them. +* BYtes:: Pseudos for working with bytes and byte pointers. +* FIleinfo:: How filenames can be accessed at assembly time. +* Terminal:: Typing on the terminal. Reading from the terminal. +* Macros:: MIDAS macros: definition and use. +* LOOps:: Assembly-time iterations for use with macros. +* Cond:: Assembly conditionals. +* Arithmetic:: .I and .F: the "arithmetic assignment" statements. +* FASL:: Assembling code to be loaded by MacLisp. +* Blocks:: Symbol table block structure. +* Constructs:: Alphabetical index of constructs (special characters). +* Pseudos:: Alphabetical index of pseudo-ops. +* LIB: (LIB) The subroutine libraries for MIDAS programs. +* Outformats:: More obscure details about output formats (RIM, etc) +* Changes: (MIDAS ARCHIV)* MIDAS changes in chronological order. + + +MIDAS Node: Invoke, Up: Top, Previous: Top, Next: Switches + +MIDAS Command Strings + + Once you have run the program MIDAS, it will ask for a command line +on which you must specify the names of the input and output files. In +addition to the filenames, the command line usually contains switches. +*Note Switches: Switches. + + MIDAS can write four output files for each assembly: a binary +output file, an error file containing whatever would normally appear on the +terminal, a listing file, and a cross-reference table file. The +cross-reference table file (a compact binary file, not a DEC cref listing) +is not really useful now that the @ program exists (*Note @: (@)Top.). +The listing output file is also inferior to an @ listing, but it is +sometimes useful for debugging hairy macros. To facilitate this use, it is +possible to ask for a listing of both passes (some macros cause fatal +errors on the first pass). The binary output file is essential; an error +output file is also very useful as a permanent record of the assembly +errors. + + Normally, one specifies either just the input file or the input +file and the binary output file. The error output file name is allowed to +default from them. MIDAS tries hard to default all filename components so +as to minimize your type-in. Not specifying the binary file name is +equivalent to letting each component of the name default based on the input +file name. + + Defaulting in MIDAS works bidirectionally; the input file name can +default from the binary file name, and the binary file name can default +from the input file name. This is actually useful. Note how the Twenex +GTJFN-from-the-terminal scheme of things cannot provide this! + + The binary file's device defaults to DSK. The directory defaults +to your working directory. The second filename defaults based on the type +of output format used: BIN for SBLK files, FASL for FASL output files, or +REL for relocatable output files. The first filename defaults to the input +files's first filename. One exception: if TTY: is specified as the input +file, and the binary file name is not specified, no binary file is made. + + The input file's device and directory default to those of the +binary file. The second filename defaults to ">" for ITS and "MID" on DEC +systems. The first filename defaults to that of the binary file. If +no first filename is specified for either file, the default is "PROG". +This becomes relevant sometimes when TTY: is specified as the input device. +Exception: if the binary file was on device PTP or NUL, the default is DSK. + + These defaulting rules make common things very convenient. +To assemble a file FOO;BAR > onto the same directory, you can use + + FOO;BAR_ + +letting the input file names default. To assemble it onto your directory, +just say + + FOO;BAR + +letting the binary file names default. + +* Menu: + +* Switches:: Command line switches. +* Interrupts:: Terminal interrupt characters. + +MIDAS Node: Switches, Previous: Invoke, Up: Top, Next: Interrupts + +Switches: + + Switches should be enclosed in parentheses or preceded by slashes, +and may go anywhere in the command string. The effects of a switch in no +way depend on where it appears, although it should not appear in the middle +of a file name as that may confuse the filename parser. Any number of +switches may be enclosed by one pair of parentheses, as in (ET) which is +equivalent to (E)(T) or /E/T. Each slash is good for just one switch. +It is sometimes significant whether a switch occurs once or twice: (TT) is +not the same as (T). + +/C Produce a CREF file. +/E Produce an error output file. +/L Produce a listing. +(LL) List on 1st pass as well as 2nd. +/T Read assembly input from the terminal after the TITLE + statement, on pass 1. You can type in parameter assignments + to control conditional assembly. +(TT) Read from the terminal on both passes. +/W Do not print on the terminal. + This implies the (E) switch, so your errors are not lost. + /W works by setting the .TTYFLG variable initially to 1. + +MIDAS Node: Interrupts, Previous: Switches, Up: Top, Next: Basic + +Terminal Interrupt Characters. + +In the ITS and Twenex (I believe) versions, the characters ^H, ^V and ^W +have an instantaneous effect if typed on the terminal while MIDAS is +running. + +^H Causes an error message "^H-BREAK" + (which says where the assembly has reached) + followed by the .INSRTion of TTY:. + Thus, this is a sort of "break-loop" you can use + to debug runaway macros. To exit, cause an end-of-file + on the terminal input. + +^V Decrements .TTYFLG. + Since type-out on the terminal happens only when .TTYFLG is + negative or zero, this undoes the effect of one ^W. + (some very bad errors that .INSRT TTY: + also zero .TTYFLG before typing an error message.) + +^W Increments .TTYFLG, suppressing terminal type-out. + It is not wise to do this if you don't have an error + output file (since after the assembly has been started + it is too late to start writing one). + + +In the Bottoms-10 version, you can get a ^H-break by typing +^C and then Reenter. + +MIDAS Node: Basic, Previous: Interrupts, Up: Top, Next: Example + +Machine Instructions in MIDAS + + The main body of a MIDAS program is composed primarily of machine +instructions -- just as you would expect. + + The PDP-10 machine language instruction breaks down into five +fields of bits: a nine bit opcode field, a four bit accumulator (AC) field, +a one bit indirect field, a four bit index register field, and an 18 bit +memory address field. The instruction set is documented very clearly in +the "DecSystem-10 System Reference Manual" (DEC-10-HGAC-D, and the later +versions), which is published by the manufacturer, Digital Equiptment Corp. +("DecSystem-10" is a pretentious salesman's name for the PDP-10). + + In MIDAS, the fundamental syntactic construct is the word. Its +components parallel the fields of a machine instruction, but it is flexible +enough to be used for all other purposes as well. This is because the +subunits or "fields" which compose a word are simply added together, into +parts of the 36-bit word determined by the pattern of spaces and commas +that separate them. Every word of data assembled into the binary program +is written in MIDAS as a syntactical word of some sort or other, with the +sole exception of multi-word text strings. *Note Words: Words, for full +details. + + Words are terminated and separated by the "line terminators", which +are Return, Linefeed, and "?". Return and Linefeed should always be used +together, to prevent confusion when editing the program. Strictly +speaking, Return Linefeed contains a blank line, but blank lines are +ignored anyway. + + The value of the words that appear in a MIDAS program become the +words of the binary program output. Each word is assembled at the +address specified by the MIDAS "location counter", which increments by one +after each word to put consecutive words in consecutive locations. This is +called "assembling a storage word". The ultimate goal of assembling a +program is to assemble storage words, but word quantities can appear in +other contexts such as to be passed as arguments to functions. Before +each word in the MIDAS input, at the beginning of the line, there may be +one or more "labels", which are symbols which are defined to equal the +current value of the location counter. Thus, a label preceding a word is +defined to be the address of that word. *Note LocnCtr: LocnCtr. + + The other most important constituent of a MIDAS program is the +comment. A comment starts with a semicolon ";" and ends with the following +Return. The whole thing is equivalent to a single Return. Another way to +think of it is that you can put a comment at the end of any line in the +file; but "lines" terminated by the "?" character do not count. + + A few other MIDAS constructs may appear in place of a word. One is +the parameter assignment, which defines a symbol with an explicitly +specified value at assembly time. *Note Assign: Symbols. Another is the +"Statement". Everything that must be specified in a MIDAS program aside +from the contents of words to be loaded and the values of symbols is +specified by means of statements. A statement begins with a symbol which +is the name of a "pseudo-op"; it is a sort of escape which directs MIDAS +to perform some special function. Some pseudo-ops read arguments. The +syntax of the arguments depends on which pseudo-op it is. An example of a +statement is the END statement, which must appear at the end of every +program. It starts with the symbol END. After that comes the program's +starting address, which is syntactically a word (and thus, terminated by a +"?" or Return or Linefeed). If a Return immediately follows the symbol +END, then there is no argument (and no starting address). + + The separation into lines should not be thought of as a +hard-and-fast rule. The "line-separating" characters USUALLY have that +effect, but in some contexts (such as text-string constants) they may have +NO special effect. and "?" are both "line-separators", but in a +semicolon-comment they do not act the same: a ends the comment, but a +"?" is ignored as "part" of the comment. Semicolon usually starts a +comment, but not inside a text string. Thus, + + MOVE A,B ;COMMENT ? MOVE C,D + +assembles only a single instruction. The moral is that the meaning of a +character depends on its context, which depends on the characters IN FRONT +of it. MIDAS does not work by BNF-like grammatical rules ("a MUMBLE can be +either a FOO or three BARs in a row") although a few constructs can be +approximated by them. It works like a finite-state machine: "In the normal +input-reading state, if a is read, terminate the line and process it; +if a question-mark is read, terminate the line and process it; if a +semicolon is read, enter the comment-reading state. In the comment-reading +state, if anything but a is read, ignore it; if a is read, return +to the normal input-reading state and terminate the line and process it." + +MIDAS Node: Example, Previous: Basic, Up: Top, Next: Frame + +Simple examples of MIDAS code + + MOVE C,COUNTA + TLNE B,100 + SETZ C, + JUMPGE A,@DISTAB(B) + JRST LABEL1 + +Each of these lines will generate one storage word in the output. +The first line will generate a MOVE instruction that will load the +contents of memory location COUNTA into accumulator C. This is accomplished +by putting the value of the symbol C in the instruction's AC field, +and the value of the symbol COUNTA in the address field, and then adding +the value of the symbol MOVE (which supplies the appropriate value in the +op-code field). The second line is similar, except that the address field +is specified by the octal number 100 instead of a symbol. That is a +common thing to do with instructions like TLNE which use the address +as a bit-mask. The third line is a SETZ instruction. The address field +has been omitted, because the SETZ instruction ignores its address. +In fact, the address field will be assembled as zero. The SETZ has been +indented one space as a note to humans that the preceding TLNE instruction +can skip over it. The fourth line +is a JUMPGE instruction which demonstrates indexing and indirect addressing. +The "@" turns on the instruction's indirect-bit, selecting indirect +addressing. The "(B)" puts B's value in the index field. Presumably, +B is the number of an accumulator which is to be used as an index register. +The fifth line shows a JRST instruction, for which it is not necessary +to specify an accumulator. In fact, the accumulator field of the instruction +will be assembled as zero; but instructions that actually use accumulator +zero should say so explicitly. + So in the simple cases, MIDAS agrees with the format used in the +"DecSystem-10 System Reference Manual." + +MIDAS Node: Frame, Previous: Example, Up: Top, Next: Words + +The Framework of Every MIDAS Program + + A MIDAS program consists primarily of PDP-10 instructions and +data, together with labels and comments. But other things are usually +or always needed at the beginning and end of the program. + + The first thing in every MIDAS program (or every subfile of +one, for that matter) is a line containing ";-*-MIDAS-*-" to tell +EMACS how the file is to be edited. + + The second thing in a MIDAS program, which is not actually +needed for small programs, is a .SYMTAB statement which says how large +a symbol table is required. The argument to .SYMTAB is the desired +number of entries in the symbol table. This must include the +predefined symbols, the user-defined symbols, and some extra to make +hashing efficient. It should also be prime. To help you set up your +.SYMTAB, MIDAS prints the symbol table size and the number of entries +used at the end of the assembly. + + Next, in every MIDAS program, should come the TITLE statement, +which consists of TITLE followed by a line of text, and performs these +functions: +1) for relocatable assemblies, the first symbol following TITLE +becomes the name of the relocatable program being assembled; +2) the text following TITLE is printed on the terminal on each pass. +3) when the /T switch is used to request input from the terminal, +this input is read when the TITLE statement is reached. +Because of 3), it is sometimes useful to define a few symbols before +the TITLE statement so that they can be used when giving input on the +terminal. If there is no TITLE statement, /T won't do anything! + + After the TITLE statement, you should define names for the +accumulators. Single letters starting with A=1 are best. Accumulator +0 should also have a name, but not in sequence with 1, since 0 can +only be used for special purposes. But don't ever write an +instruction which actually USES accumulator 0 without putting in the +name of that accumulator. The stack pointer should be in accumulator +17, which should be named P. Putting the accumulator definitions on +page 1 will produce the best results in @ listings. + + After this point, you are on your own. But at the end of the +program, you need an END statement. The END statement consists of END +followed by the starting address of the program (this is an old assembler +tradition). You can omit the starting address if you don't want your +program to have one (in a relocatable program, this is often the case). If +you don't have an END statement, you get an error. This catches many +errors in assembly conditionals and macro definitions which cause the +END statement not to be recognized as such. Any text which follows the END +statement will be ignored completely by MIDAS. + +MIDAS Node: Words, Previous: Frame, Up: Top, Next: Fields + +Words, and Their Syntax + + The "word" is the most commonly used MIDAS construct, as a storage +word to be assembled must be, syntactically, a word, and an ordinary PDP-10 +instruction is an example of a word. However, the word construct includes +other things than instructions, and is used in other contexts besides that +of storage words. This section of the manual describes how to put a WORD +together. The concept of a WORD is tied closely to those of SYLLABLES and +FIELDS, out of which WORDS are made. Loosely, a syllable is a number or +symbol, and a field is an arithmetic expression. Words are made up of +fields, and fields are made up of syllables. Do not confuse a MIDAS field +with a "field" of bits in a PDP-10 machine language word. + + A word is one or more fields connected by field separators, with +optionally an indirect bit or index field anywhere among them. There +are two field separators, space (or horizontal tab) and comma. (Space and +horizontal tab are identical and will both be referred to as space.) To +improve readability, spaces before and after a word and spaces adjacent to +a comma are ignored, and more than one space in a row are treated as one. + The values of the fields are combined to form the values of the +word according to the number of fields and the pattern of separators. These +formats are described in the following table, in which A, B, and C are +fields. "TR(x)" is used to represent the result of truncating x to 18. bits. + + +pattern format # value + in octal +====== ======= ===== + +,,C 13 TR(C) +,B 14 TR(B) +,B C 15 unassigned +,B, 16 unassigned +,B,C 17 unassigned +A 20 A + 21,22,23 not possible +A B 24 A++TR(B) +A B C 25 A++TR(B)++TR(C) +A B, 26 A+<_23.> +A B,C 27 A+<_23.>++TR(C) +A, 30 A + 31 not possible +A,, 32 _18. +A,,C 33 _18.+TR(C) +A,B 34 A++TR(B) +A,B C 35 unassigned +A,B, 36 unassigned +A,B,C 37 unassigned + + Here are some examples of what these formats are most useful for: + +A B,C This is the normal instruction format, e.g., CAMN A,FOO +A B This is good for instructions with no accumulator field, + e.g., JRST BAR +A B, and this is for instructions with no address field, e.g., + SETZ D, +A,,C This is the standard way to specify the contents of a + storage word by half-words, e.g., + BLETCH: -PDL,,PDB + +NOTES: + +1) "+" means normal 36-bit addition, but "++" addition is special in +that carry from bit 18 to bit 17 is suppressed. In other words, when the +user specifies a field which is supposed to be a right half-word field, he +can normally rest assured that his quantity didn't carry over into the left +half. + +2) A word may have more than three fields. In that case, the +fourth and following fields are added in with the third field. Thus, +if the third field is truncated to 18. bits and added in, so are the +following fields. Only spaces may be used for separating fields after +the third field; a comma after the third field is an error, but will +be treated as a space. Commas are flagged so as to catch places where +the accidental omission of a has run two lines together. + +4) The user can redefine these formats by using the .FORMAT pseudo-op. +That is what the "Format number" of a format is used for, and the pseudo +is documented here: +.FORMA fno,fval + Inserts an entry in the format table (ie replaces old entry) for +format number "fno". The numeric value of field fval is taken as three +12-bit bytes referring to the (up to) three distinctly handled fields in a +word: the left 12 bits refer to the rightmost field, the middle 12 bits to +the field next to the rightmost (if any) and the right 12 bits to the field +2 from the right and any additional fields. (If there is only one field in +a given format it is the rightmost regardless of punctuation which may be +required after it.) + A 12-bit byte describing a particular field is in turn treated as +two 6-bit bytes. The right 6-bit byte specifies a mask and the left 6-bit +byte specifies a shift. The mask number (say M) directs that only the +right M bits of the field value be taken. The shift number (say S) directs +that the bits remaining after masking be shifted left S bits. The fields, +after this masking and shifting are added to give the value of the word. +(Example: the 12-bit specification 2704 describes an accumulator field: +_23.) + There are three exceptions to the above procedure. (1) If a field +is specified as 0022 (right half, not shifted) the carry out of bit 18 is +suppressed as the field is added into the word. (2) A virtual quantity may +only occur in a field specified 0044, 0022, 2222, 0504, or 2704. (3) If as +a syllable in the leftmost field of a word appears any of the eight I/O +instructions (DATAO, DATAI, CONO, CONI, BLKO, BLKI, CONSZ, CONSO) then any +field in that word specified 2704 is instead taken as if specified 3211 +(I/O device field) + + + In addition to the fields and separators that make up a word, there +can be an indirect bit and an index field. These subconstructs resemble +the fields of the word in that their values are merged into the value of +the word. They differ from the fields in that they are marked out by their +own special syntax, and are interpreted in the same way no matter where in +the word they appear (unlike fields, which are all the same and are +interpreted according to their position in sequence). + + a. The Indirect bit + + The character @ (atsign) is a special character. It may occur +anywhere inside a word. Whenever MIDAS encounters an @ inside a word, a 1 +is ORed into bit 22. of the word, i.e., the indirect bit. The @ does not +terminate syllables or fields, nor is it taken as part of a syllable or +field. + Its position in the word is totally irrelevant. However, the +normal convention is to put it in front of the field specifying the right +half of the word (the address) if there is one; if not, put the @ where the +address would go. + + b. The Index field + + To get a certain quantity into the index field, the easy, convntional +way is to use a bracketed word of the parentheses type. For example, + MOVE A,FOO(D) +will put the value of D into the storage word's index field. As explained +in section C.2.d, the parenthesis bracketed word works in its strange way +because the index field of the machine word is the lowest four bits in the +left halfword. + The index field, used this way, may appear anywhere in the word +except in the middle of a syllable or following an arithmetic operator, but +the normal convention is to put it at the end of the field specifying the +right half of the word (the address) if there is one. When "(" appears +following an arithmetic operator, it signifies a type of bracketed word, +rather than an index field. + +MIDAS Node: Fields, Previous: Words, Up: Top, Next: Syllables + +Fields + + A "field" in MIDAS is essentially an arithmetic expression. A +field may be either a single syllable, or two or more syllables combined +arithmetic operators. Many MIDAS pseudo-ops take arguments that are +syntactically fields. These are the arithmetic operators, in their order +by priority: + + char. operator + ===== ======== +highest _ left shift 1st operand by # of bits specified by 2nd + operand. (Negative 2nd operand shifts right) + & bitwise AND + # bitwise XOR + \ bitwise OR + * and / 36. bit integer multiplication and subtraction +lowest + and - 36. bit integer addition and subtraction + + + Thus all _'s are done first, then &'s, then #'s, then \'s, then *'s +and /'s, and finally +'s and -'s. Operators of the same priority will be +performed in left-to-right order. Examples: (assuming that A, B and FOO +are numerically defined symbols with the values 1, 2, and 53 respectively.) + + Field Value + ===== ===== + 3+4 7 + 1+4&FOO+1 2 + 1+4& 5 + + The first example is rather trivial. The second and third +demonstrate the use of angle brackets as algebraic parentheses (actually, +part of the syntax of syllables). In the second, 4 is anded with FOO, +giving zero, then 1+0+1 equals 2. In the third example, first FOO is added +to 1, giving 54. Then 54&4 gives 4, and then the 4 is added to the 1, +giving 5. + + Note that there may NOT be spaces within a field; so "4 * 5" is +not the same as "4*5". + +MIDAS Node: Syllables, Previous: Fields, Up: Top, Next: LocnCtr + +Syllables + + There are several types of MIDAS syllables. A symbol may be a +NUMBER, a NUMERICALLY DEFINED SYMBOL, a QUOTED CHARACTER, a BRACKETED WORD, +or a call to a PSEUDO-OP (but see *Note MACROS:macros) +(Note: only "value-returning" pseudo-ops can be used to make syllables. +Other pseudo-ops will either be ignored by the process of building words +and fields out of syllables (except for their side effects), or illegal to +be used except alone on a line). + + Each syllable has a value, which is a 36.-bit quantity. + + a. NUMBERS + + The simplest form of number is an octal integer, which is just a +string of digits. Following them with a "." makes it a decimal integer +instead. + + *Note Numbers: Numbers, for other sorts of numbers, which you won't +need very often. + + + b. SYMBOLS + + A symbol is a string of SQUOZE characters which is not a +number. More precisely, it is a string of characters from the +SQUOZE character set of length 1 or greater which contains at +least one letter, or at least one % (percent) or $ (dollarsign), +or at least two .'s (periods). The SQUOZE set includes all 26. +letters, all 10. digits, and the characters $ (dollar sign), % +(percent sign), and "." (period). (Note that the symbol "." (a +single period) is special; *Note LocnCtr: LocnCtr.). + + Here are some examples of symbols: + + LOC3 + GOHERE + $END + A%LOCATION + 35X + 1.2.3 + .$Z%.G + +(The last example is NOT considered an example of good programming style.) +A symbol has no length restriction, but MIDAS only looks at the first six +characters, so the symbols THISLOCN and THISLO, for example, are +effectively identical. + + MIDAS symbols can have several sorts of definitions. The symbols +that can appear as syllables are those with numeric definitions (other +sorts of symbols might appear at the same places, but they would be +interpreted differently and would constitute different constructs). MIDAS +provides many predefined numeric symbols (including all the PDP-10 +instructions, and others specific to the operating system), and programmer +can define others (*Note Define: Symbols.). + + An example of numerically defined symbols: +In the word MOVE B,FOO , there are three symbols: MOVE, B, and FOO. +The symbol MOVE is predefined; the other two must be defined by the +programmer. + + c. Quoted Characters: + + A quoted character starts with any one of the characters ' (single +quote), " (double quote), or ^ (uparrow) followed by a character. The +quote or uparrow and the character following are taken as a syllable. A ' +followed by a character has the value of the SIXBIT representation of the +character. A " followed by a character has as its value the ASCII +representation of the character. ^ works the same way as " except that the +ASCII value is ANDed with 77 octal; that is, only the low six bits are +kept. ^ is used for generating the ASCII code for "control" characters. + Examples of quoted characters: + + Syllable Value + ======== ===== + + 'A 41 octal + "+ 53 octal + ^C 3 octal + + d. Bracketed words: + + A word surrounded by ( ) (parentheses), < > (angle brackets), or [ +] (square brackets) is a syllable called a BRACKETED WORD. Each works in +its own way: + + is simply a syllable whose value is that of the word between the + brackets. Angle brackets act much like algebra's parentheses, + and are usually used that way. + +(word) works two different ways. If the preceeding character is an + arithmetic operator, the value of the word has its halves swapped, + and this becomes the value of the syllable, on which the arithmetic + operator acts. If the preceeding character is not an arithmetic + operation, the value of the word is swapped and saved, and at the + end of the outer word, it is added into the word being formed. + This quirk is so that (5) stuck at most places in a word will put 5 + in the index field. + +[word] is a LITERAL, or CONSTANT. *Note Literals: Literals. The value of + the syllable is the location where MIDAS put the literal. + + It is hard to give examples of ( ) and < > until some further +concepts have been introduced, so these have been delayed. + + e. Pseudo-ops which return a value: + + Pseudo-ops are instruction given by the programmer to MIDAS in the +input ASCII file about how to assemble various things. They are described +in section E, "Pseudo-ops that every programmer needs," and in the section +on pseudo-ops. + They are the "built-in functions" of the MIDAS assembly-time +programming language. Some pseudo-ops are used for their side-effects; +some, to compute values. Calls to value-returning pseudo-ops constitute +syllables, whose value, of course, is the value returned by the pseudo-op. + +MIDAS Node: LocnCtr, Previous: Syllables, Up: Top, Next: Output + +The Location Counter + + Normally, when MIDAS finishes reading a Word at top level in the +input file, the value of that word is assembled into the binary program +output. The place where it will be loaded is specified by the location +counter, which is normally an 18.-bit number. After assembling each such +word, MIDAS increments the location counter. + + The value of location counter is explicitly available as the value +of the symbol ".". It refers to the address of the current word, not the +following one. A label defines a symbol to equal the current value of ".". + + The location counter can be set with a LOC statement, or by +assigning a value to the symbol "." (*Note .=: Symbols, for how to do +that). These have slightly different effects when an offset is in effect. +In a relocatable program, the location counter can be set to a relocatable +value or to an absolute value. + + The usual way to leave space for non-constant data in a program is +the BLOCK statement. + + BLOCK 200 + +leaves 200 words of space, by incrementing the location counter by 200 . +It is an error to ask for a block of negative length. + + In relocatable assemblies, the location counter starts out at +relocatable zero. In absolute assemblies, it starts out at absolute 100 +octal. + + Sometimes it is necessary to assemble code at one location and copy +it to another before using it. When that is done, all references to labels +in the code (whether from within it or outside it) should be arranged so as +to be correct when the code has been moved to its ultimate position. This +can be done by defining an offset. The statement + + OFFSET 200 + +causes all references to the location counter -- the symbol ".", labels, +etc. -- to add 200 to the real value of the location counter. If the code +being assembled is moved 200 words upward, it will be at the addresses at +which the program will refer to it. + + Offsets do not affect the actual location counter, which is the +place at which code will actually be loaded. They affect the value of the +location counter as seen by references to it from within the program. +The difference between LOC and assigning a value to "." is that LOC sets +the real location counter, whereas assigning "." sets the value of ".": +that is, it subtracts the offset and then sets the real location counter, +so that when the offset is added in again to get the value of "." it will +equal the value assigned. + + An offset can be cancelled by setting the offset to zero. + + A frequent use of the offset is for error checking. If there are a +series of symbols FOO, BAR, QUUX ... with values 0, 1, 2 ... intended to be +the values of a particular table index, with MAX being 1 larger than the +largest legal index, the table can be defined with + + TABLE: OFFSET -. + FOO:: + BAR::
+ QUUX::
, and the format of the +SBLK file symbol table in .INFO.;DDTORD >. + +MIDAS Node: Relocation, Previous: Output, Up: Top, Next: Symbols + +Relocatable Assemblies. Specifying the Type of Output. + + Like MACRO-10, MIDAS is capable of making both relocatable and +absolute assemblies. The type of assembly is controlled by pseudos +appearing in the program, with a default which varies with the operating +system. In an absolute assembly, all location counter values (and all +expression values, in fact) are completely known at assembly time, or else +are undefined. In a relocatable assembly, while some location counter +values and expression values may be known at assembly time, most depend on +an unknown relocation which will be determined only by the linking loader. +The location counter value is likely to be a known quantity plus the +unknown relocation. Symbol values can also have that form (and will, when +the symbol is defined as a label when the location counter has that form). +Expression values can take the form of a known quantity plus any number +times the relocation that number being the "relocation factor". Values +completely known at assembly time are called "absolute", and have a +relocation factor of 0. Simply relocatable quantities, such as typical +location counter values, have relocation factors of 1. MIDAS can handle +higher or negative relocation factors internally but cannot write them into +the output file except in STINK format output. + + Whether an assembly is absolute or relocatable is tied closely to +what output format is used. The formats that exist are + + SBLK Standard ITS absolute format. + This is the default on ITS. + RELOCATABLE STINK format (relocatable). + Used only on ITS, and not much. + .DECREL Standard DEC relocatable, for LINK10. + This is the default on non-ITS systems. + .DECTWO Standard DEC two-segment relocatable. + is the segment boundary, usually 400000 . + .DECSAV Standard DEC SAV file format. Absolute. + .FASL MACLISP FASL file format. Relocatable. + RIM Read-In Mode format for PDP-6. Absolute. + RIM10 Read-In Mode format for PDP-10. Absolute. + + The names of the formats are all pseudo-ops which you can put in +the program to specify those formats. If the format you want is the +default for your particular system, you don't need to specify it, but if +you can anticipate that your program will be assembled on other systems it +might be wise to do so anyway. + + A few functions are available for manipulation of relocatable +quantities. These include .ABSP, .RELP, and .RL1. .ABSP and .RELP return +the absolute and relocatable parts of a quantity (the relocatable part is +the relocation factor. .RL1 is a symbol whose value is a pure +relocatability of 1; that is, a relocatable zero. You can think of these +as analogous to the the complex number functions Re, Im and the constant i. +.RELP .RL1 is nonzero if the asembly is relocatable. + +MIDAS Node: Symbols, Previous: Relocation, Up: Top, Next: DDT + +Defining Symbols + + You have already been told how to use symbols and what names they +are allowed to have. Here is how to define them. + + A symbol can have these types of definition (or none at all): +numerically defined symbols, pseudo-op names (*Note Pseudos:Pseudos.), and +macroinstruction names (*Note Macros: Macros.). Here we are concerned only +with numerically defined symbols. New pseudo-ops cannot be defined by the +user, so the initial supply is all you get, but pseudo-op definitions can +be copied from one symbol to another using EQUALS. + + There are basically two ways to define a symbol numerically: as a +LABEL, and as a PARAMETER. + + 1. Labels. + + The primary use of symbols is to hold the address of an instruction +or variable in the program. MIDAS has a special construct, the LABEL, for +defining such symbols. A label is simply a symbol followed by a colon, and it +can appear at the beginning of any line. Its effect is to give the +symbol a value equal to the address where the next storage word will go. +A line can have several labels in it, but a label may not appear after +any other construct has begun. A label may be followed by anything at all, +or it may be the only thing on its line. An example is: + + FOO: MOVE A,TABLE(C) + +which assembles a storage word containing a MOVE instruction, and +also defines FOO as the address of that instruction. + + If a symbol is defined as a label, it can have only one value. +If anything in the program tries to define the symbol with a different +value, either before or after the symbol's appearance as a label, an +error message will be typed. It is legal to define the symbol again +with the SAME value. In fact, that happens to every label, since it +is seen on both passes of the assembly. + + The parameter assignment "=:." has the exact same +effect as the label ":", which is allowed for convenience's sake. + + 2. Parameters. + + There are other uses of numerically defined symbols besides +their use as labels. MIDAS also allows definition of symbols by +PARAMETER ASSIGNMENT. A parameter assignment is a line of the form + = or == +which tells MIDAS to compute the value of and make that the value +of . This is similar to the "assignment" statement of most +mathematical languages, such as FORTRAN. Using the == construction +makes the symbol half-killed in DDT (this is explained in the section +on OUTPUT; for now, suffice to say that the == form is the one you +probably want to use.) Here is one of the ways to use this feature: + + Say a programmer is writing a program which knows how to handle +four FOOBAR's. If in the future he should want to modify the program +to handle five or six FOOBAR's, there might be many places where the +program would have to be changed. Now if he had made the number of +FOOBAR's an assembly parameter, by defining a symbol as in: + NFOOBR==4 +and writing all of the program to work for NFOOBR FOOBAR's +Whenever there is a table or block of data whose length must +be referred to by the program, that length should be expressed +by a numeric symbol. + + Symbol definitions actually have a static scoping or block +structure as in Algol or PL/I. *Note Blocks: Blocks. + +MIDAS Node: DDT, Previous: Symbols, Up: Top, Next: Numbers + +Communicating Information about Symbols to DDT + + One of the most important things about symbols in assembler +programs is that they are passed to DDT. MIDAS has several features +designed specifically for communicating with DDT. + + If DDT, needing to print the value 205, chose at random a symbol +whose value was close to 205, it would be likely to find several names for +bits in various registers. It is essential to have a way to tell DDT which +symbols ought to be used for such type-out. This is done by "half-killing" +the symbols which ought not to be used. + + The most common way to half-kill a symbol is to duplicate the colon +or equal sign used to define it. Thus, FOO==200 says that FOO is to be +half-killed and should never be printed out, while FOO=200 allows FOO to be +printed out. FOO:: defines FOO as a half-killed label. + + If those methods of half-killing are not convenient, the .HKILL +statement is available. .HKILL followed by a list of symbols half-kills +those symbols. If the symbol .HKALL is nonzero, then all labels defined +are half-killed. + + .KILL can be used to avoid sending a symbol to DDT at all. It is +followed by a list of symbols to kill. MIDAS does not forget the value of +a symbol when you .KILL it, so .KILL is not the same as EXPUNGE. .KILL +causes the symbol to be forgotten only when the symbol table is written +into the output file. + + The NOSYMS statement can be used to avoid outputting any symbol +table at all. + +MIDAS Node: Numbers, Previous: DDT, Up: Top, Next: Literals + +Details of the Syntax of Numbers + + A string of digits in which no digit is preceeded by a period +forms an INTEGER, a type of syllable whose value is the value of the +number interpreted in the CURRENT RADIX (octal by default, but see +*Note PSEUDO-OPS:pseudo-ops.). + +However, an integer followed by ' (single quote) is interpreted as octal, +and one followed by . (period) is interpreted as decimal, regardless of +the current radix. A string of digits with a . (period) to the left of +some digit forms a FLOATING-POINT NUMBER, interpreted in decimal. + + Either of these may be followed by a ^ (uparrow) which works +something like scientific notation. An integer may be followed by an +integer as + + A^B + + which would have the value of + + B + A*R + +where R is the radix in which A is expressed. The result is fixed-point. +A floating point number may also be followed by a ^ and an integer, as in + + X.Y^A + +which is interpreted as + + A + X.Y*10. + +that is, as scientific notation. The result is still floating-point. + + Also, any of the preceeding numeric formats may be followed by a _ +(backarrow, or underscore) and an integer, which multiplies the value by + integer + 2 + The integer is interpreted in the current radix, but may +be forced to decimal or octal by terminating it with . or ' as explained +above. The result is always a fixed-point number, even if the first number +was floating-point! + +Examples of NUMBERS: + (the current radix is taken to be octal) + + Syllable Value + ======== ===== + + 23 23 octal + 23. 27 octal + 3^3 3000 octal + 3.^3 5760 octal (3000. decimal) + 1_3 10 octal + 23_10. 46000 octal + 3.5 3.5 floating-point + 3.5^4 35000.0 floating-point + 3^3_4 60000 octal + 1.5_3 14 octal (Note: NOT floating point!) + +MIDAS Node: Literals, Previous: Numbers, Up: Top, Next: Bytes + +Literals + + Normally, when you write a machine instruction in an assembler, you +specify the memory operand by its address. Sometimes, it is desirable to +refer to "a word containing X" without worrying about where that word is +going to be stored. The LITERAL is a construct that permits just this. + + A literal consists of any number of lines enclosed in square +brackets ("[" and "]"). MIDAS assembles the lines enclosed into locations +of its own choosing. The value of the literal, where it appears, is the +address of the location chosen by MIDAS to hold the first word of the +literal. For example, + + MOVEI A,[1 ? 2 ? 3] + +would load accumulator A with the address of a three-word table whose +contents are 1, 2 and 3 in successive words. It is equivalent to + + MOVEI A,FOO1 + .... +FOO1: 1 ? 2 ? 3 + +where FOO1 is a non-existent label by which you can imagine that MIDAS +connects the usage of the literal with the location of its contents. + + Unless you request otherwise, all literals will actually appear at +the end of your program (that is, at wherever the location counter was set +when the END statement was encountered). However, you can alter this with +the pseudo-op CONSTANTS. Whenever CONSTANTS appears, all saved-up literals +will be "dumped out" or assigned locations starting at the current location +counter. CONSTANTS may appear any number of times (up to 75 or so), but +must appear the same number of times and at the same locations on both +passes. + + On pass 1, MIDAS doesn't know where a literal is going to be +located until the CONSTANTS statement is seen. On pass 2, the location of +the CONSTANTS statement is known in advance (remember, it must be the same +as on pass 1), but the location of the literal is still not known until the +end of the literal (so that recursive literals can work). For these +reasons, labels inside literals cannot work, so they are not allowed. +The symbol "." inside a literal refers to the location from which the +literal is being referred to, not the location where the literal will +appear. + + If you set the variable .LITSW nonzero, any use of a literal is an +error (until you set the symbol to zero again). + +MIDAS Node: Bytes, Previous: Literals, Up: Top, Next: FileInfo + +Manipulating Bytes and Byte Pointers. + + MIDAS provides several built-in functions for making and using byte +pointers of the form suitable for the LDB and DPB instructions. + + When you want to make a byte pointer from a given numeric position and +size, simply write the byte pointer left half as an octal constant. There +is really no way to improve on that, given that you are going to be using +numbers. For example, 440700,,FOO is suitable for ILDB'ing the ASCII +string starting at word FOO. It is common practice to define symbols for +byte pointer left halves and then use them to represent fields, as in + +ASCBP==440700 +... + MOVE A,[ASCBP,,FOO] + + A more sophisticated symbolic way of referring to fields uses the .BP +function. .BP takes as an argument a mask for a field in a word, and +returns a byte pointer to that field (in address zero). Thus, <.BP 7770> +would return 031100,,000000. When the argument to .BP is terminated with a +comma, the comma is not eaten, as it would be with most functions. +Instead, the comma turns into a space. Thus, .BP 7770,FOO returns +031100,,FOO, a byte pointer to the 7770 field in address FOO. In addition, +parentheses inside the argument to .BP are part of the argument to .BP, not +part of the word in which .BP occurs. .BP is most useful with symbolic +names for fields or bits in a word. For example, + LDB A,[.BP (%TOERS),TTYOPT] +would get into A the contents of the %TOERS bit in the left half of TTYOPT +(%TOERS being a bit symbol suitable for use in a TLNE instruction). + + The reverse of .BP is .BM. It takes a byte pointer (ignoring the +address) and produces a mask for the specified byte. The left half of a +byte pointer may be passed in the right half of the argument word. This +Is useful when you have defined a symbol for a byte pointer left half and +want the corresponding mask. Unlike .BP, .BM follows the ordinary +conventions for arguments. Example: .BM 030600 returns 770. + + Bytes can be extracted from and deposited into quantities at assembly +time using the .LDB and .DPB functions. .LDB takes a byte pointer +(ignoring the address) or a byte pointer left half in the right half, and +also a quantity as second argument. It returns the contents in that +quantity of the specified byte. .LDB 030600,1234 returns 23. +.DPB takes as arguments a byte value, a byte pointer (or left half in right +half, etc) and a quantity, and returns a new quantity made by changing the +specified byte of the old quantity to contant the byte value. For example, +.DPB 11,030600,4444 returns 4114. + + The .IBP function increments a byte pointer. It accepts a byte pointer +and returns the incremented pointer. .IBP <440700,,> returns <350700,,>. +The address supplied with the byte pointer is part of the incrementing +process; thus, .IBP <440700,,FOO> returns <350700,,FOO> and +.IBP <010700,,FOO> returns <350700,,FOO+1>. If the left half of the +argument is zero, the argument is swapped, so .IBP 440700 returns +<350700,,>. + + Two functions related two byte manipulation are .LZ and .TZ, which return +the number of leading zero bits and trailing zero bits, respectively, in +their arguments. .LZ SETZ is 0 and .TZ SETZ is <35.>. When applied to +zero, both return <36.>. + + For assembling words into memory made by packing bytes together, you +could use .DPB, but a special feature exists for this purpose, called +.BYTE. .BYTE takes a list of byte sizes, and enters a special mode in +which "words" assembled at top level are stored, not into successive whole +words, but into successive bytes of the specified sizes. The sizes are +used in the order specified, over and over cyclically. Here is an example: + +.BYTE 12.,6 + 2222 + 33 + 1111 + 44 +.BYTE + +would assemble a single word, made up of a 12. bit byte, a 6 bit byte, a +12. bit byte, and a 6 bit byte. The contents would be 222233,,111144. +Note that .BYTE with no arguments is used to return to ordinary non-byte +mode. + + Byte mode inside literals and other bracketed groupings is independent +of what is going on outside the grouping. That is, groupings always start +out in ordinary (non-byte) mode, even if byte mode was in effect outside; +byte mode may be turned on inside the grouping, but when the grouping ends +the state of byte mode will be restored to what it was before the grouping. +For example, <.BYTE 7 ? ^M ? ^J> is a quantity whose value is a CRLF in +ASCII. It is equivalent to ASCII/ +/. + + While byte mode is in effect, the location counter is a byte pointer. +Its value is such that an ILDB instruction on it would fetch the next byte +to be assembled. This is historic; it may well be that a better +convention would be that the location counter be such that a LDB would +fetch the next byte to be assembled. As it is, you must use .IBP to get +such a byte pointer. It works to set the location counter to a different +byte pointer, though it is recommended that you make the size correct. +If the byte pointer is inconvenient for you, .BYTC may be more useful. Its +value is the total number of bytes assembled since byte mode was entered. +The insides of literals and groupings do not count. + + .WALGN (word-align, not wall-generate) in byte mode advances the location +counter to the beginning of a fresh word. It does nothing in normal +non-byte mode. .BYTE with no arguments automatically does a .WALGN. + +MIDAS Node: FileInfo, Previous: Bytes, Up: Top, Next: Terminal + +Obtaining Information on Filenames at Assembly Time. + + One of the most common things one wants to do is to assemble a program's +version number into the program. This can be done, on ITS and Twenex, +using the symbol .FVERS, whose value is the version number of the main +input file, and .IFVRS, whose value is the version number of the current +input file if that file has done no .INSRTs, or the version number of the +last file .INSRTed by the current input file. + + More information is available in the variables .FNAM1 and .FNAM2, which +hold the sixbit filenames 1 and 2 of the main input file, and .IFNM1 and +.IFNM2, which hold similar information for the same file as .IFVRS. +These variables are available on Bottoms-10, where there are no version +numbers, as well as on other systems. On ITS, the version number is a +function of the filename 2, made by taking all the digits in it and +converting them using base ten to a number. + + The names of the output file (in sixbit) can be found in .OFNM1 and +.OFNM2. The version number is not available, since on ITS it does not +exist. + +MIDAS Node: Terminal, Previous: FileInfo, Up: Top, Next: Macros + +Interaction with the Terminal. + + The simplest and standard way to print a message on the terminal is with +the PRINTX operation. It takes a string, delimited as for ASCII, and types +it out. For example, PRINTX /FOO/ will type FOO, with no carriage return. +.TYO is a function that takes a single character, as a number, and types +it. .TYO 101 will print an A. + + Another useful function is .TYO6, which takes an argument which is +interpreted as sixbit and printed out. .TYO6 is useful primarily with +.FNAM1 and .FNAM2. + + Error messages are printed on the terminal, of course. The .ERR function +signals an error, taking the rest of the line as error message. Along with +the error message will go the usual information of filenames, page and line +number, location counter both absolute and relative, and macro depth. +There are no special facilities for putting any variable information in the +error message because the macro features can be used to do this. + + There are two ways to request input from the terminal. You can ask a +specific question, or you can give the user the opportunity to enter any +MIDAS code he wants. To allow him to enter arbitrary text, do + .INSRT TTY: +which reads input from the terminal, ended by ^C or ^Z. If you want it to +be done only on pass 1, you must put it in an IF1 conditional. +The /T switch can be used in the command line to cause a .INSRT TTY: to be +done in a program which does not actually contain one. It will be done +right after the TITLE statement. + + To ask a specific question, use .TTYMAC, which a sort of macro that reads +its arguments from the terminal. .TTYMAC looks like a macro definition +except that there is no macro name in the define line; just an argument +list, followed of course by the macro body and a TERMIN. Instead of +defining a macro which must be called later with arguments specified +explicitly, .TTYMAC defines a nameless macro which is called immediately, +getting the arguments by reading as many lines as are necessary from the +terminal. *Note TTYMAC: Macros, for more information. Here is an example: + +PRINTX /Value of BAR = / +.TTYMAC FOO +BAR=FOO +TERMIN + +MIDAS Node: Macros, Up:Top, Previous:Terminal, Next:Loops + +MIDAS MACROS + +It is often useful, when the text to be assembled +has some pattern, to cause it to be computed, rather than +putting it all in the file to be assembled. This reduces the number +of possible typos and makes it easy to change all occurrences +of a particular construct. + +To do this, one needs to be able to define a function which will +be evaluated at assembly time, with the result being text to be assembled +in place of the call to the function. Such a function is called a MACRO. + +In this document, "EOL" means either CR or LF; +"open" means "<", "(", "{" or "["; "close" means ">", ")", "}" or "]". +"the EOL or CRLF is thrown away" means that the EOL encountered as +should have been previously described is thrown away, and if the EOL +is a CR and the following character is a LF, the LF is also thrown away. +Thus, either a CR alone, a LF alone, or a crlf may be used, and will be +flushed at that point. + +* Menu: + +* Definitions:: Macro Definitions. +* Calls:: Macro Calls. +* Examples:: Examples of macro definitions and calls. +* Remote:: The "REMOTE MACRO" construction. + +MIDAS Node: Definitions, Up: Macros, Next:Calls + +Macro Definitions + +A function definition must specify the name of the function, the +formal parameters (called DUMMY ARGUMENTS when macros are concerned) +and the expression to be evaluated when the function is +called - or in the case of a macro, the text to be assembled when +the macro is called. + +In MIDAS, a macro definition is introduced by the pseudoop +DEFINE, which should be followed by the macro name. +After that, on the same line, come the names of the dummy +arguments, perhaps followed by a comment. +The text of the macro starts on the next line, and continues +until the DEFINE is matched be a TERMIN. +The character that ends the TERMIN is gobbled up. + +* Menu: + +* Example: Macro Definition Example +* Define:: The Macro Define Line +* Body:: The Macro Body + +MIDAS Node: Macro Definition Example, Up: Definitions + +Macro Definition Example + +DEFINE FOOBR AA,B + MOVE A,AA + CAIL A,B + POPJ P, +TERMIN + +A call to that macro might be: + + FOOBR ZZZ,10 + +which would assemble into + + MOVE A,ZZZ + CAIL A,10 + POPJ P, + +MIDAS Node: Define, Up: Definitions + +THE MACRO DEFINE LINE + +The "DEFINE" line is the first component of a macro definition. +It begins with the "DEFINE" pseudo (which needn't actually be at the +beginning of a line). Next comes the name of the macro to be defined, +optionally preceded by an explicit block name (eg DEFINE FOO"BAR to +define a macro BAR in the block named FOO, rather than in the +current block). After the macro name come the dummy argument names, +followed optionally by a comment. In any case, the define line +extends through the first CRLF or EOL after the DEFINE. + + a. bindclasses - semantics. + +Most higher level languages have several bind classes. The function +definition specifies one of the bind classes for each formal parameter, +which is used in decoding a call to the function, to decide what value to +give to the formal parameter. Macro dummy arguments also have bind +classes, which say three things: +what to do if the dummy is UNSPECIFIED (that is, if, in a particular call, +the argument list runs out before this dummy is reached) or NULLSPECIFIED +(the argument for this dummy is left out), the alternatives being +NULLIFIED, GENSYMMED and DEFAULTED (see *Note UNSPEC:calls-8, for the +meanings of the three options); +which argument syntax to use for the dummy when processing calls to the +macro (There are 6 different argument syntaxes available in MIDAS: NORMAL, +WHOLELINE, BALANCED, STRUNG, KEEPSTRUNG, and EVALUATED. +See *Note SYNTAX:syntax-footnote, for descriptions of them.); +and how the actual arguments are to be associated with the dummies, the +alternatives being by ORDER and by KEYWORD. + + b. bindclasses - syntax. + +In MIDAS, it is not necessary to specify the complete bindclass +of each dummy with that dummy's name. Only the ways in which its +bindclass differs from that of the preceding dummy are specified, +by means of special delimiters between the names of the dummies. +The first dummy is given the default bindclass (nullified normal by order) +unless special delimiters precede it. The delimiters are: + {[(< which cause following dummies to be balanced, + >)]} which cause following dummies to have normal syntax, + * which causes following dummies to be strung, or, if + strung was already the selected syntax, causes them to + be normal (This is called "turning strungness on or off"), + & which turns keepstrungness on or off, + # which turns evaluatedness on or off, + ? which turns balancedness on or off, + - which turns wholelineness on or off, + \ which complements gensymmedness, + + which switches between by order and by keyword, + : which reverts to the default in all ways (normal syntax, + by order (not keyword), and not gensymmed). +"/" is a delimiter which is like "-" except that if it follows +a dummy immediately, wholelineness is complemented before the dummy +rather than after. That is, "FOO/" is equivalent to "-FOO". +This is mainly for compatability with older versions of MIDAS. +A dummy is defaulted iff its name is followed by "=". +The "=" should be followed by the desired default value, +whose syntax is that of a normal macro argument. +Beware: the dummy argument delimiters do not terminate default values, +and default values are read in with the normal argument syntax +regardless of the specified syntax of the dummy being defaulted. +Thus, DEFINE FOO \(A,B=100)C makes B's default value be 100)C, which +is probably not what you wanted. +If a dummy is specified as gensymmed, and is also given an explicit +default value, the explicit default overrides the gensymming. + + c. DEFINE line example. + +DEFINE FOBR \A#B\C:D,+E=BAR,F,G(H,I=X,)*J*+-K + +would give FOBR the dummies A,B,C,D,E,F,G,H,I,J,K as follows: + +dummy bindclass (argument syntax, what to do if unspecified). + the first few dummies are by order: + A normal, gensymmed + B evaluated, gensymmed + C evaluated, nullified + D normal, nullified + the next few dummies are by keyword: + E normal, defaulted to "bar" + F normal, nullified + G normal, nullified + H balanced, nullified + I balanced, defaulted to "X" + (note that the comma after "I=X" is necessary because + the ")" would otherwise be part of the default + value of I. after dummy names not given default values + a comma is not necessary, although an extra one can't hurt.) + J strung, nullified + the next dummy is by order. + K wholeline, nullified + +MIDAS Node: Body, Previous:Define, Up: Definitions + +THE MACRO BODY + +The macro body is the text string to be substituted in place +of a call to the macro. The macro body specified in a macro +definition starts with the first character after the CRLF or EOL +that ends the define line, and continues through the character +before the TERMIN that ends the macro definition. Remember that +the character ending the symbol "TERMIN" is thrown away. + +WARNING: ANY occurrence of "DEFINE" or "TERMIN" inside a macro body +will affect MIDAS's determination of where the body ends. This is +true regardless of whether you intended them to or not. Just because +the "DEFINE" was in a text string or a comment does not change this. +"Terminate" and "Terminal" must also be avoided. If you need to put a +"DEFINE" or "Terminal" into a macro body, use .QUOTE (*Note quote:quote.). +The same holds for any other MIDAS pseudo-ops that require a matching +TERMIN, such as IRP and .TTYMAC. + +* Menu: + +* Parameters:: Dummy Argument Substitution. +* Concatenation:: Concatenation. +* Quote:: The .QUOTE pseudo. +* Inner:: Inner Macro Definitions. +* Stopping:: The .STOP pseudo. +* Jumping:: The .TAG and .GO pseudos. + +MIDAS Node: Parameters, Up: Body, Next: Concatenation + +DUMMY ARGUMENT SUBSTITUTION. + +Whenever the name of one of the dummy arguments appears in the macro +body specified in the definition, it represents a request for the value +of that dummy to be inserted at that point when a macro call +is expanded. Dummy argument names are recognized only when surrounded +by non-squoze characters, so neither of the dummy names "A" and "B" occurs +in the string " AB ", but both occur in " A B ". The way dummy +argument substitution is implemented is that the dummy argument names +are recognized when the macro is defined, and replaced by special +characters. Therefore, if the name of a dummy argument is created by +the expansion of a macro call (perhaps part of the name came from the +substitution of the value of another dummy) that dummy-name will +not be replaced by the dummy's value. In other words, text produced +by substitution for dummy arguments is not rescanned for occurrences +of dummy argument names. + +MIDAS Node: Concatenation, Previous: Parameters, Up: Body, Next: Quote + +CONCATENATION. + +Suppose it is desired to have the substituted value of the dummy +argument FOO followed immediately by the squoze character X. +It will not do to put "FOOX" in the macro body, because "FOO" is +not considered to occur in "FOOX". "FOO X" will cause the value +of FOO to be substituted, but the space will remain between it +and the "X". The way to win is to use the concatenation +character "!". "!" can delimit the names of dummy arguments, as +any other non-squoze character can, but it alone is thrown away after +doing so. For example, "FOO!X" will cause FOO to be recognized, +but followed immediately by an "X". +Similarly, the TERMIN that ends the macro definition must be +preceded by a non-squoze character, which normally becomes part +of the macro definition. If it is desired for the macro definiton +to end with a squoze character, separate it from the TERMIN with +an "!", which will be thrown away. "!"'s that appear in the macro +body not adjacent to a dummy agument name, a .QUOTE, or the final TERMIN +are not thrown away; this makes it possible to put "!"'s in macros. + +MIDAS Node: Quote, Previous: Concatenation, Up: Body, Next: Inner + +.QUOTE + +It is possible to prevent recognition of dummy argument names +in a part of the macro body by using the .QUOTE pseudoop. The +pseudo is followed by a text string like the argument to ASCII et al., +which is not scanned for dummy argument names. The first character +of the text string will follow the character before the "." of the +.QUOTE, and the last character before the closing delimiter will +come before the character after tht delimiter, in the macro as it +will be defined. The .QUOTE, to be recognized, must be +preceded by a non-squoze character, so in order to make it +possible for a quoted string to follow a squoze character, an "!" +before a .QUOTE is deleted. +Not only dummy names, but TERMIN, .QUOTE, and the pseudos +matched by TERMINs (DEFINE, .TTYMAC, and the various flavors of IRP) +are not detected or treated specially when within a .QUOTE . + +MIDAS Node: Inner, Previous: Quote, Up: Body, Next: Stopping + +INNER MACRO DEFINITIONS. + +In order to make it possible to define a macro which will, when +called, define another macro, it is possible to insert matching +DEFINE - TERMIN pairs in a macro definition. A definition is +ended not by the first TERMIN after the DEFINE, but by the first +TERMIN that is unmatched by previous DEFINEs (or other pseudos +such as IRP and .TTYMAC that also expect to be matched by TERMINs). +(DEFINEs, TERMINs, etc. within .QUOTEs are ignored in the matching-up.) +Remember that when the outer macro is called and the inner one is +defined, its TERMIN will gobble up one character. +For that reason, when a macro definition ends with an inner +macro definition or an IRP, "TERMIN TERMIN" should be used, +rather than "TERMIN!TERMIN". If the latter is used, the main +macro will end with "TERMIN", so when it is called the inner +"TERMIN" will gobble an extra character after the call. +Using the space gives the inner TERMIN a character to gobble, +thus protecting all the other characters from being gobbled. + +MIDAS Node: Stopping, Previous: Inner, Up: Body, Next: Jumping + +.STOP + +The .STOP pseudo is used to exit from a macro. +At macro expansion time, when .STOP is executed, the +rest of the macro body will be ignored that time through. +execution will continue with the first character after the macro +call. For example, + + DEFINE FOO A,B + 1 + IFE A,.STOP + 2 + TERMIN + + FOO 1 +; 1 +; 2 ;note the .STOP isn't exectuted. + FOO 0 +; 1 ;and that's all, because of the .STOP. + +Beware of putting a .STOP inside brackets ("[" and "]"). +Because brackets are used for both literals and conditionals, +MIDAS must keep a stack with an entry for each unmatched "[" +saying what is was for. If a .STOP, which is like a jump to +the end of the macro body, is within brackets inside the macro, +then although those bracket pairs will be exited, the bracket +stack will not be updated because the closebrackets will +not be encountered. When a "]" is next seen, MIDAS may +treat it the wrong way (eg, may think it closes a literal +when it was supposed to close a conditional). +The way to win is to use braces +("{" and "}") instead of brackets when conditionalizing +a .STOP. Since braces are not used for anything but +conditionals, there is no need for MIDAS to maintain such +a stack, and thus no data base is invalidated if +the brace depth is changed. +Thus, this macro may cause problems: + + DEFINE FOO A,B + 1 + IFE A,[.STOP ] + 2 + TERMIN + +and this one should be preferred: + + DEFINE FOO A,B + 1 + IFE A,{.STOP } + 2 + TERMIN + +MIDAS Node: Jumping, Previous: Stopping, Up: Body + +.TAG and .GO + +These two pseudos provide arbitrary transfers at macro +expansion time. That is, they do not assemble into jump +instructions; rather, they tell MIDAS to jump around +while expanding the macro. That can cause parts of the +macro to be expanded more than once or not at all. +The way to use them is to put .GO at the place +MIDAS should transfer from, and .TAG at the +place it should transfer to. Thus, .GO FOO will +transfer to a .TAG FOO . Nonlocal transfers are +allowed; if a .GO does not find a matching TAG in the +macro it is in, it will exit that macro and search the macro +which called the macro containing the .GO. Any number +of levels may be popped up this way but popping into a +file will cause lossage. There should be a space after the + in both the .GO and the .TAG to prevent lossage. +Note that .GO and .TAG may be used in REPEAT's and +IRP's just as in macros, and nonlocal .GO's in macros +are allowed to find .TAG's in IRP's and REPEAT's, etc. +Transfering from one level in brackets to another has dangers +associated with it, just as with .STOP - see the detailed +explanation under *Note STOP:Stopping. +For example, + + DEFINE FOO + BAR==5 + .TAG BARF + BAR==BAR-1 + BLETCH + IFN BAR,.GO BARF + TERMIN + +when called, will do BLETCH 5 times +(of course, a REPEAT could have been used in this +case, and would have meant a simpler macro). + +MIDAS Node: Calls, Previous: Definitions, Up: Macros, Next: Examples + +MACRO CALLS. + +A macro call is a request for the body of a macro to be substituted +into the text to be assembled. The call must specify the name of the +macro and the values to be given to the macro's dummy arguments +(if it has any) + +* Menu: + +* Call: calls-1 Macro Call Syntax. +* Normal: calls-2 The "Normal" Argument Syntax. +* Balanced: calls-3 The "Balanced" Argument Syntax. +* Wholeline: calls-4 The "Wholeline" Argument Syntax. +* Strung: calls-5 The "Strung" Argument Syntax. +* Keepstrung: calls-6 The "Keepstrung" Argument Syntax. +* Evaluated: calls-7 The "Evaluated" Argument Syntax. +* Unspecified: calls-8 What Happens To Dummies That Are Unspecified. + +MIDAS Node: Calls-1, Up: Calls, Next: Calls-2 + +MACRO CALL SYNTAX. + +Every macro call begins with name of the macro. In order for +the macro name to be recognized as such, it must be evaluated. +Therefore, macro calls are possible only in those places where +a symbol will be evaluated. (For example, putting the macro's name +in the middle of an ASCII will not cause the macro to be called). + +* Menu: + +* Simple: calls-1a: Macros With No Dummies. +* Degenerate: calls-1b: Degenerate Calls. +* Normal: calls-1c: Normal Calls. +* Parens: calls-1d: Parenthesized Calls. + +MIDAS Node: Calls-1a, Up: Calls-1, Next: Calls-1b + +MACROS WITH NO DUMMIES. + +A call to a macro without dummies consists of just the macro name. +The character that terminates the name is left to be reprocessed after +the text of the macro is processed. + +MIDAS Node: Calls-1b, Previous: Calls-1a, Up: Calls-1, Next: Calls-1c + +DEGENERATE CALLS. + +A degenerate call to a macro with dummies consists of the macro +name followed by an EOL. The EOL or CRLF will be thrown away. +All the dummies of the macro will be unspecified (*Note UNSPEC:calls-8.). + +MIDAS Node: Calls-1c, Previous: Calls-1b, Up: Calls-1, Next: Calls-1d + +NORMAL CALLS. + +A normal call to a macro with dummies follows the macro name with +anything but an EOL or OPEN. The character immediately after the macro +name will be ignored. After it, the scanning for the values of the dummies +will commence. +MIDAS considers "by order" dummies one at a time, in the order +they appeared in the macro definition. Each dummy is given a value +obtained by scanning the text of the macro call according to the +argument syntax determined by the dummy's bindclass (which is +one of normal, balanced and wholeline). +(*Note SYNTAX:syntax-footnote, for descriptions of the argument syntaxes). +When a run of "by keyword" dummies is reached, MIDAS expects to +see in the macro call expressions of the form =. +MIDAS reads the dummy name and checks that the "=" is there; it then +finds the dummy with that name and reads in the using that +dummy's bindclass. When, instead of a dummy name, a terminator +(comma, EOL, semicolon, CLOSE, etc) is seen, all the "by keyword" +dummies in that particular run of them which have not been specified +in the macro call are considered to be unspecified. If there are +by order dummies after the run of by keyword ones, MIDAS then +proceeds to read in their values. If the scan for one dummy detects +the "end of the call" (*Note EOL/SEMI:calls-2d,) then the scan for +all following dummies becomes trivial: they are all unspecified, +regardless of their designated argument syntaxes, and no more +characters will be read from the input stream for any of them. +If a normal call is ended in this fashion by an EOL, +the EOL or CRLF is thrown away. + +MIDAS Node: syntax-footnote, Up: Calls-1c + +MACRO ARGUMENT SYNTAX + +* Menu + +* Normal: calls-2 +* Balanced: calls-3 +* Wholeline: calls-4 +* Strung: calls-5 +* Keepstrung: calls-6 +* Evaluated: calls-7 + +MIDAS Node: Calls-1d, Previous: Calls-1c, Up: Calls-1 + +PARENTHESIZED CALLS. + +In these calls, the macro name is followed by an OPEN. The assignment +of values to dummies procedes as in a normal call. At the end, though, +characters are thrown away until and including a CLOSE that matches the +OPEN. In the matching, parens and brackets within the values of +dummies are not considered. Also, only the number of brackets seen is +remembered - not what kind. There is nothing to stop a "(" from matching +a ">" at this stage. Parenthesized calls are most useful with macros whose +dummies are balanced - then the macro call is guaranteed +to terminate precisely at that closeparen that matches the initial +openparen, regardless of whether enough or too many argumentss +are present in between. Note that where. below, the macro call is said +to be "ended", in a parenthesized call that really means +that scanning for the matching closeparen will begin. + +MIDAS Node: Calls-2, Previous: Calls-1, Up: Calls, Next: Calls-3 + +THE "NORMAL" ARGUMENT SYNTAX. + +MIDAS begins scanning for a normal argument by examining +the first character. + +* Menu: + +* Bracket: calls-2a First Character is "[". +* Slash: calls-2b First Character is "\". +* Comma: calls-2c First Character is ",". +* EOL/SEMI: calls-2d First Character is an EOL or semicolon. +* Otherwise: calls-2e Otherwise. + +MIDAS Node: Calls-2a, Up: Calls-2, Next: Calls-2b + +FIRST CHARACTER IS "[". + +All the text up to the matching "]", not including either of them, is part +of the dummy's value, and the scanning of the next dummy +begins with the character after the "]". +If a normal argument is delimited by squarebrackets, +it is never unspecified or nullspecified, even if the value +between the squarebrackets is the null string. +Thus, when a dummy has a default value, it is possible to specify +the null string explicitly in the call, overriding the default. + +MIDAS Node: Calls-2b, Previous: Calls-2a, Up: Calls-2, Next: Calls-2c + +FIRST CHARACTER IS "\". + +A field is read (leading spaces ignored) +and the field's value, converted to a string using MIDAS's current +radix, is used as the value of the dummy. In this case the scan +of the next argument begins with the character after the field terminator. +Arguments specified in this way are never unspecified or nullspecified. + +MIDAS Node: Calls-2c, Previous: Calls-2b, Up: Calls-2, Next: Calls-2d + +FIRST CHAR IS ",". + +In this case, the dummy is nullspecified (see *Note UNSPEC:calls-8.). +The scan for the next dummy, or the text to be handled after +the macro call if there are no more dummies, starts after the comma. + +MIDAS Node: Calls-2d, Previous: Calls-2c, Up: Calls-2, Next: Calls-2e + +FIRST CHARACTER IS AN EOL OR SEMICOLON. + +This dummy is unspecified (*Note UNSPEC:calls-8,) and so are all +remaining dummies. The scan for the remaining dummies will not +attempt to read any characters. If the terminator was an EOL, +and the call is a normal one, the EOL or CRLF will be thrown away +at the end of macro call processing (*Note NORMAL:calls-1c.). + +MIDAS Node: Calls-2e, Previous: Calls-2d, Up: Calls-2 + +OTHERWISE. + +All text, including the first character, +up to the first comma, semicolon or EOL goes into the argument, +except that tabs and spaces before a semicolon are ignored. +Then, depending on the terminating character, action is taken as +in *Note COMMA:calls-2c, or *Note SEMI/EOL:calls-2d, except that in +neither case is the present dummy nullspecified or unspecified, +since a nonnull value has already been specified for it. + +MIDAS Node: Calls-3, Previous: Calls-2, Up: Calls, Next: Calls-4 + +THE "BALANCED" ARGUMENT SYNTAX. + +When a dummy uses the balanced syntax, MIDAS insists that its +value contain no unbalanced brackets. +That is, while scanning for the end of the argument, MIDAS counts +opens and closes, and will not let anything terminate the argument +when the count is nonzero. Also, unmatched closes will not be allowed +into the argument - they will terminate the argument and the macro +call. When the bracket count is zero - that is, when it is permissible +for the argument to terminate - a comma, semicolon, or EOL will +do it, just as if the dummy used the normal syntax. +That is, unspecification or nullspecification of the present dummy +or the remaining dummies may happen, as described in B.2.c-B.2.e. +Termination by an unmatched close is like termination by an EOL (B.2.d). +For balanced dummies, "[" or "\" as the first character have +no special significance. + +MIDAS Node: Calls-4, Previous: Calls-3, Up: Calls, Next: Calls-5 + +THE "WHOLELINE" ARGUMENT SYNTAX. + +The scan for a wholeline argument stops only when an EOL is +encountered. Thus, the value of a wholeline argument is everything +up to but not including the first eol. While an EOL that +terminates a normal or balanced argument ends the macro call, thus +making all remaining dummies unspecified, the EOL that ends a +wholeline argument does not do so. The EOL or CRLF is thrown away, +and scanning for the next dummy starts on the next line. +A wholeline dummy is never unspecified or nullspecified (except +that it will of course be unspecified if the macro call is terminated +by an EOL ending some previous non-wholeline dummy). + +MIDAS Node: Calls-5, Previous: Calls-4, Up: Calls, Next: Calls-6 + +THE "STRUNG" ARGUMENT SYNTAX. + +A strung argument looks just like the argument to ASCII or SIXBIT: +it is bounded on both sides by an arbitrarily chosen delimiter. +When the argument is scanned, first non-space character is taken +to be the delimiter, and everything up to the second occurrence +of that character is part of the argument's value. Semicolon, +EOL, comma, and closebrackets of various kinds, cannot be used as +the delimiter, because if they are seen when the opening delimiter +is expected they will nullspecify the argument and (except for comma) +end the macro call, as they would in the balanced syntax. The +closing delimiter should be followed by an appropriate argument +terminator such as comma, semicolon, EOL, or a closebracket (but +spaces and tabs may intervene); all except comma end the macro +call, while comma allows more arguments to follow. + +MIDAS Node: Calls-6, Previous: Calls-5, Up: Calls, Next: Calls-7 + +THE "KEEPSTRUNG" ARGUMENT SYNTAX. + +A keepstrung argument is exactly like a strung argument, except that the +delimiters are retained. This is useful for passing on such arguments +to other macros or pseudos, without having to worry about +what delimiters to use, since appropriate ones will be included with +the argument itself. + +MIDAS Node: Calls-7, Previous: Calls-6, Up: Calls, Next: Calls-8 + +THE "EVALUATED" ARGUMENT SYNTAX. + +An evaluated argument is passed by value instead of by name. +When it is time to scan for such an argument, a field is read +in and evaluated, and the value is converted to a string by +expressing it as a number in the current radix. This is exactly +like the treatment of a normal argument whose value starts with +"\", except that the "\" is not present itself in the call +(see *Note SLASH:calls-2b.). + +MIDAS Node: Calls-8, Previous: Calls-7, Up: Calls, + +WHAT HAPPENS TO DUMMIES THAT ARE UNSPECIFIED. + +Whether a dummy is unspecified in a particular +call depends on what came in the call before the place +where the dummy's value should have been, and on the variety of +argument syntax used by the dummy. Similarly, the criterion for +being nullspecified depends on the argument syntax used. However, +the consequences of being unspecified or nullspecified are independent of +the argument syntax used. Instead, they depend on the other part +of the bindclass of the dummy: whether it is to be nullified, +gensymmed, or defaulted to a pre-specified value. + +MIDAS Node: Calls-8a, Up: Calls-8, Next: Calls-8b + +nullified dummies. + +When a dummy defined as nullified is unspecified or nullspecified, +it is given the null string as its value. Most dummies of most macros +used are of bindclass nullified. + +MIDAS Node: Calls-8b, Previous: Calls-8a, Up: Calls-8, Next: Calls-8c + +gensymmed dummies. + +If a gensymmed dummy is unspecified, +its value will be a GENERATED SYMBOL +6 characters long - the first character "G"; the rest, +a number in the current radix whose value equals that of .GSCNT, +which starts out as 0 and is incremented before each gensymming. +Thus, in each call, an unspecified gensymmed dummy +will provide a unique label. +If nullspecified, a gensymmed dummy has the null string as a value. +Gensymmed dummies are treated differently when nullspecified +or unspecified for compatability with old versions of MIDAS. +In fact, the distinction between unspecification and nullspecification +is made only to handle this case. + +MIDAS Node: Calls-8c, Previous: Calls-8b, Up: Calls-8 + +defaulted dummies. + +If a defaulted dummy is nullspecified or unspecified, + its default value will be used as its value in that call. + + +MIDAS Node: Examples, Previous: Calls, Up: Macros, Next: Remote + +EXAMPLES OF MACRO DEFINITIONS AND CALLS. + +* Menu: + +* Normal: Example-1 Normal (Nullified And Defaulted) Arguments. +* Balanced: Example-2 Balanced Arguments. +* Gensymming: Example-3 Gensymming. +* Wholeline: Example-4 Wholeline Arguments. +* Keyword: Example-5 "By Keyword" Dummies. +* Strung: Example-6 Strung And Keepstrung Dummies. +* Evaluated: Example-7 Evaluated Dummies. + +MIDAS Node: Example-1, Up: Examples, Next: Example-2 + +NORMAL (NULLIFIED AND DEFAULTED) ARGUMENTS. + +DEFINE MACRO1 A,B=FOO,C ;3 DUMMIES; SECOND DEFAULTED. + A ? B ? C TERMIN + +MACRO1 1,2,3 +; 1 ? 2 ? 3 + +MACRO1 [FOO,,BAR]2,3 +; FOO,,BAR ? 2 ? 3 + ;Showing how to put commas, etc. in args. + +MACRO1 1,,3 ;2nd arg nullspecified and defaulted. +; 1 ? FOO ? 3 + +MACRO1 1,[]3 ;2nd specified as null, not nullspecified. +; 1 ? ? 3 + +MACRO1 1,2 ;3rd arg unspecified. +; 1 ? 2 ? + +MACRO1 1 ;2nd and 3rd args unspecified; 2nd defaulted. +; 1 ? FOO ? + +MIDAS Node: Example-2, Previous: Example-1, Up: Examples, Next: Example-3 + +BALANCED ARGUMENTS. + +DEFINE MAC2 ?A,B ;2 BALANCED DUMMIES. + A ? B ? BLETCH +TERMIN + +DEFINE MAC2(A,,B,,),, ;another way to define the same macro. + A ? B ? BLETCH +TERMIN + +DEFINE MAC2A A,B ;SIMILAR BUT DUMMIES NOT BALANCED. + A ? B ? BLETCH +TERMIN + +MAC2 , +; ? ? BLETCH + +MAC2A , +; ? BLETCH +; + ;Note that the first dummy was bound to "". + ;The "" wasn't even part of the call. + +MAC2(FOO,-1(P))+1 +; FOO ? -1(P) ? BLETCH+1 + ;A parenthesized call. Note that the closeparen + ;ends the second arg and the macro call, and is thrown away. + +MAC2 FOO,-1(P)+1 +; FOO ? -1(P)+1 ? BLETCH + +DEFINE SQR (X) +<*>TERMIN ;this macro squares its arg. + +1+SQR(2)*3 ;a parenthesized call. +;1+<<2>*<2>>*3 +;note that 1+SQR(2>*3 would have the same effect. + +3*<1+SQR 2>-4 +;3*<1+<<2>*<2>>>-4 + ;Here we have, not a parenthesized call, + ;but an ordinary call within parens. + ;The ">" ends the argument to SQR and is not thrown away. + +MIDAS Node: Example-3, Previous: Example-2, Up: Examples, Next: Example-4 + +GENSYMMING. + +DEFINE GENMAC \FOO,BAR + FOO,,BAR +TERMIN + +GENMAC X+1,Y ;Both args specified nonnull. +; X+1,,Y + +GENMAC X+1,, ;Second arg nullspecified. +; X+1,, ;Nullspecified args are not gensymmed. + +GENMAC X+1 ;Second arg unspecified. +; X+1,,G00001 + +GENMAC X+1 ;Note uniqueness of gensyms. +; X+1,,G00002 + +GENMAC() ;Both args unspecified +; G00003,,G00004 + + +GENMAC(,) ;First arg nullspecified; second, unspecified. +; ,,G00005 + +MIDAS Node: Example-4, Previous: Example-3, Up: Examples, Next: Example-5 + +WHOLELINE ARGUMENTS. + +DEFINE FOOWH A-B ;first arg normal; second, wholeline. + A + B +TERMIN + +FOOWH 1,2,3,4 +; 1 +; 2,3,4 + +FOOWH 1 +; 1 +; + +DEFINE BARWH -A B ;both args wholeline. + A + B +TERMIN + +BARWH 1,2,3 ;note that each arg requires a line. +4,5,6 ;a comment on the line is part of the arg. + ;that is, semicolon isn't special. +; 1,2,3 ;note that each arg requires a line. +; 4,5,6 ;a comment on the line is part of the arg. + +MIDAS Node: Example-5, Previous: Example-4, Up: Examples, Next: Example-6 + +"BY KEYWORD" DUMMIES. + +DEFINE KWDM +A,B,C=FOO,+ ;all three arguments by keyword. + A + B + C +TERMIN + +KWDM B=1, A =2 +; 1 +; 2 +; FOO + +KWDM C=1 +; +; +; 1 + +DEFINE KWD1 A=1,+B=2,C=3,+D=4 ;B and C are by keyword; A and D are by order. + A ? B ? C ? D +TERMIN + +KWD1 100,,200 ;both A and D but neither B nor C specified. +; 100 ? 2 ? 3 ? 200 + +KWD1 10,C=11 ;A and C specified. +; 10 ? 2 ? 11 ? 4 + +KWD1 ,B=20,C=21,,40 ;B, C and D specified; A was nullspecified. +; 1 ? 20 ? 21 ? 40 + +MIDAS Node: Example-6, Previous: Example-5, Up: Examples, Next: Example-7 + +STRUNG AND KEEPSTRUNG DUMMIES. + +DEFINE TYPEZ *STR* ;STR is strung. + OUTUUO [ASCIZ ^@STR +^@]TERMIN ;note ctrl-@ used as delimiter of ASCIZ. + +TYPEZ /UNDEFINED SYMBOL/ +; OUTUUO [ASCIZ ^@UNDEFINED SYMBOL +;^@] + +FOO== ;Here a closebracket follows the string. +;FOO==< OUTUUO [ASCIZ ^@WHY FOO? +;^@]> + +TYPEZ(:MYSTERIOUS ERROR:) ;A parenthesized call, and a strange delimiter. +; OUTUUO [ASCIZ ^@MYSTERIOUS ERROR +;^@] + +DEFINE ASCNT &KSTR& ; KSTR is keepstrung. +.LENGTH KSTR,,[ASCII KSTR]!TERMIN + +OUTUUO [ASCNT "String=^@"] ; Note that delimiters are kept with argument. +;OUTUUO [.LENGTH "String=^@",,[ASCII "String=^@"]] + + +DEFINE 2STRS *A=UGH,B* ;Two strung arguments, one defaulted. + ASCIZ /A,B/ +TERMIN + +2STRS =FOO= ;Call ended after 1st string +; ASCIZ /FOO,/ + +2STRS .FOO.,-BAR- +; ASCIZ /FOO,BAR/ + +2STRS ,/BAR/ ;Here no 1st argument is given +; ASCIZ /UGH,BAR/ + +2STRS //,/BAR/ ;Here an explicit null string is given. +; ASCIZ /,BAR/ + +MIDAS Node: Example-7, Previous: Example-6, Up: Examples + +EVALUATED DUMMIES. + +DEFINE TYPECH #CHAR ;CHAR is evaluated. + MOVEI A,CHAR + PUSHJ P,TYO +TERMIN + +TYPECH 40 ;Print a space. +; MOVEI A,40 +; PUSHJ P,TYO + +TYPECH "; ;Print a semicolon +; MOVEI A,73 ;73 is the value of ";. +; PUSHJ P,TYO ;This would not be possible with normal + ;or balanced syntax, since the ";" would + ;be an argument terminator. + +DEFINE TYPEI (CHAR) ;CHAR balanced instead of evaluated + MOVEI A,CHAR + PUSHJ P,TYO +TERMIN + +TYPECH "0(B) ;Print C(B) as a digit. +; MOVEI A,"0(B) ;This would not work with TYPECH, +; PUSHJ P,TYO ;Since CHAR would evaluate to B,,"0 + ;giving MOVEI A, = MOVEI A,"0. + +MIDAS Node: Remote, Previous: Examples, Up: Macros + +The "REMOTE MACRO" construction. + +It is often desirable to use a macro as if it were a string variable, +appending text to it little by little and then accessing the whole +text as accumulated at some time. A way to do this is as follows: + +;initialization: + + IF1 [DEFINE BNKBLK OP + OP + TERMIN ] ;BNKBLK accumulates text. + + DEFINE BLCODE NEWCFT + BNKBLK [DEFINE BNKBLK OP + OP]NEWCFT + TERMIN + TERMIN ;BLCODE adds its arg to the end of BNKBLK. + +;add some text: + + BLCODE [FOO] ;add FOO. + BLCODE [BAR] ;add BAR (note BLCODE inserts CRLF's, too). + +;assemble what has been accumulated: + + BNKBLK ;which expands into ... +; FOO +; BAR + +In understanding this example, it is necessary to realize that MIDAS +is a string-processing language that just happens to produce binary +output as a side effect. It does not matter whether an expression +appears to be properly nested with the various sorts of syntactic +bracket (such as [-] and DEFINE-TERMIN) because the order the brackets +are processed in may not be the order they appear in - especially +since not all phases of processing look for all types of bracket. +For example, when BLCODE is called, it calls BNKBLK with argument +"DEFINE BNKBLK OPOP". That there is an unmatched DEFINE in that +argument does not matter because DEFINE is not special at macro +call time or macro expansion time. Since BNKBLK substitutes its arg +in, there will be an unmatched DEFINE in the expansion of BNKBLK. +So, when MIDAS expands BNKBLK, it will begin processing the DEFINE, +and it will keep on reading for the new macro definition past the +end of BNKBLK. That is not a problem, because AFTER the call to +BNKBLK, within BLCODE, there is a TERMIN that will make MIDAS +end the new macro definition. The inner DEFINE and TERMIN appear +to match in a simple minded way, which is necessary since otherwise +it would be difficult to define BLCODE containing them, but when +BLCODE is called they actually match up in a much more complicated way. +To get a full understanding of exactly what expands into what, +assemble such a segment of program with the (L) switch. The listing +will show not only macro calls but what they expand into. + +Two other examples using this construct follow. +They use a modification of the remote-macro hack +to accumulate things in the reverse +of the order they are put in. + +;Backwards IRP: to get the backwards version of +;IRP FO,BA,[mumble] +; body!TERMIN +;use +;IRPB FO,BA,[mumble][body] + + DEFINE IRPB X,Y,Z,BODY ;IRP BACKWARDS + DEFINE 1IRPB1 FOO + FOO!TERMIN + DEFINE 2IRPB2 BAR + 1IRPB1 [DEFINE 1IRPB1 FOO + FOO + BAR]TERMIN + TERMIN + IRP X,Y,[Z] + 2IRPB2 [BODY] + TERMIN + 1IRPB1 + TERMIN + +;LISP-style PROGs in MIDAS - use these macros as follows: +; PROG [X,Y,Z] ;X, Y, and Z are the locals. +; body of subroutine +; ENDPROG + + DEFINE PROG VARS + IRP X,,[VARS] + PUSH P,X + TERMIN + DEFINE ENDPROG FOO + FOO + TERMIN + DEFINE 2PROG2 BAR + ENDPROG [DEFINE ENDPROG FOO + FOO + BAR]TERMIN + TERMIN + IRP X,,[VARS] + 2PROG2 [POP P,X] + TERMIN + TERMIN + +MIDAS Node: Loops, Up: Top, Previous: Macros, Next: Cond + +Midas Assembly-time Loops + +Loops are useful for many reasons. One might merely wish to +initialize the contents of a table in a simple pattern. +One might also use a loop in conjuntion with macros, in +all the ways loops are used in other programming languages. +The loops that exist in MIDAS are REPEAT and +the various kinds of IRP. Because MIDAS canned loops +all begin with pseudoops, they will only be recognized and +expanded where a symbol would be evaluated +(not within comments, failing conditionals, macro definitions, +text strings, etc.). + +* Menu: + +* REPEAT: loops-A +* IRP: loops-B +* Particulars: loops-C Particular Types Of IRP. + +Node: loops-A, Up: loops, Next: loops-B + +REPEAT. + +REPEAT is used to assemble a single string (called the REPEAT string) +several times - like a DO in PL-1 or MACLISP. The REPEAT string need +not assemble into the same thing each time, however, because each +assembly of the string may have side effects that alter the action of +the next. + +* Menu: + +* Syntax: loops-A1 Syntax of REPEAT +* Expansion: loops-A2 +* RPCNT: loops-A3 +* STOP: loops-A4 +* ISTOP: loops-A5 +* Jumping: loops-A6 .GO and .TAG inside REPEAT + +Node: loops-A1, Up: loops-A, Next: loops-A2 + +SYNTAX. + +The REPEAT pseudoop should be followed by a field whose +value is the number of times the REPEAT string is to +be repeated. That string follows immediately after the field. +The syntax of the REPEAT string is the same as that +of the string in a conditional. If the first character after +the space or comma that ends the field is a "[", then all +characters up to the matching "]", not including either of the +brackets, make up the string to be repeated. Otherwise, that +first character itself and all characters up to the next EOL +make up the REPEAT string. The EOL or CRLF is +thrown away, and a CRLF is added to the end of the REPEAT +string, in the case that square brackets are not used. + +Node: loops-A2, Previous: loops-A1, Up: loops-A, Next: loops-A3 + +EXPANSION. + +A REPEAT expands by substituting the REPEAT string +into the assembler input stream appropriately many times. For example, + + REPEAT 5, SETZ ? 500 + +is equivalent to + + SETZ ? 500 + SETZ ? 500 + SETZ ? 500 + SETZ ? 500 + SETZ ? 500 + +where the REPEAT string is "SETZ ? 500 ". +Each time through except the last, the last character +of the string will be followed immediately by the first character +of the string. To illustrate, + + 0,,REPEAT 3,[.+1 + 10,,]0 + +expands into + + 0,,.+1 + 10,,.+1 + 10,,.+1 + 10,,0 + +This example also shows that there is no need for the +boundary between one pass through the string and the +next to coincide with any logical +division in the resulting concatenated text (such as a word +or field boundary); the several passes through the string may +all be part of one syllable if they do not contain any syllable +separators! (for example, REPEAT 3,['A] = 'A'A'A = (SIXBIT/AAA/)). + +Node: loops-A3, Previous: loops-A2, Up: loops-A, Next: loops-A4 + +.RPCNT. + +During the expansion of a REPEAT, the symbol .RPCNT +has the value of the number of completed passes through the REPEAT; +that is, it is 0 the first time through, 1 the second, etc. +When nested REPEATs are used, .RPCNT always refers to the innermost REPEAT. +For example, + + REPEAT X,[.RPCNT+]0 is X*/2 for X >= 0. + REPEAT X,[<.RPCNT+1>*]1 is FACTORIAL(X). + +Node: loops-A4, Previous: loops-A3, Up: loops-A, Next: loops-A5 + +.STOP. + +When the pseudoop .STOP is executed in a REPEAT, the +pass through the REPEAT then in progress is ended. .STOP +is like a jump to the label on the END of a DO in PL-1. +The character after the "P" of .STOP is ignored; the next +character asembled will be the first character of the REPEAT +string (if there are more repetitions to go) or the one after +the "]", EOL or CRLF that ended the REPEAT string. +Thus, + + REPEAT 5,[ + FOO + IFE BAR,.STOP + + ] + +is equivalent to (but assembles faster if BAR is 0 than) + + REPEAT 5,[ + FOO + IFN BAR,[ + + ]] + +Note that it currently loses to put .STOP (or .ISTOP) inside a +bracketed conditional within the REPEAT. For details and reasons, +see *Note MACROS:macros. The way to avoid this problem is to use +braces instead of brackets in conditionals that surround .STOP's. +The same applies to .ISTOP, .GO and .TAG. + +Node: loops-A5, Previous: loops-A4, Up: loops-A, Next: loops-A6 + +.ISTOP. + +.ISTOP is like .STOP, but also inhibits all further +repetitions of the REPEAT string. It is like a jump to a +label after the END of a DO in PL-1. The character after +the "P" is ignored; the next character assembled is the one after +the "]", EOL or CRLF that ended the REPEAT string. +For example, + + REPEAT 36.,[ + FOO==.RPCNT + IFN BAR&<1_.RPCNT>,.ISTOP + ] + +sets FOO to the number of trailing zeros in BAR. + +Node: loops-A6, Previous: loops-A5, Up: loops-A + +.GO AND .TAG + +The pseudos .GO and .TAG may be used inside REPEAT's +just as in macros. See *Note JUMPING:jumping. + +Node: loops-B, Previous: loops-A, Up: loops, Next: loops-C + +IRP'S IN GENERAL. + +IRP's in MIDAS are somewhat analogous to MAPCAR +in LISP. In an IRP, a dummy name is supplied and also +a string to repeat (called the IRP BODY) and a string +(called the IRP STRING) to +take substrings from according to a prespecified syntactical +rule which depends on which IRP pseudoop is used. The IRP +body is assembled several times, with the dummy name bound to +successive substrings of the string being IRP'ed over. +For example, + + IRP X,,[1,4,5] + FOO+X ? TERMIN + +expands into + + FOO+1 ? FOO+4 ? FOO+5 + +X is the dummy, "1,4,5" is the IRP string, +"1", "4", and "5" are the substrings, +and "FOO+X ? " is the IRP body. + +Node: loops-B1, Up: loops-B, Next: loops-B2 + +SYNTAX OF IRP'S. + +All kinds of IRP have the same syntax (except that IRPNC is slightly +different). After the pseudoop itself come any number of IRP GROUPS, +which make up the IRP HEADER (most IRP's have only one group) then comes +the IRP body, which is just like a macro body (see *Note BODY:Body.). + +Node: loops-B2, Previous: loops-B1, Up: loops-B, Next: loops-B3 + +IRP GROUPS. + +Each IRP group specifies one repetition to be done. +It contains one string to take substrings from, and two +dummies to put them in. The dummy names come first, and +should be terminated by commas. If one of the dummies +would not be referred to in the IRP body, it may be omitted +from the IRP group, but the comma in its position may not +be omitted (if a comma is missing, MIDAS will sometimes be +able to detect that fact, in which case MIDAS will print an +error message and assume there is no second dummy. However, +a missing comma is not always detectable). The string to take +substrings from comes after the second comma, +and its syntax is that of a normal macro argument, +except that "\" is not special as the first character. +f the first character encountered after the string is read is +a squoze character or a comma, MIDAS assumes that it begins +another group. Otherwise, the group just ended is the last one. +This means that if the string is terminated by a "]" or comma, +the character following determines whether another group follows, +while if the string is ended by an EOL or ";", there are +automatically no more groups. +The EOL or ";", or whatever character follows the comma or "]", +is thrown away. If the next character is a LF, it too is discarded. +A comment following the IRP header will lose. The best possibility is +that it will merely go in the IRP body. The worst is that the ";" +will be one of the characters thrown away and, causing total lossage. +An example of an IRP with several groups is + + IRP X,,[1,2,3]Y,,[4,5] + ASCIZ \X+Y\ + TERMIN + +which expands into + + ASCIZ \1+4\ + ASCIZ \2+5\ + ASCIZ \3+\ + +Node: loops-B3, Previous: loops-B2, Up: loops-B, Next: loops-B4 + +THE IRP BODY. + +The body of an IRP is just like the body of a macro definition. +The dummy arguments mentioned in the IRP header may be used +in the IRP body, representing requests for the corresponding +substrings of the IRP strings to be substituted in. +Concatenation with "!", and .QUOTE, may be used as in +macro definitions. The IRP body is ended by a TERMIN, +just like a macro body. Because of this, the character after +the "N" of the TERMIN wil be discarded. Also for that reason, +IRP's are expected to be matched by TERMIN's within macro +bodies and IRP bodies. For example, in + + DEFINE INSIRP INSN,ADDR + IRP X,,[ADDR] + INSN,ADDR + TERMIN + TERMIN + +the first TERMIN matches the IRP; the second, the DEFINE. +When the DEFINE executes, it increments its counter on seeing +the IRP, and decrements it on seeing the first TERMIN, so the +second TERMIN ends the macro body. A call to INSIRP +expands into a string containing the IRP and the first TERMIN, +which closes the IRP body when the IRP executes. The result is that in + + INSIRP PUSH P,[A,B,C] + +NSN's value is "PUSH P" and ADDR's is "A,B,C". +The macro call expands into + + IRP X,,[A,B,C] + PUSH P,X + TERMIN + +which expands into + + PUSH P,A + PUSH P,B + PUSH P,C + +Node: loops-B4, Previous: loops-B3, Up: loops-B, Next: loops-B5 + +IRP EXPANSION + +An IRP should be thought of as first defining an internal +macro whose body is the IRP body, and whose dummy args are +the dummies mentioned in the IRP header, and then calling that +macro repeatedly with arguments which are substrings +of the IRP strings, chosen according to the rule for +the particular IRP pseudoop that was used. +Each call made to the internal macro constitutes one pass +through the IRP. +When an IRP has several groups, on every pass through the IRP +each group is stepped to its next substring, independently of +the other groups. The expansion of the IRP stops (that is, no +more passes through it are made) only when ALL of the groups +are exhausted (the ends of all the IRP strings have been +reached). + +Node: loops-B5, Previous: loops-B4, Up: loops-B, Next: loops-B6 + +.STOP, .ISTOP, .GO AND .TAG. + +These pseudoops, when executed in an IRP expansion, act the way they +do in REPEAT's. That is, .STOP ends only the current pass of the IRP, +while .ISTOP also prevents any future passes from starting. +See *Note WHOLELINE:Body-4(A.4) and *Note STRUNG:Body-5(A.5). + +Node: loops-B6, Previous: loops-B5, Up: loops-B + +.IRPCNT. + +While an IRP is being expanded, .IRPCNT has the value +of the number of completed passes through the IRP +(0 the first pass, 1 on the next, etc.). When nested +IRP's are used, .IRPCNT refers to the innermost one. Thus, + + IRP AC,,[NIL,A,B,C,D,E,F,G,H,I,J,K,L,M,N,P] + AC==.IRPCNT + TERMIN + +defines all the ACs with the specified names. + +Node: loops-C, Previous: loops-B, Up: loops + +PARTICULAR TYPES OF IRP. + +The previous section described what all the IRP pseudoops +have in common. This section describes the peculiar details +of each IRP pseudoop. The IRP pseudoops differ in how +they divide the IRP strings into substrings, and in how they +choose the values to be given to the two dummies of each group. + +* Menu: + +* C: loops-C1 IRPC (Indefinite Repeat on Characters). +* W: loops-C2 IRPW (Indefinite Repeat on Words). +* S: loops-C3 IRPS (Indefinite Repeat on Syllables). +* IRP: loops-C4 IRP (Indefinite Repeat (on elements)). +* NC: loops-C5 IRPNC (Indefinite Repeat on Characters). +* Example: loops-C6 A Complicated IRP Example. + +Node: loops-C1, Up: loops-C, Next: loops-C2 + +IRPC (INDEFINITE REPEAT ON CHARACTERS). + +IRPC scans the IRP strings a character at a time. +Each time through the IRP body, the first dummy of each group +is set to the next successive character of the group's IRP string, +(or to the null string if the IRP string is exhausted), and +the second dummy is set to the remainder of the IRP string - +the part that follows the character that the first dummy is set to. +For example, in + + IRPC X,Y,[ABCDE]A,B,1234,U,,[+-+-] + ASCIZ /X,Y,A!U!B/ + TERMIN + +the dummies are X and Y in the first group, A and B in +the second, and U in the third (which has no second dummy). +The IRP strings are "ABCDE", "1234", and "+-+-". +The expansion is + + ASCIZ /A,BCDE,1+234/ + ASCIZ /B,CDE,2-34/ + ASCIZ /C,DE,3+4/ + ASCIZ /D,E,4-/ + ASCIZ /E,,/ + +Node: loops-C2, Previous: loops-C1, Up: loops-C, Next: loops-C3 + +IRPW (INDEFINITE REPEAT ON WORDS). + +IRPW takes the IRP strings a line at a time (ignoring null lines). +On each pass, the next nonnull line of every IRP string is used up. +The first dummy of each group is set to the part of the line +up to the first semicolon, and the second dummy is set +to the part that follows the semicolon (or to the +null string if there is no semicolon on the line). +The semicolon, if any, does not become part of either dummy. +Unfortunately there +is no way to tell whether the line contained no semicolon, or there +was only one semicolon and it was the last character - in either case +the second dummy will be null. For example, + + IRPW X,Y,[ + FOO ;BAR + FOO1 ;MUMBLE + ] + [X] ;; Y + TERMIN + +expands into + + [ FOO ] ;; BAR + [ FOO1 ] ;; MUMBLE + +Node: loops-C3, Previous: loops-C2, Up: loops-C, Next: loops-C4 + +IRPS (INDEFINITE REPEAT ON SYLLABLES). + +IRPS attempts to scan the IRP strings a syllable at a time. +However, it is not smart enough to duplicate the actions of the +MIDAS syllable reader perfectly. In actuality, it divides the IRP +string into syllables which are strings of consecutive squoze characters separated +by strings of consecutive nonsquoze characters. On each pass, +the first dummy of each group is set to the next string of +consecutive squoze characters found in the IRP string of the group, +or to the null string if the group's IRP string is exhausted, +and the second dummy is set to the non-squoze character that +terminates the run of squoze characters (or to the null string +if there is none, because the first dummy's value reaches to the +end of the IRP string or the IRP string is exhausted). For example, + + IRPS X,Y,[A+B+C+ D+,E+ ,, &/!,F-G- H-I+] + X==Y!100 + TERMIN + +sets A, B, C, D, E, and I to +100 and F, G, and H to -100. +The extra spaces, commas, and "&/!" in the IRP string do not matter, because +only the first non-squoze character after each syllable becomes the +value of the second dummy Y. Extra CRLF's or + or - signs +could also have been inserted at the same places without effect. + +Node: loops-C4, Previous: loops-C3, Up: loops-C, Next: loops-C5 + +IRP (INDEFINITE REPEAT (ON ELEMENTS)). + +IRP regards the IRP string as a list of elements +separated by commas, and scans the IRP string an element at +a time. An EOL or CRLF will also separate elements but since +null elements are not ignored the CRLF or EOL should be used +instead of a comma, not in addition to one. +Square brackets are also special in the scan of the IRP string. +The actual algorithm used by IRP to find the end of the next +element is that a comma, EOL or CRLF (or the end of the IRP string) +ends the element, and an "[" +is flushed but causes commas and EOLs (and therefore CRLFs) +not to be special until the matching "]", which is flushed. +Note that this resembles but is distinctly different from the +normal macro argument syntax rules. +On each pass through the IRP, the first dummy of each group is set +to the next element in the IRP string of that group, and the second +dummy is set to the rest of the IRP string (starting after the +comma, EOL or CRLF that ended the element). Note that the commas, EOLs and +CRLFs that separate the remaining elements will be present in the second +dummy's value, as will square brackets that are doomed to be flushed when +the elements they are part of are reached by the scan. +For example, + + IRP X,Y,[123 4,56789 + ABCD[EF]GH,[IJ,],K] + ASCIZ /X:Y/ + TERMIN + +expands into + + ASCIZ /123 4:56789 + ABCD[EF]GH,[IJ,],K/ + ASCIZ /56789:ABCD[EF]GH,[IJ,],K/ + ASCIZ /ABCDEFGH:[IJ,],K/ + ASCIZ /IJ,:K/ + ASCIZ /K/ + +Node: loops-C5, Previous: loops-C4, Up: loops-C + +IRPNC (INDEFINITE REPEAT ON CHARACTERS). + +IRPNC is similar to IRPC, but more general. It allows the +characters of the IRP strings to be taken not only one at a time, +but any fixed number at a time. Also, it may be told to +ignore any number of characters at the beginning of each of the IRP +strings, or to limit the number of passes to be made to +a specified maximum value. IRPNC may be used to take an arbitrary +substring of a string, or to index into a string. + +* Menu: + +* Syntax: loops-C5a Syntactic Differences between IRPNC and Other IRP's +* Expansion: loops-C5b Expansion. +* Applications: loops-C5c Applications. + +Node: loops-C5a, Up: loops-C5, Next: loops-C5b + +Syntactic Differences between IRPNC and Other IRP's + +IRPNC's syntax differs from that described in B.1 in that after +the IRPNC pseudoop itself, before the first IRP group, there come +three numeric arguments, terminated by commas. +They specify the number of characters +to ignore at the beginning of each IRP string (to be referred to as +), the number of characters to take from each IRP string per pass +(to be referred to as ), and the maximum number of passes allowed +(to be referred to as

).

may be -1, meaning that the +number of passes is not numerically limited. If

is 0, +the IRPNC is not expanded at all. If is less than 1, it is +defaulted to 1. If is negative, it is defaulted to 0. + +Node: loops-C5b, Previous: loops-C5a, Up: loops-C5, Next: loops-C5c + +Expansion. + +On each pass, the first dummy of each group is set to the next + characters of the group's IRP string (or the whole remainder +of the IRP string if fewer than characters remain). +On the first pass, instead of using the first characters of +the IRP string, which would be like all the other kinds of IRP, + characters are skipped and the next are used. (If the IRP string +contained fewer than characters to begin with, it is considered to +be exhausted starting from the first pass). The second dummy +is set to the remainder of the IRP string, following the characters +forming the first dummy's value, but containing only those +characters that will eventually get into the first dummy. That is, if +the number of passes has been limited, the characters of the IRP +string that will never appear in the first dummy because it +would take too many passes to get that far, will not appear in the +value of the second dummy on any pass. + +Node: loops-C5c, Previous: loops-C5b, Up: loops-C5 + +Applications. + +To take an arbitrary substring of a string, limit the IRPNC to +a single pass. To select characters +FOO through FOO+10 of the dummy name BAR, + + IRPNC FOO,11,1,X,,[BAR] + ;in here, use X to refer to the desired substring + TERMIN + +To convert a SIXBIT value to text, index into a string of all +the SIXBIT characters in order. This IRPNC will +type on the terminal the version number of the program (using .FNAM2). + + REPEAT 6,[ + IFE .FNAM2_<6*.RPCNT>,.ISTOP + ;GIVE UP IF ONLY SPACES REMAIN. + TEMP==77&<.FNAM2_<6*<5-.RPCNT>>> + ;ISOLATE THE NEXT CHAR TO BE TYPED + IRPNC TEMP,1,1,X,,[ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_] + PRINTX aXa ;NOTE LOWER CASE "a" IS NOT SIXBIT + TERMIN + ] + +To XOR together all the words of an ASCII string, +use this macro: + + DEFINE FOO STRING + < + IRPNC 0,5,-1,BAR,,[STRING] + ASCII /BAR/#TERMIN + >TERMIN + +Node: loops-C6, Previous: loops-C5, Up: loops-C + +A COMPLICATED IRP EXAMPLE + +This shows how to assign several symbols default values (that is, +set them only if they haven't already been set). It allows +each symbol to accompany its value, and either = or == may be +used for each symbol independently. + + IRPW X,,[ + FOO==1 ;mumble + BAR==500 ;bletch + ] + IRPS Y,,[X] + IFNDEF Y,X + .ISTOP + TERMIN TERMIN + +expands into + + IRPS Y,,[ FOO==1 ] + IFNDEF Y, FOO==1 + .ISTOP + TERMIN + IRPS Y,,[ BAR==500 ] + IFNDEF Y, BAR==500 + .ISTOP + TERMIN + +which expands into + + IFNDEF FOO, FOO==1 + IFNDEF BAR, BAR==500 + +Note that the expansion is described as a two-step process only +to make it easier to understand the effects of the various IRP's. +In fact, it all goes on at once, coroutine-style. The flow of +control is approximately: read in the IRPW's arguments, +set up the first pass through the IRPW, encounter the IRPS +and read its arguments (which come out of the IRPW's body), +begin the first pass through the IRPS, perform the IFNDEF, +hit the .ISTOP which exits from the IRPS, preventing further +passes through it, try again to read from the IRPW body, reach +the end of it and then set up for the next pass through the IRPW. + +MIDAS Node: Cond, Up: Top, Previous: Loops, Next: Arithmetic + +Conditional Assembly in MIDAS + +Maybe someday this node will be INFO-ized. + +@. OVERVIEW. + +It is often desirable to decide at assembly time, rather than at +editing time, whether a particular piece of code is to be +assembled. One might wish to assemble different versions of a +program, usually based on the value of some symbol. Also, in +order for arbitrary functions to be expressed by macros, +conditionals are needed. When thinking about MIDAS conditionals, +one should always remember that MIDAS is a string-processing +language which simply happens to output the values of most +expressions evaluated into the binary file. + + +A. CONDITIONALS IN GENERAL. + + 1. SYNTAX OF CONDITIONALS. + +Every MIDAS conditional construct begins with a pseudo which +introduces the condition. This pseudo may require arguments +which are part of the condition - a given conditionalizing +pseudo always requires a particular number of arguments. After +those arguments, if any, comes the text to be conditionalized, +in a format independent of which condition was tested. + + 2. WHERE CONDITIONALS MAY BE USED. + +Because the constructs begin with pseudos, they are only +recognized as such in places where symbols' values are being +examined. Those are exactly the places in which macro calls will +be recognized. explicitly, something that looks like a +conditional but appears inside a macro definition, a text +string, a comment, a macro call, etc. will not be treated as a +conditional but as part of the macro body, text string, comment, +or macro argument, etc. Of course, if the conditional appears +inside a macro definition, when the macro is called the +conditional will be recognized unless there is something else to +stop it. The point is that in + + DEFINE FOO + IFN 0,TERMIN + +the TERMIN shown does end the definition of FOO even though it +is inside what appears to be a failing conditional, because that +conditional is not recognized at macro definition time. The +definition of FOO is "IFN 0,". When the macro FOO is called, it +will expand into a conditional, which WILL be recognized that +time. Thus, + + FOO BAR + +will not assemble the BAR because the BAR will be inside a +failing conditional. + + 3. SYNTAX OF THE CONDITIONALIZED TEXT. + +The conditional pseudo, together with arguments if any, are +usually arranged to end with a field-terminator (SPACE or +COMMA). The first character after that field-terminator is the +beginning of the conditionalized text. The extent of the +conditionalized text is determined in one of three ways, depending +on whether that first character is one of "[" and "{". + + a. one line conditionals. + +If the first character is not "[" or "{", then the +conditionalized text is the rest of the line containing the +conditional. For example, + + IFN X,FOO+BAR + +conditionalizes the string "FOO+BAR" on the value of X. It does +not matter how many "["'s or "]"'s there are in the line. There +may be other conditionals in the line, but it isn't wise to have +any multi-line bracketed ones start in the conditionalized line. + + b. bracketed conditionals. + +If the first character is "[", the conditional is called +"bracketed". In this case, the conditionalized text runs up to +the "]" that matches the "[". The opening "[" and the closing +"]" are ignored except for their function as delimiters of the +conditionalized text. Other "["'s and "]"'s in the +conditionalized text act as normal, as well as being counted to +find the end of the conditional. The conditional may span many +lines, or may be only a part of a line. For example, + + IFN X,[BAR-]FOO + +assembles either FOO or BAR-FOO depending on the value of X. +However, + + IFN X, [BAR-]FOO + +conditionalizes the string " [BAR-]FOO" because the first +character of the conditionalized text is not a "[". + +Note that though when the conditional fails, the brackets inside +the conditional are just those that are visible, since macros, +etc., are not expanded if the condition fails, if the condition +succeeds the expansion of macros may cause other brackets to +appear inside the conditionalized text. If such brackets are +unbalanced, they may cause the opening "[" of the conditional to +match a bracket other than the intended one, which may in +obscure circumstances ruin the assembly. + +If the "]" of a failing bracketed conditional is missing, the +assembly will by a complete loss. In that case, the error +message will say where the beginning of the conditional was +located. If the "]" of a successful bracketed conditional is +missing, no harm results unless a literal was in progress. +However, it means that if in another assembly the same +conditional failed (perhaps due to different parameter +settings), lossage would occur. Therefore, MIDAS prints a +message at the end of the assembly stating that there was +an unterminated successful conditional, and says where the +first one was. Fixing that one and reassembling will cause +MIDAS to find the second one, if there are any more. + +The reason that MIDAS must remember unterminated successful +bracketed conditionals is that a "]" in MIDAS may terminate +a literal or a conditional, and MIDAS has to be able to +decide which whenever a "]" is seen. This means that when +a .STOP, .ISTOP, .GO or .TAG is inside "[" - "]" pairs, +lossage can result because brackets are skipped over, +causing the "[" stack to get out of phase with the position +in the macro or loop. For this reason, bracketed conditionals +should never be used to conditionalize those four pseudos. +Braced conditionals should be used instead. + + c. braced conditionals. + +Braced conditionals look just like bracketed conditionals +except that braces ("{" and "}") are used instead of brackets. +Braced conditionals count ONLY braces when matching up - +brackets have no effect on them. + +Semantically, braced +conditionals are almost the same as bracketed conditionals +but the few differences are important in some situations. +The differences come from the fact that MIDAS does not keep +a stack of all unterminated successful braced conditionals, +whereas for bracketed conditionals it does. MIDAS can get away +without such a stack because braced conditionals cannot be +confused with literals, unlike brackets. This has two +consequences: first, MIDAS cannot warn the user about +unintentionally unterminated successful braced conditionals; +second, intentionally unterminated braced conditionals are +possible. If that boggles your mind, note that in + + IFE X,{.STOP } + +the conditional is unterminated if it is successful. +Also, because brackets do not interfere with braced +conditionals, constructions such as + + IFE X,{ASCII/ + [/} + +are possible. While overall unbalanced brackets are unwise, +it may be reasonable to have such constructions +in parts of a macro which as a whole has balanced brackets. + +There are reasonable constructions which can sometimes +result in unmatched braces/brackets, and for which therefore +only braces should be used. An example is the hack for OR'ing +two condions: + + IFN X,{IFNDEF A,} + +If the IFN succeeds but the IFNDEF fails, the "}" will not +be assembled. If brackets were used, that might cause trouble. + + 4. .SUCCESS, .ALSO, .ELSE. + +After the testing of the condition, when it has been decided +whether the conditional has succeeded or failed, the symbol +.SUCCESS is given a value automatically - 0 if the conditional +failed, and -1 if it suceeded. Also, after the "]" terminating a +bracketed conditional, .SUCCESS is again set to the same value. +The conditionals .ALSO and .ELSE test the symbol .SUCCESS's +value, and may be used to generate IF-THEN-ELSE constructs as +follows: + + IFN X,FOO + .ELSE BAR ;assembles either FOO or BAR. + + IFN X,[ FOO ] + .ELSE [ BAR ] + ;similar, but now it works even if + ;"FOO" is a macro containing conditionals + ;that clobber .SUCCESS. + + IFN X,IFN Y,FOO + .ELSE BAR + ;assembles FOO if both X and Y are nonzero. + ;assembles BAR otherwise + + IFN X,[IFN Y,[FOO]] + .ELSE BAR ;if X=1 and Y=0, assembles nothing. + + IFN X,FOO ;assembles either FOO and MUMBLE, or BAR + .ELSE BAR ;because .ELSE sets .SUCCESS. + .ELSE MUMBLE + + IFN X,FOO + .ALSO BAR ;assembles FOO and BAR, or nothing. + +B. THE CONDITIONS AVAILABLE. + +This section describes all the conditional pseudos in MIDAS and +their conditions and arguments. + + 1. ARITHMETIC CONDITIONALS. + +These conditionals all test the sign of an expression. They are: + + IFN X,FOO ;assemble FOO if X is nonzero + IFG X,FOO ;assemble FOO if X is positive + IFGE X,FOO ;assemble FOO if X is nonnegative + IFL X,FOO ;assemble FOO if X is negative + IFLE X,FOO ;assemble FOO if X is nonpositive + IFE X,FOO ;assemble FOO if X is zero + + 2. STRING CONDITIONALS. + +These take two string arguments and compare them for equality. +IFSE succeeds if the strings are equal; IFSN, if they are not. +The case of alphabetic characters is ignored, so "a" and "A" match. +The syntax of the string arguments is the same as that of normal +macro arguments except that "\" is not special as the first +character. Examples: + + IFSE FOO,BAR,[BLETCH] + ;assembles BLETCH if FOO and BAR are equal + ;strings (which obviously can't be the case + ;unless either FOO or BAR is a macro dummy + ;argument which will be replaced by something). + + IFSE FOO,[BAR][BLETCH] + ;has the same meaning, but now "[]" are used to + ;delimit the second string argument. This makes + ;it possible to win if BAR contains commas or + ;CRLF's. Note that, as with bracketed macro + ;arguments, a comma is not needed after [BAR]. + ;In fact, a comma there would be wrong: + + IFSE FOO,[BAR],[BLETCH] + ;conditionalizes the string ",[BLETCH]", because + ;the first character of the conditionalized text + ;is the comma, so the "[" in front of the + ;"BLETCH" is not recognized. + + IFSE [FOO][BAR][BLETCH] + ;this is just like the first example, but now + ;FOO and BAR may contain commas or CRLF's. + + 3. CONDITIONALS ON SYMBOL DEFINITION. + +These conditionals test whether a specified symbol is defined. +The symbol should follow the conditional name, ended by a +field-terminator, which is followed by the conditionalized text. +The pseudos are IFDEF, which succeeds if the symbol is defined, +and IFNDEF, which has the opposite sense. For example, + + IFNDEF FOO,FOO=1 + ;defines FOO to be 1 if it isn't defined + ;already. it is a good idea to define all the + ;assembly parameters of a program in this way so + ;that it is not necessary to edit the program to + ;assemble it with different settings - instead, + ;just assemble the program with the "T" switch + ;in the command string and then type the desired + ;definitions in from the TTY. + + IFNDEF FOO,.M"FOO=1 + ;if FOO isn't defined, defines it in the main + ;block (the previous example would define it in + ;the current block. + + IFNDEF XX"FOO,XX"FOO=1 + ;if FOO isn't defined in block XX, defines it to + ;be 1. + + IFDEF FOOBAR,PUSHJ P,FOOBAR + .ELSE JFCL + ;call the FOOBAR routine if the user has one. + ;this might appear in a package that is + ;.INSRT'ed by several programs. + ;The .ELSE is needed because on pass 1 it will + ;not in general be known yet whether the user + ;has a FOOBAR routine. + + 4. "BLANKNESS" CONDITIONALS. + +These conditionals take a single string argument, using macro +argument syntax (just like IFSE), and test whether it contains +any SQUOZE characters (letters, digits, and ".", "$", "%"). The +string is "blank" if it has no SQUOZE characters. The +conditionals are IFB "If Blank" and IFNB "If Not Blank". +Examples: + + IFB X,FOO + ;assembles FOO unless X contains a SQUOZE + ;character. Since "X" IS a SQUOZE character, the + ;conditional will always fail unless X is a + ;macro dummy argument. + + IFB [X]FOO + ;has the same semantics, but X may now contain + ;commas, CRLF's, etc. + + 5. SQUOZENESS CONDITIONALS. + +These conditionals are somewhat like the blankness conditionals, +but instead of testing whether any of the characters in the argument +is squoze, they test whether all of the characters are squoze. The +conditionals are IFSQ "If all SQuoze" and IFNSQ "If Not all SQuoze". +Examples: + + DEFINE FOO X + 1+< IFSQ X,[1] > + TERMIN + + FOO BAR ;assembles 2 + FOO BAR BLETCH ;assembles 1 + + 6. PASS CONDITIONALS. + +These two conditionals allow different things to be assembled on +pass 1 and pass 2. IF1 succeeds only on pass 1, and IF2 only on +pass 2. Note that the conditionalized text starts with the +character after the space or comma that ends the name of the +pseudo. One use is to avoid defining macros on pass 2: if a +macro is never to be redefined, there is no need to define it on +pass 2, because it already has the correct definition, given to +it on pass 1. Thus, + + IF1 [ DEFINE FOO + .... + TERMIN ] + +Another use might be: have a macro to make entries in the FOO +table. On pass 1, simply have the macro count up the number of +times it is called. Then, at the end of the file, allocate +enough words for the table. From then on, the address of the +table is known, so on pass 2 the macro can actually assemble +values into the words of the table. +Caution is needed when using pass conditionals, because, by +assembling more words on one pass than on the other, it is easy +to cause all the labels in the rest of the program to yield +"MDT" errors, because their addresses on pass 2 are not the same +as they were on pass 1. Also, one should avoid using any literals +on pass 2 that were not used on pass 1 (but doing the opposite +can't do worse than make the constants area waste some space). + + 7. .ELSE AND .ALSO. + +.ELSE and .ALSO exist to make a generalized IF-THEN-ELSE +construction possible. They act just like "IFE .SUCCESS" and +"IFN .SUCCESS" respectively. The conditionalized text starts +after the space or comma that terminates the pseudo itself. See +section A.4. for more details. + +MIDAS Node: Arithmetic, Up: Top, Previous: Cond, Next: FASL + +The arithmetic-statement pseudo-ops: .I and .F + B.K.P. Horn + + This is a feature of MIDAS which facilitates the rapid writing + and debugging of programs involving much nmerical calculation. + The statements used are ALGOL-like and easy to interpret. + +[ Note: This was originally written as AI Memo #179, Aug 1969, and +has been copied into this file with as much versimilitude as possible] +--------------------------------------------------------------------------- + +An arithmetic-statement expander: + +Since the Incompatible Timesharing System (ITS) does not support an ALGOL +style compiler, it is very tedious to perform even the simplest algorithms +of numerical analysis. To alleviate this problem without an inordinate +amount of effort, two pseudo-ops were added to MIDAS (the macro-assembly +language). + +The pseudo-ops are .F and .I. The first of these will have the arithmetic +in the arithmetic statement following it performed in floating point, +the latter in fixed point. + +Each statement is treated without reference to any of the others. Spaces +may apear in a statement almost everywhere and are ignored. Exceptions are +in the continue part of a continuation statement and in a subscript. (see later +on) + +Arithmetic statements are combinations of variable names, numbers, function +names and operators. Normally each statement specifies the calculation of +one or more values and where they are to be stored. + +The operators are: + = ( ) < > ^ / * + - # $ , + +A number is a character-string starting with a numberic character (0, 1 ... 9) +followed by non-operators. This number should make sense to MIDAS. The +operator ^ is permitted to appear in the number, being the separator used +in MIDAS for the exponent of a number. + +A variable (or function) name is a character-string starting with a character +which is neither numeric nor a operator and consists of up to six non- +operators. + +/ * + - have the usual meaning of divide, multiply, add and subtract. ^ is +used for exponentiation. ( and ) are used to force the precedence as usual, +ie normal evalutaion proceeds from left to right, with exponentiation +being performed first, then multiplications and divisions, and additions and +subtractions last, except that expressions in parentheses are evaluated first. +This is strictly adhered to and thus A^B^C = (A^B)^C unlike the FORTRAN +convention A**B**C = A**(B**C). Nested pairs of parentheses are evaluated from +the inside out. + +Intermediate results are kept in a stack which has to be in the accumulators +and is defined by the user. These accumulators are called A0, A1, ... A9. +If fixed point arithmetic is used, Ai must not be = Aj+1 if i surround the arguments of a function. The arguments are separated by +commas. Thus a name as defined above is a function name if it is followed by +a <. For example: + + MAX and RANDOM<> + +If used not directly following a name, < and > act exactly like ( and ). + +Functions return a single value in A0. The assembled code includes a PUSHJ P, +to the function, the user being responsible for providing a subroutine which +accepts the arguments as presented in A0, A1, etc., does not disturb any +accumulators other than those in which the arguments were passed and returns +the result in A0 before executing a POPJ P, . + +A variable name followed directly by a ( is considered to be a vector. The +subscript between the ( and the matching ) can be of the following form: + + ACxNUM + xNUM+AC where "x" is either "+" or "-". + +Where AC is the variable name of an accumulator in which the subscript is +assumed to have been loaded. NUM is a number, acting as a displacement. + += indicates that the value available at this point (as calculated by the +portion of the arithmetic statement to he right) is to be stored as the +value of the variable name to its left. More than one = may thus appear +in one arithmetic statement. Fo example: + +.F A=B=ARM-LOSS=FOO*BARF + +This invokes the multiplication of FOO by BARF, storage of the result in LOSS. +Next LOSS is subtracted from ARM and the result stored in both A and B. More +complicated constructs are possible by making use of parentheses. Some care +is required in arranging the right sequence of storage operations so as not +to overwrite values needed further on. (perhaps a more intuitive structure +could be given to multiple equals if one did not adopt the FORTRAN like +convention of having the statement follow the equals). + += permits the passing of arguments by name rather than value, ie it performs +a quoting action. This is particularly useful for subroutines operating on +vectors (dotproduct for example), or subroutines executed for their effect +rather than their value. It also permits the passing of a function address +as a argument. This is achieved by surrounding the variable name with [ and ]. + +$ indicates a continuation and must be directly followed by a carriage-return +and linefeed (usually supplied by TECO anyway) and either .I or .F +(which is ignored), a space or tab and the continuation of the statement. +For example: + +.F ZANSWER=273.0/T $ +.F -IN*VEST*MENT + +Unitary + and * are ignored. Unitary / and - are interpreted as 1.0/ and 0.0- +respectively. = and ^ may not appear unitarily. + +Since @ and ' may be part of a variable name, one can make full use of MIDAS's +indirect addressing and automatic variable storage assignment conventions. The +use of @ comes in very handy when working with multi-dimensional arrays +addressed through margin-arrays. + +^ normally generates a call to a function called EXPLOG, which gets two +arguments. To facilitate generation of fast inline exponentiation one may +follow the ^ directly by the single digits 1, 2, 3, or 4. For example: + +.F R=SQRT + +MIDAS Node: FASL, Up: Top, Previous: Arithmetic, Next: Blocks + +Assembling Files to be Loaded by MacLisp + + Midas can now assemble FASL files that can be loaded +by LISP in the same manner as LAP FASL output. This mode is +entered by the .FASL pseudo op, which must appear at the +beginning of the file before any storage words. + After .FASL has been seen, the assembly becomes a +two pass relocatable assembly. However, certain +restrictions and "changes of interpretation" apply. + Global symbols (declared as usual with " or .GLOBAL) +are persmissible. However, since the output is to be loaded +with FASLOAD using DDT's symbol table instead of STINK, +there are quite a few differences in detail. + For symbols defined within the current assembly, the +only effect of being declared GLOBAL is that the GLOBAL +information is passed on to FASL when the symbol table is +written at the end of pass 2. This in combination with the +SYMBOLS switch in FASLOAD determines whether the symbol gets +loaded into DDT's symbol table. If SYMBOLS is NIL, no +symbols will be loaded; if SYMBOLS is EQ to SYMBOLS, only +globals will be loaded; and if SYMBOLS is T, all symbols +(local and global) will be loaded. Once the symbol is +loaded (or not), the information as to its GLOBALness is +lost and, of course, makes no further difference. The +initial state when LISP is loaded is NIL. + GLOBAL symbols not defined in the current assembly +are also legal, but there are additional restrictions as to +where in a storage word they may appear and what masking may +be specified (as compared to a normal relocatable assembly). +Briefly, they may appear as in a storage word as a full +word, a right half, a left half, or an accumulator. They may +be negated, but can not be operated on with any other +operator. Error printouts will be produced if they appear +elsewhere. When the symbol is encountered by FASLOAD, DDT's +symbol table is consulted. If it is defined at that time, +OK, otherwise FASLOAD will generate an error. + Any sort of global parameter assignment or location +assignment is Forbidden. .LOP, .LVAL1, .LVAL2, etc are not +available. + + +New Pseudo OPs Available only in FASL assemblies. + + The following pseudos are available to facilitate +the communication between MIDAS assembled programs and LISP +(particularily with regard to list structure). + +.ENTRY function type args + + Function is an atom and is taken as the name of + a function beginning at the current location. Type + should be one of SUBR, FSUBR or LSUBR, and has the + obvious interpretation. Args is a numeric-valued field + which is passed thru to FASLOAD and used to construct + the args property of the function. If it is zero, no + args property is created. Otherwise it is considered to + be a halfword divided into two 9 bit bytes, each of + which is converted as follows: + byte result + 0 nil + 777 777 + otherwise n n-1 + These two items are then CONSed and from the + args property. + +The following pseudos may appear in constants!! + +.ATOM atom + + followed by a LISP atom in "MIDAS" format (see below). + May only appear in right half (or entire word) of a + storage word. Assembles into a pointer to the atom + header of the specified atom. + +.SPECI atom + + similar to .ATOM but assembles into a pointer to the + SPECIAL value cell of the specified atom. + +.FUNCT atom + + similar to .ATOM, but invokes special action by FASLOAD + in case the PURESW is on. Normally used in function + calls. Briefly, if FASLOAD is going to purify the + function it is loading, it must "snap the links" first. + If .FUNCT is used, the location will be examined by + FASLOAD and the link snapped if possible before + purification. + Typical usage: + CALL 2,.FUNCT EQUAL ;calls equal as a function of 2 args + ; note: the CALL is not defined + ; or treated specially by MIDAS. + +.ARRAY atom + + similar to .ATOM, but assembles into a pointer to the + Array SAR. + +.SX S-expression + + similar to .ATOM, but handles a LISP S-expression. + (See below). + +.SXEVA S-expression + + reads S expression. This S expression is EVALed (for + effect presumably) at FASLOAD time. The resulting + value is thrown away. Does not form part of storage + word. + +.SXE S-expression + + Similar to .SX but list is EVALed at FASLOAD time. The + resulting value is assembled into storage word. + + +The MIDAS "LISP READER" + + By a conspiracy between MIDAS and FASLOAD, a version +of the LISP reader is available. However, due to historical +reasons (mostly, i.e. the FASLOAD format was originally +intended only to deal with COMPLR type output), there are a +number of "glitches" (see below for list). These will +probably tend to go away in the fullness of time. + +a) numeric ATOM + + The first character of a LISP atom is examined +specially. If it is a # or &, the atom is declared to be +numeric and either fixed (#) or floating (&). Midas then +proceeds to input a normal numberic field (terminated, note, +by either space or comma). This value is then "stored" in +the appropriate "space" (fixnum space or flonum space). + +b) other ATOMs (also known as PNAME atoms or (LISP) SYMBOLS) + + If the first character of the atom is not # or &, +the atom is a "PNAME" atom. / becomes a single character +quote character as in LISP. The atom may be indefinitely +long. The atom will be terminated by an unquoted space, +carrige return, tab, (, ), or semicolon. Unquoted linefeeds +are ignored and do not become part of the atom. The +character that terminates the atom is "used up" unless it is +a ( or ). Note that period is a legal constituent of a atom +and does not terminate it or act specially. + +c) lists. + + Work normally, but note following caution relative +to dot notation: . does not terminate atoms. Thus, to +invoke dot notation, the dot must be left delimited by a +space, tab, parenthesis, or other character that does +terminate atoms. + +Glitches: + + 1) Restriction on pass dependant list + structure -- In any list reading operation, no new + atoms not previously encountered may be + encountered for the first time on pass 2. + However, this restriction does not apply to + atom-only reading operations (.ATOM, .SPECI, + .FUNCT etc). + 2) Single quote for quoting does not exist (no + other macro characters exist either.) + 3) Numbers must be flagged as above always. + MOVEI A,.ATOM 123 ;LOSES - gives pointer + ; to PNAME type atom + ; with PNAME 123. it is + ; not numeric. + use: + MOVEI A,.ATOM #123 ;WINS + 4) No provision exists to reference "GLOBALSYMS" + in FASLOAD. This mostly means only that DDT must + be present to load a MIDAS assembled FASL file. + (some simple COMPLR and LAP FASL files can + successfully be FASLOADed by, for example, a + disowned LISP running without a DDT. + 5) LOC is illegal in a FASL assembly. BLOCK of a + non-relocatable quantity is ok. + 6) Currently, symbol loading is VERY slow. Thus + use SYMBOLS nil, (the initial state) unless + symbols are necessary. + 7) Midas does not know about any LISP symbols or + UUOs specially. Use them as globals until someone + gets around to fixing up a .INSRT file with the + appropriate defs. + 8) .ATOM "should" be a special case of .SX . + However, it is handled separately because of the + following "reasons": + a) The previously noted restriction on pass + dependent LISTS. + b) Midas can do constants optimization on + atoms ppearing in constants (on both pass one + and pass two) but not on LISTS. Therefore, + each list is guaranteed to take a separate + word in the constants area even if it is + identical to some other list which also + appears in a constant. + c) Each list takes an additional entry in + FASLOAD's "atom" table. This is a temporary + table that is flushed after the FASLOADing is + complete. Of course, .SX still works for + atoms modulo the above noted restrictions and + inefficencies. + +MIDAS Node: Blocks, Up: Top, Previous: FASL, Next: Constructs + +Symbol Table Block Structure + + The MIDAS symbol table allows blocks of code to be defined within +which local definitions of symbols can be made. Local definitions are +normally visible within the blocks they belong to, including other smaller +blocks included in them, but are normally invisible outside. However, it +is possible to examine or set the local value of any symbol in any block +explicitly, whether inside the block or outside it. The intended +application of block structure is for libraries that are to be assembled +into other programs with .INSRT. Because there is a natural tendency to +use block structure in assemblers for purposes that do not merit it, any +temptation to use block structure for any other reason should be +entertained only with great self-restraint. + + A block is entered with a .BEGIN and exited with a .END. Both the +.BEGIN and the .END should be followed by the name of the block. It is +not usually wise for two blocks to have the same name, although it is legal +if the two are contained in different blocks. .BEGINs and .ENDs must +match. .BEGINs and .ENDs serve as a sort of parentheses, and impose a tree +structure on all blocks, so that each block has a direct superior and any +number of direct inferiors. Initially, even if you never use .BEGIN and +.END, there are two blocks in the structure: .INIT, which contains the +predefined MIDAS symbols, and .MAIN, which is the one which your program is +in. .MAIN is a subblock of .INIT, and any other blocks you .BEGIN are +direct or indirect inferiors of .MAIN. .END should not be confused with +END, which ends the whole assembly. Block names do not conflict with any +other kinds of names. + + A simple example of block structure will explain much: + + A=1 + A ;Value of A is now 1. + .BEGIN FOO ;Enter a block named FOO. + A ;Value of A is 1 on pass 1, but 2 on pass 2. + A=2 + A ;Value of A is now 2. + .END FOO ;Exit block FOO. Now back in main block. + A ;Value of A is now 1 again. + END + +This program will assemble four words: 1, 2, 2 and 1. This is because, on +pass 2, the local definition of A in block FOO becomes visible as soon as +the .BEGIN FOO is passed, and ceases to be visible when the .END FOO is +passed. The definition of A as 1 in the main block is always visible, +except that within FOO it is "shadowed" by a more local one. + + Whenever a symbol's value is used, the most local definition which +is visible determines the value. That is, within block FOO, where both the +local definition in FOO and the definition in the main block are visible, +the more local one (in FOO) wins out. When a symbol is defined, however, +it is always defined in the current block unless you specify otherwise. +All operations that affect the symbol's value in any way are counted as +definitions in this regard; this includes such things as .HKILL, .KILL, +EQUALS, DEFINE, :, and =. + + When you wish explicit control of shadowing, you can use .BIND. +.BIND is followed by a list of symbols, and forcibly markes them as local +to the current block, if they were not already defined locally therein. +Definitions in outer blocks are hidden by this, so that a symbol defined +outside the current block can become undefined inside it, after a .BIND, +until a definition in that block is seen. .BIND can be used to force +shadowing of some predefined symbols which it is normally an error to +shadow. + + One use of .BIND is to force forward references in a one pass +assembly to a symbol defined in an outer block which is going to be defined +locally in the current block later on. One pass assemblies and block +structure are a can of worms anyway. Normally, a symbol defined in an +outer block is NOT visible in lower blocks, unless it is a macro or pseudo, +or you mention it in a .DOWN statement. If it is a macro, and you don't +want to see it in an inner block, you must .BIND it. + + The distinctive feature of MIDAS block structure is the ability to +look at or set the definition of any symbol in any block at any time. This +makes it possible for a block to define symbols in its containing block, or +in the main block (a practice whose wisdom is currently a subject of +debate). It also allows an outer block to define and refer to symbols in +an inner block, which is the main way of communicating with .INSRTed +libraries, and is essential. + + The way to refer to a symbol in a specific block is to prefix the +symbol's name with the block name and a doublequote. Thus, FOO"BAR means +the value of BAR in block FOO. This construct can be used wherever a +symbol name can appear, in both references and definitions. If there is or +might be more than one block named FOO, it can be qualified by the name of +the containing block, as in UGH"FOO"BAR, which means the value of BAR in +that block named FOO which is directy inside a block named UGH. In +addition, there are a few special "block names": .C signifies the current +block, and .U signifies the direct superior of the current or specified +block. Thus, .U"BAR means the value of BAR in the block containing the +current one. FOO".U"BAR means the value of BAR in the direct superior of +the block FOO. .U"FOO"BAR means the value of BAR in the block FOO which is +a sibling of the current one (that is, it and the current one have the same +direct superior). + +MIDAS Node: Constructs, Up: Top, Previous: Blocks, Next: Pseudos + +MIDAS constructs, in alphabetical order: + +! is the concatenation character inside macro definitions, + IRP bodies, and .TTYMAC's. An ! next to either a dummy name + or the final TERMIN will be thrown away. For example, + inside DEFINE FOO A,B, A!!B will concatenate A's value and B's, + as will just A!B. A!!!B will leave one ! between them (the + middle ! is not adjacent to either A or B). That may be what + you want to do if you are expanding an inner macro definition + and A or B wil expand into one of that definition's dummies. + +" has four constructs: + + " + makes the global, as well as referring + to the 's value. + " + refers to the value of in the specified + block. Also, .C refers to the current block, + .M to the main block, and .U to the block containing + the current one. Multiple use of this construct is + allowed: FOO".U"BAR"BLETCH refers to BLETCH + in the block named BAR which is contained in the + block which is the father of the block FOO. + " + assembles right-justified ASCII for . + contains at least one character in any case, + and all following squoze characters. + This construct exists only if .QMTCH is zero + (as it initially is); otherwise, the next construct + exists instead: + "" + assembles right-justified ASCII for . + may contain anything; doublequotes may be + put in using the PL/1 quoting convention + ("""" gives the ASCII for a doublequote). + +# XOR operator. + + # gives the XOR of and . + # gives the complement of . + ## therefore gives "neither nor ". + +& AND operator. + +' has several constructs, syntactically distinguished. + + ' + makes a variable; like + < .SCALAR ? > + This construction is a bad one because it makes + it easy to assign a storage word without commenting + what its contents will mean. It exists for historical + reasons. + + ' + forces the use of base 8 in the number, regardless + of the current radix. + + ' + like ", but generates SIXBIT instead of ASCII. + + '' + like "", but generates SIXBIT instead of ASCII. + +(,) () has the value of with its halves + swapped, if preceded by an arithmetic operator. + Otherwise, it takes that halves-swapped value and adds it into + the current word, and is invisible to its neighbors. + For example, 1(2)+3 == 1+3(2) == 4(2), and all are the same as + 4 except that 2 is added to the left half of the current word. + +* Multiplication operator. + ++ Addition operator. + +, Field terminator. It is used for separating the fields of a word, + and also terminates the arguments to many pseudos and macros. + +- Subtraction operator, and unary negation operator. + +/ Division operator. + +: indicates a label. + + : + defined to be equal to the current value of ".", + which is equal to the location being loaded into + plus the offset (normally 0, but see .OFFSET). + There may not be any spaces before the colon. + Once a symbol has been defined as a label, it is an error + to give it a different value in any way. + :: + is similar but "half-kills" , so DDT will not + use it for type-out. + +; begins a comment, which is ended by the following carriage return. + That carriage return is not gobbled; it has its normal effect. + ";", like all other MIDAS constructs, is not recognized inside + of text strings; also, it is recognized in macro argument scanning + only in certain specific situations (see MACROS >). + +<,> in MIDAS are like parentheses in algebra. + They for a "grouping" (other groupings are made by (,) and [,]). + They are generalized to allow more than one expression to be + within them; the last one's value is the value of the grouping. + This makes it possible to do assignments, etc. before computing + the ultimate value. + += is the assignment operator. + + = + sets 's value to 's. + If there are undefined symbols in the + assignment is not performed. + This construct is illegal where a value is needed, + but if it is the last thing in a grouping it does + supply the value of the grouping. Thus, + FOO= is legal, though FOO=BAR=1 is not. + == + is similar but half-kills + =: + is like "=" but makes it an error if ever + gets (or previously had) a different value (this is + what labels do; =:. is just like :). + ==: + makes half-killed and unredefinable. + +? separates words. ? is just as good as a carriage-return + for most purposes, the exceptions being termination of + macro arguments and conditionals (? does not terminate them). + That facilitates constructs like + IFN FOO, MOVE A,B ? JRST BAR + which conditionalizes both instructions. + +@ sets the indirect bit of the word it is in. + +[,] delimit a literal. Their value is the address of the space + MIDAS allocates to contain whatever is assembled inside them. + There may be any number of lines or words in the literal. + Example: MOVEI A,[.BYTE 7 ? ^M ? ^J] + loads A with the address of a word containing the ASCII + for carriage-return linefeed. + +\ Inclusive-or operator. + +^ has several constructs: + + ^ + has the value of the control-character associated + with . Thus, ^M is 15 . + + ^ + + multiplies by 's own radix to the + power. Thus, 1.^6 is 1 million. + 777^11 is the op-code field. + This construct works for floating point numbers as well: + 1.0^6 = 1000000.0 . + +_ left-shift operator. + NOTE: this is an arithmetical, not logical, shift! + +MIDAS Node: Pseudos, Up: Top, Previous: Constructs, Next: Outformats + +Alphabetical list of MIDAS pseudo-ops + +$. Location being loaded into. Works only via STINK. +$L. REAL LOCATION (WITHOUT OFFSET) (only in STINK format) +$O. GLOBAL OFFSET (only in STINK format) +$R. The relocation factor (only in STINK format) +. = address of current code word. In a literal, . refers + to the location of the word containing the literal, not the + word in the literal. + The offset is included in the value of .. +.1STWD put before a text-generating pseudo (SIXBIT, ASCII, + ASCIZ, ASCIC, .ASCII) to throw away all but the first + word of text. +.ABSP , + returns the "absolute part" of . +.ALSO conditional: "If the previous conditional succeeded". + (See *Note Cond: Cond, for conditional info) +.AOP is like .OP, but returns no value. However, all the + information is still available in .AVAL1 and .AVAL2. +.ARRAY reference a lisp array (.FASL feature) +.ASCII /text/ + Like ASCIZ, but when the character "!" is encountered in the + text, the following it is evaluated and the value + inserted into the assembled string as a sequence of digits in + the current radix, replacing the "!" and the expression. + Terminate with a space or comma, which unfortunately will become + part of the assembled string. +.ASCVL / + (Yes, only one "/") returns the ascii value of . +.ASKIP -1 if instruction executed by most recent .OP or .AOP + skipped; 0 if it didn't skip. +.ATOM + refer to header of named LISP atom (see *Note Fasl: Fasl.) +.AUXIL does nothing - it exists for the sake of the listing program "@". +.AVAL1 What was left in the ac by the instruction executed by + the most recent .OP or .AOP +.AVAL2 What was left in the memory location by the .OP or .AOP. +.BEGIN + begin a symbol-scope block. defaults to + most recent label. +.BIND ,... + Create bindings for these symbols in the current block. + Must be used when it is desired to shadow a built-in + symbol under certain circumstances. Also sometimes needed + in 1-pass assemblies when symbol is defined in higher block + and will be defined later in current block, to force a + forward reference to be made. +.BM , + returns a mask to the byte pointed to by the specified + byte pointer (address field ignored). If arg's LH is 0, + the arg will be swapped first to get a byte pointer. + The comma is thrown away except for ending the arg. +.BP , + returns a byte pointer to the byte which the argument is + a mask to. The address field of the value is 0. The comma + which terminates the argument is not flushed, so that + .BP , will produce a byte pointer to in + location . For those who understand .FORMAT, that + contrives to use the format field-space-field rather than + the problematic field-comma-field format, which many users + like to redefine. +.BYTC The number of bytes assembled since .BYTE mode was entered. +.BYTE N assemble N bit bytes. That is, take the assembled "words" + and pack them into N-bit bytes to get what is really output. + When another byte won't fit in the current word, the word is + output and a new one is started. +.BYTE M,N,O,P,... + assemble an M bit byte, then an N bit one, then an O bit one, etc., + returning to an M bit one after using the last of the specified sizes. + If a negative "byte size" is specified, it causes a block of zero bits + to be assembled right after the previous byte; the number of zero bits + is the abs. value of the specified number. This can cause an extra + zero word to be assembled if .byte mode is left right away. + In byte mode, "." is a byte pointer which could be ILDB'd to get + the next byte. +.BYTE with no arg leaves byte mode, returning to the initial state. +.C Current block (as in .C"FOO). +.CRFIL +.CRFOFF CREF off +.CRFON CREF on +.CURLN current line number minus 1 +.CURPG current page number minus 1 +.DECREL selects DEC relocatable output format +.DECSAV selects DEC/TNX SAV output format. Symbols are deposited + where the location counter points when END is reached, + and location 116 (.JBSYM) given a pointer to them. + Location 120 (.JBSA) is given the start address unless + the instruction furnished to the END pseudo has something + in the LH, in which case it is treated as an entry vector pointer + (only meaningful on TNX systems). +.DECTW + Two-segment DEC relocatable output format. + Arg is address of bottom of high segment (normally 400000). +.DECTXT /text/ + Like .TEXT in MACRO. .DECREL format only, outputs an ASCIZ REL + block consisting of the given text, which LINK interprets as a + command string. +.DOWN ,... + Causes the symbols to be visible in subblocks in 1PASS mode. + In 2-pass assemblies, symbols are always visible in subblocks + of the blocks they are defined in. In 1PASS mode, they are + usually not (except for macros), in case the same name is + defined later on in the subblock itself. +.DPB ,,, + deposits into the byte in specified by , + and returns the result. Thus, .DPB 0,30300,-1, returns -1,,777707 +.ELDC End a load-time conditional - STINK format only. + Any storage words appearing between a load-time conditional (e.g. + .LIFS, .LIFE, etc) and its matching .ELDC are passed on to the + loader, which will load them only if the conditional is true at + the time it is encountered during loading. .ELDC should always + be followed by a location assignment (eg LOC pseudo). Sometimes + if there is a series of load-time conditionals with no intervening + non-conditional words the LOC need only be used after the last. + Notice that LOC $." may be used to continue loading storage words + into subsequent locations where the effect of the load-time conditional + is not necessarily known. Load-time conditionals may be nested. +.ELSE conditional: "If the previous conditional failed". (*Note Cond:Cond.) +.END + terminate symbol-scope block, if its name is . Error + if the current block's name isn't . +.ENTRY .FASL feature - declare a LISP entry point (SUBR beginning, etc). +.ERR + Causes an error with error message +.ERRCNT Number of errors seen in entire assembly thus far. +.F floating mode Fortran arithmetic statement. + *Note .F: Arithmetic, for details. +.FASL Selects FASL output format, loadable by MACLISP. +.FATAL + Causes a fatal error with as the error code. + The output buffers are written out and the output files + are closed, though only the error output file is renamed. +.FNAM1 numeric value of sixbit for first file name of main input file. +.FNAM2 numeric value of sixbit for second file name of main input file. +.FORMAT fno,fval Specify interpretation of fields in a word. + See description in *Note Forma: Words. +.FUNCT + refers to the specified function, in FASL format. *Note Fasl: Fasl +.FVERS version number of main input file. +.GLOBAL ,... + Makes the specified symbols global. +.GO + assembly continues at .TAG tag (within macro body) + Non-local .GO's outward are allowed. +.GSCNT The value of the generated symbol counter - may be read or set. +.GSSET + same as .GSCNT= +.HKALL If nonzero, causes ":" to be treated as "::". +.HKILL ,... + Half-kills the specified symbols. Does not define them. + Acts only on the last pass. + Does shadow definitions in outer blocks, like .BIND. +.I integer mode Fortran arithmetic statement + *Note .I: Arithmetic, for details. +.IBP + returns incremented a la IBP instruction. +.IFNM1 numeric value of sixbit for first file name of insert file + (the file most recently .INSRT'ed by the current input file, + or the current file's name if it hasn't .INSRT'ed any others yet). +.IFNM2 numeric value of sixbit for second file name of insert file +.IFVRS version number of insert file. +.INEOF In an .INSRT file, acts just like EOF. +.INIT The outermost block (as in .INIT"MOVE). All the predefined + symbols are defined in this block. Symbol definitions in this + block are not output to the binary file. +.INSRT + Pushes the current input file and begins reading from the + specified file. After the end of that file, reading from + the inserting file will resume. If the sname of the file to + be inserted is not specified, that of the file being read + will be used. If the file is not found, the user will be + asked to respecify the names. .INSRT'ing the TTY is a + good way to let the user make arbitrary redefinitions at + some point in the assembly. +.IRPCNT # of completed iterations of innermost indefinite repeat +.ISTOP stop REPEAT or IRP - see *Note loops: Loops +.KILL ,... + The specified symbols will not go in the symbol table. +.LDB ,, + returns as a value the contents of the byte in + specified by . may be either a byte pointer + or the left half of one, as in .BM. +.LENGTH /text/ + returns the number of characters in the specified string. +.LIBRA namelist (linking loader pseudo - STINK format only) + This must occur before any storage words. It tells the loader + that the program to follow is a "library program". The entries + in the namelist, separated by commas, are either (a) names, or + (b) groups of names separated by space, +, and -. An entry is + said to be "satisfied" by a list of symbols if either (a) the entry + is a name and that name appears in the list of symbols; or (b) the + entry is a group of names, ALL of which names preceded by space or + + are in the lst of symbols, and NONE of which names preceded by + = are. STINK will omit to load a library program unless one or + more entries in its namelist are satisfied by the list of + undefined global symbols used in programs already loaded. +.LIBRQ nam1,nam2,... (linking loader pseudo - STINK format only) + This will output the given names to STINK such that the loader + "sees" them in this program when queried by load-time conditionals. + No definition is given to the loader, and a use of .LIBRQ does not + cause the names to be seen at all by the assembler. +.LIFE word Load if word = 0. (Load-time conditional, see .ELDC) +.LIFG word Load if word > 0. (Load-time conditional, see .ELDC) +.LIFGE word Load if word >= 0. (Load-time conditional, see .ELDC) +.LIFL word Load if word < 0. (Load-time conditional, see .ELDC) +.LIFLE word Load if word =< 0. (Load-time conditional, see .ELDC) +.LIFN word Load if word not 0. (Load-time conditional, see .ELDC) +.LIFS namelist Load If Seen. (Load-time conditional, see .ELDC) + This conditional is true only if one or more entries in the namelist + are satisfied by the list of defined AND undefined global symbols + used in programs already loaded. See .LIBRA for an explanation of + the namelist. +.LITSW if nonzero, using a literal causes an error message. +.LNKOT (linking loader pseudo - STINK format only) + If output is relocatable (STINK) format, causes immediate output + of all accumulated linking pointers. +.LOP ,, + like .OP, but the instruction is executed in STINK rather + than in MIDAS. Has no value in MIDAS. The loader sets the value + of the global symbols .LVAL1 and .LVAL2 to the resulting contents + of AC and memory respectively. (Initially .LVAL1 and .LVAL2 have + value 0). +.LSTOF listing off +.LSTON listing on +.LVAL1 .LOP value left in accumulator. +.LVAL2 .LOP value in memory location. +.LZ , + the number of leading zeros in the value of . + The comma serves only to terminate . +.M Main block (as in .M"FOO) +.MLLIT set positive to allow multi-line [], (), and <>. + Set negative for the old-fashioned mode where they didn't + need to be terminated. Zero selects "error mode" useful + in converting an old-fashioned program to multi-line mode. + Now initially positive. +.MRUNT MIDAS's runtime so far, in milliseconds. +.NSTGW sets .STGSW to cause error message if any storage words are assembled. +.NTHWD , + returns the 'th word of the text string. + Thus, .NTHWD 1, is equivalent to .1STWD. By + is meant an invocation of ASCIZ, ASCII, ASCIC, .ASCII or SIXBIT. +.OFNM1 = SIXBIT// +.OFNM2 = SIXBIT// +.OP ,, + executes on an AC containing and a memory + location containing , and returns what this leaves + in the AC. Thus, <.OP SUB,5,2> equals 3. This value is also + made the value of .AVAL1, while .AVAL2 contains what was left + in the memory location: .OP SUBM,5,2 sets .AVAL2 to 3, and + returns 5. .ASKIP will be nonzero if the instruction skipped. + If an instruction is supplied with a nonzero AC field, that + AC field will be used unchanged, and the number of the AC + used for the argument and value will not be substituted. + Similarly, if the address field or index field in is + nonzero, the address of .AVAL2 will not be substituted. + This is useful for immediate instructions, including such + ITS UUOs as .RDATE which equals .OPER 46: ASDATE=.OP .RDATE + sets ASDATE to today's date in SIXBIT. + Note that is read in as a field, and thus cannot contain + any spaces or commas (unless they are inside brackets). +.OSMIDAS + is the sixbit name of the operating system MIDAS is running + under. It is SIXBIT of ITS, TENEX, SAIL, CMU or DEC. + Twenex is considered the same as Tenex. + Programs that have versions for more than one operating + system should by default assemble to run on the one + in .OSMIDAS, but they should make it possible to override + that default with the use of the T switch: + IFNDEF RUNOS, RUNOS==.OSMIDAS + DEFINE IFITS + IFE RUNOS-SIXBIT/ITS/TERMIN +.PASS is 1 or 2, depending on which pass MIDAS is in. +.PPASS is 1 in a 1-pass assembly; 2, in a 2-pass assembly. +.QMTCH if set nonzero, causes ' and " text constants to use the newer + fail-style syntax. +.QUOTE /text/ inhibit checking for TERMIN and macro dummies. +.RADIX ,, + evaluates , using as the radix. +.RELP , + returns 's relocation. Always 0 in an absolute + assembly. + For any X, X = .ABSP X,+.RL1*.RELP X, +.RL1 in a relocatable assembly, returns a relocatable 0. + In an absolute assembly, returns 0. + .ABSP .RL1 is always 0. .RELP RL1 is 0 iff the assembly is + absolute. +.RPCNT = # iterations of REPEAT completed +.RSQZ , + generates right-justified SQUOZE such as the DEC system likes. +.SBLK Specifies ITS SBLK output format. Same as SBLK but doesn't type + warning message. For details on format, see ITSDOC;BINFMT > + and the "Symbol table format" section of .INFO.;DDTORD >. +.SCALAR (),,... + makes the symbols "variables", like the ' construct, + causing them to have storage words allocated for them later + (at the time of the next VARIAB or END). An optional + may be specified in parentheses after a symbol, reserving that + many words for it rather than the default of just one. + See also .VECTOR, which is identical except for the way sizes default. +.SEE ,... + Has no effect except to make cref entries for the specified symbols. +.SITE + returns word (origin 0) of a SIXBIT string that says + the name of the machine MIDAS is running on. If is + out of range 0 is returned. The format of the string is + operating system dependent; on I.T.S. .SITE 0, will return + the standard I.T.S. "machine name" which is SIXBIT of + "AI", "ML", "DM", or "MC". + Programs with different versions for different sites should + by default assemble to run on the one specified by .SITE, + but they should make it possible to override that default + using the T switch: + IFNDEF RUNSITE,RUNSITE==.SITE 0, + then later on + IFE RUNSITE-SIXBIT/ML/,... +.SLDR selects SBLK output format, but outputs a loader in front + of the file. +.SPECI .FASL special variable reference. +.STGSW set nonzero => it is illegal to generate storage words. + .NSTGW and .YSTGW act by setting this flag. +.STOP stop current iteration of REPEAT or IRP, go on to next. +.STPLN Set to line # to break assembly at (see below) +.STPPG Set to page # to break assembly at. By setting .STPLN and .STPPG + you can break assembly (i.e. .INSRT the TTY) at an arbitrary point. +.SUCCESS + flag, used to make .ELSE and .ALSO work. +.SX .FASL quoted S-expression reference. +.SXE .FASL S-expression load time evaluated and value assembled in. +.SXEVA .FASL S-expression load time evaluated and value thrown away. +.SYMCNT returns the number of symbol table entries in use. This is the + number of user-defined symbols plus the number of initial symbols + (not counting symbols that have been expunged). It is useful for + determining what argument to give to .SYMTAB (below); +.SYMTAB , + makes sure the symbol table can hold symbols + and the literal table can hold words of literal. + If either table actually needs to be enlarged, both are + re-initialized, so that all user symbol definitions are lost. + For this reason, a .SYMTAB should come at the beginning of the + program. If both tables are already big enough (for example, + when the same .SYMTAB is seen on pass 2), .SYMTAB is a no-op. + The normal version of MIDAS starts out with space for 2700. + symbols, and has about 1200. initial symbols, so only + programs using more than 1500. symbols need a .SYMTAB. + To decide what symtab you need, try a very large value (10000.). + The number of symbols including initial symbols, printed at + the end of the assembly, is the minimum value you can use; + for best results choose an arg at least 20% larger. + The literal table size you need is usually the size of the largest + constants area; this can be computed from the constants + area addresses printed at the end of the assembly. + Sometimes, that size may cause a "Constants Global Table Full" + error, and a larger size must be used. +.TAG see .GO +.TTYFLG if greater than zero, TTY typeout is inhibited + (but not output to error output file if any). +.TTYMAC allows the program to read a few arguments from the TTY at + assembly time, and refer to them as dummy arguments. + .TTYMAC is used the way DEFINE is used (see *Note macros: Macros.) + but without a macro name; the macro definition is read in and + then immediately evaluated, with arguments read in from the TTY. + Try .TTYMAC FOO + BAR=FOO TERMIN +.TYO , + Like TYO n MACLISP; prints on the TTY the character whose ASCII + code is . Thus, .TYO 61 prints a "1". +.TYO6 , + Prints the word, regarded as a sixbit. + Try .TYO6 .FNAM1,.TYO 40,.TYO6 .FNAM2,PRINTX/ + / +.TYPE , Find definition status of symbol. + Value is one of the following: + -1 is really a number + 0 common + 1 pseudo or macro + 17 not seen (except in this .TYPE) + 12-16 either impossible or not documented yet. + + Defined/Undefined + 2 3 Local symbol (not global, not a var) + 4 5 Local variable + 6 7 Global variable + 10 11 Global symbol (not a var) +.TZ , + is the number of trailing zeros in the value of . +.U containing block (as in .U"FOO) +.VECTOR (), (),... + Makes be the name of a vector words long. + The space is actually allocated by the next VARIAB, or by + the END statement. Like .SCALAR, more than one vector can + be specified at a time. If no size is specified, or size is zero, + the default size is used (initially 1, always set to last size used). + e.g. in ".VECTOR FOO(3),BAR" the vector BAR will have size 3. + This defaulting scheme is the only difference from .SCALAR. +.WALGN word-align; in byte mode, move up to a word boundary. +.XCREF ,... + Suppress creffing of the specified symbols. +.YSTGW OK to generate storage words +1PASS one pass assembly. Implies RELOCA +ASCIC /text/ like ASCIZ but fill with ^C. +ASCII /text/ generate ascii character string. +ASCIZ /text/ ascii character string, 0 byte at end. +BLOCK + reserve words - increment "." by . +COMMEN /text/ + ignores the text. +CONSTA dump out literals seen so far. +DEFINE define a macro. See *Note macros: Macros +END + terminates tha assembly, and sets the program starting address + to the argument (which is optional). +EQUALS , + sym1 gets same meaning as sym2. +EXPUNGE ,... + forgets the definitions of the specified symbols. The symbols are + actually deleted from the symbol table altogether. +IF1 ifbody Assemble if pass 1. +IF2 ifbody Assemble if pass 2. +IFB string,ifbody Assemble if string blank (has no squoze chars). +IFDEF sym, ifbody Assemble if sym defined. +IFE exp, ifbody Assemble if = 0. +IFG exp, ifbody Assemble if > 0. +IFGE exp, ifbody Assemble if >= 0. +IFL exp, ifbody Assemble if < 0. +IFLE exp, ifbody Assemble if <= 0. +IFN exp, ifbody Assemble if ^= 0. +IFNB string, ifbody Assemble if string not blank. +IFNDEF sym, ifbody Assemble if sym not defined. +IFNSQ string, ifbody Assemble if string is not all squoze chars. +IFSE string,string,ifbody Assemble if strings equal. +IFSN string,string,ifbody Assemble if strings not equal. +IFSQ string, ifbody Assemble if string is all squoze chars. +IRP indefinite repeat (like macro args sort of). See *Note loops: Loops +IRPC indefinite repeat (characters). +IRPNC indefinite repeat (groups of characters). +IRPS indefinite repeat (symbols). +IRPW indefinite repeat (words - i.e. code lines). +LOC + set value of "." to . +NOSYMS don't put symbols in output. +NULL ifbody + This a "conditional" that always fails. +OFFSET + offset . and labels by specified amt (code to be moved before run). +PRINTC /text/ type out the text. +PRINTX /text/ Same as PRINTC, but ignores any "!" chars in the text. +RADIX + set number radix to . +RELOCA relocatable assembly. +REPEAT ,[] repeat times. See *Note loops: Loops +RIM Readin mode output format. This is what the PDP-6 used. + A series of 2-wd pairs (DATAI PTR,loc ? val); last pair is a + transfer block with 1st wd an instruction taken from END stmt + and executed when transfer block is read. 2nd wd is a dummy. +RIM10 Readin mode output format, for KA-10 hardware bootstrap readin. + RIM10 format is a single block where the 1st word is IOWD n,,loc and + n = # words in rest of block, loc = location to load these words at. + Last loaded word is executed after readin is complete, so it should be + a JRST somewhere. MIDAS makes it unnecessary to do anything about + this as its strategy for RIM10 is to first output a + RIM10-format SBLK loader, followed by the code in normal SBLK format, + except that no symbols are provided. +SBLK Simple Block loader output format (this is the default). + Starts with a SBLK loader in RIM (not RIM10) format, followed by + code in SBLK format. +SIXBIT /text/ generate sixbit character string. +SQUOZE , + value is a word containing the squoze-code for + with /4 put in the top 4 bits. +SUBTTL + ignores the line. This pseudo is for @'s sake. +TERMIN terminate macro body or indefinite repeat. +TITLE + specify name of program as (relocatable only). + Types and on the TTY. + It is at the TITLE that TTY will be .INSRT'ed by + the (T) switch. +VARIAB leave space for, and define, the "variables" seen so far. + "Variables" are symbols not defined and seen with singlequotes + and symbols seen in .SCALAR and .VECTOR pseudos. +WORD + outputs the argument directly to the binary file. + Allows writing of nonstandard binary formats. +XWD , + returns a word with the specified halfwords. + +MIDAS Node: Outformats, Up: Top, Previous: Pseudos, Next: Changes + +This node documents some obscure details of assembler output formats. +Much of the wording is taken from old DEC manuals. + +----------------- RIM ----------------- + + This format is (was) primarily used in PDP-6 systems and +consists of a series of paired words. The first word of each pair is +a paper-tape read instruction giving the memory address of the second +word. E.g. + DATAI PTR, + +The last pair of words is a transfer block; the first is an +instruction obtained from the END statement and executed when the +transfer block is read, and the second is a dummy word to stop the reader. + +The loader that reads this format is normally toggled into memory and +started at location 20: + LOC 20 + CONO PTR,60 + A: CONSO PTR,10 + JRST .-1 + DATAI PTR,B + CONSO PTR,10 + JRST .-1 + B: 0 + JRST A + +----------------- RIM10 ----------------- + + The PDP-10 has a hardware readin mode which can read in one +block of data. Programs which can be loaded using this readin mode +are said to use RIM10 format. The format of this block is: + -n,,loc-1 ; equiv to IOWD n,,loc + ; the last data word is executed after readin. + +In MIDAS, "RIM10" causes the output binary to start with a RIM10-format +SBLK loader provided by MIDAS. The assembled code then follows in SBLK +format. Only data blocks and the final transfer block are output (no +symbol blocks or anything else). This is very similar to MACRO's "RIM10B" +(see below). The RIM10 loader code can be found at label LDR10 in MIDAS. + +In MACRO, "RIM10" causes the assembled code to be output exactly as it +is produced; i.e. the first data word is the first output word. No +blocking, checksumming, or anything else is done; in particular, no +loader is furnished by MACRO. This functionality can be achieved in +MIDAS by means of the WORD pseudo-op, which writes an arbitrary word +to the output file. + +----------------- RIM10B ----------------- + + This is a MACRO format, not MIDAS, but is documented here anyway. +It is very similar to what MIDAS produces for "RIM10". That is, MACRO will +first output a loader in RIM10 format, followed by the assembled code in a +"simple-block" format. This simple-block format is identical to DECSAV +except that there is a checksum word following each block. In this respect +it is similar to SBLK, however it also differs in the way the checksum is +computed; RIM10B just adds words, whereas SBLK rotates the checksum 1 bit +before each add. + +The following is the loader inserted by MACRO for RIM10B: + R1BLDR: + PHASE 0 + IOWD $ADR,$ST + $ST: CONO PTR,60 + HRRI $A,$RD+1 + $RD: CONSO PTR,10 + JRST .-1 + DATAI PTR,@$TBL1-$RD+1($A) + XCT $TBL1-$RD+1($A) + XCT $TBL2-$RD+1($A) + $A: SOJA $A, + $TBL1: CAME $CKSM,$ADR + ADD $CKSM,1($ADR) + SKIPL $CKSM,$ADR + $TBL2: JRST 4,$ST + AOBJN $ADR,$RD + $ADR: JRST $ST+1 + $CKSM: + DEPHASE + +----------------- SBLK ----------------- + + When SBLK format is selected, MIDAS will (presumably for historical +reasons) first output a SBLK loader in RIM (not RIM10!) format, followed by +the assembled code in SBLK format. The latter consists of data blocks, a +transfer block, symbol table blocks, and any extra blocks. + SBLK is to ITS what DECSAV is to DEC systems. + SBLK format is documented in ITSDOC;BINFMT >, and the format of the +SBLK file symbol table in .INFO.;DDTORD >. The RIM loader code can +be found at label SLOAD in MIDAS. + +----------------- DECSAV ----------------- + + DECSAV is a simple absolute format which can be used for +immediately executable programs on TOPS-10, TENEX, and TOPS-20. +It consists only of data blocks followed by a 2 word transfer block. +Each data block has the format: + IOWD n,,loc + +The transfer block is: + JRST start-address ; This word is specified by END + JRST reenter-address ; MIDAS always leaves this 0 + +----------------- DECREL ----------------- + + This format produces DEC relocatable format (.REL) files +which the DEC linking loader (LINK) can then use to put a program +together. It is not necessary to use this unless you need to load +in some already assembled modules or use other loader features; if the +MIDAS program is self-contained it is easier to use DECSAV format. + DEC relocatable format is documented in the DEC LINK Reference +Manual (TOPS-20 version is AD-4183C-T1). + +----------------- STINK ----------------- + + The MIDAS "RELOCA" pseudo generates ITS relocatable format, +also known as STINK format because STINK is the name of the ITS linking +loader. This format is not well documented anywhere, which is partly +why very few people use STINK or RELOCA any more, especially when MIDAS +is fast enough that it is much easier and simpler to always produce +self-contained absolute assemblies. (Library routines are shared by +using .INSRT) + +MIDAS Node: Changes, Up: Top, Previous: Outformats, Next: (MIDAS ARCHIV)* + +Changes are catalogued in an uninfo-ized file. Do "L" to get back here. + +* Menu: + +* Changes: (MIDAS ARCHIV)* MIDAS changes in chronological order. + + + +Local Modes: +Fill Column:75 +Page Delimiter:  +End: