TUHS

tuhs@tuhs.org

47 participants
6504 discussions

by Steve Simon

i never got on with rpn, even though i am the kind if person who should - i have a little bit of dyslexia, perhaps thats why. when i moved to plan9 i found it included hoc from K&P, just used that for the odd bits of maths i need. -Steve

5 years, 2 months

Unix on Zilog Z8000?

by Jon Forrest

There's been a lot of discussion about early Unix on Intel, National Semi, Motorola, and Sparc processors. I don't recall if Unix ran on the Z8000, and if not, why not. As I remember the Z8000 was going to be the great white hope that would continue Zilog's success with the Z80 into modern times. But, it obviously didn't happen. Why? Jon

5 years, 2 months

Re: [TUHS] Unix 8th / 9th edition IPC paper

by Clem Cole

I sent it off list to Chet and Paul but it's too big for Warren's reflector. I'll work with him to get it separately. If anyone else wants it before, please let me know off list. Clem On Mon, Mar 16, 2020 at 10:37 AM Clem Cole <clemc(a)ccc.com> wrote: > Here you go... > > Warren - Would please be able to add to the docs/paper directories... > USENIX Summer 1985 June 11-14 >

5 years, 2 months

BSD Net/2 Updates from CSRG

by Dan Plassche

Hi, Would anyone know how the CSRG made available updates to the public distribution of Net/2 before releasing 4.4 BSD Lite? Net/2 was released on tape in July 1991 as represented in the TUHS archive. The first mention I see of the sources appearing online is old usenet posts announcing the bsd-sources mirror on uu.net starting in January 1992. However, the Net/2 derived versions of NetBSD (0.8-0.9) and FreeBSD (1.0-1.1.5.1) imported userland tools revised after both dates in early 1993, when there are also mentions of using 4.4 code in the commit logs (well before Lite 1 was released in March 1994). At this point, I'm wondering if the latest code was issued on tape at the time of a request for Net/2 sources and there were direct uploads from the CSRG to any online mirrors before the USL lawsuit? Thanks, Dan Plassche -- Dan Plassche

5 years, 2 months

Re: [TUHS] Command line options and complexity

by Dave Horsfall

