TUHS

tuhs@tuhs.org

12 participants
6534 discussions

by Steve Simon

at the risk of making a fool of myself - there are several people far better qualified here, however… my memory is that the plan9 linker could be easily rebuilt to use malloc and free in the traditional style, reducing its memory footprint - though making it much slower. -Steve

2 years, 6 months

Early Unix on (64-bit) Risc-V

by Paul Ruizendaal

Adam Thorton wrote: > I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support. > > The third one is a solved problem. The second one would not be that hard to adapt, say, uIP 0.9, to v7. That first one would require some work with C type sizes, but getting larger is easier than the reverse. It's that last one. > > Having said that...maybe what I really want is 64-bit 4.3 BSD? > > I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine. I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host. Luther Johnson wrote: > I'm in the process of building a system like that for myself, but > perhaps a little smaller - mine will be based on an embedded > microprocessor I've developed (so much work still yet to do ! at least a > year out). Earlier this year I ported VAX System III to Risc-V, to a simple Allwinner D1 based SBC. This is RV64GC. Just ported to the console terminal. It turned out that porting Sys III to 64 bit was surprisingly easy, most of the kernel and user land appears to be 64 bit clean. It helps that I am using a LLP64 compiler, though. Apart from networking Sys III also feels surprisingly modern (for an ancient Unix) - its should get more attention than it does. The hardest work was in porting the VAX memory code to Risc-V page tables (and to a lesser extent, updating libc for the different FP formats). The code is currently in an ugly state (with debug stuff in commented-out blocks, a mix of ansi and K&R styles, an incoherent kludgy build system, etc.) and the shame stopped me from putting it out on gitlab until I found enough time to clean this up. As there seems to be some interest now, I’ll put it up anyway in the next week or so. There you go Adam, half your wish comes true. The kernel is about 60KB and most binaries are quite close in size to the VAX equivalents. My next goals for it are to re-implement the Reiser demand paging (I think I have a good enough view of how that worked, but the proof of the pudding will be in the eating), and to add TCP/IP networking, probably the BBN stack. Making it work on RV32 and exploring early SMP work is also on my interest list. === David Arnold wrote: > I think xv6 does SMP? (param.h says NCPU = 8, at least). > > You’d need to add a network stack and a userland, but there are options for those … For the above, making xv6 work on the D1 board was my first stepping stone, to proof the tool chain and to get the basics right (hardware init, low-level I/O, etc.). As an educational tool, I am sure that xv6 hits all the right spots, and it certainly does SMP (the D1 is single hart, so I have not tried that myself). I like it a lot in that context. However, as a simple Unix it is useless: from a user-land view it is less capable than LSX. At minimum it needs fixes to make the file system less constrained. In my view, for SMP Keith Kelleman’s work for Sys-V is probably a better place to start.

2 years, 6 months

Xv6, Linux and SysIII on a RV32 FPGA system

by Paul Ruizendaal

Having done the SysIII 64-bit port to a recent Risc-V chip, I realised that whilst it is an interesting exercise bij itself -- and maybe even useful to students and educators around the world -- it is not ideal as a research tool for analysing Unix from the early 80’s. The address size difference adds some superfluous porting, and the 100x speed difference can hide critical algorithm constraints. Also the complex IO devices are out of character. For a Risc-V 32 bit target I’ve settled on an FPGA implementation from the University of Tokyo. I’ve somewhat modified the system to work with the open source Yosys/NextPNR tool chain. It now implements a Linux-capable SoC with a full MMU, a 4-way cache and SD card driver in less than 4,000 lines of plain Verilog (compiling to about 14K LUTs). In a way, the code has a 6th edition feel to it: it covers a real and usable system and the code can be understood in a couple of days -- or a semester for a student who is new to the concepts involved. https://gitlab.com/r1809/rvsoc/-/tree/main/doc So far I have Linux and XV6 (https://gitlab.com/r1809/xv6-rv32) running, but have not started on SysIII yet. Usefully for my use case this system is not very fast, completing an instruction in on average 10 clocks. Still, when running at 40MHz it is about 2 or 3 times as fast as a VAX11/780, which is similar to the systems of the mid-80’s. Even at this speed, a single user console Linux is surprisingly usable. By the way, funny to realise that ‘Unix/Linux capable’ has been a marketing slogan for system capability for 40 years now. There is a short video clip with a demonstration (but running at 100MHz) here: https://youtu.be/Kt_iXVAjXcQ Due to its simple design, the main CPU only uses some 30% of the cache memory bandwidth and it should not be all that hard to add a second CPU to the system (the CPU already supports the Risc-V atomic operations), and this could be a nice target for studying the early Unix multi-processor designs (e.g. VAX/BSD & 3B2/SVR3). I find it an intriguing thought that the chip technology of the early 80’s (let’s say the technology used for the Bellmac-32 or M68K) would probably have sufficed to build a CPU similar to the one used in this FPGA design. As the topic of this post is on a tangent from the focus of this list, I would recommend that any follow-ups not related to the history of Unix are sent off list.

