From coff at tuhs.org Fri Sep 5 01:00:31 2025 From: coff at tuhs.org (Stuff Received via COFF) Date: Thu, 4 Sep 2025 11:00:31 -0400 Subject: [COFF] The gallant font? In-Reply-To: References: Message-ID: <9beffcbc-e500-bcc8-852e-b0d97ce74e12@riddermarkfarm.ca> A question was asked on comp.sys.sun.hardware (reproduced below as I could not find a link for it). The OBP description (https://github.com/openbios/openboot/blob/master/obp/pkg/termemu/gallant.fth) says nothing about author -- not surprising as all copyright is invested in one's employer. Anyone here know? S. On 2025-08-27 15:33, Jens Schweikhardt wrote on comp.sys.sun.hardware: > hello, world\n > > I'm digging into the history of the gallant 12x22 font that was used > as the console font for many SUN products. Think "ok" prompt. I know > it from watching SPARCstations boot. > While it at some point made its way into BSD, as evidenced by NetBSD's > https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/dev/wsfont/gallant12x22.h, > I asked Jef and he guesses it was designed by someone at Sun. > Any old Sun engineers around who can contribute a little bit of > history of the gallant font and associated files? > > Regards, > > Jens From coff at tuhs.org Sat Sep 6 01:04:14 2025 From: coff at tuhs.org (Clem Cole via COFF) Date: Fri, 5 Sep 2025 11:04:14 -0400 Subject: [COFF] [ih] Confusion in the RFCs In-Reply-To: <4A3E1B0C-0AEB-458D-BFFC-7428DDCCC983@comcast.net> References: <30997E86-9BC4-496E-86CE-AC6AFAF3DC8F@comcast.net> <240F434C-AFF1-44F3-A072-66DC658B1B0F@comcast.net> <30A88A33-049B-456E-A51F-69EDD0D301D9@comcast.net> <4A3E1B0C-0AEB-458D-BFFC-7428DDCCC983@comcast.net> Message-ID: below.. [note this really belongs in COFF, as it's less Internet History and more reminiscent of us old guys] On Fri, Sep 5, 2025 at 8:44 AM John Day via Internet-history < internet-history at elists.isoc.org> wrote: > It inspired everything we did. It was a revelation. That is why our PDP-11 > OS language was called PDP-11 Espol, their OS language. > Fascinating - did that survive? Could you tell us more? I did not know that someone had tried to make an ESPOL for the 11. Was it a cross compiler, and what was the native OS? I grew up on BLISS and C, of course, and knew about other system languages like BCPL and concurrent Pascal that targeted the 11, but I never knew about an implementation of ESPOL for it. > > I knew there was one around UCLA somewhere and at Stanford. Knuth wrote > the early Algol compiler for it. It was the first system to use a stack for > procedures, as well as arithmetic. Tagged architecture, descriptor based > memory. The system had a coherence I have never seen again. > No doubt, the B5000 was the first "high-level" system design, incorporating everything you describe, along with some interesting support for its multi-tasking concepts. [I remember trying to wrap my head around the idea of how a cactus stack worked]. One of my old colleagues at Tektronix was Bill Price, who was earlier one of the MCP's designers and implementors, and he took great pride in schooling us youngsters in those days. He pointed out to us that if Burroughs' management had had any real idea of what they were doing and how far out it was and different from anything else being done at IBM in White Plains or Remington Rand/Eckert-Mauchly in North Philly, he is pretty sure they would have shut it down. As Bill explained it to us (then UNIX guys in the late 1970s), the designers of the MCP were very rigorous in their design, but had a great sense of humor and used really marvelous names for some of the data structures and kernel tasks. The MCP was extremely well structured, but when they ended up with something that did not quite fit in their structured design, they gave the special case to Bill to deal with in his "Old Weird Harold" kernel task, which, among other things, maintained "the bed," which was a list of tasks awaiting actions. One of my favorite actions was when Bill shared the comments from some of the code he still had, which revealed that Old Weird Harold was responsible for "monitoring the bed for something to fork." Also, one minor correction, while I do believe that Burroughs had an LA-based team, I am under the impression that most of the work on both HS and SW for the B5000 and B6000 families was done in Philadelphia (well, Paoli to be more precise). > > Trivial example: 48-bit word. Floating point format was a 39-bit mantissa > (sign bit, 8-bit exponent) but the decimal point was at the right end of > the word. Integers were merely unnormalized floating point numbers. No > integer to real conversion. It just worked. Also, it was pointed out to me > recently that there was a hardware operator that convert an integer to BCD. > A 39-bit binary integer would convert within 48 bits. (The Burros 3500 was > a COBOL machine and all decimal including the addressing!) Burros was > architecture-agnostic. One could go on and on. > Yeah, they got it about language-driven architectures. My favorite Burroughs machine was their mid-range B1700, which they targeted at small businesses. This machine changed its microcode on the fly depending on the application (*i.e.,* it had Cobol microcode, Algol microcode, etc.). We studied this system in great detail in Dan Siewiorek's computer architecture class when I was an undergrad. It was a very cool machine that really learned a great deal about how microcoding could be used (and some of you have heard my story during my UCB grad qualifiers when I was asked a question about microcoding and used the B1700 to answer it). > > Why can’t we build systems like that any more. > Sadly, because often simpler is much less costly, and as I have said many times,* "Simple Economics always beats Sophisticated Architecture."* -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Sat Sep 6 16:02:01 2025 From: coff at tuhs.org (segaloco via COFF) Date: Sat, 06 Sep 2025 06:02:01 +0000 Subject: [COFF] Early Bell Laboratories CPU Datasheets Message-ID: Just wanted to share a couple of datasheets that may interest folks here. This evening I scanned both the MAC-8 and MAC-4 preliminary datasheets from late 1978. While many details of the MAC-8 are currently known, the MAC-4 has been elusive in my study until I received these documents in a collection of MAC-8 materials. [https://archive.org/details/212-b-mac-8-data-sheet](https://archive.org/details/212-b-mac-8-data-sheet/) [https://archive.org/details/mac-4-specification-sheet](https://archive.org/details/mac-4-specification-sheet/) These are Bell Laboratories' 1970's 8-bit and 4-bit microprocessors which preceded their work on the WE32000. I have some hints on the typical development environment too. The BTL editions of the UNIX 5.0 and SVR2 manuals contain numerous references to MAC-8 and MAC-4 tools. I intend to preserve those pages too as part of a larger effort to illuminate the history of these two processors. I've provided much more info here: https://forum.vcfed.org/index.php?threads/western-electric-component-databooks.1250931/#post-1464263 - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Sun Sep 7 11:25:43 2025 From: coff at tuhs.org (segaloco via COFF) Date: Sun, 07 Sep 2025 01:25:43 +0000 Subject: [COFF] Early Bell Laboratories CPU Datasheets In-Reply-To: References: Message-ID: And now I've started a repository here: https://gitlab.com/segaloco/pwb5btl_man This will slowly accumulate reconstructions of the various manpages in the BTL edition of the Release 5.0 User's and Administrator's Manuals. I've started with the MAC-4 development utilities, and intend to tackle the pages for the MAC-8 and BASIC-16 environments next. I'll be adding various pages from these manuals over time, in the same spirit as my 4.1 3B20S project. I look forward to the opportunity to share these materials around Bell Labs's use of UNIX in their hardware design operations. Will probably start a more focused TUHS thread when the repository has more stuff in it, but a Bcc mention for now. - Matt G. On Friday, September 5th, 2025 at 23:02, segaloco via COFF wrote: > Just wanted to share a couple of datasheets that may interest folks here. This evening I scanned both the MAC-8 and MAC-4 preliminary datasheets from late 1978. While many details of the MAC-8 are currently known, the MAC-4 has been elusive in my study until I received these documents in a collection of MAC-8 materials. > > [https://archive.org/details/212-b-mac-8-data-sheet](https://archive.org/details/212-b-mac-8-data-sheet/) > > [https://archive.org/details/mac-4-specification-sheet](https://archive.org/details/mac-4-specification-sheet/) > > These are Bell Laboratories' 1970's 8-bit and 4-bit microprocessors which preceded their work on the WE32000. > > I have some hints on the typical development environment too. The BTL editions of the UNIX 5.0 and SVR2 manuals contain numerous references to MAC-8 and MAC-4 tools. I intend to preserve those pages too as part of a larger effort to illuminate the history of these two processors. > > I've provided much more info here: https://forum.vcfed.org/index.php?threads/western-electric-component-databooks.1250931/#post-1464263 > > - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Wed Sep 10 14:32:56 2025 From: coff at tuhs.org (Warren Toomey via COFF) Date: Wed, 10 Sep 2025 14:32:56 +1000 Subject: [COFF] A Potted Minnie History Message-ID: Over on TUHS we've been preserving the history of Unix for about thirty years. That makes my server, minnie, a bit historical herself :-) Being a bit vain (and a bit bored) I decided to write up a quick history of minnie. Here it is: https://minnie.tuhs.org/Blog/2025_09_10_Minnies_History.html Hope you find it somewhat interesting! Cheers, Warren From coff at tuhs.org Sat Sep 20 06:30:09 2025 From: coff at tuhs.org (Charles H Sauer (he/him) via COFF) Date: Fri, 19 Sep 2025 15:30:09 -0500 Subject: [COFF] SOSP 1973 [was Multics<->Unix Re: [TUHS] Re: History of cal(1)? In-Reply-To: References: Message-ID: [trying to broaden the discussion & transition to COFF] On 9/19/2025 2:57 PM, Dan Cross via TUHS wrote: > So I sort of wonder if the Multics folks also showed up to some of > those conferences: SOSP, for example. I imagine people like Fano and > Corby attended. And the Unix community coalesced quickly and became > quite strong (as we all know), I wonder about interaction with other > communities. Looking at the SOSP 1973 list of presentations at https://dblp.org/db/conf/sosp/sosp73.html, where Dennis & Ken presented Unix at IBM Yorktown, there's only one presentation obviously Multics related, by Saltzer, and no other presentations obviously associated with currently well known operating systems. In the (admittedly, insular) IBM environment, there seemed little interest in anything besides MVS for production and VM/370 for development. (From Popek/Goldberg SOSP 1973 Abstract: "Virtual machine systems have been implemented on a limited number of third generation computer systems, e.g. CP-67 on the IBM 360/67. From previous empirical studies, it is known that certain third generation computer systems, e.g. the DEC PDP-10, cannot support a virtual machine system.") As late as 1979 at UT-Austin, Unix was not available in the C.S. Dept -- TOPS-10 was gaining traction over the homegrown "UT-2D" environment for CDC 6400/6600 and the subsequent CDC machines that supplanted those. For various reasons, lack of commercial dominance, lack of source, ..., there didn't seem to be any specific OS that gained mind share in the O.S. community until Unix did. Well after 1985 in IBM, those of us advocating Unix were definitely in the minority. [https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/] Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From coff at tuhs.org Sat Sep 20 07:49:20 2025 From: coff at tuhs.org (Noel Chiappa via COFF) Date: Fri, 19 Sep 2025 17:49:20 -0400 (EDT) Subject: [COFF] SOSP 1973 [was Multics<->Unix Re: [TUHS] Re: History of cal(1)? Message-ID: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> > From: Charles H Sauer > For various reasons, lack of commercial dominance, lack of source, ..., > there didn't seem to be any specific OS that gained mind share in the > O.S. community until Unix did. Before UNIX, almost all OS's were written in assembler, tying them to one particular vendor's machines. (Multics, although in PL/I, was so specialized to the Heneywell architecture it was in the same boat.) UNIX was really the first portable OS (at least, that I know of - am I wrong?. I suspect thatwas a large factor too. Noel From coff at tuhs.org Sat Sep 20 07:59:36 2025 From: coff at tuhs.org (Charles H Sauer (he/him) via COFF) Date: Fri, 19 Sep 2025 16:59:36 -0500 Subject: [COFF] SOSP 1973 [was Multics<->Unix Re: [TUHS] Re: History of cal(1)? In-Reply-To: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> Message-ID: <076df8c1-1616-4224-88cc-85923f7d1735@technologists.com> On 9/19/2025 4:49 PM, Noel Chiappa wrote: > > From: Charles H Sauer > > > For various reasons, lack of commercial dominance, lack of source, ..., > > there didn't seem to be any specific OS that gained mind share in the > > O.S. community until Unix did. > > Before UNIX, almost all OS's were written in assembler, tying them to one > particular vendor's machines. (Multics, although in PL/I, was so specialized > to the Heneywell architecture it was in the same boat.) UNIX was really the > first portable OS (at least, that I know of - am I wrong?. I suspect thatwas > a large factor too. > > Noel Emphasis on "portable," since there seemed to be so many competing processor architectures. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From coff at tuhs.org Sat Sep 20 08:45:57 2025 From: coff at tuhs.org (Dave Horsfall via COFF) Date: Sat, 20 Sep 2025 08:45:57 +1000 (EST) Subject: [COFF] SOSP 1973 [was Multics<->Unix Re: [TUHS] Re: History of cal(1)? In-Reply-To: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> Message-ID: On Fri, 19 Sep 2025, Noel Chiappa via COFF wrote: > Before UNIX, almost all OS's were written in assembler, tying them to > one particular vendor's machines. (Multics, although in PL/I, was so > specialized to the Heneywell architecture it was in the same boat.) UNIX > was really the first portable OS (at least, that I know of - am I > wrong?. I suspect thatwas a large factor too. Burroughs' MCP (Master Control Program) was written in ALGOL, but again it was specific to the hardware (which basically was an ALGOL machine). (I used one once; I think it was a B-1500, but I've long since lost the manual) -- Dave From coff at tuhs.org Sat Sep 20 09:49:52 2025 From: coff at tuhs.org (Charles H. Sauer (he/him) via COFF) Date: Fri, 19 Sep 2025 18:49:52 -0500 Subject: [COFF] SOSP 1973 [was Multics<->Unix Re: [TUHS] Re: History of cal(1)? In-Reply-To: References: <20250919214920.55FBF18C073@mercury.lcs.mit.edu> Message-ID: On 9/19/2025 5:45 PM, Dave Horsfall via COFF wrote: > On Fri, 19 Sep 2025, Noel Chiappa via COFF wrote: > >> Before UNIX, almost all OS's were written in assembler, tying them to >> one particular vendor's machines. (Multics, although in PL/I, was so >> specialized to the Heneywell architecture it was in the same boat.) UNIX >> was really the first portable OS (at least, that I know of - am I >> wrong?. I suspect thatwas a large factor too. > > Burroughs' MCP (Master Control Program) was written in ALGOL, but again it > was specific to the hardware (which basically was an ALGOL machine). > > (I used one once; I think it was a B-1500, but I've long since lost the > manual) > > -- Dave And there were Lisp machines... -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From coff at tuhs.org Mon Sep 22 23:03:53 2025 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Mon, 22 Sep 2025 13:03:53 +0000 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> (Johan Helsingius via TUHS's message of "Mon, 22 Sep 2025 10:02:31 +0200") References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> Message-ID: <7w7bxqfxl2.fsf@junk.nocrew.org> Johan Helsingius wrote: > I was trying to port forth to the PDP-10 and had to give up When was that? And why did you give up? I wrote a Forth for the PDP-8; based on that I would say one for the PDP-10 wouldn't be overly difficult. There's a Forth for the PDP-10 written in Maclisp, but perhaps that's a bit of a cheat. [Veering wildly off TUHS, redirected to COFF] From coff at tuhs.org Mon Sep 22 23:52:56 2025 From: coff at tuhs.org (Johan Helsingius via COFF) Date: Mon, 22 Sep 2025 15:52:56 +0200 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <7w7bxqfxl2.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: On 22/09/2025 15:03, Lars Brinkhoff via TUHS wrote: > When was that? And why did you give up? Early 1980's - gave up because just like C, forth is pretty byte-oriented, and the PDP-10 byte pointers (and half-words) were quite a hassle. In the end I just ran out of time and patience. Julf From coff at tuhs.org Tue Sep 23 00:00:09 2025 From: coff at tuhs.org (Ori Kuttner via COFF) Date: Mon, 22 Sep 2025 17:00:09 +0300 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: FORTH is a Write Only Language, you write it and can't even read it yourself :-) I used to like FORTH, did some PostScript and now I just hate it. -- Ori Kuttner CEO Helicon Books http://www.heliconbooks.com On Mon, Sep 22, 2025 at 4:53 PM Johan Helsingius via COFF wrote: > On 22/09/2025 15:03, Lars Brinkhoff via TUHS wrote: > > When was that? And why did you give up? > > Early 1980's - gave up because just like C, forth is pretty > byte-oriented, and the PDP-10 byte pointers (and half-words) > were quite a hassle. In the end I just ran out of time and > patience. > > Julf > > > From coff at tuhs.org Tue Sep 23 00:53:42 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Mon, 22 Sep 2025 10:53:42 -0400 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: On Mon, Sep 22, 2025 at 10:19 AM Ori Kuttner via COFF wrote: > FORTH is a Write Only Language, you write it and can't even read it > yourself :-) > I used to like FORTH, did some PostScript and now I just hate it. I thought that was Perl? (*jumps for the exit*) - Dan C. From coff at tuhs.org Tue Sep 23 01:23:06 2025 From: coff at tuhs.org (Ori Kuttner via COFF) Date: Mon, 22 Sep 2025 18:23:06 +0300 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: On Mon, Sep 22, 2025 at 5:54 PM Dan Cross wrote: > On Mon, Sep 22, 2025 at 10:19 AM Ori Kuttner via COFF > wrote: > > FORTH is a Write Only Language, you write it and can't even read it > > yourself :-) > > I used to like FORTH, did some PostScript and now I just hate it. > > I thought that was Perl? (*jumps for the exit*) > Perl is the only language that looks the same before and after encryption... :-) > > From coff at tuhs.org Tue Sep 23 01:46:44 2025 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Mon, 22 Sep 2025 15:46:44 +0000 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: (Dan Cross via COFF's message of "Mon, 22 Sep 2025 10:53:42 -0400") References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: <7wsegeebh7.fsf@junk.nocrew.org> Dan Cross wrote: > Ori Kuttner wrote. >> FORTH is a Write Only Language, you write it and can't even read it >> yourself :-) I used to like FORTH, did some PostScript and now I just >> hate it. > > I thought that was Perl? (*jumps for the exit*) Y'all got nothing on TECO. I agree to some extent I can barely read my own Forth code from a year ago, but still, I think it looks pleasant somehow. Well written Forth looks like a haiku - dense and cryptic, but possibly profound. Or maybe it's just crap. From coff at tuhs.org Tue Sep 23 02:08:28 2025 From: coff at tuhs.org (Paul Winalski via COFF) Date: Mon, 22 Sep 2025 12:08:28 -0400 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: <7wsegeebh7.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wsegeebh7.fsf@junk.nocrew.org> Message-ID: On Mon, Sep 22, 2025 at 11:54 AM Lars Brinkhoff via COFF wrote: > Dan Cross wrote: > > Ori Kuttner wrote. > >> FORTH is a Write Only Language, you write it and can't even read it > >> yourself :-) I used to like FORTH, did some PostScript and now I just > >> hate it. > > > > I thought that was Perl? (*jumps for the exit*) > > Y'all got nothing on TECO. > > When I worked at DEC (1980-2001) the engineering departments had a bunch of VAX NOTES discussion forums on the corporate internal network. One of these was Trivia, which as the name implies was a place to pose trivia questions/puzzles. One question posted by Stan Rabinowitz was: What do these three two-character sequences have in common? [followed by three random-seeming sequences of two special characters] The answer was that they are the only 2-printing-character sequences that are not valid TECO commands. -Paul W. From coff at tuhs.org Tue Sep 23 02:19:52 2025 From: coff at tuhs.org (Johan Helsingius via COFF) Date: Mon, 22 Sep 2025 18:19:52 +0200 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: <7wsegeebh7.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wsegeebh7.fsf@junk.nocrew.org> Message-ID: <45844562-1d44-45f8-abe5-91b3c1b17500@Julf.com> On 22/09/2025 17:46, Lars Brinkhoff wrote: > Y'all got nothing on TECO. sendmail.cf anyone? :) Julf From coff at tuhs.org Tue Sep 23 02:54:45 2025 From: coff at tuhs.org (Larry McVoy via COFF) Date: Mon, 22 Sep 2025 09:54:45 -0700 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: <20250922165445.GD31455@mcvoy.com> On Mon, Sep 22, 2025 at 06:23:06PM +0300, Ori Kuttner via COFF wrote: > On Mon, Sep 22, 2025 at 5:54???PM Dan Cross wrote: > > > On Mon, Sep 22, 2025 at 10:19???AM Ori Kuttner via COFF > > wrote: > > > FORTH is a Write Only Language, you write it and can't even read it > > > yourself :-) > > > I used to like FORTH, did some PostScript and now I just hate it. > > > > I thought that was Perl? (*jumps for the exit*) > > > Perl is the only language that looks the same before and after > encryption... :-) I wrote a source management system mostly in perl. I rewrote it twice and by the last time I adopted a very stylized way of doing things. I was pretty happy with the last version, I could pop in there and fix bugs easily. This was all perl4, I'm not a fan of 99% of perl5 but you can write perl4 code in perl5 just fine. I liked perl so much that I proposed rewriting much of /usr/bin in perl. I wised up when I started benchmarking, perl is pretty fast but it is no match for C. I wrote the next source management system in C. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From coff at tuhs.org Tue Sep 23 03:45:03 2025 From: coff at tuhs.org (Tony Patti via COFF) Date: Mon, 22 Sep 2025 13:45:03 -0400 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: <20250922165445.GD31455@mcvoy.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <20250922165445.GD31455@mcvoy.com> Message-ID: <036701dc2be8$a0b07c40$e21174c0$@glassblower.info> > Larry McVoy via COFF wrote at September 22, 2025 12:55 PM > > I wised up when I started benchmarking, perl is pretty fast but it is no match for C. I wrote the next source management system in C. Speaking of benchmarking multiple languages, I recently created version 2 of my paper (now 186 pages) entitled: "An interesting example at the intersection of Matrix Mathematics and Cryptography (and how Artificial Intelligence can write programs)" which can be found at https://glassblower.info/crypto/an-interesting-example-at-the-intersection-o f-matrix-mathematics-and-cryptography-version-2.pdf The timings below (from page 80) are for inversion of a 500x500 matrix in Galois Field GF(997727), processing 5-million-bit matrix encryption/decryption keys: Python 223 seconds PHP 29.6 seconds Java 4.3 seconds C 2.5 seconds Go 1.84 seconds Rust 1.7 seconds I thought you might find these timings interesting: a full two orders of magnitude difference! Google Gemini tells me that for 64-bit integer math, Perl (which I have not used for a very long time) is likely to be even slower than Python. Tony Patti (ARPAnet NIC IDENT "TP4") From coff at tuhs.org Tue Sep 23 07:57:55 2025 From: coff at tuhs.org (Adam Thornton via COFF) Date: Mon, 22 Sep 2025 14:57:55 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <7w7bxqfxl2.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: I found a pretty decent one-file FORTH in K&R C and tried to port it to v7. Too many symbols in that one file. So then I tried breaking each FORTH word out into its own file and linking a bunch of tiny little .o files, and that was too many files for the linker. I'm sure there's a sweet spot in there somewhere but at that point it's probably just easier to sit down and write a FORTH. Which I haven't yet done. From coff at tuhs.org Tue Sep 23 11:59:02 2025 From: coff at tuhs.org (John Levine via COFF) Date: 22 Sep 2025 21:59:02 -0400 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: <036701dc2be8$a0b07c40$e21174c0$@glassblower.info> References: <7w7bxqfxl2.fsf@junk.nocrew.org> <20250922165445.GD31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <2025092203 <036701dc2be8$a0b07c40$e21174c0$@glassblower.info> Message-ID: <20250923015902.CA406DD58472@ary.qy> It appears that Tony Patti via COFF said: >The timings below (from page 80) are for inversion of a 500x500 matrix in >Galois Field GF(997727), processing 5-million-bit matrix >encryption/decryption keys: > >Python 223 seconds >PHP 29.6 seconds >Java 4.3 seconds >C 2.5 seconds >Go 1.84 seconds >Rust 1.7 seconds Something smells wrong here. Anyone doing numerical work in python uses the numpy and scipy libraries which represent arrays in native binary form and have efficient versions of numerical operations. This suggests they did a mechanical translation into simple minded python using ineffiecient data structures rather than the way an actual python programmer would do it. Or as someone said "you can write FORTRAN programs in any language." For reasons I have never figured out, perl's regular expression matcher is at least twice as fast as the ones in perl or PHP. I have rewritten programs that do a lot of regex from python into perl because the speedup is so great. If you like awk, I believe that mawk's regex is much faster than the competition, too. R's, John From coff at tuhs.org Tue Sep 23 12:28:22 2025 From: coff at tuhs.org (Joseph Holsten via COFF) Date: Mon, 22 Sep 2025 19:28:22 -0700 Subject: [COFF] TECO variants (was Re: Perl (was Re: forth on early unix)) In-Reply-To: <7wsegeebh7.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wsegeebh7.fsf@junk.nocrew.org> Message-ID: <7090f29e-6b7c-4fe3-b677-a1b72ac38c3c@app.fastmail.com> On Mon, Sep 22, 2025, at 08:46, Lars Brinkhoff via COFF wrote: > Dan Cross wrote: >> Ori Kuttner wrote. >>> FORTH is a Write Only Language, you write it and can't even read it >>> yourself :-) I used to like FORTH, did some PostScript and now I just >>> hate it. >> >> I thought that was Perl? (*jumps for the exit*) > > Y'all got nothing on TECO. I’ve been collecting notes about text editors prior to 1985 (Gnu Emacs release), and I know TECO was in use on all sorts of systems, but there’s so much more about the MIT systems than elsewhere. Did you get use TECO much? I’ve wondered how unusual extensions like Control-R were on other systems. Were different implementations as different as some authors make it sound? Or were they roughly as similar as the QED implementations? Also, do you buy the modern argument that TECO vs emacs proved the command language and the extension language should be entirely different? -- Joseph Holsten http://josephholsten.com mailto:joseph at josephholsten.com tel:+1-360-927-7234 From coff at tuhs.org Tue Sep 23 12:38:36 2025 From: coff at tuhs.org (Tony Patti via COFF) Date: Mon, 22 Sep 2025 22:38:36 -0400 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: <20250923015902.CA406DD58472@ary.qy> References: <7w7bxqfxl2.fsf@junk.nocrew.org> <20250922165445.GD31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <2025092203 <036701dc2be8$a0b07c40$e21174c0$@glassblower.info> <20250923015902.CA406DD58472@ary.qy> Message-ID: <051a01dc2c33$2a205af0$7e6110d0$@glassblower.info> > From: John Levine via COFF on September 22, 2025 at 9:59 PM wrote: > > Something smells wrong here. Anyone doing numerical work in python uses the numpy and scipy libraries which represent arrays in native binary form and have efficient versions of numerical operations. > This suggests they did a mechanical translation into simple minded python using ineffiecient data structures rather than the way an actual python programmer would do it. Hi John, NumPy's core library does not natively support arithmetic over Galois fields. As the title of my paper should suggest "An interesting example at the intersection of Matrix Mathematics and Cryptography (and how Artificial Intelligence can write programs)", the goal was to see how well A.I. could generate cryptographic software, in multiple programming languages, and in what most people would consider to be atypical (uncommon) Galois Fields such as GF(997727) and GF(1077777719) and even polynomials over GF(9973^12). The latter, by definition, are subject to both a prime modulus and a monic irreducible polynomial modulus. Additionally, the software handles matrices with sizes ranging over six orders of magnitude, from 4×4 to 4000×4000. So, when you say "they" in your sentence, you are referring to the two A.I.'s cited in my paper: Google Gemini and Microsoft Copilot. I would agree with your use of the word "mechanical" since the software in the paper was A.I. machine-generated. Full source code is included in my paper, for those who are interested. Tony Patti (ARPAnet NIC IDENT "TP4") From coff at tuhs.org Tue Sep 23 12:50:28 2025 From: coff at tuhs.org (Dan Halbert via COFF) Date: Mon, 22 Sep 2025 22:50:28 -0400 Subject: [COFF] Perl (was Re: forth on early unix) In-Reply-To: <051a01dc2c33$2a205af0$7e6110d0$@glassblower.info> References: <7w7bxqfxl2.fsf@junk.nocrew.org> <20250922165445.GD31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <2025092203 <036701dc2be8$a0b07c40$e21174c0$@glassblower.info> <20250923015902.CA406DD58472@ary.qy> <051a01dc2c33$2a205af0$7e6110d0$@glassblower.info> Message-ID: <7ed35f42-092a-417e-8f99-31dca6bf7caf@halwitz.org> On 9/22/25 22:38, Tony Patti via COFF wrote: >> From: John Levine via COFF on September 22, 2025 at 9:59 PM wrote: >> >> Something smells wrong here. Anyone doing numerical work in python uses the numpy and scipy libraries which represent arrays in native binary form and have efficient versions of numerical operations. >> This suggests they did a mechanical translation into simple minded python using ineffiecient data structures rather than the way an actual python programmer would do it. > Hi John, > > NumPy's core library does not natively support arithmetic over Galois fields. > As the title of my paper should suggest > "An interesting example at the intersection of Matrix Mathematics and Cryptography (and how Artificial Intelligence can write programs)", > the goal was to see how well A.I. could generate cryptographic software, in multiple programming languages, > and in what most people would consider to be atypical (uncommon) Galois Fields such as GF(997727) and GF(1077777719) and even polynomials over GF(9973^12). > The latter, by definition, are subject to both a prime modulus and a monic irreducible polynomial modulus. > Additionally, the software handles matrices with sizes ranging over six orders of magnitude, from 4×4 to 4000×4000. > So, when you say "they" in your sentence, you are referring to the two A.I.'s cited in my paper: Google Gemini and Microsoft Copilot. > I would agree with your use of the word "mechanical" since the software in the paper was A.I. machine-generated. > Full source code is included in my paper, for those who are interested. > > Tony Patti > (ARPAnet NIC IDENT "TP4") https://pypi.org/project/galois/ is available, and is a "performant NumPy extension for Galois fields and their applications". I guess I would say it's too bad AI didn't have that in its completions. It would be interesting to adjust the prompt to tell it to look for some numpy extension that would help.  --Dan H. From coff at tuhs.org Tue Sep 23 14:58:28 2025 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Tue, 23 Sep 2025 04:58:28 +0000 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: (Adam Thornton's message of "Mon, 22 Sep 2025 14:57:55 -0700") References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> Message-ID: <7wcy7hepe3.fsf@junk.nocrew.org> Adam Thornton wrote: > I found a pretty decent one-file FORTH in K&R C and tried to port it > to v7. Too many symbols in that one file. So then I tried breaking > each FORTH word out into its own file and linking a bunch of tiny > little .o files, and that was too many files for the linker. My personal toy Forth runs on V7, but I only tested it with the apout emulator. https://github.com/larsbrinkhoff/lbForth/tree/master/targets/pdp11 From coff at tuhs.org Tue Sep 23 15:07:28 2025 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Tue, 23 Sep 2025 05:07:28 +0000 Subject: [COFF] TECO variants (was Re: Perl (was Re: forth on early unix)) In-Reply-To: <7090f29e-6b7c-4fe3-b677-a1b72ac38c3c@app.fastmail.com> (Joseph Holsten's message of "Mon, 22 Sep 2025 19:28:22 -0700") References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wsegeebh7.fsf@junk.nocrew.org> <7090f29e-6b7c-4fe3-b677-a1b72ac38c3c@app.fastmail.com> Message-ID: <7w8qi5eoz3.fsf@junk.nocrew.org> Joseph Holsten wrote: > Did you get use TECO much? I’ve wondered how unusual extensions like > Control-R were on other systems. Were different implementations as > different as some authors make it sound? Or were they roughly as > similar as the QED implementations? PDP-6 TECO (running standalone) and ITS TECO is readily available if you want to try them yourself. Basic text editing and navigation is easy enough. You have to enter the mindset that you edit one page at a time and then move on to the next. Other TECO variants also got real-time display, but I don't know if they used Control-R to enter that mode, or something else. > Also, do you buy the modern argument that TECO vs emacs proved the > command language and the extension language should be entirely > different? Yes, I think so. Lisp is better extension language than TECO. The semantics of the ITS TECO programming language are actually fine, but the terse syntax is difficult. From coff at tuhs.org Tue Sep 23 15:20:52 2025 From: coff at tuhs.org (Bakul Shah via COFF) Date: Mon, 22 Sep 2025 22:20:52 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <7wcy7hepe3.fsf@junk.nocrew.org> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> Message-ID: <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> > On Sep 22, 2025, at 9:58 PM, Lars Brinkhoff via COFF wrote: > > Adam Thornton wrote: >> I found a pretty decent one-file FORTH in K&R C and tried to port it >> to v7. Too many symbols in that one file. So then I tried breaking >> each FORTH word out into its own file and linking a bunch of tiny >> little .o files, and that was too many files for the linker. > > My personal toy Forth runs on V7, but I only tested it with the apout > emulator. https://github.com/larsbrinkhoff/lbForth/tree/master/targets/pdp11 I wonder if there is a meta-circular evaluator for forth (i.e. forth in forth) like Scheme in Scheme - a scheme program that evaluates any scheme program given to it as input. https://www.cs.uoregon.edu/research/summerschool/summer25/_lectures/Amin-notes-1.pdf From coff at tuhs.org Tue Sep 23 22:13:42 2025 From: coff at tuhs.org (Mike Markowski via COFF) Date: Tue, 23 Sep 2025 08:13:42 -0400 Subject: [COFF] TECO variants In-Reply-To: <7090f29e-6b7c-4fe3-b677-a1b72ac38c3c@app.fastmail.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wsegeebh7.fsf@junk.nocrew.org> <7090f29e-6b7c-4fe3-b677-a1b72ac38c3c@app.fastmail.com> Message-ID: <1e04a1e3-9043-4436-859c-06e2f1f0ff66@gmail.com> On 9/22/25 10:28 PM, Joseph Holsten via COFF wrote: > ...I’ve wondered how unusual extensions like Control-R were on other systems. Were different implementations as different as some authors make it sound? Or were they roughly as similar as the QED implementations? > > Also, do you buy the modern argument that TECO vs emacs proved the command language and the extension language should be entirely different? The 1980 DEC TECO manual has a section on some differences, but they don't seem that big.  Their list is likely not all-inclusive, only talking about their versions of teco on various OSes.  I learned TECO at age 16 in 1978 on a PDP-11/70 RSTS/E system and thought I was all-powerful :-D, such an incredible program.  For fun I recently compiled Paul Cantrell's Video TECO on my ubuntu box (must add -lncurses to makefile).  It's aaalmost as nice as vi but of course not as fully visually oriented.  I won't be giving up on vim... Many TECO commands can be preceded by an integer or followed by a string.  The output of a command can be used as the input to another, making TECO a quasi-functional language.  I don't have the background to comment on the pros and cons of the command language, but for something begun in 1962 it's impressive. "It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text."  -Ed Post Here is a macro of Cantrell's that converts the word at current pointer position to lower case:  .UU<0A-32"E0;'0A-9"E0;'0A-10"E0;'C>.UL$QUJQL-QU<0A-64"G0A-91"L0A+32IDR''C>$ What do you mean, it's unreadable? :-)  Curious what it was doing, I rewrote with comments: .UU                 ! Put dot in Q-reg U.                 ! <                   ! Loop till finding white space.      !     0A-32"E0;'      !   Ascii code at dot == space? break !     0A-9"E0;'       !   Ascii code at dot == \t?    break !     0A-10"E0;'      !   Ascii code at dot == \n?    break !     C               !   Fwd 1 char.                       ! > .UL$                ! Put loc of 1st white space in L.    ! QUJ                 ! Return to original dot.             ! QL-QU<              ! Loop from U (orig dot) to L (1st white space). !     0A-64"G         !   If ascii code at dot >= 'A':      !         0A-91"L     !     If also <= 'Z':                 !             0A+32I  !       Insert lower case letter.     !             D       !       Delete upper case letter.     !             R       !       Back up 1 char to prepare for 'C' below. !         '     '     C               ! Fwd 1 char ! >$ Mike Markowski From coff at tuhs.org Wed Sep 24 06:09:18 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Tue, 23 Sep 2025 16:09:18 -0400 Subject: [COFF] TECO variants In-Reply-To: <1e04a1e3-9043-4436-859c-06e2f1f0ff66@gmail.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wsegeebh7.fsf@junk.nocrew.org> <7090f29e-6b7c-4fe3-b677-a1b72ac38c3c@app.fastmail.com> <1e04a1e3-9043-4436-859c-06e2f1f0ff66@gmail.com> Message-ID: On Tue, Sep 23, 2025 at 8:13 AM Mike Markowski via COFF wrote: > [snip] > What do you mean, it's unreadable? :-) Curious what it was doing, I > rewrote with comments: > > .UU ! Put dot in Q-reg U. ! > < ! Loop till finding white space. ! > 0A-32"E0;' ! Ascii code at dot == space? break ! > 0A-9"E0;' ! Ascii code at dot == \t? break ! > 0A-10"E0;' ! Ascii code at dot == \n? break ! > C ! Fwd 1 char. ! > > > .UL$ ! Put loc of 1st white space in L. ! > > QUJ ! Return to original dot. ! > QL-QU< ! Loop from U (orig dot) to L (1st white space). ! > 0A-64"G ! If ascii code at dot >= 'A': ! > 0A-91"L ! If also <= 'Z': ! > 0A+32I ! Insert lower case letter. ! > D ! Delete upper case letter. ! > R ! Back up 1 char to prepare for 'C' below. ! > ' > ' > C ! Fwd 1 char ! > >$ Huh, neat (and very clear explanation; thanks for that). I suppose the registers 'U' and 'L' are meant to be evocative of 'Upper' and 'Lower' (bounds)? It appears as though they're reversed here? Perhaps I am trying to ascribe meaning where none exists. - Dan C. From coff at tuhs.org Wed Sep 24 09:46:26 2025 From: coff at tuhs.org (Alexis via COFF) Date: Wed, 24 Sep 2025 09:46:26 +1000 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> (Bakul Shah via COFF's message of "Mon, 22 Sep 2025 22:20:52 -0700") References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> Message-ID: <87ms6k3f71.fsf@gmail.com> Bakul Shah via COFF writes: > I wonder if there is a meta-circular evaluator for forth > (i.e. forth in forth) The 'MetaCircularEvaluator' page on the c2 wiki: https://wiki.c2.com/?MetaCircularEvaluator includes this: here is a simple metacircular interpreter in arbitrary dialect Forth: : myInterpreter begin 32 word find dup if execute else number then again ; And here would be a compiler: : my-] begin 32 word find dup if dup immediate? if execute else compile then else compile-number then again ; Alexis. From coff at tuhs.org Wed Sep 24 10:17:38 2025 From: coff at tuhs.org (Larry McVoy via COFF) Date: Tue, 23 Sep 2025 17:17:38 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <87ms6k3f71.fsf@gmail.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> Message-ID: <20250924001738.GD26901@mcvoy.com> On Wed, Sep 24, 2025 at 09:46:26AM +1000, Alexis via COFF wrote: > : myInterpreter > begin 32 word find dup if execute else number then again ; > > And here would be a compiler: > > : my-] > begin 32 word find dup if dup immediate? if execute else compile > then else compile-number then again ; I say this as a guy who loved the reverse polish HP calculators, but my, oh my, that reads as gibberish to me today. Probably because I have an old tired boomer brain. Even when I wasn't tired, I drilled into my team "make code readable, you read it way more than you write it". I have never found forth to be readable. As Rob says, I survived Forth. I agree that that would make a good nerd tshirt but I also suspect very few people would get it. Mitch would but I think he wouldn't like it :) From coff at tuhs.org Wed Sep 24 10:35:34 2025 From: coff at tuhs.org (Bakul Shah via COFF) Date: Tue, 23 Sep 2025 17:35:34 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <87ms6k3f71.fsf@gmail.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> Message-ID: On Sep 23, 2025, at 4:46 PM, Alexis via COFF wrote: > > Bakul Shah via COFF writes: > >> I wonder if there is a meta-circular evaluator for forth (i.e. forth in forth) > > The 'MetaCircularEvaluator' page on the c2 wiki: > > https://wiki.c2.com/?MetaCircularEvaluator > > includes this: > > here is a simple metacircular interpreter in arbitrary dialect Forth: > > : myInterpreter > begin 32 word find dup if execute else number then again ; > > And here would be a compiler: > > : my-] > begin 32 word find dup if dup immediate? if execute else compile then else compile-number then again ; Thanks but... Not quite what I had in mind. See https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/01c6ba0c5d426b5459d66340e60eb00f_lecture20evalco.pdf For a Scheme meta-circular-evluator. It doesn't rely on an eval function (not part of R4RS Scheme). Though one can argue that "execute" built in so this is indeed a MCE! From coff at tuhs.org Wed Sep 24 10:40:12 2025 From: coff at tuhs.org (Dave Horsfall via COFF) Date: Wed, 24 Sep 2025 10:40:12 +1000 (EST) Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <20250924001738.GD26901@mcvoy.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> Message-ID: On Tue, 23 Sep 2025, Larry McVoy via COFF wrote: > I say this as a guy who loved the reverse polish HP calculators, but my, > oh my, that reads as gibberish to me today. Probably because I have an > old tired boomer brain. I still treasure my olde HP-42S. -- Dave From coff at tuhs.org Wed Sep 24 10:57:54 2025 From: coff at tuhs.org (Larry McVoy via COFF) Date: Tue, 23 Sep 2025 17:57:54 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> Message-ID: <20250924005754.GE26901@mcvoy.com> On Wed, Sep 24, 2025 at 10:40:12AM +1000, Dave Horsfall via COFF wrote: > On Tue, 23 Sep 2025, Larry McVoy via COFF wrote: > > > I say this as a guy who loved the reverse polish HP calculators, but my, > > oh my, that reads as gibberish to me today. Probably because I have an > > old tired boomer brain. > > I still treasure my olde HP-42S. I still remember going to a store where they sold an HP-16c, the sales guy hurled it at the wall of the store. Like as hard as he could. And it worked and it did hex and octal and binary, yeah, bought that. These days I can find an app that does that online when I want the memories. It's not the same as touching those keys, the sales guy told me the print on the keys is not on top, it goes all the way through the keys so they never wear out. Those were the days, my friend, wwe thought they'd never end, but then we out sourced and things went down hill. I don't know where you buy stuff like what the old HP did. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From coff at tuhs.org Wed Sep 24 15:33:58 2025 From: coff at tuhs.org (Tomasz Rola via COFF) Date: Wed, 24 Sep 2025 07:33:58 +0200 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: <20250924005754.GE26901@mcvoy.com> References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On Tue, Sep 23, 2025 at 05:57:54PM -0700, Larry McVoy via COFF wrote: [...] > > Those were the days, my friend, wwe thought they'd never end, but then we > out sourced and things went down hill. I don't know where you buy stuff > like what the old HP did. If you want calculator, you may try your luck with Swiss Micros: The DM16C is the programmer's calculator designed to display and work with numbers in hexadecimal, decimal, octal and binary, and convert numbers from one base to another. It provides a wealth of specialized functions, including left- and right-shifting, masking, and bitwise logical operations. [ https:// www.swissmicros.com /product/dm16c ] It looks like HP16C clone (for me at least, I did not look into manual and do not own, but seems to have way more memory then original "16") and they say titanium case, so perhaps you could do wall test on it. If you do, please write about results. Actually, I doubt it is really a clone. Inspired, probably. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From coff at tuhs.org Wed Sep 24 15:51:41 2025 From: coff at tuhs.org (Tomasz Rola via COFF) Date: Wed, 24 Sep 2025 07:51:41 +0200 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On Wed, Sep 24, 2025 at 07:33:58AM +0200, Tomasz Rola via COFF wrote: > On Tue, Sep 23, 2025 at 05:57:54PM -0700, Larry McVoy via COFF wrote: > [...] > > > > Those were the days, my friend, wwe thought they'd never end, but then we > > out sourced and things went down hill. I don't know where you buy stuff > > like what the old HP did. > > If you want calculator, you may try your luck with Swiss Micros: [...] But OTOH, after a while, I think that since I never owned HP calculator (I owned a simple programmable of SE-Asia make, which had no loops/jumps, i.e. no Turing completeness and I bought me certain Russian model, just to see if I can repair it and have some fun, and it is Turing complete but not repaired yet) = so I have no nostalgia. I guess I would be much better off if I just installed me a gforth onto this Android smartphone and that would be it, for me at least. The only thing I would detest in this second case is no on/off switch and if it still had the switch, then about a minute of boot time rather than instant Forth prompt. And I would need to recharge it on a daily basis... Because this is what smartphone is. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From coff at tuhs.org Wed Sep 24 16:16:55 2025 From: coff at tuhs.org (Dave Horsfall via COFF) Date: Wed, 24 Sep 2025 16:16:55 +1000 (EST) Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <20250924005754.GE26901@mcvoy.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On Tue, 23 Sep 2025, Larry McVoy wrote: > Those were the days, my friend, wwe thought they'd never end, but then > we out sourced and things went down hill. I don't know where you buy > stuff like what the old HP did. We'd sing and dance for ever and a day... I used to lend out my HP-42S to cow-orkers, and smirk as they tried to find the "=" key :-) Reverse Polish rules! The thing is starting to play up now, with various memory errors etc; well, you show me memory still working after 70+ years... I looked at the printer, but it was far too expensive; has anyone decoded the IR protocol it uses so that it can be fed it into an iPad etc? -- Dave From coff at tuhs.org Wed Sep 24 18:50:36 2025 From: coff at tuhs.org (Tomasz Rola via COFF) Date: Wed, 24 Sep 2025 10:50:36 +0200 Subject: [COFF] HP42S In-Reply-To: References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On Wed, Sep 24, 2025 at 04:16:55PM +1000, Dave Horsfall via COFF wrote: [...] > > The thing is starting to play up now, with various memory errors etc; > well, you show me memory still working after 70+ years... > > I looked at the printer, but it was far too expensive; has anyone decoded > the IR protocol it uses so that it can be fed it into an iPad etc? The info (or some info) may be buried inside Free42 emulator - it claims to do both HP42S and HP-82240 printer: https://thomasokken.com/free42/ https://codeberg.org/thomasokken/free42 But I have no idea if it is so and not so much time to investigate right now. I have just happened to find this while cleaning up (i.e. closing) excessive browser tabs. HTH -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From coff at tuhs.org Wed Sep 24 21:21:29 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Wed, 24 Sep 2025 07:21:29 -0400 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: <20250924005754.GE26901@mcvoy.com> References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On Tue, Sep 23, 2025 at 9:04 PM Larry McVoy via COFF wrote: > On Wed, Sep 24, 2025 at 10:40:12AM +1000, Dave Horsfall via COFF wrote: > > On Tue, 23 Sep 2025, Larry McVoy via COFF wrote: > > > > > I say this as a guy who loved the reverse polish HP calculators, but my, > > > oh my, that reads as gibberish to me today. Probably because I have an > > > old tired boomer brain. > > > > I still treasure my olde HP-42S. > > I still remember going to a store where they sold an HP-16c, the sales > guy hurled it at the wall of the store. Like as hard as he could. > And it worked and it did hex and octal and binary, yeah, bought that. > > These days I can find an app that does that online when I want the memories. > It's not the same as touching those keys, the sales guy told me the print > on the keys is not on top, it goes all the way through the keys so they > never wear out. > > Those were the days, my friend, wwe thought they'd never end, but then we > out sourced and things went down hill. I don't know where you buy stuff > like what the old HP did. My dad had the HP-15c, which I always thought was super cool. But he is (was; he's retired now) a real engineer, unlike me, who is just a poser. I believe he still has it; I remember being fascinated by all the cool symbols on it when I was a kid. That said, this fellow over in Switzerland has done an amazing job building recreations of a number of the classic HP calculators, including the 15C and 16C. https://www.swissmicros.com/products I still keep an RPN calculator on my desk, though I rarely need to use it anymore; most of the time if I need to do a quick computation, I just fire up `bc` at the command line. - Dan C. From coff at tuhs.org Wed Sep 24 22:00:51 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Wed, 24 Sep 2025 08:00:51 -0400 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On Wed, Sep 24, 2025 at 1:44 AM Tomasz Rola via COFF wrote: > On Tue, Sep 23, 2025 at 05:57:54PM -0700, Larry McVoy via COFF wrote: > [...] > > > > Those were the days, my friend, wwe thought they'd never end, but then we > > out sourced and things went down hill. I don't know where you buy stuff > > like what the old HP did. > > If you want calculator, you may try your luck with Swiss Micros: > > The DM16C is the programmer's calculator designed to display and > work with numbers in hexadecimal, decimal, octal and binary, and > convert numbers from one base to another. It provides a wealth of > specialized functions, including left- and right-shifting, masking, > and bitwise logical operations. > > [ https:// www.swissmicros.com /product/dm16c ] Oops, I hadn't seen your response before mentioning Swiss Micros myself. > It looks like HP16C clone (for me at least, I did not look into manual > and do not own, but seems to have way more memory then original "16") > and they say titanium case, so perhaps you could do wall test on > it. If you do, please write about results. > > Actually, I doubt it is really a clone. Inspired, probably. I'll admit to having it, and it is pretty much a clone. Expanded, sure, but meant to be an almost exact facsimile. At one point, they referred to the HP user's manual to figure out how to use the thing. I believe he spoke with some retired HP engineers when designing the first versions to make them accurate; I can't find the link now, but I remember seeing a video by an HP guy who talked about the 15C and then mentioned SwissMicros and said something like, "wow, he's done a remarkable job: I can't believe he hasn't been sued yet!" In that video, he did note that the keys were not likely to be as durable. As Larry mentioned, on the real HP calculators, they go all the way through the plastic and so don't wear off, whereas whatever manufacturing process does that wasn't available to SM (at least, not at the scale he's doing things at). I guess travel and pressure and stuff varies as well; apparently, calculator keys are quite complex in a way that, say, a keyboard is not (perhaps due to the limited size?). With respect to the 16c itself, the bitwise functions are kind of neat, but I believe they top out at 16 bits; the display is probably the limiting factor there. - Dan C. From coff at tuhs.org Wed Sep 24 22:07:06 2025 From: coff at tuhs.org (Paul Guertin via COFF) Date: Wed, 24 Sep 2025 08:07:06 -0400 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: <77060602-4564-462f-8007-6b79797c7d3b@guertin.net> Dixit Dan Cross via COFF (2025-09-24 08:00): > In that video, he did note that the [SwissMicros] keys were > not likely to be as durable [as HP keys]. I have several HP calculators and a couple SwissMicros as well, and I can confirm that HP keys are the best of the two by far (my favorites being the ones of the HP 34C era). Still, SwissMicros are very usable and pretty much the only way to buy new RPN calculators these days. Paul Guertin From coff at tuhs.org Thu Sep 25 00:32:11 2025 From: coff at tuhs.org (Dan Halbert via COFF) Date: Wed, 24 Sep 2025 10:32:11 -0400 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: <77060602-4564-462f-8007-6b79797c7d3b@guertin.net> References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> <77060602-4564-462f-8007-6b79797c7d3b@guertin.net> Message-ID: On 9/24/25 08:07, Paul Guertin via COFF wrote: > I have several HP calculators and a couple SwissMicros as > well, and I can confirm that HP keys are the best of the > two by far (my favorites being the ones of the HP 34C era). > Still, SwissMicros are very usable and pretty much the > only way to buy new RPN calculators these days. > Looks like a Czech company (not SwissMicro) has licensed several HP calculator designs, in particular HP-15C and -12C, but not the 16C https://shop.moravia.education/calculators/hp.html From coff at tuhs.org Thu Sep 25 00:53:57 2025 From: coff at tuhs.org (Mike Markowski via COFF) Date: Wed, 24 Sep 2025 10:53:57 -0400 Subject: [COFF] HP16C In-Reply-To: References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> <77060602-4564-462f-8007-6b79797c7d3b@guertin.net> Message-ID: On Wed, Sep 24, 2025 at 10:39 AM Dan Halbert via COFF wrote: > On 9/24/25 08:07, Paul Guertin via COFF wrote: > > I have several HP calculators and a couple SwissMicros as > > well, and I can confirm that HP keys are the best of the > > two by far (my favorites being the ones of the HP 34C era). > > Still, SwissMicros are very usable and pretty much the > > only way to buy new RPN calculators these days. > > > Looks like a Czech company (not SwissMicro) has licensed several HP > calculator designs, in particular HP-15C and -12C, but not the 16C > > https://shop.moravia.education/calculators/hp.html The HP-15C Collectors Edition apparently has 3 firmware variations in it and a magic key sequence lets you choose one at start up. One choice is HP-16C, though you need the correct keyboard overlay, sold by https://www.thecalculatorstore.com/ . I bought the calc and overlay for the fun of it. I also have a SwissMicros DM42 and played with using the additional screen real estate that the HP-42S didn't have: https://udel.edu/~mm/hp/hp42s/ Little activities to while away rainy days. :-) Mike Markowski From coff at tuhs.org Thu Sep 25 01:48:47 2025 From: coff at tuhs.org (Stuff Received via COFF) Date: Wed, 24 Sep 2025 11:48:47 -0400 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> Message-ID: On 2025-09-23 20:40, Dave Horsfall via COFF wrote: > On Tue, 23 Sep 2025, Larry McVoy via COFF wrote: > >> I say this as a guy who loved the reverse polish HP calculators, but my, >> oh my, that reads as gibberish to me today. Probably because I have an >> old tired boomer brain. > > I still treasure my olde HP-42S. > > -- Dave My wife still uses an HP-32S for the odd book-keeping stuff. (We still have our 16S somewhere.) S. From coff at tuhs.org Thu Sep 25 01:57:29 2025 From: coff at tuhs.org (Dennis Boone via COFF) Date: Wed, 24 Sep 2025 11:57:29 -0400 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: (Your message of Wed, 24 Sep 2025 08:00:51 -0400.) References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: <20250924155729.D19D744BD75@yagi.h-net.msu.edu> > With respect to the 16c itself, the bitwise functions are kind of > neat, but I believe they top out at 16 bits; the display is probably > the limiting factor there. Er, pretty sure everything the machine does works up to 64 bits. The screen display is admittedly a bit tedious for word sizes that don't fit in the base you're using. De From coff at tuhs.org Thu Sep 25 02:11:54 2025 From: coff at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via COFF) Date: Wed, 24 Sep 2025 09:11:54 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: <4a618c6352351417@orthanc.ca> Dave Horsfall via COFF writes: > I looked at the printer, but it was far too expensive; has anyone decoded > the IR protocol it uses so that it can be fed it into an iPad etc? I've thought about using an Atmel chip to build an irda controller to talk to my 50g. And if I can figure out how to squeeze a tiny 9p protocol stack in there, then I could mount the 50g on the plan9 network ;-) Sadly, it's so far down the 'fun projects' list it will never get built :-( --lyndon From coff at tuhs.org Thu Sep 25 02:16:43 2025 From: coff at tuhs.org (Lyndon Nerenberg (VE7TFX/VE6BBM) via COFF) Date: Wed, 24 Sep 2025 09:16:43 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: <4a618c7208aaf75c@orthanc.ca> Dan Cross via COFF writes: > I still keep an RPN calculator on my desk, though I rarely need to use > it anymore; most of the time if I need to do a quick computation, I > just fire up `bc` at the command line. I use my 50g every day. I find bc just too clunky to use regularly. And for more than simple math, I have programs that help derive values for low/high/bandpass filters that save a lot of time when prototyping new filters, or for building PADs, etc. There isn't much you cannot do with an HP 50g. --lyndon From coff at tuhs.org Thu Sep 25 02:51:13 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Wed, 24 Sep 2025 12:51:13 -0400 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: <20250924155729.D19D744BD75@yagi.h-net.msu.edu> References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> <20250924155729.D19D744BD75@yagi.h-net.msu.edu> Message-ID: On Wed, Sep 24, 2025 at 12:04 PM Dennis Boone via COFF wrote: > > > With respect to the 16c itself, the bitwise functions are kind of > > neat, but I believe they top out at 16 bits; the display is probably > > the limiting factor there. > > Er, pretty sure everything the machine does works up to 64 bits. The > screen display is admittedly a bit tedious for word sizes that don't fit > in the base you're using. You are correct! I sat down and looked into it and yes, it supports word sizes up to 64 bits. But it is kind of tedious because of the display. - Dan C. From coff at tuhs.org Thu Sep 25 03:34:11 2025 From: coff at tuhs.org (Marc Howard via COFF) Date: Wed, 24 Sep 2025 13:34:11 -0400 Subject: [COFF] HP16C Re: [TUHS] Re: forth on early unix In-Reply-To: References: <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> <20250924155729.D19D744BD75@yagi.h-net.msu.edu> Message-ID: That isn’t a problem with the latest Swiss Micro software for the 16 C. The new software supports what they call a two line mode which normally displays both the X and Y register simultaneously. They now have an enhanced show function, which will allow an entire 64 bit value to be displayed even in octal at one glance. On Wed, Sep 24, 2025 at 12:51 PM Dan Cross via COFF wrote: > On Wed, Sep 24, 2025 at 12:04 PM Dennis Boone via COFF > wrote: > > > > > With respect to the 16c itself, the bitwise functions are kind of > > > neat, but I believe they top out at 16 bits; the display is probably > > > the limiting factor there. > > > > Er, pretty sure everything the machine does works up to 64 bits. The > > screen display is admittedly a bit tedious for word sizes that don't fit > > in the base you're using. > > You are correct! I sat down and looked into it and yes, it supports > word sizes up to 64 bits. But it is kind of tedious because of the > display. > > - Dan C. > From coff at tuhs.org Thu Sep 25 17:15:35 2025 From: coff at tuhs.org (Johan Helsingius via COFF) Date: Thu, 25 Sep 2025 09:15:35 +0200 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: On 24/09/2025 13:21, Dan Cross via COFF wrote: > I still keep an RPN calculator on my desk, though I rarely need to use > it anymore; most of the time if I need to do a quick computation, I > just fire up `bc` at the command line. This discussion made me pull out and check my 32SII and 35s. The latter seems to need new batteries - but these days I just keep one tab in my terminal emulator permanently running dc. Julf From coff at tuhs.org Sat Sep 27 00:26:03 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Fri, 26 Sep 2025 10:26:03 -0400 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: [Honoring wkt's recent request for this discussion to migrate to COFF, sending TUHS to Bcc] While this discussion moves to COFF, there is a Unix tie-in specifically with respect to the empty-file `true`: Gerard Holzmann wrote a nice article about this several years ago in the "Reliable Code" column of IEEE Software, titled, "Code Inflation". It's not long, and it's a very fun read. Themes he explores may resonate well with the average TUHS reader: https://spinroot.com/gerard/pdf/Code_Inflation.pdf As an aside, the implementation of `true` as an empty file relies on a quirk of `sh` to work: `sh` would try to invoke a program via `exec`, and if that failed, would then try to interpret it as a shell script. Since a zero-byte file is not a valid binary executable for invocation via `exec`, this would fail; the shell would then try to interpret it, do nothing (as there was nothing to do), and exit with its default value (0), indicating success. But a side-effect of this is that one cannot directly `exec` true and expect success; the result is an error. "Why would anyone want to do that, anyway?" Good question; I suspect they wouldn't in the normal case. But I can imagine someone linking `true` to something they expect to succeed to, or specifying it as an argument to something in lieu of another command they didn't want to bother with (perhaps an editor or something). Perhaps `true` should be, `#!/bin/sh` and nothing else, but `exec` support for invoking interpreters via the `#!` syntax came in 4.1BSD, well after zero-byte `/bin/true`. A random thought: some versions of UFS have support for something they call "fast symlinks". Symbolic links, of course, are just files that contain a string naming some other file, and if a pathname has a component naming a symlink when walked by `namei`, that string is substituted for the name of the symlink. But often these names are very short, and recall that the `inode` contains some space for disk block addresses (60 bytes in UFS on 4.1C, but this got bigger in later versions). The idea with fast symlinks is that, if the target file name of a symlink is short enough, the system can just store it in the space that would normally be used for block addresses; there's no need to allocate a separate fragment from a disk block, let alone bear the cost of allocating a buffer and fetching a block from disk, if a short name can be written directly into the inode. I don't think anyone ever gave serious thought to generalizing this facility for very small files, but in principle, one could store their contents in a similar manner (think of all those random little files that just have a pid in them or something). In that case, one wonders what the smallest executable binary implementing `_exit(0)` is. Some folks have played around with hacks and gotten very small files indeed: less than 120 bytes for ELF files, for example, and with a.out, it would have been even smaller. So, it raises the question: could one have written a hyper-size optimized version of `true` that generated a very, very small executable binary that was embedded directly into its inode in the form of one of these hypothetical short files, but still executable? I suspect the answer is "yes". For the record, I don't think this would have any _practical_ utility, and putting effort into such a thing for real work would be about as useful as adding a `--false` flag to `true`. But it would be a neat hack. On Thu, Sep 25, 2025 at 11:32 PM segaloco via TUHS wrote: > On Thursday, September 25th, 2025 at 20:18, Warner Losh via TUHS wrote: > > On Thu, Sep 25, 2025, 8:08 PM segaloco via TUHS tuhs at tuhs.org wrote: > > > > > On Thursday, September 25th, 2025 at 17:23, jason-tuhs--- via TUHS < > > > tuhs at tuhs.org> wrote: > > > > > > > > Heck; at one time the "true" command was a Shell script with a huge > > > > > copyright notice, followed by... nothing... (The "false" script > > > > > actually had "exit 1" at the end.) > > > > > > > > From http://web.42.net/true.html > > > > > > ========================================================================== > > > > > > > cat /bin/true > > > > > > > > # Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T; > > > > # All Rights Reserved > > > > > > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T; > > > > # The copyright notice above does not evidence any > > > > # actual or intended publication of such source code. > > > > > > > > #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */ > > > > > > > > I'm not sure what I like most. The fact that they're claiming strict > > > > copyright on a file that is all comments? The fact that they're up to > > > > version 1.6 of all-comments, after five years of development? Or the fact > > > > that the GNU version had to be rewritten (due to the above copyright), > > > > and > > > > thus actually offers three times as much functionality? > > > > > > ========================================================================== > > > > > > > -Jason > > > > > > So assuming the whole text of the program after the copyright statement > > > itself as well as the source control statements is truly AT&T > > > property...does that mean AT&T lays copyright to the empty file? I jest > > > but it is an interesting suggestion. > > > > I think this credits too much intentionality... but you can't copyright > > nothing, despite the claims here. There's no creative content. > > > > Also, we all know this was done by the sed-o-matic on every file without > > thinking. So from that perspective, it's not additive to nothing... I suspect the answer to the original question is "no", as it's really copyrighting nothing, and ... what would that mean? Can I claim copyright over the empty set in mathematics? Surely there must be a thing in order to claim copyright over that thing; copyrighting the absence of a thing makes no sense, and we're back to this notion that you can't copyright an idea. This feels like one of those weird "physical reality meets the law" things, like trying to pass a law banning meteor showers or something goofy like that. > I meant more along the lines of a specific disk, a physical instance. Barring some ability to pursue damages on theft or something, imagine for instance using copyright law to prohibit distribution of some snapshot of a filesystem header, on the grounds that even the directory information has been claimed as under copyright by the owner of that physical piece of media. Indeed this is in the weeds but just felt like an amusing parallel to the idea of copyrighting an empty file. It's a construct more than it is original, intentional content. To oversimplify it, could the output from ls(1) in a directory be copyrighted by the person who happened to type "ls"? Huh. I don't know about a superblock, but it seems unlikely: a superblock changes all the time during the course of normal operation. To what would the copyright apply, other than the SB's state at a specific instance in time? How is that different than, say, trying to copyright the position of a flywheel in some mechanical engine at a specific moment in time? But it is an interesting question. IIRC Oracle's licensing terms for its database product are sort of weird in this regard: they license for a physical processor, and this has given folks all sorts of headaches when considering virtualized environments. A question that has been raised is whether it's a violation of the licensing terms to migrate the VM running an instance of Oracle to a separate physical machine, or even snapshot the VM's (memory) state and write it to a separate machine, then copy it back and resume it (even if the snapshot doesn't run). Questions like that make me glad I'm not a lawyer. - Dan C. From coff at tuhs.org Sat Sep 27 00:51:20 2025 From: coff at tuhs.org (Arnold Robbins via COFF) Date: Fri, 26 Sep 2025 08:51:20 -0600 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: <202509261451.58QEpK5e025554@freefriends.org> Dan Cross via TUHS wrote: > A random thought: some versions of UFS have support for something they > call "fast symlinks". Symbolic links, of course, are just files that > contain a string naming some other file, and if a pathname has a > component naming a symlink when walked by `namei`, that string is > substituted for the name of the symlink. But often these names are > very short, and recall that the `inode` contains some space for disk > block addresses (60 bytes in UFS on 4.1C, but this got bigger in later > versions). The idea with fast symlinks is that, if the target file > name of a symlink is short enough, the system can just store it in the > space that would normally be used for block addresses; there's no need > to allocate a separate fragment from a disk block, let alone bear the > cost of allocating a buffer and fetching a block from disk, if a short > name can be written directly into the inode. > > I don't think anyone ever gave serious thought to generalizing this > facility for very small files, but in principle, one could store their > contents in a similar manner (think of all those random little files > that just have a pid in them or something). I recall hearing that Amdahl did this for UTS, their System V port. I think it was a little more general, in that if there were, say 2 inodes in a 512-byte block, a file of size (256 - sizeof(struct inode)) could be stored in the same block as the inode itself. FWIW, Arnold From coff at tuhs.org Sat Sep 27 08:04:49 2025 From: coff at tuhs.org (Steffen Nurpmeso via COFF) Date: Sat, 27 Sep 2025 00:04:49 +0200 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: <202509261451.58QEpK5e025554@freefriends.org> References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> <202509261451.58QEpK5e025554@freefriends.org> Message-ID: <20250926220449.eHlQSbj3@steffen%sdaoden.eu> Arnold Robbins via COFF wrote in <202509261451.58QEpK5e025554 at freefriends.org>: |Dan Cross via TUHS wrote: ... |> [.] recall that the `inode` contains some space for disk |> block addresses (60 bytes in UFS on 4.1C, but this got bigger in later |> versions). The idea with fast symlinks is that, if the target file |> name of a symlink is short enough, the system can just store it in the |> space that would normally be used for block addresses; there's no need |> to allocate a separate fragment from a disk block, let alone bear the |> cost of allocating a buffer and fetching a block from disk, if a short |> name can be written directly into the inode. |> |> I don't think anyone ever gave serious thought to generalizing this |> facility for very small files, but in principle, one could store their |> contents in a similar manner (think of all those random little files |> that just have a pid in them or something). | |I recall hearing that Amdahl did this for UTS, their System V port. |I think it was a little more general, in that if there were, say 2 |inodes in a 512-byte block, a file of size (256 - sizeof(struct inode)) |could be stored in the same block as the inode itself. Now you got me in my user space comfort. But, from readings here and there from about 25 years ago, wasn't this one of the things the people liked so much about ReiserFS? And likewise i would think BTRFS also does this. "man 5 btrfs" says max_inline= (default: min(2048, page size) ) Specify the maximum amount of space, that can be inlined in a metadata b-tree leaf. The value is specified in bytes, option‐ ally with a K suffix (case insensitive). In practice, this value is limited by the filesystem block size (named sectorsize at mkfs time), and memory page size of the system. In case of sectorsize limit, there's some space unavailable due to b-tree leaf headers. For example, a 4KiB sectorsize, maximum size of inline data is about 3900 bytes. Inlining can be completely turned off by specifying 0. This will increase data block slack if file sizes are much smaller than block size but will reduce metadata consumption in return. NOTE: The default value has changed to 2048 in kernel 4.6. Monty Python would now possibly go and say "hey, let's design a tiny house with the core design principle of inlining small subjects, like elephant or giraff". (And ah, the luxury of heigh ceilings..) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From coff at tuhs.org Sat Sep 27 08:21:00 2025 From: coff at tuhs.org (Yeechang Lee via COFF) Date: Fri, 26 Sep 2025 15:21:00 -0700 Subject: [COFF] [TUHS] Re: forth on early unix In-Reply-To: References: <20250922031711.GB31455@mcvoy.com> <93dcc5eb-1152-468f-8c87-5715243b14a9@Julf.com> <7w7bxqfxl2.fsf@junk.nocrew.org> <7wcy7hepe3.fsf@junk.nocrew.org> <77DDD45E-C282-414F-BAC2-9BB8E74C8204@iitbombay.org> <87ms6k3f71.fsf@gmail.com> <20250924001738.GD26901@mcvoy.com> <20250924005754.GE26901@mcvoy.com> Message-ID: <26839.4556.484785.994318@dobie-old.ylee.org> Johan Helsingius says: > but these days I just keep one tab in my terminal emulator > permanently running dc. I do the same thing, with tmux and Orpie. From coff at tuhs.org Sat Sep 27 08:48:32 2025 From: coff at tuhs.org (Bakul Shah via COFF) Date: Fri, 26 Sep 2025 15:48:32 -0700 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: On Sep 26, 2025, at 7:26 AM, Dan Cross via COFF wrote: > > A random thought: some versions of UFS have support for something they > call "fast symlinks". Symbolic links, of course, are just files that > contain a string naming some other file, and if a pathname has a > component naming a symlink when walked by `namei`, that string is > substituted for the name of the symlink. But often these names are > very short, and recall that the `inode` contains some space for disk > block addresses (60 bytes in UFS on 4.1C, but this got bigger in later > versions). The idea with fast symlinks is that, if the target file > name of a symlink is short enough, the system can just store it in the > space that would normally be used for block addresses; there's no need > to allocate a separate fragment from a disk block, let alone bear the > cost of allocating a buffer and fetching a block from disk, if a short > name can be written directly into the inode. Storing symlink or small file content in the inode breaks unix semantics: whether you can hard link to a file would depends on its size! From coff at tuhs.org Sat Sep 27 10:21:20 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Fri, 26 Sep 2025 20:21:20 -0400 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: On Fri, Sep 26, 2025 at 6:48 PM Bakul Shah wrote: > On Sep 26, 2025, at 7:26 AM, Dan Cross via COFF wrote: > > A random thought: some versions of UFS have support for something they > > call "fast symlinks". Symbolic links, of course, are just files that > > contain a string naming some other file, and if a pathname has a > > component naming a symlink when walked by `namei`, that string is > > substituted for the name of the symlink. But often these names are > > very short, and recall that the `inode` contains some space for disk > > block addresses (60 bytes in UFS on 4.1C, but this got bigger in later > > versions). The idea with fast symlinks is that, if the target file > > name of a symlink is short enough, the system can just store it in the > > space that would normally be used for block addresses; there's no need > > to allocate a separate fragment from a disk block, let alone bear the > > cost of allocating a buffer and fetching a block from disk, if a short > > name can be written directly into the inode. > > Storing symlink or small file content in the inode breaks unix > semantics: whether you can hard link to a file would depends > on its size! I don't see why? A hard link is just a directory entry that points to an inode; regardless of whether or not the file's data is in the inode or in another block, the inode is still an inode, and the inode continues to track metadata like link counts. As far as links are concerned, placement of the file's data is irrelevant. If you tried to inline file data into a directory, on the other hand.... - Dan C. From coff at tuhs.org Sat Sep 27 11:35:31 2025 From: coff at tuhs.org (Theodore Ts'o via COFF) Date: Fri, 26 Sep 2025 21:35:31 -0400 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: <20250927013531.GC118657@mit.edu> On Fri, Sep 26, 2025 at 08:21:20PM -0400, Dan Cross via COFF wrote: > > If you tried to inline file data into a directory, on the other hand.... > Something quite interesting (to me, anyway :-) is the inclusion of *metadata* into the directory entry; specifically, d_type, since while you can change the file permission, you can't change a symlink to a regular file or directory, and this can significantly speed up operations like "find . -type f -name .[a-z]*". Chris Siebenmann has a very nice write up the history here[1]; I didn't realize that it didn't show up until BSD 4.4, albeit undocuimented, and did't show up as a documented interface until 1997 in FreeBSD, with Linux picking it up in 2001, and Solaris picking it up.... never. (Although ZFS maintains the information on-disk, even though Solaris didn't have a way of taking avantage of the d_type field.) [1] https://utcc.utoronto.ca/~cks/space/blog/unix/DirectoryDTypeHistory - Ted From coff at tuhs.org Sat Sep 27 11:55:49 2025 From: coff at tuhs.org (Bakul Shah via COFF) Date: Fri, 26 Sep 2025 18:55:49 -0700 Subject: [COFF] [TUHS] Re: History of cal(1)? In-Reply-To: References: <7p3hPqt4RxWN3O4Qkd113NNRo_EOSAY3kaE2k05oaUHHRXGZdHpNgLhL_wmuMjdtX1y-qtBZ_pzPcjFbaqlhUEQku2JSvNtYJnn9kX_mYB4=@protonmail.com> Message-ID: <5444A2BD-85BA-4A27-B27D-BF4E61BE6604@iitbombay.org> On Sep 26, 2025, at 5:21 PM, Dan Cross wrote: > > I don't see why? A hard link is just a directory entry that points to > an inode; regardless of whether or not the file's data is in the inode > or in another block, the inode is still an inode, and the inode > continues to track metadata like link counts. As far as links are > concerned, placement of the file's data is irrelevant. You're right. I was thinking of when a symlink is stored in a directory as that can save a disk access to the symlink's inode. I don't recall if FreeBSD or any other system ever did this though.