Meant for the list (and don't get me started on Reply All)... -- Dave ---------- Forwarded message ---------- Date: Fri, 13 Mar 2020 21:43:51 +1100 (EST) From: Dave Horsfall <dave(a)horsfall.org> To: Greg 'groggy' Lehey <grog(a)lemis.com> Subject: Re: [TUHS] Command line options and complexity On Fri, 13 Mar 2020, Greg 'groggy' Lehey wrote: >> -h is a gnuism, isn't it? > > It might have originated there, but then I would expect it to be spelt > '--produce-human-readable-output'. I haven't been able to establish from the > FreeBSD sources or commit logs when it was introduced. It would clearly have > been a reimplementation. It's in "df" as well, praise Cthulu: aneurin# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 496M 302M 154M 66% / devfs 1.0K 1.0K 0B 100% /dev tmpfs 1000 272K 999M 0% /tmp /dev/ad0s1d 2.9G 1.4G 1.2G 54% /usr /dev/ad0s1e 989M 581M 329M 64% /var /dev/ad0s1f 3.9G 2.2G 1.4G 62% /home /dev/ad0s1g 8.9G 8.0G 127M 98% /usr/local fdescfs 1.0K 1.0K 0B 100% /dev/fd procfs 4.0K 4.0K 0B 100% /proc (Memo to self: see where all the room has gone in /usr/local, as that's where I assigned the leftover space after the other partitions.) No, I've never liked stuffing everything under the root file system as both the Mac and Penguin do; fill the root file system and you're hosed (and I also have an itch about /tmp being there as it's a world-writable directory). >> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html does >> specify the -S switch. That's POSIX, isn't it? > > So it is! This was the first option that I wanted to add, back when I still > had practice wheels. I asked my mentor, and he said "not the Unix way", so I > let it be. Then Wes Peters came up with the idea, and I thought he committed > it, but it seems that it ultimately came from Kostas Blekos in 2005, based on > the same feature on NetBSD and OpenBSD. I wonder when it made it to POSIX. Years ago I wrote a simple script "lss" which did the sort after being howled down on one of the FreeBSD lists; what a surprise to see "-S"... Heck, back in my UNSW days I suggested extending stty() to cover non-TTY devices and got trashed by the AGSM/ElecEng mob; well well, look at ioctl() when it appeared. -- Dave

5 years, 2 months

Re: [TUHS] Command options and complexity

by Doug McIlroy

> -,: Make the option standard: output numbers with commas every 3 digits A terrible idea. Whatever ls outputs should be easy for other programs to read, and few know how to read commafied numbers. As others have mentioned, this is also a strong argument for changing the output representation of dates. I often do mailx -H | sort -t/ -k2nr to sort in reverse order of size--a quick way to find the pay dirt when I want to shrink my mailbox. This would never fly if the sizes had commas. (Well, I suppose I could add sed s/,//g to the pipeline.) Doug

5 years, 2 months

Command line options and complexity

by Jon Steinhart

OK, this should be good for some conversation. A friend sent me this link today: http://danluu.com/cli-complexity/

5 years, 2 months

Re: [TUHS] Command line options and complexity

by John P. Linderman

Nothing I'm aware of. I didn't mind throwing "tac" over the wall, because it was trivial, probably a couple hours work for me, under a minute for Ken. But the rsort source is not at all trivial, and still of potential value to AT&T. The source managed to get out as part of the "Hancock" project. I found a link in https://www.wired.com/2007/10/att-invents-pro/ but the page is gone. It probably didn't help that Wired titled the article *AT&T Invents Programming Language for Mass Surveillance* That's horse-pucky, akin to "Pitchfork makers invent device for spearing babies". I'm trying to track down a copy that was released publicly. I'm not hopeful. On Mon, Mar 9, 2020 at 11:28 AM Tyler Adams <coppero1237(a)gmail.com> wrote: > Woah, this sounds really useful, is there anything like it today? > > On Sun, Mar 8, 2020, 16:32 John P. Linderman <jpl.jpl(a)gmail.com> wrote: > >> In the "UNIX SYSTEM" issue of the BSTJ back in October of 1984, I >> suggested that it might be better, both for functionality *and* >> performance, to have a sort that only worked on records with a *single* >> key to be sorted *lexicographically*, and put all the complexity of >> dealing with native integers, dates, case-mapping, etc into a key-building >> front end. I wrote such a sort built around a radix sort. The sort >> itself sported very few options relating to record format (fixed-length, >> newline terminated, and header-based, where an ascii header identified >> record length, and, optionally, key position and key length), where to find >> the key in fixed-length and newline terminated records, merge-only, check >> sort order only, unique, strip off the sort key (to avoid the need for a >> post-process in many cases). Key-building was usually near-trivial using >> awk or perl or a few commands for tweaking native integer and floating >> point values so they would sort lexicographically. The sort was stable and >> blazingly fast. Some summer students once complained to me that I was >> messing up a paper they were writing because my external sort was faster >> than an internal qsort... the kind of complaint that warms one's heart. At >> the back of my mind was a generic key-building library that would >> accommodate (decimal) numbers of arbitrary length, with or without "E" >> exponents, dates in various formats, string collation for Unicode, etc. It >> remains at the back of my mind. >> >> On Sun, Mar 8, 2020 at 5:32 AM Tyler Adams <coppero1237(a)gmail.com> wrote: >> >>> The idea of a simple rule is great, but the suggested rule fails on sort >>> -u which afaik came after sort | uniq for performance reasons. >>> >>> Another idea on the same vein is that a flag should be added only when >>> the job can be done inside the program and not with stdin/stdout (or no >>> flag can be added if one can reproduce the same behavior using pipelines). >>> >>> So, you need sort -u because only within sort can you get the >>> performance needed to get the job done. >>> >>> But you don't need -h in ls -lh. All the information to render a human >>> readable number is present on stdout of ls -l. You could easily have a >>> filter which renders numbers with options like adding commas, dots, >>> scientific notation, precision, money, units, etc. >>> >>> Tyler >>> >>> On Sun, Mar 8, 2020, 07:33 Jon Steinhart <jon(a)fourwinds.com> wrote: >>> >>>> After following this discussion, I guess that I have a simplistic way to >>>> determine whether something should be a dash option or a filter. In >>>> general, I'd make a filter if whatever it was doing was applicable to >>>> more than one command, a dash option otherwise. >>>> >>>> Jon >>>> >>>

5 years, 2 months

Re: [TUHS] eqn anomaly

by norman＠oclsc.org

On (post-)V10: echo '.EQ define f % $1 % f("a,b") .EN' | eqn emits .lf 1 - .EQ .ds 11 "\f2a,b\fP .if 1m>\n(.v .ne 1m .rn 11 10 \&\*(10 .EN .lf 5 On a Linux system with GNU eqn (groff) version 1.22.3, the output is rather more verbose (48 lines!), but the troff result is just an a (rather than the proper a,b) and eqn complains eqn:<standard input>:3: newline before end of quoted text I assume this Linux result is more or less what Doug expects. Norman Wilson Toronto ON (still heating my basement with a MicroVAX)

5 years, 2 months

Re: [TUHS] eqn anomaly

by Doug McIlroy

I was surprised that eqn parses the macro call below as having two arguments, each with an unmatched ". .EQ define f % $1 % f("a,b") .EN Ralph Corderoy found that the comma can be hidden by replacing it with \N'44'. A somewhat cleaner way to hide it is .EQ define f % $1 % define comma % , % f(a comma b) .EN This works too. .EQ f(f(a comma b)) .EN [Note for cognoscenti. Eqn's practice in expanding macro arguments clashes with troff's. Eqn expands nested calls after substitution in the outer macro definition; troff expands while collecting arguments of the outer call. I've found no documentation of the eqn behavior.] The classical man page for eqn asserts categorically, `Strings enclosed in double quotes " " are passed through untouched.' Unfortunately the version of Kernighan/Cherry User's Guide that describes macros with arguments says little about how arguments are parsed except that they are separated by commas--nothing about whether commas are hidden by parentheses or quotes. Certainly splitting at a comma in a quoted string violates the plain meaning of the man-page assertion. If anyone has v10 (or perhaps something else after v7) running, I'd be grateful to learn what classic eqn actually did. I'm morally certain that if it did split and anyone had complained to Brian, he would have fixed it. These observations lead me to file a bug report. Doug

5 years, 2 months

Re: [TUHS] Command line options and complexity

by Doug McIlroy

> This begs questions of stability Astute question. I had that in my original draft, but eliminited it for what I thought was clarity. Anyway, depending on implementation of sort, you may need sort -s. Of course it doesn't matter which copy among several equal lines uniq produces, nor does it matter in sort when there are no comparison options--they're all the same. > I don't know enough about the > internals of sed to know even what algorithm it uses > (... a disk-based merge sort?) sed is not a sorting program--basically it copies input to output, making line-by-line editing changes. That's the way I meant to use it in sed s/nonkeys//|sort -keys|uniq. (I have added options to sort, hopefully for clarity). The argument to sed here means substitute the empty string for the nonkey fields (specified by a regular expression). If "sed" was a typo for "sort", all versions of sort that I know of use an internal sorting algorithm for big chunks of the file, then combines the chunks by merge. But internal sorting varies all over the map--variations on quicksort, radix sort, merge sort, ... Doug

5 years, 2 months

Re: [TUHS] Command line options and complexity

by Doug McIlroy

> The idea of a simple rule is great, but the suggested rule fails on sort -u > which afaik came after sort | uniq for performance reasons. As the guilty party for most of sort's comparison options, I can attest that efficiency was not an objective of -u. It was invented precisely because uniq had proved useful, but not when one was interested in uniqueness only of some key aspect of the data. -u differs from uniq in that -u selects samples based on equality of keys, not equality of lines. In the default case of whole-line keys, sort -u of course does exactly what sort|uniq does. For many applications of -u with keys, the non-key fields are not of interest. Then sed s/nonkeys//|sort|uniq may suffice. But sed did not exist when -u was invented. And not all sort key specs are easily imitated in sed. Doug

5 years, 2 months

sockets (was Re: First appearance of named pipes)

by Norman Wilson

Derek Fawcus: Yeah - I always found that a bit weird, having to use socketpair() to get a bidirectional "pipe". In the Research system, pipes became bidirectional when they became streams. That happened slightly before my time, but so far as I know it broke absolutely nothing. Some time in the late 1980s, the System V people wanted to allow pipes to be streams, but were worried about the bidirectionality. They proposed to have a new system call to make a bidirectional pipe. I attended a meeting with the relevant programmers and program manager to find out why they thought pipes couldn't just be bi-directional, as they had been without fuss in the Research system for some years. They agreed with me that that was how it ought to be; the trouble was that System V releases all had to pass an official System V Verification Suite (reasonable enough), and that suite checked not only that you could read the one pipe file descriptor and write the other, but that you couldn't do it the wrong way. Wait a minute, I said. I'm pretty sure that's not how the official System V Interface Description reads. Anyone got a current copy handy? We found one, and we looked, and sure enough, the official verification suite was wrong. The specification said that data written to fd[1] must be readable from fd[0], but nothing about the other direction: full-duplex pipes were not required but neither were they outlawed! The programming group was delighted: I'd given them the ammo they needed to do it right (make pipes streams, and make them full-duplex by default). I believe that is how it came out, though the only reference I have is Solaris 10, where the manual page specifically says that what pipe(2) makes is full-duplex (and a stream). I wish POSIX and Linux and the BSDs would catch up; that was only 30 years ago. Norman Wilson Toronto ON

5 years, 2 months

First appearance of named pipes

by Paul Ruizendaal

> Always bemused me that to get a named local I/O connection one ended up with "Unix domain (what does that even mean?) sockets" rather than named pipes, especially since sockets are about as natural a Unix concept as lawn mowers. I've been told, but haven't confirmed, that early sockets didn't even support read and write. They still don't support open and close, and never will. My interest in Unix networking 1975-1985 originally came from wondering how we came up with this alien feeling socket API as the dominant model. The original ideas for this API are in the recently found CSRG tech reports #4 and #3 - which I hope to discuss on this list in Spring. I think we have to distinguish the API and the underlying paradigms. When it comes to the “Arpa” lineage of Unix networking, the original API model was fully within the open-read-write-close framework. See for instance RFC681 and this document: https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/doc/net.5.P; the entire BBN network API model fits on a few pages of ‘man’ text. In 1975 Arpa Unix, the network name space was integrated with the file name space, by creating a character special file for each network host. This was possible because at that time an Arpa network address was 8 bits, and this fitted in the minor number; when Arpa addresses were expanded to 24 bits soon after this approach was abandoned (but one could think of a mechanism akin to symbolic links that could have continued the practice). One could have an entry for the local host, e.g. “/n/local” or something like that. In my mind, “socket” does not only refer to the sockets API, but also to the concept of a bi-directional, possibly remote, named pipe; ‘named' as in “discoverable by a possibly unrelated process”, i.e. the in file name space, the network name space if different, etc. [aside: I realise (now) that this is a confusing use of the word socket, but I don’t have a better phrase at hand.] In my opinion, it is this concept that has proven strong and durable, much more so than the socket API itself. When viewed in this definition a ‘fifo’ is a limited form of socket: it is unidirectional, local only (although in the 1981 S/F-Unix it wasn’t) and a server process cannot easily distinguish or delegate individual client connections. The Rand Port was better in the sense that it prefixed each client’s data with a header block. > Networks are not intrinsically more special than any other I/O peripheral, but they have become gilded unicorns mounted on rotating hovercrafts compared to the I/O devices Unix supported before them. -rob "Networks are not intrinsically more special than any other I/O peripheral”: that indeed is the paradigm that underlies Spider-Datakit-streams-STREAMS-Plan9, networks are just an I/O peripheral. There is nothing wrong with that paradigm, excellent systems can be built on top of it. The other paradigm is that the network is a (mostly hidden) substrate that carries bidirectional pipes between processes. It would seem to me that there is nothing wrong with that paradigm either and it can be implemented in a “natural Unix” way as well. > On Sun, Mar 8, 2020 at 3:48 AM Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote: > >> > On Sat, Mar 07, 2020 at 01:17:09PM +0100, Paul Ruizendaal wrote: >> > > >> > > Interestingly, Luderer also refers to a 1978 paper by Steve Holmgren (one of the Arpa Unix authors), suggesting ’sockets’ (in today’s parlance) for interproces communication. >> > >> > Could that simply be bleed over of terminology from the ARPAnet / Internet >> > usage, in that "socket" is used to refer to protocol end points? I meant ’socket’ in the sense that I described above. “Socket” must be one of the most overloaded words in networking. My understanding is that on the Arpanet the “socket number” was what we now would call a "port number”, although I think it was initially meant to identify a user on a host, rather than a service on a host. In the 1980 BBN TCP implementation “socket” is used to mean “ip address”. A year later, Bill Joy uses “socket” as an API call name. >> > >> > i.e. see these from 1970: >> > >> > https://tools.ietf.org/html/rfc54 >> > https://tools.ietf.org/html/rfc55 >> > https://tools.ietf.org/html/rfc60 >> > >> > DF

5 years, 2 months

Re: [TUHS] Command line options and complexity

by Nelson H. F. Beebe

Arnold Robbins writes: >> There was no tac in V7 Unix. It was first posted to USENET, I don't >> know by who, and picked up by Linux and *BSD. That brought back memories, and to verify them, I checked the tac.c source code in the latest GNU coreutils test release. It says /* Written by Jay Lepreau (lepreau(a)cs.utah.edu) GNU enhancements by David MacKenzie (djm(a)gnu.ai.mit.edu) */ So my memory was right that my old friend Jay was the author. Sadly, we lost him in September 2008: see https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?page=lifest… Jay founded the influential Flux group in advanced networking research: http://www.flux.utah.edu/profile/lepreau ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

5 years, 2 months

First appearance of named pipes

by Paul Ruizendaal

The Luderer paper on distributed Unix has the following paragraph: "A new special UNIX interprocess communication mechanism is the fifo, which provides communication between unrelated processes by associating a new special file type with a file name. Since remote fifos are legal, they can be used for interprocessor communication between S-UNIX machines or between an S-UNIX machine and an F-UNIX machine.” The paper is from late 1981. Maybe I’m especially mud-eyed today, but I cannot see FIFO’s implemented in V7..V8 or 4.1xBSD. When did FIFO’s become a standard Unix feature? Paul

5 years, 2 months

Re: [TUHS] Command line options and complexity

by Doug McIlroy

> These go all the way back to v7 unix, where ls has an option to reverse the sort order (which could have been done by passing the output to tac). A cool idea, but tac was not in v7. And tail didn't get the -r option until v8. As for rev, I don't know why it was first written, but one use was to examine suffixes--a kind of thing that several word lovers in the Unix lab were prone to do. Apropos of using rev to make rhyming dictionaries, Walker's Rhyming Dictionary was published decades before Noah Webster's dictionary appeared and stayed in print for about 200 years. Notionally the relation between webster and walker is rev <webster | sort | rev >walker Doug

5 years, 2 months

Early Datakit

by Paul Ruizendaal

I’m making a little progress with early Datakit & Unix. It would seem that there were various experimental protocols before URP was arrived upon. The first protocol appears to have been designed by Chesson in 1979. One Fraser paper says: ""The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer.” I think this protocol is being described in his paper "Datakit Software Architecture” (vol. 2, pp. 20.2.1-20.2.5 Proceedings of the IEEE Int. Conf. on Communications, June 1979, Boston) - which unfortunately does not seem to be available in the IEEE online library. Maybe it will surface some day. Next there was a protocol tied to a Datakit terminal interface board that used an 8-slot packet sequence/acknowledge mechanism that carried over into URP. Not much appears to have been published about this. The most interesting experiment seems to have been a project by Luderer, Che and Marshall to build a Datakit-based distributed Unix in 1980/81. Marshall is credited by Fraser as one of the inventors of the URP protocol. The papers are “A virtual switch as the basis for distributed systems” and “A distributed unix system based on a virtual circuit switch” (available online from the ACM library). The first has a good overview description of how early Datakit worked (including interface hardware) and describes the Network Kernel or “NK protocol”. It would seem that URP combines the flow & retransmission control from the terminal interface board with the concept of a single simple receiver algorithm from NK. Unfortunately the paper does not describe the design of the NK transmitter algorithm(s). It confirms that everything ran on V7, but it remains unclear how the Datakit channels were exposed to the user (I currently assume as a cluster of character devices, with the major number identifying the switch connection and the minor number identifying the channel - similar to what later would be used in V8). The second has a description of a modified Unix system, where clients (“S-Unix”) talk to file servers (“F-Unix”), with the file servers mounted into the local file tree of the client. This appears to predate the work of Weinberger for the V8 network file system and its implementation appears different. Questions: - Are Luderer, Che and Marshall still around? (especially Bill Marshall might still recall some more details of the genesis of the URP protocol) - Any recollections about S/F-Unix and how it did or did not influence V8-V10/Plan9?

5 years, 2 months

Full set of "Computing Systems" for the cost of shipping

by arnold＠skeeve.com

Hi All. I have a full set (hardcopy) of the USENIX "Computing Systems" journal. It's just sitting on my shelf taking up space, and I'd like to give them to someone who'll give them a good home. So, first person to reply to me directly, who's willing to pay shipping from Israel, gets them. (Payment via paypal, or preferably a US dollar check sent to my US address.) Thanks! Arnold

5 years, 2 months

What was the release history timeline of Ultrix for VAX/MicroVAX?

by Pat Barron

I was just discussing this with someone today, and I realized this information has fallen out of working memory, and I can't find it on secondary storage anywhere... ;-) Does anyone remember the release history and version numbering of Ultrix for the VAX and MicroVAX (which I believe was referred to at various times as Ultrix-32 and Ultrix-32M, until some point when the "-32" thing was dropped, I think?) I was trying to remember what the various released versions of Ultrix were. The person I was discussing with thinks he remembers a version 1.4 and 1.6, before Ultrix 2.0. I honestly don't remember any 1.x version beyond 1.2. Is there a timeline somewhere? --Pat.

5 years, 2 months

First COFF Video Session in ~22 hours

by Warren Toomey

All, I've had a few queries about the proposed video chat sessions, so I'll kick the first one off tomorrow: UTC Brisbane London New York Friday, 28 Feb 2020 at 21:00 Sat 7:00am Fri 9:00pm Fri 4:00 pm I'll only be able to stay for an hour but the chat session should continue when I've gone. URL: https://meet.tuhs.org/COFF Password: unix Cheers, Warren

5 years, 2 months

Re: [TUHS] Crabs

by Lawrence Stewart

This explains something, I think! Luca Cardelli and Mark Manasse later worked at the Digital Systems Research Center in Palo Alto, which was formed in 1984 after PARC fired Bob Taylor. Mark helped write the window system we used, and at some point a cat appeared, which would sleep until you moved the mouse and then come over to pat at the mouse. My impression was that Luca wrote it, be he was cagy about it. This later evolved into xneko for X Windows. -Larry

5 years, 3 months

Re: [TUHS] [COFF] Fwd: Old and Tradition was V9 shell

by Adam Thornton

"I'd go to the local University that teaches Fortran and ask around." Aye, there's the rub. SIUE (Southern Illinois University at Edwardsville) still had a COBOL curriculum a decade ago, and they might still. They were fairly forthright in training people to go work at a lot of the stodgier St. Louis enterprises that still had a large COBOL footprint (AB, Enterprise Rent-A-Car, Caterpillar, et al). By 2010, though, Express Scripts was trying hard to move away from its ANCHOR (COBOL) system and whatever-it-was-they-had running on VMS, and it sure felt like in the early 2010s STL was mostly Java EE. I would think that FORTRAN is likelier to be passed around as folk wisdom and ancient PIs (uh, Primary Investigators, not the detective kind) thrusting a dog-eared FORTRAN IV manual at their new grad students and snarling "RTFM!" than as actual college courses. That said, if you want to learn FORTRAN and don't mind working from modern FORTRAN back, I really was impressed by https://lfortran.org/ , and the ability to run it in a JupyterLab playground environment is fantastic for quick-turnaround experimentation. Plus Ondřej Čertík <https://ondrejcertik.com/> was fun to talk to and hang out with. On Mon, Feb 24, 2020 at 8:19 AM Larry McVoy <lm(a)mcvoy.com> wrote: > On Mon, Feb 24, 2020 at 10:40:10AM +0100, Sijmen J. Mulder wrote: > > Larry McVoy <lm(a)mcvoy.com> wrote: > > > Fortran programmers are formally trained (at least I > > > was, there was a whole semester devoted to this) in accumulated errors. > > > You did a deep dive into how to code stuff so that the error was > reduced > > > each time instead of increased. It has a lot to do with how floating > > > point works, it's not exact like integers are. > > > > I was unaware that there's formal training to be had around this but > > it's something I'd like to learn more about. Any recommendations on > > materials? I don't mind diving into Fortran itself either. > > My training was 35 years ago, I have no idea where to go look for this > stuff now. I googled and didn't find much. I'd go to the local > University that teaches Fortran and ask around. > _______________________________________________ > COFF mailing list > COFF(a)minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff >

5 years, 3 months

Re: [TUHS] Tech memos from Heinz on MERT and others

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Heinz Lycklama has shared a binder full of old technical memos with > Clem Cole, who has scanned them in. Thanks to both of them for > preserving these documents. A big thank you to Heinz and Clem for their roles in making this happen! Very interesting material. I live in hope that someday the source will turn up - even a listing would be enough. Noel

5 years, 3 months

Fwd: Unix V0 on SIMH PDP-9

by Warren Toomey

All, I received this interesting e-mail from Michael Thompson: ----- Date: Fri, 21 Feb 2020 12:50:12 -0500 From: Michael Thompson <michael.99.thompson(a)gmail.com> To: Warren Toomey <wkt(a)tuhs.org> Subject: Unix V0 on SIMH PDP-9 I modified the PDP-7 .simh file so it will run on a SIMH PDP-9. (attached) We have a running PDP-9 at the RICM. If I added EAE, (we likely have the necessary parts) and made a disk emulator like the one at the LCM, we could also run UNIX V0 on it. It would be nice to have the disk emulator emulate an RB disk, but that would also require emulating a DMA adapter. I am considering making an FPGA to emulate the memory controller and 32KW of memory. If I did that, I could put the RB and DMA emulation in the same device. -- Michael Thompson ----- End forwarded message ----- set cpu 8k set cpu eae set cpu history=100 show cpu # set up SIMH devices: # UNIX character translations (CR to NL, ESC to ALTMODE): set tti unix # RB09 fixed head disk: set rb ena att rb image.fs # enable TELNET in GRAPHICS-2 keyboard/display(!!) #set g2in ena #att -U g2in 12345 # disable hardware UNIX-7 doesn't know about: set lpt disa set drm disa set dt disa set mt disa set rf disa set ttix disa set ttox disa # show device settings: show dev # load and run the paper tape bootstrap # (loads system from disk) load boot.rim 010000 go Cheers, Warren

5 years, 3 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