> What is the name of the mathematic symbols
Here are some readings, not exactly names
incl (used with partial orderings) is included in, or is less than
|> is not greater than
|< is not less than
<wig
>wig
wig is approximately, or asymptotically approaches
~wig is approximately
Doug
I had an experience similar to Tom London's:
To: alice!rob
Subject: you've spoiled me
I can't believe it. I'm sitting here at home in front of my
2621, and I can't work.
Damn it. I've got to get a blit at home.
When I left Bell Labs, I had an X11 workstation at work, but
only a simple terminal at home. Having used a Jerqblit5620 for
years at both work and home, I found it incredibly limiting.
After a year or so I came across a reseller who had a lot of
off-lease 5620s for sale cheap (like USD 150 or so each). I
asked around the university I now worked at, found a handful
of other people who wanted in, and then a local small company
who did System V system-administration consulting who wanted
some for themselves, and were willing to handle all the paperwork.
All that allowed us to negotiate the price down even more.
In the end I bought six, of which I think four are still working,
though I haven't turned any of them on for years.
None of the Unixes I used at the time came with 5620 support,
but the protocol for the basic window system built into the ROM
was well-documented and I managed to roll my own host support.
I also managed to cobble up my own binary-loading tools sufficient
to get sam working (I forget how I compiled the binary for the
terminal); that was rather more work, but it was worth it to
be able to have sam and multiple windows from home, even though
it was the ROM OS and therefore mpx rather than mux.
I remember porting my version of the host code to Ultrix,
SunOS 4, and IRIX.
My workplace at the time had a little bit of VAX/VMS around.
I didn't use that much but wanted to try porting my host code
to VMS as well. VMS had had a C compiler for some years and
some sort of pseudo-terminal for a shorter time, so it ought
to have been possible. I didn't get around to it before we
finally left VMS behind in the dustbin of history. I wish I'd
found time to do it, just to show that there really was nothing
Unix-specific about the idea or the implementation. It's just
a multiplexing protocol; it needs no kernel support except that
needed to run a command-line session not attached to a physical
terminal, and networking has long since made that available on
any competent OS.
Norman Wilson
Toronto ON
The standard routine for drawing menus on the jerq was
'menuhit'. Items in the menu were centered, and the menu was
scrollable when a certain threshold number of items was
reached, and in addition, when the mouse pointer was in the
top (bottom) item of the menu and it was possible to scroll
in the appropriate direction, the menu was scrolled up or
down 1 line. The structure associated with these menus is
'Menu'.
There was however another menu-drawing routine, 'mhit', the
menus drawn by this being hierarchical, the structure NMenu,
which no longer contained text strings but an array of NItems.
NMenus also had provision for 'help' text to be displayed, a
simple string displayed on the screen, when button 1 was
pressed while an entry in the menu was selected.
The earliest version in the Eight Edition jerq code, also has
one function in the NMenu structure which is called when the
mouse pointer invokes a hierarchical menu. By Ninth Edition
this has been expanded, with 3 functions, one as above, one
invoked when an item is selected ('hit') and one when a
hierarchical menu is exited.
In the jerq code directories, under 'lib/jj', is a small 'ms'
document, 'A Library of Goo for the 5620', which lists
routines available in the library, and their authors. Andrew
Hume is listed as the author of 'mhit'.
Are there examples of code using these three menu functions
('dfn', 'hfn', 'bfn')?
There seems to have been little interest in hierarchical menus
at the labs, their use was quite limited. I found a program
in the Tenth Edition archive, 'bubble' (which seems to be a
program for displaying the three-dimensional structure of
molecules) which uses them. 'samuel' made heavy use of them,
including use of the 'hit' function, and Tom Cargill used
basically the same code in 'pads' wherein the routine was
called 'scripthit'.
The plain 'menuhit' survived into Plan9, but as far as I
know, it is only used by 'sam'.
Available at https://www.skeeve.com/bell-labs-cstrs.tar.gz
Warren and Brantley and anyone else, feel free to retrieve.
I have two sets - both are in the tarball so there are undoubtedly
duplications. If someone else can curate them into single canonical
set that'd be helpful, I just don't have the time right now.
Enjoy,
Arnold
> once you've got M3 and M4, you've got a naming convention; I'd
> think it a safe bet that there was an M5 that was an internal
> experiment, and that M6 was simply the next in line
M6 came first, created by Andy Hall as a portability tool for Altran.
I always assumed the name echoed Ken Knowlton's L6 (BelL Labs low
level list language, with a superscript 6). I seem to recall that M6
was endowed with a very labored acronym.
Doug
Hi All.
Attached is "A Supplemental Document For Awk". This circulated on USENET
in the 80s. My copy is dated January 18, 1989, but I'm sure it's
older than that. One clue is the reference to the 4.2 BSD manual,
and 4.3 came out already in 1986 or so.
Does anyone else have a copy of this with perhaps an older date?
As far as I can tell from a short search, the author is no
longer living. If someone knows better and can provide contact
info for him, that'd be great.
In the meantime, Warren, do you want to add it to the archives?
Thanks!
Arnold
There is a little known suite of programs, written by Peter Weinberger,
found as 'btree', or 'cbt', in the archives for Eighth and Tenth
Edition.
The code in the Eighth Edition archive seems to be the earliest, and
has fewer utilities than available in the Tenth Edition code. A search
through files shows that it was used by 'road', 'weather' and
'apnews'.
There is an ms file, 'memo', describing the programs, amongst the code,
but an appendix seems to be missing. If anyone knows about this or
where it might be I'd like to get my hands on it.
'Memo' itself is interesting because it's the only troff document I've
seen amongst the reseach papers (excluding Christopher Van Wyk's own
paper of course) that uses 'ideal', in this case, for drawing a
picture depicting B-tree structure.
Hello, I'd like to share some analysis from my recent Sixth Edition pass of my mandiff repository. For the V5-V6 diff, I opted for a branching approach, starting with a last universal common ancestor (which isn't quite right [1]). I compared each set of changes with the MERT0, PWB 1.0, CB-UNIX 2.3, 32V, and to a lesser extent V7 and System III manuals attempting to suss out the spiderweb of changes between them all. I created a series of branches representing last common changes between groups of branches as well. This has resulted in a littering of merge commits in the repository, but a banana's gonna have a peel.
A few important points about document genealogy here:
- The MERT0 manual, in the introduction, denotes descent from the USG Program Generic 3 manual. Furthermore, there is a listing of which pages would be replaced, which also serves as a key to which pages should be PG3 original text. However, the hs(IV) and ht(IV) pages make reference to specific MERT pages, so I question the veracity of this list. In any case, for the purposes of this analysis, much may extrapolate to USG PG3 as well. More study is needed.
- The CB-UNIX manual currently available is Edition 2.3. In studying the numbering system for CB, I've found that this represents Release 2, Issue 3, as in the kernel there are references to releases, not editions. The clue is in one of the manpages somewhere, I don't recollect as of this typing where, but that'll come back around soon enough. The manual itself appears to be from a binder that was once a CB-UNIX 2.1 binder and had select pages replaced. There are some bits and pieces of 2.1 pages that were otherwise slated to be replaced, alluding to things like the /etc/lines file in common with PG3. In any case I've prioritized 2.1 changes over 2.3 changes where they can be determined, but like PG3, no complete picture can be determined of 2.1 from available documentation.
For each of the branches, the following number of files in total reflect V5-V6 changes which aren't incorporated:
- 32V: 7
- PWB: 15
- MERT0: 46
Of these MERT0 has the greatest number of items lacking research's upstream changes from late '74-early '75. Among them:
- Has a V5-ish bas(I), no rc(I) (ratfor) at all
- The group system is not present, newgrp(I), group(V), chgrp(VIII), etc. are nowhere to be found
- nice(I) has no priority argument, simply sets a "low priority"
- TTYs are still referred to as "teletypes" instead of "typewriters" in many places
- there are 10 TTYs max so many commands don't reflect adjustments for two-digit IDs (ps(I) in particular is quite different, very V5)
- retains the lpr print command (which shows up again in 32V and System III)
- additionally, according to the replacement page list, PG3 retained the fed and form editing programs
- Program Generic may not have had a man(I) page, as the one here is a MERT0 addition, hard to say
CB tragically needs to be remerged, found as I was typing this up the system call section got an errant merge with V6 changes that shouldn't be there. Needless to say there is much in section II of the CB manual that leans more V5-ish than V6-ish. PWB differs in minor ways.
The differences can be found in this list https://gitlab.com/segaloco/mandiff/-/merge_requests?scope=all&state=closed
Each of the obviously labeled, closed merges represents a snapshot diff of the particular branch in question. As stated, the CB branch currently is in dire straits, I'm going to work that up again sometime in the future, but I should be able to use this to produce diff-able reproductions of the MERT0 and CB-UNIX 2.3 manual sources for this repository, as well as any other materials that may pop up.
- Matt G.
[1] - This pass I did not take good notes on such matters, but there are a few pages I'll anecdotally say reflect contents predating V5 sprinkled amongst the various manuals. I will consult with previous diffs when questions arise on in-depth analysis of the non-research changes in the branches. In any case the historical record already confirms CB-UNIX at the very least branched off quite early.
Hello everyone,
this is my first post on this list.
After looking at the archives for this mailing list, I have seen that
the B language has been discussed several times already.
After viewing Ken Thompson's interview by Brian Kernighan at VCF East
2019, I became interested in the B language, as it seemed full-featured
for system programming, close to C, and simple enough to write a parser
for it without a code generation tool.
So for fun and self-education, I am now writing a (or yet another) B
compiler, in C, after reading Jack Crenshaw's "Let's build a compiler"
documentation ( https://compilers.iecc.com/crenshaw/ )
Here it is: https://git.sr.ht/~f4grx/bpars
It is now starting to generate code for the 68hc11 8-bit platform. It
can also generate C code.
I have written some test programs, found some B examples, but I thought
it would be great to use my compiler with actual B software.
Of course, B was a "transition" language, that did not have a continued
use as soon as it evolved into C. so if any software remains, it will be
quite hard to find.
And here is my question, is any of you aware of original B source code
archives? or are in touch with people that would know?
In particular, I read on this document written by Dennis Ritchie:
https://www.bell-labs.com/usr/dmr/www/chist.html
> After the TMG version of B was working, Thompson rewrote B in itself
(a bootstrapping step).
I have also read that the YACC tool was initially written in B.
There might be other historical B sources that I am not aware of.
Do you know if any of this code has survived to this day? Where could I
find more information about this?
Thank you very much,
Sebastien Lorquet (F4GRX)
Hello, I've come across something in a bookshelf up at the local university that I have thus far been unsuccessful at locating online.
It's a binder amongst other 4.3BSD binders like the reference manuals and supplementary documents but this one is labeled "User Contributed Software (UCS)". I can't find any of these in the doc folder of the 4.3BSD copies in the archive nor can I find a scan of the originals. There is an overview at the start listing the following packages: B, X, ansi (VAX tape tools), apl, bib, courier, cpm, dipress, dsh, emacs, enet, help, hyper, icon, jove, kermit, mh, mkmf, mmdf, news, notes, npl00, patch, path alias, rcs, rn, spms, sumacc, sunrpc, tac, tools, umodem, and xns.
There are a preponderance of man pages as well as some focused papers for B, SPMS, the Icon programming language, and MMDFII. I didn't scribble down more notes before heading home because I figured this was something I'd find on page one of an internet search, but thus far have had no luck. If I don't turn up a digital copy soon I might just have to make another trip up there soon with my flatbed scanner. In any case I left a note too hoping whoever the curator of that bookshelf is (it was in some club room) might have the scoop on those binders, if they're left over from some long gone 4.3BSD installation in the EE/CS department and if they might have some siblings in other bookshelves nearby.
- Matt G.
There may be a simple generic way to correct pic's habit of accepting
any set of object modifiers on any object, but obeying only a
compatible subset.
Pic already collects a bit vector of modifier types attached to the
current object. If that were extended with a few more bits that
designate the object types, the size, B, of the bit vector would be
about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
record both modifier/modifier incompatibilities and object/modifier
incompatibilities. The collected bit vector needs to be tested against
the matrix once per object definition.
It seems to be harder to catch duplication of modifiers, requiring
extra code at all points where bits are set. Nevertheless, this kind
of error also merits detection.
Some questions
Does anybody think the issue is not worth addressing?
Is there a better scheme than that suggested above?
Is the scheme adequate? It would not, for example, catch a three-way
incompatibility that does not entail any pairwise incompatibility,
should such an incompatibility exist.
Any other thoughts?
Doug
Good day, I've just received in the mail a UNIX System User Reference Manual for the 3B5 computer. It has a few differences with other documentation around it. As usual with an initial expository message, lots of info here, mostly so it'll get in the archive and on the record.
So first off, I can't find a version reference in this thing. It is branded as "UNIX System" consistent with the branding nomenclature in the System V era, but I can't actually find the term "System V" anywhere thus far. However, a high level view implies relative parity with the initial release of System V. There are some areas where nomenclature is closer in character to the Release 5.0 manual, for instance, the "basinf" section in the intro refers to the user guide as "UNIX User Guide" rather than "UNIX System User's Guide" which is found in later System V stuff. In fact, this minor reference may point to some branching in the documentation between 4.x and SVR2 as I have the following in various manuals (prior to 4.1 i.e. 3.0/SysIII the reference is still directly to UNIX For Beginners, not a guide):
- Release 4.1 - "UNIX User's Guide"
- Release 5.0 - "UNIX User's Guide"
- Release 5.0 BTL - "UNIX User's Guide"
- System V - "UNIX System User's Guide"
- System V 3B5 - "UNIX User Guide"
- System V R2 BTL - "UNIX System User Guide"
- System V DEC (1984) - "UNIX System User Guide"
- System V R2 (1986 Manuals) - "UNIX System User's Guide"
So SysV adds "System" to what was in Release 5.0, this carries through to conventional SVR2. The 3B5 version, however, drops the apostrophe and 's' that were in the pre-SysV nomenclature but doesn't add "System". Then even more confusing the SVR2 BTL copy appears to bear some lineage from this as it also has the dropped apostrophe and 's' but includes "System". Strange. Even stranger is I decided to take a peek at SVR2 docs from 1984, they lack the apostrophe and 's', but later SVR2 material from 1986 restores it. I wonder if this implies the 3B5 branch was started in the 5.0 days, diverged a bit, and then was only partially recombined with System V before release, although on the flip side, this manual *does* include the edit, ex, and vi manpages which were not printed in time for the System V manual run (as they are included with a separate documentation package instead.) This tracks with the BTL 5.0 having edit, ex, vi, and termcap present from Holmdel, the BTL manual got the pages early. All that to say, there are things in this manual that aren't yet in published System V manuals at the time, but there are things in this manual that have since been altered by the time of the formal System V documentation, pointing to an earlier branch point and then ongoing cross-talk after that.
Included are references to a "3B Computer Network" and a few utilities associated. There are a few other pages too I didn't see in other contemporary public manuals, in total:
- dcon(1) - Spawns a shell on a remote system via a DATAKIT circuit
- logdir(1) - Returns the home directory field from /etc/passwd, this is in the BTL versions, I don't see it in public SysV though
- ncp(1) - Copies files over the DATAKIT network
- nisend(1) - Copies files over the "3B Computer Local Network"
- nistat(1) - Query the status of said network
- nitable(1) - Display the configuration table of said network
- niupdate(1) - Update said configuration table
- nkill(1) - Kill but using process names instead of IDs, but doesn't define process names, be it argv[0], the name of the image file, etc...
- rexec(1) - Executes commands over a DATAKIT network
- rl(1) - Login remotely over the 3B Computer Network (distinct from dcon being DATAKIT remote logins) This appears to be uucp-derived (specifically cu(1))
- dkdial(3) - Dials a DATAKIT connection
- boothdr(4) - 3B5 only, provides the contents of <sys/boothdr.h> which supports storing parts of master(4), via mkboot(1M), in "a driver object file" to be used with "the self-config boot".
Section 6 is mentioned in the intro but then omitted from the rest of the manual, so nothing to compare there. Also keeping with the documentation changes at the time, this does not include Sections 1M, 7, nor 8, as those are presumably in an accompanying Administrator's Reference Manual. That is another thing pegging this as System V rather than SVR2, by SVR2 they had further divided from two to three manuals, splitting the user manual into Sections 1 and 6 (User) and Sections 2, 3, 4, and 5 (Programmer) (although even this isn't entirely true, I've got a "UNIX User's Manual" published in 1986, red ATTIS-style cover, that contains what appear to be selections from Sections 1, 2, and 3...it seems more geared towards folks writing portable software between SVR1 and SVR2 than anything)
Finally, here are the omissions I compared with the SVR2 BTL, SVR2 DEC, and 1986 manual mentioned above:
Removed by SVR2 public, only in the BTL version:
- nscstat(1)
- nsctorje(1)
- nusend(1)
- stlogin(1)
- ststat(1)
Non-portable DEC stuff:
- adb(1)
- arcv(1)
- kasb(1)
- net(1)
- vpr(1)
- maus(2)
- x25alnk(3) - This X.25 stuff never shows back up, probably dropped as of SVR2 BTL (1983)
- x25clnk(3)
- x25hlnk(3)
- x25ipvc(3)
Non-portable 3B20S stuff:
- cprs(1)
- hpio(1)
Honeywell/GCOS Interop, gone by SVR2 BTL (1983):
- dpd(1)
- dpr(1)
- fget(1)
- fsend(1)
- gcat(1)
- gcosmail(1)
Graphics Subsystem, remains in SVR2 so probably not 3B5 supported as of this printing:
- gdev(1)
- ged(1)
- graphics(1)
- gutil(1)
- stat(1)
- toc(1)
So just to review, some matters this manual supports:
- The initial 3B5 UNIX release seems closest in character to the initial System V version
- Many DEC and 3B20-specific components are omitted
- The Honeywell/GCOS interop was on the way out the door and likely never ported
- The graphics subsystem was not supported on 3B5 as of this release
- Synchronous terminals and NSC networking are taken internal likely by this release, certainly by SVR2
- The 3B5 version supported "DATAKIT" and "3B Computer Network" networks
- Included a logdir(1) command used in BTL for getting a user's login directory from /etc/passwd
- Included an nkill(1) command to kill a process by its (undefined) name
- The boot process included a header object for "driver object files" used with a "self-config boot" process
If there are any questions or any pages folks think I should peruse for details, just let me know. Otherwise this'll won't be hitting my detailed analysis for a while, I'm currently in the midst of figuring out a branching scheme in my mandiff repo that'll facilitate tracking the various forks, as I've found many changes between V5 and V6 that are *not* reflected in various ways throughout PWB, Program Generic, CB, and 32V (as an example, go look up where lpr(I) is and isn't available.)
- Matt G.
P.S. Kudos to the production quality of this manual. It's a small binder, the pages are the same size as the earlier comb-bound manuals. The binder rings themselves are fixed to the back cover and the right side of the rings is flat instead of rounded, so the pages sit very nicely whether opened or closed. This compares with the BTL SVR2 binder where the rings are perfectly round and affixed to the spine instead, so they sit differently depending on whether the binder is on a shelf or open on a desk, with pages risking getting all crumpled up getting bunched up at the edge of the rings. Certainly has nothing to do with software or technical history, but the physical nature of the various publications has also been factoring into my study. Here's a picture of the two covers by the way, since I haven't given any visuals on my work in a while: https://i.imgur.com/hhaaxfA.jpeg
At 2023-06-17T05:19:46+1000, Damian McGuckin wrote:
> Getting back to groff, that final/terminating sigma, is it still
> pronounced as sigma.
>
> It certainly has no EQN equivalent name and its groff short symbol
> name is
>
> \(ts
>
> (terminal sigma) which is not like other greek letters. Just
> wondering whether it needs a sentence to mention its abscence from
> EQN.
There are a few others, but they postdate Ossanna troff. From
groff_char(7) in 1.23.0.rc4:
ϵ \[+e] u03F5 variant epsilon (lunate)
ϑ \[+h] u03D1 variant theta (cursive form)
ϖ \[+p] u03D6 variant pi (similar to omega)
φ \[+f] u03C6 variant phi (curly shape)
ς \[ts] u03C2 terminal lowercase sigma +
I know of no reason to make these generally available by default in eqn,
though, any more than they already are. You can type their special
characters in eqn input and assign spacing and style types to them.
(This typing system is a GNU eqn feature, not present in AT&T eqn).
In fact I have a coupled pair of reforms in mind for GNU eqn:
unfastening the definitions of the lowercase Greek special characters
from the typeface used for letters (variables), and then defining the
lowercase Greek letter eqn macro names ("alpha", "beta", ...) to
explicitly use the "letter" style type.
https://savannah.gnu.org/bugs/?64232https://savannah.gnu.org/bugs/?64231
(For example:
define alpha ! type "letter" \(*a !
)
This should result in no change for historical documents (except on
terminals, where it will fix a bug), and give us some flexibility for
users of modern fonts where Greek letters are properly supported in text
fonts (i.e., in four styles).
The Graphic Systems C/A/T had uppercase Greek available _only_ upright
and lowercase Greek _only_ italic. Modern typesetting systems are not
so limited.
Regards,
Branden
At 2023-06-16T14:22:22+1000, Damian McGuckin wrote:
> On Thu, 15 Jun 2023, G. Branden Robinson wrote:
> > But I may suffer from an excessive familiarity with this material.
>
> Yes. Me too. Maybe that is a sad comment on the both of us.
That is the price of trying to leave things better than one found them.
> Why do Greeks have an alternate way of writing sigma!
We English-speakers used to have an alternative way of writing it, if
you regard the Latin alphabet's "S" as cognate (so to speak) with the
Greek sigma (and I think doing so is defensible). It's even in Unicode
with a low code point, U+017F.
For inſtance, the United States uſed to employ a non-final lowercaſe S
in the founding documents of its preſent government, where you can see
exhibits of the "Congreſs of the United States".
It can take the modern reader a "long S" time to not read that "s" as an
"f".
And if you think that's difficult enough, check out, IIRC, the Arabic
and Devanagari scripts where you can have different initial, medial, and
final forms for letters.
Follow-ups ſhould probably be confined to groff@; I'll ſtop now leſt we
get ſent to the COFF liſt for groſs tranſgreſſions of topicality.
(Although if anyone wants to tell me whether non-final s was applied to
the trailing ends of non-final morphemes _within_ words, I'm all ears.)
Regards,
Branden
I am not convinced that using special characters rather than in-line
eqn is a good thing. It means learning a whole new vocabulary. Quick,
what's the special character for Greek psi?
I have found that, for a sequence of displayed equations as in an
algebraic derivation, a pile often looks more coherent than a sequence
of EQ-EN pairs. The pile can even contain interleaved comments, as in
Hoare-style proofs.
Doug
On Tue, Jun 13, 2023 at 9:29 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
>
> VMS (officially OpenVMS; I hated that marketing name when it was first
> proposed and I hate it now) is still alive and supported by a company
> called VMS Software, Inc. (VSI). Here is a pointer to their document
> OpenVMS Programming Concepts, Volume II, which describes the CLE in
> detail:
>
>
I think it's worth mentioning that the OpenVMS Hobbyist Program is still
alive and well and recently began supplying x86_64 licenses to hobbyists,
so if you have a reasonably modern amd64 system, you can run it under QEMU.
This came up lately in the riscv firmware universe. Someone named early
boot bt0, I mentioned crt0, and ... when did that name first appear? I
first saw it in v6 but I'm sure it was long before.
> Not a citation, either, but I believe the original RUNCOM came from CTSS (https://multicians.org/shell.html)
Yes, the CTSS command "runcom" arranged for commands stored in a file
to be run in the background. Such a file (which could contain at most
six commands) became known as "a runcom".
The term "script" did not emerge until Unix. I vaguely recall that Lee
McMahon coined the usage, but would welcome more reliable info about
its origin.
Doug
Clem Cole:
> Apologies to TUHS - other than please don't think Fortran did not
> impact UNIX and its peers.
Fortran had an important (if indirect) influence in early Unix. From
Dennis's memories of the early days of Unix on the PDP-7:
Soon after TMG became available, Thompson decided that we could not
pretend to offer a real computing service without Fortran, so he sat
down to write a Fortran in TMG. As I recall, the intent to handle
Fortran lasted about a week. What he produced instead was a definition
of and a compiler for the new language B.
(The Evolution of the Unix Time-Sharing System; see the 1984
UNIX System issue of the BLTJ for the whole thing, or just read
https://www.bell-labs.com/usr/dmr/www/hist.html)
Now let's move on to the name `rc'. Not the shell, but the
usage as part of a file name. Those two characters appear
at the end of the many annoying, and mostly pointless, configuration
files that litter one's home directory these days, apparently
copied from the old system-startup script /etc/rc as if the
name means `startup commands' (or something beginning with r,
I suppose, instead of startup). But I recall reading somewhere
that it just stood for `runcom,' a Multics-derived term for what
we now call a shell script.
I can't find a citation to back up that claim, though. Anyone
else remember where to look?
Norman Wilson
Toronto ON
>I thought it was pretty well known that it [BSS] stands for, "Block Started (by) Symbol"?
BSS was a "pseudo-operation" in SAP (SHARE assembly program) for the
IBM 704. My recollection is that the assembler manual called it "block
starting at symbol". There was also a BES (block ending at symbol)
pseudo-op. Both reserved a block of memory, with the assembler
assigning the appropriate value to the pseudo-op's label.
The reason for BES was that index registers were subtractive. There
was a loop-ending instruction ,TIX (transfer on index), that decreased
the index by a specified amount and transferred to a specified
location unless the index hit zero, in which case the instruction
counter continued in sequence. BES was originally conceived for
addressing an array stored by increasing subscript but indexed by a
register that counted down. BES was also useful for FORTRAN object
code, which stored arrays backward and kept the true, uncomplemented
subscript in an index register.
Doug
> As far as I see it, EQN input is made of things where a thing is one of
> mathematical or troff or eqn symbol
> mathematical punctuation
> delimiter, these being space, '~', '^', '{', '}', or newline
> a character surrounded by punctuation or delimiters
> - with/without users errors
> a word surrounded by punctuation or delimiters
> - with/without users errors
> EQN keywords (which are special words???)
> That is way too long winded!! I want something tight.
Quotes take precedence over all other things.
What is a "troff symbol"? I can only think of troff escapes, which can
only appear in quotes , so are not eqn things in their own right. (In
user errors they may be seen as punctuation, etc.)
Ditto for "eqn symbol"? Perhaps the union of some or all of the things
that follow in the list?
Ditto again for "mathematical punctuation". Comma is one example I can
think of. Apostrophe, read as "prime", may be another. Are there
more?
Is "surrounded by" inclusive or exclusive? Why is "character"
distinguished from "word"?
The ??? question bears on the issue of whether sintheta is one thing
or two. The word "maximal" will probably figure in the answer
Another (sticky) point is how punctuation sticks to an adjacent thing.
For example, eqn inserts space in (a,b), but keeps the whole thing(?)
together in 2 sup (a,b).
Doug