2 years, 6 months

Porting the SysIII kernel: first steps & memory management

by Paul Ruizendaal

Porting the SysIII kernel to a D1 board (https://www.aliexpress.us/item/3256803408560538.html) began with a port of XV6, in order to test the tool chain and to get comfortable with this target. Michael Engel had already ported XV6 to the D1 chip a few months before (https://www.uni-bamberg.de/fileadmin/sysnap/slides/xv6-riscv.pdf) giving a ready base to work with. The main new effort was to add code to initialise the DRAM controller and the SD Card interface, and to have a simple boot loader. Such code is available from the manufacturer board support package (BSP), although in this case the DRAM controller code was only available as assembler compiler output and had to be reverse engineered back into C. In general I was surprised to see how big and unwieldy the BSP code is; maybe the code just looks sloppy because it has to deal with all kinds of edge cases - but I can also imagine that it accumulates cruft as it is ported from SoC to SoC by the manufacturer. The resulting XV6 source tree is here: https://gitlab.com/pnru/xv6-d1 This version automatically boots from the SD Card on the board. With that out of the way, the ancient Unix port was relatively easy. It would seem to me that the SysIII code base has a lot of clean-up work in it that still pays off today. The code compiles to a 64-bit target with minimal updates, which I think is a compliment to the engineers that worked on it. Probably using a LLP64 compiler also helped. In order to bring something up quickly, I modified the kernel to load ELF binaries, so that I could use proven material from the XV6 port (such as a minimalistic init and shell). Initially, I just replaced VAX memory management with page table code taken from XV6 (i.e. no VM or swapping). Working with Risc-V page tables gives much simpler code, but I have a deeper appreciation of the VAX paging design now: for the type of code that was run in 1980, the VAX design enables very small page tables with just a few dozen entries. In contrast, for the 3-level page tables of 64-bit Risc-V I end up with 7 pages of page table of 4KB each, or 28KB -- that is larger than the memory image of many SysIII programs. If I move the ‘trampoline' to just above the stack in virtual memory it could be 5 pages instead of 7, but the overall picture remains the same. The 68020 or ‘030 MMU could be configured to have various page sizes -- this looked byzantine to me when I first saw it, but it makes more sense now. Next I replaced the VAX scatter paging / partial swapping code, keeping the same methodology. I noticed that there is still confusion over memory management in 32V and SysIII (and implicitly SVR1,R2). The original 32V as described in the London/Reiser paper used V7 style swapping. This code can be found as ‘slowsys’ in the surviving source (https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/slowsys) It was quickly (Mar vs. Jan 1979) replaced by the scatter loading / partial swapping design already hinted at in the paper (source is in 32V/usr/src/sys). Unfortunately, the “32V uses V7 swapping” meme lives on. In scatter paging, the pages are no longer allocated continuous in physical memory but new pages are taken from a free list and expansion swaps are not usually needed. Also, when a process is swapped out, it is not fully swapped out, but just enough pages to make room for the new process. When it is readied to run again, only the partial set needs to be reloaded. In the VAX context, scatter paging and partial swapping are quite effective and I think competitive with demand paging for the 25-100KB processes that were in use at the time. As I mentioned in the post on the toolchain, the Plan 9 C compiler can easily use 1MB of memory and in a 4MB of core context, this trashes the algorithm; it starts to behave much like traditional swapping. The reason for this is that the entire process must be in memory in order to be able to run and the algorithm cannot recognise that a much smaller working set is needed. The implicit assumption of small processes can also be seen in the choice to limit partial swaps to 4KB per iteration (8 VAX pages). For handling processes with a large memory footprint but a small working set a true demand paged VM approach is needed. The simplest such approach appears to be Richard Miller’s work for SVR1 (see June 1984 Usenix conference proceedings, "A Demand Paging Virtual Memory Manager for System V"). This is a very light touch implementation of demand paging and it seems that enough bits and pieces survive to recreate it. The journey through the memory code made it clear again that in SysIII and before, the memory code is scattered over several locations and not so easy to fathom at first glance. It would seem that in SysV/68 an attempt was made to organise the code into separate files and with a more defined API. It does not seem to have carried through. Maybe this was because the MMU’s of the 1980-1985 era were all too different to be efficiently abstracted into a single framework. Beyond SysV/68, were there any other attempts in the early 80’s to organise and abstract the kernel memory management code (outside BSD)?

2 years, 6 months

Riscv, Plan-9 and a toolchain

by Paul Ruizendaal

After initially gearing up to use the Motorola 68020 or 68030 as a porting target for a study of Unix in the 1980-1985 era, I reconsidered and used Risc-V as a target instead. As the original RISC and MIPS projects were contemporaneous with early 32-bit Unix (32V, BSD, SysIII and SVr1,r2) it seems appropriate and there is currently considerable interest (hype?) around Risc-V. From a programming perspective, the Risk-V ISA does not feel (at least to me) all that different from what was current in the early 80’s — the number of WTFs/min is low. The modularity is a pleasant surprise, as is the observation that the 32-bit and 64-bit instruction sets are almost identical and that compressed instructions mingle nicely with full size ones. The MMU design appears straightforward. Maybe this is because the ISA is still relatively new and has not acquired much historical baggage at this point in its lifespan, but it also seems to be a good synthesis of insights gained over the last 4 decades and applied with a sense of minimalism. At first I was thinking to create a toolchain based on pcc or pcc2 for the SysIII porting effort, based on some preparation I had done when I was still thinking about 68030 as a target (the surviving Blit code includes a pcc-based 68000 compiler and the SysV/68 source archive contains a pcc2-based compiler). Before I got underway with that, I came across a presentation Richard Miller had done about his Risc-V compiler: https://riscv.org/news/2020/10/a-plan-9-c-compiler-for-rv32gc-and-rv64gc/ Richard was kind enough to share the source code for his Risc-V back-end. The first complication was that the source code assumes that it will be running inside a Plan-9 environment, whereas I was looking for a Unix/Posix environment. Luckily somebody already had assembled the libraries needed for this: https://github.com/aryx/fork-kencc I’m not sure where it came from, but I would assume it has some roots in the "Plan-9 from user space" effort. From this work I extracted the minimum needed to get the C compiler working and to build from scratch. The libraries mostly just worked. The compiler was a bit harder: the source code assumes a LLP64 model in a few places and compiling this with clang (which uses a LP64 model) introduces issues in a handful of places. Other than this initial hurdle, the compiler and tools have worked flawlessly, both for 64-bit code and for 32-bit code, and have been a joy to use. One particular nicety is that Plan 9 style "abstract assembler" source for 64-bit code is even more identical to its 32-bit variant than with the mainstream Risc-V assembler syntax. My repo for the tool chain is here: https://gitlab.com/pnru/riscv-kencc Initially, my expectation was that I could only use these compilers as cross-compilers and that I would need to do a pcc2 version for native compilation at some point. However, when I saw how small and fast the tools were, I experimented with using them on SysIII. Much to my surprise the effort required was absolutely minimal, all that was needed was adding a dozen simple standard functions in libc (see here: https://gitlab.com/pnru/SysIII_rv64/-/tree/master/libc/compat) and adding the ‘dup2' sys call. I had not expected that SysIII was so close to the Unix systems of the 1990’s in this regard. This result inspires ideas for future projects: as I plan to add an 8th edition style file system switch anyway, maybe it will not be all that hard to make the Plan-9 debugger work on this “SysIII+” as well. Another observation has been that the code size of binaries compiled for Risc-V by this tool chain is almost the same as those compiled for the VAX by pcc (the Risc-V ones are maybe 10-20% larger). This is using the compressed instructions where possible. This is I think another indication that both the Risc-V ISA and the tool chain are quite well done. The one less positive surprise has been the memory use of the compiler. Even on a relatively simple program file it will quickly use 1 megabyte or more of ram. I understood from Richard that this is because the compiler only malloc()’s and never free()’s by design. This has been a mixed blessing. Such large memory images don’t work all that well with the "scatter paging + partial swapping" memory management of SysIII when memory is constrained to say 4MB of core to mimic the systems of the era. On the other hand, parallel compiling the kernel on SysIII itself heavily exercises the partial swapping code and has been a great test case for debugging. Many thanks to Ken, Rob, Richard and all the others who created this fine tool chain!

2 years, 6 months

Re: Center 127 directory from 6/17/77

by Douglas McIlroy

> James Johnston: >> Yeah, but Rob, where was Fred? I was there in Acoustics Research (not >> 127!) then, using R70 for UCDS. > Rob Pike: > Not in (1)127 yet. He was transferred in some time after I arrived. Not > sure quite when. Mid-80s maybe. > ===== > Early-to-mid 1980s. ftg was already there when I interviewed in early 1984. > Norman Wilson In 1980 Fred was a stalwart of the computer center. There he exhibited great creativity, including the invention of "quest" for sniffing out security lapses throughout the BTL computer network. His findings underpinned the headline claim of the Labs' first computer-security task force (1982), "It is easy and not very risky to pilfer data from Bell Labs computers". Doug

2 years, 6 months

Center 127 directory from 6/17/77

by Tom Lyon

More grist from the scanner.

2 years, 6 months

Re: Center 127 directory from 6/17/77

by Norman Wilson

James Johnston: > Yeah, but Rob, where was Fred? I was there in Acoustics Research (not > 127!) then, using R70 for UCDS. Rob Pike: Not in (1)127 yet. He was transferred in some time after I arrived. Not sure quite when. Mid-80s maybe. ===== Early-to-mid 1980s. ftg was already there when I interviewed in early 1984. Norman Wilson Toronto ON

2 years, 6 months

X11 Conservancy Project

by Michelangelo De Simone

From [1]: The X11 Conservancy Project (X11CP) pulls together the disparate set of programs which were being written between the very late 80s, and early 90s -- usually for Unix and Linux. …snip… As the Internet expanded and Linux distributions became established, certain FTP sites were largely used to host some of the more established programs, as well as those found in the LSM. …snip… But the early dawn of free software, especially around applications written for X11, using Motif and XT and other widget libraries has now mostly been consigned to obscurity. With X11 itself now under threat of no longer being developed in favour of Wayland, these applications are going to be harder to run and be discovered. Hence, the X11CP is designed to be a central place for hosting the sources of these applications, and to showcase their unique history and properties. In keeping this software active, it will help keep an important historical point alive. [1] https://x11cp.org/ — Michelangelo

2 years, 6 months

Re: Early supported UNIX manual

by jnc＠mercury.lcs.mit.edu

> From: Phil Budne > The cover page has: > ... > Upper right corner: > PA-1C300-01 > Section 1 > Issue 1, January 1976 > AT&TCo SPCS I have a very similar manual; I got it a long time ago, and no longer recall how I came by it. Minor difference: mine is for PD-1C301-01, and at the bottom of the page, it says "ISSUE 1 1/30/76", followed by a prominent trade secret notice. TUHS has a copy of this version, here: https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_ja… The README file in that directory: https://www.tuhs.org/Archive/Distributions/USDL/README speculates that "this is PWB/1.0" but admits "this has not yet been confirmed". It's not PWB1, it's stock V6. If you look at the writeup of sys1$exec(), on pg. 39 of the PDF, you'll see it describing how arguments are copied into a disk buffer; that right there is the tip-off. In PWB1 (whose source we do have): https://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys1.c you'll see that PWB1 accumulates the arguments in a chunk of swap space. V6 _does_ use a disk buffer for this: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c So this is for V6. Noel

2 years, 6 months

UNIX on (not quite bare) System/370

by Phil Budne

The October 1984 BSTJ article by Felton, Miller and Milner https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf Describes an AT&T port of UNIX to System/370 using TSS/370 underpinnings as the "Resident System Supervisor" and used as the 5ESS switching system development environment. I also found mention at http://www.columbia.edu/~rh120/ch106.x09 chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96: Ian Johnstone, who had been the tutor at University of New South Wales working with Professor John Lions, was one of the researchers invited to Bell Labs. He managed the completion at AT&T Bell Labs of the port of Unix to the IBM 370 computer. See "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX Review, October, 1984, p. 26. Johnstone also led the group that did the port to the AT&T 2B20A multiprocessor system. I found https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Revie… "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers rationale. Also: "IBM's own involvement in Unix can be dated to 1979, when it assisted Bell Labs in doing its own Unix port to the 370 (to be used as a build host for the 5ESS switch's software). In the process, IBM made modifications to the TSS/370 hypervisor to better support Unix.[12]" at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0 Is there any other surviving documentation about the system? Any recall of what branch of AT&T UNIX it was based on? Thanks! Phil

2 years, 6 months

Re: UNIX on (not quite bare) System/370

by jnc＠mercury.lcs.mit.edu

> From: Bakul Shah > There is a further para: > Reducing external memory fragmentation to zero by utilizing the VAX- > 11/780 memory mapping hardware for scatter loading is high on the list > of things to do in the second implementation pass. I'm curious as to exactly what is meant by "external memory"? They must mean memory on the Synchronous Backplane Interconnect: http://gunkies.org/wiki/Synchronous_Backplane_Interconnect I.e. what most of us would call 'main memory'. If this code didn't even allocate main memory by pages, instead of in process-size blocks, it sounds like it's much like 32V (or is it 32V that's being discussed; I thought this thread had moved on to the Reiser demand paging version - my apologies it I've gotten lost). Also, this note: http://gunkies.org/wiki/Talk:CB-UNIX from Dale DeJager (which he kindly gave me permission to post) gives a fair amount of detail on the relationship between the Research and CB/UNIX versions, with a brief mention of USG - precisely the era, and relationships, that are so poorly documented. Interestingly, he indicates that the early versions of what later became CB/UNIX used something in the V1/V3 range (V4 was the first one in C), so it dates back earlier than most people apparently assume. If anyone else has any first-hand notes (i.e.from people who were there at the time), about the relationship between all the early systems, for which the author has given permiosssion to post it, please send it to me and I will add it to the appropriate article on the CHWiki. Probably the most needed is more about the roots of USG; Dale has filled in CB/UNIX, and the roots of PWB are covered fairly well in the BSTJ article on it: https://archive.org/details/bstj57-6-2177 at least, for PWB1. Anything that covers the later PWBs would likewise be gratefully receied. I suppose I should also write up the relationships of the later UNIXen - 32V and its descendants too - any material sent to me about them will be most gratefully received. (If anyone want a CHWiki account, to write it up themselves, please let me know). Noel

2 years, 6 months

3B20S UNIX User's Manual Release 4.1 Scans Thread

by segaloco

Good evening folks. I'm starting a new thread to pass along info as I scan materials from the 3B20S manual that I picked up. I figured it'd be easier to trickle out the bits folks ask me for first and then continue to scan the rest, that way anyone looking to sink their teeth into something specific can be sated first. With that, the first scan (and frankly one of my favorite things about this manual) is the cover itself: https://commons.wikimedia.org/wiki/File:UNIX4.1UsersManualCover.png Someone had mentioned the idea of making this into a poster and I gotta say, I'd gladly put one up. The image definitely would need some cleanup for that, I just scanned it like it came, haven't tried to clean up any of the wear of time yet. Sadly, the back cover isn't emblazoned with a big Bell logo like the 3.0 and 5.0 (Bell variant) manuals, so scanning that would be a boring white piece of cardstock. Anywho, the next round which may come later this evening or sometime this weekend is going to be various *ROFF-related documents, so documents like troff(1), mm(5), etc. - Matt G.

2 years, 6 months

Re: UNIX on (not quite bare) System/370

by jnc＠mercury.lcs.mit.edu

> From: Bakul Shah > Is there a publicly available description of Reiser's VM system? I > found "A Unix operating system for the DEC VAX 11/780 Computer" by > London & Reiser which includes a long paragraph on VM (included below) That para is basically all about the VAX paging hardware; it doesn't say anything about how that (any :-) Unix actually uses it. Noel

2 years, 6 months

Stdin Redirect in Cu History/Alternatives?

by segaloco

Good morning all. I've been doing some historical research on the UUCP cu utility this morning and have come across a little discrepancy between the various UNIX streams I was wondering if someone could illuminate. So cu as of V7 supported the ~$ escape, a means of calling a local procedure and emitting stdout over the TTY line to the remote machine, all fine and good for packaging a character stream to emit. However, what I'm not finding in that age of documentation is any means of requesting std*in* from the TTY line as input to a local procedure (in essence running a text filter or handshake-driven protocols over cu). The context in which I'm researching this is integrating cu into my bare-metal SBC programming using XMODEM so I can rest a little easier my process is based on tools I'll probably find in most places. So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no stdin. I did some further digging and it looks like different UUCP implementations cracked this nut with different escapes, with BSD eventually going with ~C and Taylor UUCP opting for ~+. Checking the current illumos manual pages (for a SVR4-ish example) doesn't turn up any command for this. This is indicative of there never being an agreed-upon mechanism for doing this, although I could see this being a very useful mechanism. What I'm curious about is if the lack of a bi-directional redirect in early cu is reflective of a lack of need for that sort of functionality at the time or that matters such as that were handled through a different mechanism. One thought I did have is that there wasn't file locking at the time (right?) and so theoretically nothing would prevent one from using a cu session on one terminal to send interactive commands and then a second using fd redirects in the shell to run filters/protocols separately of the interactive stream. - Matt G.

2 years, 6 months

Re: pre-1991 USENIX proceedings

by Marc Donner

https://bitsavers.org/pdf/usenix/USENIX_1986_Winter_Technical_Conference_Pr… Here is the URL (All I did was search for ‘“Unix on big iron” usenix proceedings’) On Mon, Dec 19, 2022 at 4:59 PM James Frew <frew(a)ucsb.edu> wrote: > Hello Marc, > > Where did you find the 1986 USENIX proceedings? > > Reason I'm asking is, I have a pile of pre-1991 USENIX proceedings that I > haven't found online, and I'm planning to get them scanned. It would be > great if I didn't have to go the trouble :-) > > Thanks, > /James Frew > On 2022-12-19 13:36, Marc Donner wrote: > > > There was a track of USENIX 1986 called "UNIX on Big Iron." Peter Capek > of IBM was the chair and Gene Miya and Jim Lipkis rounded out the program > committee. The proceedings are available. > > -- ===== nygeek.net mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

2 years, 6 months

Re: origin of null-terminated strings

by Douglas McIlroy

> To what extent were the Unix folks at Bell Labs already familiar with DEC systems before the PDP-7? Some awareness, but no hands-on experience, > was any thought given to trying to get a 360 system? Very serious thought. However, virtual memory was a non-negotiable desideratum, to which Gene Amdahl was implacably opposed because demand paging would devastate hardware performance. Soon after GE got the nod, IBM revealed Gerrit Blaauw's skunk-works project, the 360/67, but by then the die had been cast. Michigan bought one and built a nice time-sharing system that was running well before Multics. Doug

2 years, 6 months

origin of null-terminated strings

by Douglas McIlroy

I think this cited quote from https://www.joelonsoftware.com/2001/12/11/ is urban legend. Why do C strings [have a terminating NUl]? It’s because the PDP-7 microprocessor, on which UNIX and the C programming language were invented, had an ASCIZ string type. ASCIZ meant “ASCII with a Z (zero) at the end.” This assertion seems unlikely since neither C nor the library string functions existed on the PDP-7. In fact the "terminating character" of a string in the PDP-7 language B was the pair '*e'. A string was a sequence of words, packed two characters per word. For odd-length strings half of the final one-character word was effectively NUL-padded as described below. One might trace null termination to the original (1965) proposal for ASCII, https://dl.acm.org/doi/10.1145/363831.363839. There the only role specifically suggested for NUL is to "serve to accomplish time fill or media fill." With character-addressable hardware (not the PDP-7), it is only a small step from using NUL as terminal padding to the convention of null termination in all cases. Ken would probably know for sure whether there's any truth in the attribution to ASCIZ. Doug

2 years, 6 months

Re: origin of null-terminated strings

by jnc＠mercury.lcs.mit.edu

> From: Bob Supnik > The PDP11 had .ASCIZ, starting with Macro11 in 1972. I was just about to report on my results, after a tiny bit of digging, which included this. The important datum is that PAL-11 (in DEC-11-GGPB-D, "paper tape software", April 1970, revised March 1971), which _preceded_ Macro-11, _does not_ include .ASCIZ (although it has .ASCII). My oldest Macro-11 book (DEC-11-OMACA-B-D, "BATCH-11/DOS-11 Assembler (MACRO-11)", April 1972, revised March 1973) does have .ASCIZ. So in the DEC PDP-11 universe, it dates from sometime between 1970 and 1972. I'm not sure if Bell had any of the DEC paper tape software: "In early 1970 we proposed acquisition of a PDP-11, which had just been introduced by Digital. ... an order for a PDP-11 was placed in May. The processor arrived at the end of the summer, but the PDP-11 was so new a product that no disk was available until December. In the meantime, a rudimentary, core-only version of Unix was written using a cross-assembler on the PDP-7." So the .ASCIZ in Macro-11 wasn't until a couple of years later. Noel

2 years, 6 months

Terms for string, and similar character constructs (was: origin of null-terminated strings)

by Alejandro Colomar

[Resend from my subscribed address, as the list is subscribers-only, it seems] In C, most syscalls and libc functions use strings, that is, zero or more non-NUL characters followed by a NUL. However, there are a few cases where other incompatible character constructs are used. A few examples: - utmpx(5): Some of its fields use fixed-width char arrays which contain a sequence of non-NUL characters, and padding of NULs to fill the rest (although some systems only require a NUL to delimit the padding, which can then contain garbage). - Some programs use just a pointer and a length to determine sequences of characters. No NULs involved. - abstract sockets: On Linux, abstract Unix socket names are stored in a fixed-width array, and all bytes are meaningful (up to the specified size), even if they are NULs. Only special that that the first byte is NUL. Since those are only rare cases, those constructs don't seem to have a name; some programmers call them strings (quite confusingly). Has there been any de-facto standard (or informal naming) to call those things, and differentiate them? Thanks, Alex -- <http://www.alejandro-colomar.es/>

2 years, 6 months

Please reinstate

by Aaron

I accidentally unsubscribed Sent from my iPhone

2 years, 6 months

Continued celebration of Warren's Flame

by Will Senn

All, I recently migrated my blog - it's new and improved, of course:) over to https://decuser.github.io. When I saw Warren was awarded Usenix's "The Flame" last week, I thought it appropriate that one of my first new blog posts celebrate Warren and his well deserved award. Here's the post: https://decuser.github.io/unix/2022/12/15/usenix-flame-award-2022.html Thanks again to Warren, both for the initiative, and for the maintenance of one of my all time favorite archives. Thanks, Will

2 years, 6 months

UNIXabilia

by James Frew

Having recently emeritated, I'm clearing out my university office and giving away hundreds of books. It occurs to me that some of them may be of interest to some of the folks on this list. (Before you ask, no, you can't have my original printed-on-Kleenex versions of the Lions notes...) Most of the books are listed here: https://www.librarything.com/catalog/james.frew . They're (alas) utterly uncategorized, but include a fair amount of UNIX, C, and general CS stuff. I also have some manuals and USENIX conference proceedings even LibraryThing couldn't locate; they're listed in the attached Markdown file. None of these proceedings are online at usenix.org, so I'd be stoked if someone volunteered to scan them. If you want any of them, let me know, and we'll figure out some way to reimburse me for shipping them. (No charge for the "content".) Or if you're close enough to Santa Barbara, come and get 'em. Cheers, /Frew <https://purl.org/frew>

2 years, 6 months

Re: Clever code

by Rudi Blom

I vaguely remember having read here about 'clever code' which took into account the time a magnetic drum needed to rotate in order to optimise access. Similarly I can imagine that with resource restraints you sometimes need to be clever in order to get your program to fit. Of course, any such cleverness needs extra documentation. I only ever programmed in user space but even then without lots of comment in my code I may already start wondering what I did after only a few months past. Cheers, uncle rubl -- The more I learn the better I understand I know nothing.

2 years, 6 months

OT - Remington Rand ad from 1956

by Rich Morin

This is rather off-topic, but some folks here might find it amusing... A Univac Commercial from Remington Randt - 1956 https://www.youtube.com/watch?v=-Ge0N080qw8& -r

2 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS