So this is weird. My publisher contacted me this week asking for permission
to send a copy of my book to these folks: https://archiveprogram.github.com/
Hadn't heard of them before. Looks like they're filling their archive with
stuff from github which means that most of the stuff being preserved by TUHS
is likely not there. Might be a good idea to see if it can be included. I
have no contact with these folks but can probably get a contact from my
publisher if this is something that y'all think is worth doing.
Jon
> Does {Reiser's bitblt replacement] exist for the rest of us to study?
A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c
It appears to be a pre-Reiser bitblt, not what was asked for. But
weighing in at over 800 lines of C, it vivifies the challenge that
Reiser met in half the space.
Doug
The recent discussion about Research choosing BSD's paging over
Reiser-London's brought to mind a stunning program by Reiser that
Research did adopt.
A critical primitive in the Blit terminal was bitblt (block transfer
of a rectangular area). It was used ubiquitously, for example to
refresh data when window-stacking changed, to move data within a
window, or to pop up a menu.. The display memory was word-oriented, so
bitblt was fraught with niggling details about bit alignment and
overlap of source and destination. A general bitblt subroutine was a
rats' nest of conditionals--grossly inefficient for important special
cases like scrolling.
Bitblt got refined (i.e. elaborated) several times before Reiser did
away with it entirely. Instead he wrote a just-in-time generator of
optimal code. Thousands of distinct variants, which varied in size
from 16 to 72 bytes, could be produced by the same 400 lines of
assembler code.
Doug
> From: Clem Cole
> Ward had a nice history here: TecoEditor
> <http://c2.com/wiki/remodel/?TecoEditor> - worth reading
Yeah, pretty good. A couple of minor points:
"TECO Madness -- a moment of convenience, a lifetime of regret" - I
have seen this attributed to Dave Moon.
"the [ITS] version of TECO was used by Richard Stallman to implement the
original Emacs Editor" - accurate if read _just_ the right way, but incorrect
in the 'naive' reading.
Stallman didn't _originate_ the body of stuff that eventually turned into ITS
EMACS, although he did take over maintenance of it once it was rolling; and
later wrote Gnu Emacs from scratch himself.
The mostly accurate one-line history is the one given in Dan Weinreb's blog
"the original (TECO-based) Emacs was created and designed by Guy L. Steele
Jr. and David Moon. After they had it working, and it had become established
as the standard text editor at the AI lab, Stallman took over its
maintenance", to which Moon added "in all fairness I have to say that
Stallman greatly improved Emacs after he 'liberated' it from Guy and me".
More people were involved than Moon, Steele and Stallman, though; a lot of
people were writing stuff before Stallman took over; and even after that,
others (like Eugene Ciccarelli, a member of the CSR group) helped a lot with
ITS EMACS.
Stallman's EMACS paper ("sEMACS: The Extensible, Customizable,
Self-Documenting Display Editor") contains _many_ statements that are
_demonstrably_ wrong, e.g. "it is simply impossible to implement an extensible
system in [languages like PASCAL or C]" ... "This eliminates most popular
programming languages except LISP, APL and SNOBOL." Given that I've been using
a heavily customized Epsilon for decades, which is written completely in EEL
(a dialect of C enhanced with editing primitives like buffers, etc), that's
clerly very confused.
Noel
> From: George Michaelson
> Teco was painful.
Some of us can recall when the _only_ choices for editing on UNIX (on the
PWB1 systems at MIT) were 'ed' and TECO!
But to add some real history (not just the usual low S/N flaming about
people's opinions of various relatively recent software, which is way too
common on this list), the guys at MIT in DSSR/RTS (the group which later did
the 68K version of PCC), who had done the port of PDP-11 TECO (in MACRO-11)
from the Delphi system at MIT (which preceded adoption of UNIX there) - a
comment in one source file alludes to Delphi, so that's where it came from, to
UNIX (I think this TECO was written there, and was not a port of a DEC one,
since it's all in lower case, and doesn't have other DEC stylisms), after the
port, added a '^R mode' similar to the one added to the PDP-10 ITS TECO and
used there to write EMACS (in TECO's usual 'line noise' code - historical
aside: at one point there was a whole 'Ivory' package for ITS TECO which could
'purify' ITS TECO code so that one copy in core [actual, real core!] could be
shared by multiple processes). That was used to write an EMACS-like package
for the PDP-11 UNIX TECO (but much simpler than real EMACS), which we used for
quite a while before Montgomery EMACS for UNIX showed up.
The full dump of the MIT-CSR PWB1 UNIX system which I retrieved has all the
sources and documentation for that TECO, and the ^R-mode code, etc. If anyone
is interested in seeing it (or maybe even playing with it, which will need
the UNIX MACRO-11), let me know, and I'll upload it.
Noel
PS: Speaking of the full dump of the MIT-CSR PWB1 UNIX system, I was poking
around it a couple of days ago, and I found V6 'multiplexor' kernel drivers -
mpio.c and mpx.c, etc - I think thay 'fell off the back of a truck' at Bell,
like a lot of other stuff we weren't supposed to have, like the circuit design
tools, etc. I'm not sure if I have the user programs to go with them; I think
I may have found some of them for Paul Ruizendaal a while back, but the memory
has faded. Again, if interested, let me know.
I never really used it but i do remember an editor called le on the v7 interdata/Perkin Elmer i used at Leeds poly.
I read electronics and we all used vi, the computer science people at a different campus used le on their Interdata; no idea why.
anyone any background on le? ihave not seen sight nor sound of it since.
-Steve
Evening all,
Seeing as our leader is worried about aliveness, I felt it fitting to send a link to a part-time project I’m working on.
A couple of weeks ago, I fired up Virtualbox and installed NetBSD/i386 1.0 from floppy images. Virtualbox can be persuaded to read 1.2MB floppies - I’ve had less luck on Qemu with this. But after I setup the VM, I quickly converted it to one that Qemu could use.
Then I loaded all the source floppies for 1.1 and 1.2 onto the VM, then upgraded the VM to 1.1 then 1.2 by compiling from source. By which time the pcnet network interface worked reliably. NetBSD still provides a pserver CVS method, so I was able then to CVS update, upgrade to 1.3.3 onwards.
1.4.3 -> 1.5.4 involves a change of binary format from a.out -> ELF.
From 1.6 onwards, life becaomes simpler because of the build.sh system, but I spent the time to go all the way up to 9.2 via sources between each release. (I managed to build 9.2 from 6.1 as well.)
The VMs can be found on this landing page:
https://chrispinnock.com/stuff/netbsd/
I’m working on a write-up which I will publish at some point and I’m also working on OpenBSD branching off at NetBSD 1.1 - I’ve build a OpenBSD 2.0 VM from the NetBSD 1.1 VM on the page above.
amnesiac# ls -l /ne*
-rwxr-xr-x 1 root wheel 19089180 Mar 26 02:47 /netbsd
-rwxr-xr-x 1 root wheel 659600 Mar 13 22:09 /netbsd.10
-rwxr-xr-x 1 root wheel 1332275 Mar 13 22:09 /netbsd.11
-rwxr-xr-x 1 root wheel 1477949 Mar 13 16:13 /netbsd.12
-rwxr-xr-x 1 root wheel 1530049 Mar 13 17:47 /netbsd.121
-rwxr-xr-x 1 root wheel 2211878 Mar 14 02:23 /netbsd.133
-rwxr-xr-x 1 root wheel 3407541 Mar 14 05:12 /netbsd.143
-rwxr-xr-x 1 root wheel 4941157 Mar 14 05:50 /netbsd.154.aout
-rwxr-xr-x 1 root wheel 5048054 Mar 14 09:20 /netbsd.154.elf
-rwxr-xr-x 1 root wheel 6182687 Mar 14 11:53 /netbsd.162
-rwxr-xr-x 1 root wheel 7447216 Mar 14 14:35 /netbsd.203
-rwxr-xr-x 1 root wheel 7476202 Mar 15 01:12 /netbsd.21
-rwxr-xr-x 1 root wheel 8577892 Mar 15 11:50 /netbsd.31
-rwxr-xr-x 1 root wheel 10343742 Mar 15 23:47 /netbsd.4
-rwxr-xr-x 1 root wheel 12002769 Mar 16 05:31 /netbsd.52
-rwxr-xr-x 1 root wheel 13116694 Mar 16 14:53 /netbsd.61
-rwxr-xr-x 1 root wheel 17143555 Mar 17 04:50 /netbsd.72
-rwxr-xr-x 1 root wheel 19695304 Mar 20 09:12 /netbsd.82
-rwxr-xr-x 1 root wheel 19089180 Mar 28 10:46 /netbsd.92
All the best
Chris
> From: Angelo Papenhoff
> By 'upload it' do you mean the full dump or TECO only?
At this point in time, not the full dump (below for why).
I have previously uploaded lots of other bits, e.g. (looks quickly): the
TCP/IP that was written for it (with the TCP in the 'user process', making
for a small system, good for -11/23's and -11/40's); Montgomery EMACS; TECO
(already done - along with the MACRO-11, but I still need to do the linker,
and the BCPL compiler one needs for the linker).
> That system sounds very interesting and I'd love to see the whole thing.
Unfortunately, the dump includes _everything_ on the system, including
personal email, etc, etc. So I have to curate it anything I upload.
I suppose I should put together an 'index page', which lists (and links
to) everything that has been uploaded?
Noel
> Just checking that the TUHS list hasn't gone belly up, as it's been pretty
> quiet for a week :-)
>
> Cheers, Warren
Not relevant to a sudden dip, but overall my observation is that retro computing interest tends to focus on a period 30-40 years ago. For example, in the late 80’s people were going retro on the LGP-30, the story of Mel, etc. Probably this matches with people retracing their formative years in the industry when they retire.
If correct, we should see a rise in interest around early Linux in the upcoming years, with interest in 80’s Unix and early networking declining. We’re probably already past peak for interest in 1970’s Unix.
The historical log of this mailing list is important. Documenting historical events will get much harder after the "40 year window" has closed.
Paul
I did not have a lot of time to work on documenting the evolution of paging / virtual memory code in 32V, Sys III and early SysV in the past months, but I did get some more background information that seems worth sharing.
My understanding of the virtual memory story at USG is now as follows:
Somewhere in 1981/82 a project plan for Unix 5 / System V was made and evolving John Reiser’s virtual memory code for 32V-r3 was part of that plan. “Evolving” in this context meant making it more maintainable and more hardware independent. John’s code assumed a memory page, a disk block and a file block all to be the same size, and it needed to be more general. It was also designed around the VAX MMU and this too needed to be generalised. The person assigned to that job was Bob (Robert) Baron, reporting to Tom Raleigh. The project involved quite a bit of re-architecting and progress was slowish. On top of that Bob left for CMU to work on Mach. Tom Raleigh tried to pick up where Bob had left off, but progress remained slowish.
In parallel, Keith Kelleman and Steve Burroff were working on Unix for the 3B20 Unix. They did paging code from scratch around the 3B20 MMU (which used a more or less ‘modern’ page table design) and developed their idea for the “regions” abstraction to support large, non-contiguous address spaces. It seems that they built on the main working set ideas/concepts in the Reiser/Baron/Raleigh code base, combined these with their “regions” idea, made it multi-processor capable and made it all work on the 3B20. Around that time Tom Raleigh seems to have transferred to Bellcore, and the VAX code base got orphaned.
Two young engineers appear to have picked up the work on the VAX code base: Dean Jagels and Jim McCormick. My understanding is that they essentially back ported the 3B20 work to the VAX, falling back on the Reiser/Baron/Raleigh work where necessary. They got it working, and as far as I can tell, this is what got released in 1984 as part of SysV R2.4 for the VAX (the oldest surviving source code for this that I could find).
This somewhat tortuous birth may in part explain why Research chose to use the 4BSD virtual memory code for 8th edition.
> From: Bakul Shah
> My impression is that there is much less traffic on pretty much all the
> mailing lists I am on and I am wondering why.
Ukraine? That's certainly been absorbing a lot of my attention (but it
seems like it's going to go on for quite a while now).
Noel
> 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
