> From: Warren Toomey
> Just checking that the TUHS list hasn't gone belly up, as it's been
> pretty quiet for a week :-)
Thank goodness!
That's one way to improve the S/N ratio.
Noel
> From: Clem Cole
> I'm thrilled to see the 11 kept alive.
Ditto. The most elegant archtecture ever, IMO.
> I was under the impression ??Ken?? had created them for B
> independently (which, of course, was first on the PDP-7).
"The Development of the C Language", by Dennis M. Ritchie:
https://www.bell-labs.com/usr/dmr/www/chist.html
says:
The PDP-7, however, did have a few `auto-increment' memory cells, with the
property that an indirect memory reference through them incremented the cell.
This feature probably suggested such operators to Thompson; the
generalization to make them both prefix and postfix was his own. Indeed,
the auto-increment cells were not used directly in implementation of the
operators, and a stronger motivation for the innovation was probably his
observation that the translation of ++x was smaller than that of x=x+1.
Note the "probably"; unless Ken remembers, and says something, that's
probably the best we are going to get.
> I did not think the PDP-7 ISA includes addressing modes in the same
> manner as the 11. .. I thought PDP-7 is a very simple instruction (and
> small) with an AC, Link/Indirection and a PC - it reminded me of the
> PDP-8 more than anything else
The PDP-4, -7 and -9 are all the same architecture (very similar to the
PDP-1, but simplified a bit), differing only in implementation. (Most PDP-7
code will run on a -9, un-modified.) Basic instructions look like:
Instructions had a 4-bit opcode ('000'-'054'), 1 bit of indirect, and 13
bits of address. It was a load-store architecture, with a single accumulator.
So, yes, similar to an -8. There are other opcodes for non-memory operations
('074' opcode), and I/O ('070'), using bits in the 'address' field. ('060'
opcodes were for the optional EAE.) All of the -4/-7/-9 had the
'auto-increment on locations 010-017' when indirecting through them' feature.
Bitsavers has fairly complete docs on them all:
http://www.bitsavers.org/pdf/dec/pdp4/http://www.bitsavers.org/pdf/dec/pdp7/http://www.bitsavers.org/pdf/dec/pdp9/
Noel
> From: "Nelson H. F. Beebe"
> there is a nice compact history of the PDP-11 and early Unix at this
> new article:
Not a bad artcle, but it had a number of minor errors, which I found irritating.
They should have gotten an expert to proof it.
Here are some:
registers could access any other register - as well as memory or direct
data - using one of the six different addressing modes
I think 'instruction' may have been meant for the first "register"; as
written it makes on sense. (Unlike the PDP-10, in the PDP-11, a register
can't address another register.) Oh, and there are eight addressing modes.
use of labels instead of hard-coded addresses makes it easier to
program and makes the code relocatable in memory
I'm not sure whether the writer knows the difference between 'PC-relative
addressing' (a PDP-11 feature; code that will run at any address, without
_any_ changes to the binary) and 'relocatable binary (which uses labels, as he
describes). - but is not PDP-11 specific.
The program counter can be accessed like any of the other registers ... The
program counter is intended to support jump, branching, and other control
flow instructions.
Uh, no. It's not clear _exactly_ what was meant here, but... having the PC as
a general register is for PC-relative addressing of operands, immediate data,
and absolute addressing of operands. Jumps, branches, etc don't use the fact
that the PC is a general register.
These are the key advantages of assembly programming over high-level
languages - assembler code always runs faster and uses less memory.
Not really, with modern compilers.
The number above represents -2.
A commenter caught this one.
Just use a $ to represent a decimal number
In UNIX assembler, "$" means 'immediate data'; a trailing
"." means decimal.
And a tip of the hatly hat for getting this:
Although the ++ and - operators in C are equivalents of DEC and INC
instructions, they were inspired by an addressing mode in the PDP-7.
right.
Noel
Although the story is well known to members of this list, there is a nice
compact history of the PDP-11 and early Unix at this new article:
A brief tour of the PDP-11, the most influential minicomputer of all time
https://arstechnica.com/gadgets/2022/03/a-brief-tour-of-the-pdp-11-the-most…
It describes PDP-11 assembly language, and shows the booting of a Unix
system on a simh instance. It also includes the famous picture of
Dennis and Ken at a PDP-11 console, and concludes with a link to an
online text of a book about PDP-11 assembly language programming.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
I am reading some UNIX text processing books and am interested in the
lineage of Documenter's Workbench.
I see documentation of 1.0 (i.e
https://archive.org/details/sysv-dwb/page/n5/mode/2up)
I see a copy of 2.0 for 3B2 (i.e.
https://archives.loomcom.com/3b2/software/Documenters_Workbench/)
>From there things get a little less clear, it seems like we jump to
3.2 with SysVR3.2?
Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3
One of my books from the late 80s references 3.4 available as a source
code purchase independent of UNIX.
Then it appears SGI might have had a 4.x strain? (i.e.
https://archive.org/details/sgi_Documenters_Workbench_4.1.3)
Heirloom is derived from OpenSolaris which is derived from?
Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what
(I extracted the image, the relnotes inside might as well not exist).
Regards,
Kevin
> On Mar 12, 2022, at 2:02 PM, Rob Pike <r(a)golang.org> wrote:
>
> Indeed. Be careful about the code Numerical Recipes if you are doing
> important numerical work.
> For simple stuff it's fine, of course, but floating point is a
> minefield that requires expert navigation.
>
> -rob
That's the seductive trap of floating-point numbers, isn't it? They invite us to think about them as if they were the real numbers, but they are very, very much *not* the real numbers. And yet, most of the time, for most applications, if you treat them as if they were, you get plausible results.
Adam
Hello,
I'm trying to understand a quirk in 32-bit x86 code generation conventions:
on Linux, when returning a structure from a function by value:
struct S {
int i, j;
};
struct S f(int x)
{
return (struct S){x, sizeof(void*)};
}
the caller reserves space for the returned structure and passes a pointer
to that space as an 'invisible' extra argument, which is prepended to
the argument list; the callee returns this pointer (although the caller
knows it anyway); it's as if the function is transformed to
struct S *f(struct S *ret, int x)
{
ret->i = x;
ret->j = sizeof(void*);
return ret;
}
with one essential difference: the function 'f' itself is responsible for
popping the extra argument off the stack (the 'x' argument is popped by
its caller).
This necessitates using the return-with-immediate ('ret 4') instruction
instead of the normal 'ret'; this is the only instance where this variant of
the 'ret' instruction is used in code generation for C programs on Linux
normally.
I wonder how this exception came to be.
Early versions of GCC (e.g. gcc-1.27) did not implement this convention, i.e.
the caller was responsible for popping the invisible pointer similar to the
normal arguments. The "callee-pops" variant was implemented later for
"compatibility with other compilers", and the option that controls this is
called -fpcc-struct-return, which also disables returning small structures in
registers (in the example above GCC would return the value in EDX:EAX register
pair).
Operating systems differ on following this convention. For example, FreeBSD
and OpenBSD do not, and neither does Windows.
Looking at 386BSD tree in unix-history-repo, I see that it used GCC, not PCC.
Where can I look at the history of x86 code generation development in PCC?
Do I understand correctly that i386 code generation in PCC evolved in parallel
with GCC, and at some point GCC was convinced to adopt the (less efficient)
PCC calling convention by default?
Did PCC prefer to do this stack adjustment for the invisible pointer on the
callee side for some other platform, and the behavior was merely carried over
to the i386 port?
Thank you.
Alexander
> The Documenter's Workbench is sort of the unsung hero
> of Unix. It is why Unix exists, Unix was done to write patents and
> troff and the Documenter's Workbench was all about that.
My response along the following lines seems to have gone astray.
The prime reason for Unix was the desire of Ken, Dennis, and Joe
Ossanna to have a pleasant environment for software development.
The fig leaf that got the nod from Multics-burned management was
that an early use would be to develop a "stand-alone" word-processing
system for use in typing pools and secretarial offices. Perhaps they
had in mind "dedicated", as distinct from "stand-alone"; that's
what eventuated in various cases, most notably in the legal/patent
department and in the AT&T CEO's office.
Both those systems were targets of opportunity, not foreseen from the
start. When Unix was up and running on the PDP-11, Joe got wind of
the legal department having installed a commercial word processor.
He went to pitch Unix as an alternative and clinched a trial by
promising to make roff able to number lines by tomorrow in order to
fulfill a patent-office requirement that the commercial system did
not support.
Modems were installed so legal-department secretaries could try the
Research machine. They liked it and Joe's superb customer service.
Soon the legal department got a system of their own. Joe went on to
create nroff and troff. Document preparation became a widespread use
of Unix, but no stand-alone word-processing system was ever undertaken.
Doug
Decades ago (mid 1993) I produced a CD-ROM with free software for
Novell's UnixWare entitled "Applications for UnixWare". This was at
Novell's request, and they distributed the CDs at trade shows.
There's nothing very special in the CD, but I recently received a
request for it, so I put it up with a minimal description at
http://www.lemis.com/grog/Software/Applications-for-UnixWare.php
Feel free to copy it (with attribution).
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php
All, I've just placed this document at
https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstru…
Many thanks to Doug for passing it on!
Cheers, Warren
----- Forwarded message from Douglas McIlroy -----
Warren,
Someone asked if Brenda Baker's original technical memorandum about
struct is available. I scanned my copy and passed it on, secure in my
belief that the Labs won't care since it is essentially the same as
her journal publication.
For the memo to be genuinely available, I'd like to send it to TUHS.
With that in mind I redacted information about corporate organization
and distribution channels. However the memo still bears the AT&T logo
and the words "not for publication".
Doug
----- End forwarded message -----
Thanks to Doug and Warren for getting Brenda Baker's memo on struct
online at
https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstru…
She later published a formal article about that work in
An Algorithm for Structuring Flowgraphs
Journal of the Association for Computing Machinery 24(1) 98--120 January 1977
https://doi.org/10.1145/321992.321999
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Last week there was a bit of discussion about the different shells
that would eventually lead to srb writing the shell that took his name
and the command syntax and semantics that most modern shells use
today. Some of you may remember, VMS had a command interpreter
called DCL (Digital Command language), part of an attempt to make
command syntax uniform across DEC's different operating systems
(TOPS-20 also used DCL). As DEC started to recognize the value of the
Unix marketplace, a project was born in DEC's Commercial Languages and
Tools group to bring the Unix Bourne shell to VMS and to sell it as a
product they called DEC Shell.
I had been part of that effort and one of the issues we had to solve
is providing formal UNIX pipe semantics. They of course needed to
somehow implement UNIX style process pipelines. VMS from the
beginning has had an interprocess communications pseudo-device called
the mailbox that can be written to and read from via the usual I/O
mechanism (the QIO system service). A large problem with them is that
it is not possible to detect the "broken pipe" condition with a
mailbox and that feature deficiency made them unsuitable for use with
DEC Shell. So the team had me write a new device driver, based
closely on the mailbox driver, but that could detect broken pipes
lines UNIX-style.
Shortly after I finished the VMS pipe driver, the team at DECwest had
started work on the MICA project, which was Dave Culter's proposed OS
unification. Dave's team had developed a machine architecture called
PRISM (Proposed RISC Machine) to be the VAX follow-on. For forward
compatibility purposes, PRISM would have to support both Ultrix and
VMS. Dave and team had already written a microkernel-based,
lightweight OS for VAX called VAXeln that was intended for real-time
applications. His new idea was to have a MACH-like microkernel OS
which he called MICA and then to put three user mode personality
modules on top of that:
P.VMS, implementing the VMS system services and ABI
P.Ultrix, implementing the Unix system calls and ABI
P.TBD, a new OS API and ABI intended to supersede VMS
So I wrote the attached "why pipes" memo to explain to Cutler's team
why it was important to implement pipes natively in P.TBD if they
wanted that OS to be a viable follow-on to VMS and Ultrix.
In the end, Dick Sites's 64-bit RISC machine architecture proposal,
which was called Alpha, won out over PRISM. Cutler and a bunch of his
DECwest engineering team went off to Microsoft. Dave's idea of a
microkernel-based OS with multiple personalities of course saw the
light of day originally as NT OS/2, but because of the idea of
multiple personalities, when Microsoft and IBM divorced Dave was able
to quickly pivot to the now infamous Win32 personality, as what would
be called Windows NT. It was also easy for Softway Systems to later
complete the NT POSIX layer for their Interix product, which now a few
generations later is called WSL by Microsoft.
-Paul W.
> You made a comment that MINI-UNIX wasn't available outside of Bell...
No, I didn't say that. What I _actually_ said was: "don't think they were in
wide use outside Bell".
Noel
PS: Can I appeal to people to please take a few seconds of their time and
trim messages they are replying to? Thank you.
> From: Andrew Hume
> the actual configuration of Lions; PDP 11/40 was
> 128 Kbytes of core memory
> ...
> but note that because ... of addressing weirdness (the top 8KB were
> memory-mapped to I/O registers), Lions' PDP actually had 112KB of main
> memory
I think that '112KB' must be an error; the 8KB for the 'I/O page' (as DEC
eventually named ir, long after the rest of the world had started using the
term :-) were deducted from the _UNIBUS_ address space, meaning a UNIBUS -11
(the 'pure' UNIBUS -11's, i.e. other than the -11/70, -11/44, etc) could have
a maximum of 248KB of main memory (which is on the UNIBUS).
A pure UNIBUS -11 with 128KB of main memory (like Lions') has... 128KB of
main memory. The 'small memory management model' -11's (like the /40, /60,
/23, etc) can use at most 64KB of that _at any moment in time_ for user
processes (i.e. directly accessible by the CPU, in 'user' mode).
(The kernel on such machines is basically retricted to 56KB at any moment in
time, since one 'segment/page' - the terminology changed over time - has to be
dedicated to the I/O page: the memory management control registers are in
that, so once the CPU can no longer 'see' them, it's stuck. Long, potentially
interesting digression about, and ways to semi-work around that, elided,
unless people want to hear it.)
> From: Noel Chiappa
> The -11/40 (as it was at first) that I had at LCS had, to start with,
> I'm pretty sure, 3 MM11-L units .. - i.e. 48KB. I know this sounds
> incredible, and I'm having a hard time believing it myself, wondering
> if my memory is failing with age
It is:
# size /lib/c0
13440+2728+10390=26558 (63676)
('c1' takes 14848+6950+2088=23886, FWIW.) So 'my' -11/40 must have had more
than 48KB.
MINI-UNIX provides, on an -11/05 type machine with the maximum of 56KB of
addressable main memory (if you plugged in 64KB worth, the /05 CPU couldn't
'see' the top 8KB of that), up to 32KB for a user process. So that will
just hold the stock V6 C compiler.
I'm not now sure how much memory my -11 _did_ have initially, but it's not
important.
Noel
I enjoy this dc(1) discussion. I am a daily dc user, and since my fisrt
calculator was an HP-45 (circa 1973) RPN felt right. However I think
dc pre-dates ALL HP calculators, since there was one in the 1st Edition
written in assembly.
I extened my version of dc (way before gnu existed)
based on common buttons I used from HP calculators:
CMD WHAT
# comment, to new line
~ change sign of top of stack (CHS key)
| 1/top of stack (1/x key)
e push 99 digits of e (2.718..) on the stack
@ push 99 digits of pi on the stack (looks like a circle)
r reverse top of stack (x<>y key)
I had been fascinated with pi stemimg from the Star Trek epsiode Wolf
in the Fold where Spock uses it to usa all computing power
"Computer, this is a Class A compulsory directive. Compute to
the last digit the value of pi."
"As we know, the value of pi is a transcendental figure without
resolution. The computer banks will work on this problem to the
exclusion of all else until we order it to stop."
As it was supposed to be "arbitrary precision" here was my tool.
So I wrote Machin formula in dc slowing increasing the scale and printing
the results. In the orginal dc, yes the whole part was arbitrary, but the
decimal part (scale) was limited to 99. Well that became a disappiontment.
(this program is lost to time)
So I decided to rewrite it but increasing pi as a whole numbers instead
of increasing scale (ex. 31415, 314159, 3141592, ... etc)
I still have that program which is simply this --
[sxln_1ll*dsllb*dszli2+dsi5li^*/+dsn4*lelzli239li^*/+dse-dlx!=Q]sQ
1[ddsb5/sn239/se1ddsisllQx4*pclb10*lPx]dsPx
if you run it you'll notice the last 1 to 2 digits are wrong due to precision.
The next problem became small memory. I still have thes saved output before
it crashed at 1024 digits. No idea what specs of the machine it was run
on anymore its really old --
3141592653589793238462643383279502884197169399375105820974944592307816\
4062862089986280348253421170679821480865132823066470938446095505822317\
2535940812848111745028410270193852110555964462294895493038196442881097\
5665933446128475648233786783165271201909145648566923460348610454326648\
2133936072602491412737245870066063155881748815209209628292540917153643\
6789259036001133053054882046652138414695194151160943305727036575959195\
3092186117381932611793105118548074462379962749567351885752724891227938\
1830119491298336733624406566430860213949463952247371907021798609437027\
7053921717629317675238467481846766940513200056812714526356082778577134\
2757789609173637178721468440901224953430146549585371050792279689258923\
5420199561121290219608640344181598136297747713099605187072113499999983\
7297804995105973173281609631859502445945534690830264252230825334468503\
5261931188171010003137838752886587533208381420617177669147303598253490\
4287554687311595628638823537875937519577818577805321712268066130019278\
76611195909216420198938095257201065485862972
out of space: salloc
all 8587356 rel 8587326 headmor 1
nbytes -28318
stk 71154 rd 125364 wt 125367 beg 125364 last 125367
83 11 0
30 IOT trap - core dumped
But I was much happier with that.
On a side note: programming dc is hard. There was no comment character.
And it's a pain to read, and it's a pain to debug.
When I discovered the Chudnovsky algorithm for pi, of course I implemented it
in dc --
[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlx_262537412640768000*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP
7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx
At 99 digits of scale it ran out in 7 rounds, but now with that limitation
removed and large memeories it just goes on and on.....
-Brian
PS: Thanks for the fast OpenBSD version of dc, Otto.
Otto Moerbeek wrote:
> On Thu, Feb 17, 2022 at 01:44:07PM -0800, Bakul Shah wrote:
>
> > On Feb 17, 2022, at 1:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
> > >
> > > On Thu, 17 Feb 2022, Tom Ivar Helbekkmo via TUHS wrote:
> > >
> > >> Watching the prime number generator (from the Wikipedia page on dc)
> > >> running on the 11/23 is much more entertaining than doing it on the
> > >> modern workstation I'm typing this on:
> > >>
> > >> 2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x
> > >
> > > Wow... About 10s on my old MacBook Pro, and I gave up on my ancient
> > > FreeBSD box.
> >
> > That may be because FreeBSD continues computing primes while the MacOS
> > dc gives up after a while!
> >
> > freebsd (ryzen 2700 3.2Ghz): # note: I interrupted dc after a while
> > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > ^C 11.93 real 11.79 user 0.13 sys
> > $ wc xxx
> > 47161 47161 319109 xxx
> > $ size `which dc`
> > text data bss dec hex filename
> > 238159 2784 11072 252015 0x3d86f /usr/bin/dc
> >
> > MacOS (m1 pro, prob. 2Ghz)
> > $ command time dc <<< '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x' > xxx
> > time: command terminated abnormally
> > 1.00 real 0.98 user 0.01 sys
> > [2] 37135 segmentation fault command time dc <<< > xxx
> > $ wc xxx
> > 7342 7342 42626 xxx
> > $ size `which dc`
> > __TEXT __DATA __OBJC others dec hex
> > 32768 16384 0 4295016448 4295065600 100018000
> >
>
> MacOS uses the GNU implementation which has a long standing issue with
> deep recursion. It even cannot handle the tail recursive calls used
> here and will run out of its stack.
>
> -Otto
Someone on one of these lists seems to be at ok-labs.com; well...
aneurin% host ok-labs.com
;; connection timed out; no servers could be reached
aneurin%
Houston, we have a problem... Could whoever is responsible please
sprinkle some fairy dust somewhere?
Thanks.
-- Dave
Does anybody know how much memory was configured on the PDP-11 that
Lion's used for the commentary system. Here's what the book says about
the system:
; from lions, page 1
; The code selection presumes a "model" system consisting of:
; PDP11/40 processor;
; RK05 disk drives;
; LP11 line printer;
; PC11 paper tape reader/punch;
; KL11 terminal interface.
I usually add the mag tape, too
; TM10 magnetic tape - not in lions, but super handy
It seems like he must have had an MMU and 128k memory, but I don't know.
I'm hoping y'all remember, know, or can otherwise divine the correct
value. I've run with no MMU - crash on boot. I've also run with less
memory, but then cc won't build mkconf, when I have the TM10 enabled
kernel loaded. As a reminder, his book was published in 1977.
Thanks,
Will
> From: Will Senn
> Does anybody know how much memory was configured on the PDP-11 that
> Lion's used for the commentary system. Here's what the book says about
> the system:
> ..
> ; PDP11/40 processor;
> ...
> It seems like he must have had an MMU
V6 absolutely requires an MMU; the need for it is all throughout basic
attributes of the system - e.g. user processes start their address space at 0.
(BTW, there are V6 descendants, MINI-UNIX:
http://gunkies.org/wiki/MINI-UNIX
and LSX, which don't use/need an MMU, and run on -11 models without memory
managament, such as -11/05's, but I don't think they were in wide use outside
Bell.)
> and 128k memory
The -11/40, as originally released, only supported the MM11-L, which came in
multiples of 16KB (for a 3-board set). Use of the later MM11-U (32KB units)
required a new main power harness, which only came in on
higher-serial-numbered -11/40's.
The -11/40 (as it was at first) that I had at LCS had, to start with, I'm
pretty sure, 3 MM11-L units (i.e. one MM11-L backplane full) - i.e. 48KB. I
know this sounds incredible, and I'm having a hard time believing it myself,
wondering if my memory is failing with age; but it definitely had
extraordinarily little.
I just looked on my V6 (running in a simulator), and it appears that by
trimming all parameters (e.g. number of disk buffers) to the absolute bone,
the kernel could be trimmed to about 36KB. (I haven't actually tried it,
since I don't feel like recompiling all the kernel modules, but one can
estimate it - take the current system size [44KB], delete 10 buffers @ .5KB
gives 39KB, etc, etc.)
That would allow a maximum user process of 12KB on a 48KB machine - and
MINI-UNIX, which runs basically stock V6 user code, can manage with user
processes that small.
I see Andrew's email which reports that the Lions machine had more main
memory, 128KB (maybe 4 MM11-U's - two MM11-U backplanes full); that
woould have made their life a lot easier.
Noel
> The X11 tree was a heavily ifdef-ed. And it needed to be, I don't have
> an answer as to how you would reuse all that code on different hardware
> in a better way.
Plan 9 did it with #include. The name of the included file was the same for
every architecture. Only the search path for include files changed. Done with
care, this eliminates the typical upfront #ifdefs.that define constants and set
flags.
Other preprocessor conditionals can usually be replaced by a regular if, letting
the compiler optimize away the unwanted alternative. This makes conditionals
obey the scope rules of C.
Doug
6th Edition used the Thompson shell as /bin/sh. I don't think it had
those capabilities. Sometimes you could find an early version of the
Bourne shell in /bin/nsh (new shell) in v6.
The 7th Edition made the Bourne shell /bin/sh. And there sometimes
you could find the Thompson shell in /bin/osh (old shell).
Will Senn wrote:
> Login commands question:
>
> I'm sure it's simple, but I can't figure it out. How do I get something
> to run at login in v6? Right now, I use ed to create a file 'setprof'
> that contains:
>
> stty erase[space][backspace][return]
> stty nl0 cr0
>
> Then after logging in:
>
> sh setprof
>
> It works, but, it is pretty clunky.
>
> stty question:
>
> So, I looked at stty.c and it looks like the following should work, if
> the terminal is sending ^H for backspace:
>
> #define BS0 0
> #define BS1 0100000
>
> modes[]
> ...
> "bs0",
> BS0, BS1,
>
> "bs1",
> BS1, BS1,
>
>
> but:
>
> stty bs0
> or
> stty bs1
>
> don't result in proper backspace handling..
>
> but:
>
> stty[space][^h][return]
>
>
> works...
>
> Thoughts?
Login commands question:
I'm sure it's simple, but I can't figure it out. How do I get something
to run at login in v6? Right now, I use ed to create a file 'setprof'
that contains:
stty erase[space][backspace][return]
stty nl0 cr0
Then after logging in:
sh setprof
It works, but, it is pretty clunky.
stty question:
So, I looked at stty.c and it looks like the following should work, if
the terminal is sending ^H for backspace:
#define BS0 0
#define BS1 0100000
modes[]
...
"bs0",
BS0, BS1,
"bs1",
BS1, BS1,
but:
stty bs0
or
stty bs1
don't result in proper backspace handling..
but:
stty[space][^h][return]
works...
Thoughts?
> From: Clem Cole
> what I don't remember was it in v5
Your memory is going! :-) We discussed this recently (well, recently in _our_
timescale :-); it's built into in 'cc' in V5:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c
see "expand(file)".
Noel
> From: Will Senn
> My question is - how did y'all run things - with CSR zero and no kernel
> messages ... or with CSR non-zero and kernel messages.
On the -11/45 V6+ at MIT, we didn't have a printing terminal on the console,
just a VT52. We had a tool at MIT called 'dmesg':
http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/dmesg.8
which made up for that a bit.
We normally ran with the CSR set to 173030 - the 'boot in single-user'
setting. That's because at one point the machine was in the 9th floor machine
room, but the console VT52 was on the 5th floor (where our offices were - the
famous print of the GE-645 Multics was on the hallway wall outside mine :-),
and I'd added a 'reboot()' system call (nothing fancy, it just jumped to the
bootstrap ROM), so we could reboot the machine without going up in the
elevator (not if it had crashed, of course). Later on, after we'd done with
kernel hacking (adding a network interface, and IP), and the machine stayed up
for long periods, we moved the console up next to the machine (since if it
crashed, you had to use the front panel to restart it, so you had to be up
there anyway); we stayed with the default CSR setting, though. (If it panic'd,
you could see the reason why when you went to reboot it.)
> Oh, BTW, I know I've seen this noted elsewhere, but I can't remember
> where.
Maybe at:
https://gunkies.org/wiki/UNIX_Sixth_Edition#Distros
which discusses it?
Noel
I noticed in v6 source that putch in prf.c - the system kernel printf's
character routine, only prints to the console if the Console Switch
Register is non-zero.
My question is - how did y'all run things - with CSR zero and no kernel
messages (seems dangerous to me, being naive and all) or with CSR
non-zero and kernel messages.
On my FreeBSD instance, I value the messages that show up on console as
they've alerted me to big problems in the past, but on my Mac, not as
much (sure you can run Console and see them, but they aren't immediate).
Oh, BTW, I know I've seen this noted elsewhere, but I can't remember
where. Dennis's v6 doesn't have the Western Electric message:
mem = 435
RESTRICTED RIGHTS
Use, duplication or disclosure is subject to
restrictions stated in Contract with Western
Electric Company, Inc.
It was a bit of a head scratcher as I was trying to read from the Dennis
version of the distro on my mac while running Wellsch's tape on simh. I
spent quite a while spinning my wheels looking for "Western" in the
files to no avail. I thought something was screwy with the files or my mac.
