From douglas.mcilroy at dartmouth.edu Sat Apr 2 01:59:41 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 1 Apr 2022 11:59:41 -0400 Subject: [TUHS] A Reiser tour de force Message-ID: The recent discussion about Research choosing BSD's paging over Reiser-London's brought to mind a stunning program by Reiser that Research did adopt. A critical primitive in the Blit terminal was bitblt (block transfer of a rectangular area). It was used ubiquitously, for example to refresh data when window-stacking changed, to move data within a window, or to pop up a menu.. The display memory was word-oriented, so bitblt was fraught with niggling details about bit alignment and overlap of source and destination. A general bitblt subroutine was a rats' nest of conditionals--grossly inefficient for important special cases like scrolling. Bitblt got refined (i.e. elaborated) several times before Reiser did away with it entirely. Instead he wrote a just-in-time generator of optimal code. Thousands of distinct variants, which varied in size from 16 to 72 bytes, could be produced by the same 400 lines of assembler code. Doug From david at kdbarto.org Sat Apr 2 03:15:11 2022 From: david at kdbarto.org (David Barto) Date: Fri, 1 Apr 2022 10:15:11 -0700 Subject: [TUHS] A Reiser tour de force In-Reply-To: References: Message-ID: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> > On Apr 1, 2022, at 8:59 AM, Douglas McIlroy wrote: > > The recent discussion about Research choosing BSD's paging over > Reiser-London's brought to mind a stunning program by Reiser that > Research did adopt. > > A critical primitive in the Blit terminal was bitblt (block transfer > of a rectangular area). It was used ubiquitously, for example to > refresh data when window-stacking changed, to move data within a > window, or to pop up a menu.. The display memory was word-oriented, so > bitblt was fraught with niggling details about bit alignment and > overlap of source and destination. A general bitblt subroutine was a > rats' nest of conditionals--grossly inefficient for important special > cases like scrolling. > > Bitblt got refined (i.e. elaborated) several times before Reiser did > away with it entirely. Instead he wrote a just-in-time generator of > optimal code. Thousands of distinct variants, which varied in size > from 16 to 72 bytes, could be produced by the same 400 lines of > assembler code. > > Doug Does this exist for the rest of us to study? David From jon at fourwinds.com Sat Apr 2 03:26:15 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 01 Apr 2022 10:26:15 -0700 Subject: [TUHS] A Reiser tour de force In-Reply-To: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> References: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> Message-ID: <202204011726.231HQFm03349496@darkstar.fourwinds.com> David Barto writes: > > > > > On Apr 1, 2022, at 8:59 AM, Douglas McIlroy wrote: > > > > The recent discussion about Research choosing BSD's paging over > > Reiser-London's brought to mind a stunning program by Reiser that > > Research did adopt. > > > > A critical primitive in the Blit terminal was bitblt (block transfer > > of a rectangular area). It was used ubiquitously, for example to > > refresh data when window-stacking changed, to move data within a > > window, or to pop up a menu.. The display memory was word-oriented, so > > bitblt was fraught with niggling details about bit alignment and > > overlap of source and destination. A general bitblt subroutine was a > > rats' nest of conditionals--grossly inefficient for important special > > cases like scrolling. > > > > Bitblt got refined (i.e. elaborated) several times before Reiser did > > away with it entirely. Instead he wrote a just-in-time generator of > > optimal code. Thousands of distinct variants, which varied in size > > from 16 to 72 bytes, could be produced by the same 400 lines of > > assembler code. > > > > Doug > > Does this exist for the rest of us to study? > > David It's not insanely complicated by modern standards. Without any knowledge of other work, I did the same thing for a 68020 based graphics system where the JIT code went into the I-cache and was amazingly fast for its day. If I remember correctly, things started with an outer-loop test to see if there were overlapping regions to determine whether to go forward to backwards to avoid having the destination trash the source. Then, there was an inner loop test for whether or not the left edge was on a word boundary, the right edge was on a word boundary, or whether or not both edges were inside of the same word. Depending on the results the generated inner loop code had left edge handling, non-edge handling, and right edge handling code. Finally, code was generated plugging in whatever was needed for the op-code. Maybe this is just a semantic nit, but to me this is just a better implementation of bitblt, not doing away with it. Jon From steffen at sdaoden.eu Sat Apr 2 05:41:59 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 01 Apr 2022 21:41:59 +0200 Subject: [TUHS] A Reiser tour de force In-Reply-To: <202204011726.231HQFm03349496@darkstar.fourwinds.com> References: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> <202204011726.231HQFm03349496@darkstar.fourwinds.com> Message-ID: <20220401194159.HF6gb%steffen@sdaoden.eu> Jon Steinhart wrote in <202204011726.231HQFm03349496 at darkstar.fourwinds.com>: |David Barto writes: |>> On Apr 1, 2022, at 8:59 AM, Douglas McIlroy > du> wrote: |>> The recent discussion about Research choosing BSD's paging over |>> Reiser-London's brought to mind a stunning program by Reiser that |>> Research did adopt. |>> |>> A critical primitive in the Blit terminal was bitblt (block transfer |>> of a rectangular area). It was used ubiquitously, for example to ... |>> Bitblt got refined (i.e. elaborated) several times before Reiser did |>> away with it entirely. Instead he wrote a just-in-time generator of |>> optimal code. Thousands of distinct variants, which varied in size |>> from 16 to 72 bytes, could be produced by the same 400 lines of |>> assembler code. ... |> Does this exist for the rest of us to study? ... |It's not insanely complicated by modern standards. Without any knowledge |of other work, I did the same thing for a 68020 based graphics system where |the JIT code went into the I-cache and was amazingly fast for its day. | |If I remember correctly, things started with an outer-loop test to see |if there were overlapping regions to determine whether to go forward |to backwards to avoid having the destination trash the source. ... Only to add that "modern standard" C libraries define "overlapping" by means of exclusivity, meaning that memcpy(x, &x[1], 1) is an invalid overlapping that requires memmove() to be used. |#?132(0.02 1/76)|alp-2022:tmp$ cat t.c |#include |void doit(char *cp); |int main(void){ | char buf[3] = {'1', '2', '\0'}; | doit(buf); | return buf[0]; |} |void doit(char *cp){ | memcpy(cp, &cp[1], 2); |} |#?0(0.02 1/76)|alp-2022:tmp$ gcc -D_FORTIFY_SOURCE=2 -O -o zt t.c |#?0(0.02 1/76)|alp-2022:tmp$ ./zt |Illegal instruction |#?132(0.02 1/76)|alp-2022:tmp$ gcc --version |gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219 |Copyright (C) 2021 Free Software Foundation, Inc. |This is free software; see the source for copying conditions. There is NO |warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | |#?0(0.02 1/76)|alp-2022:tmp$ Your mileage will vary though. --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 robpike at gmail.com Sat Apr 2 07:29:44 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 2 Apr 2022 08:29:44 +1100 Subject: [TUHS] A Reiser tour de force In-Reply-To: <20220401194159.HF6gb%steffen@sdaoden.eu> References: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> <202204011726.231HQFm03349496@darkstar.fourwinds.com> <20220401194159.HF6gb%steffen@sdaoden.eu> Message-ID: A copy of our paper is at https://9p.io/cm/cs/doc/87/archtr.ps.gz -rob From robpike at gmail.com Sat Apr 2 07:31:04 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 2 Apr 2022 08:31:04 +1100 Subject: [TUHS] A Reiser tour de force In-Reply-To: References: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> <202204011726.231HQFm03349496@darkstar.fourwinds.com> <20220401194159.HF6gb%steffen@sdaoden.eu> Message-ID: And yes, this _was_ bitblt, its apotheosis, not its elimination. -rbo On Sat, Apr 2, 2022 at 8:29 AM Rob Pike wrote: > > A copy of our paper is at https://9p.io/cm/cs/doc/87/archtr.ps.gz > > -rob From jon at fourwinds.com Sat Apr 2 07:43:14 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 01 Apr 2022 14:43:14 -0700 Subject: [TUHS] A Reiser tour de force In-Reply-To: <20220401194159.HF6gb%steffen@sdaoden.eu> References: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org> <202204011726.231HQFm03349496@darkstar.fourwinds.com> <20220401194159.HF6gb%steffen@sdaoden.eu> Message-ID: <202204012143.231LhE2U3355821@darkstar.fourwinds.com> Steffen Nurpmeso writes: > Jon Steinhart wrote in > <202204011726.231HQFm03349496 at darkstar.fourwinds.com>: > |David Barto writes: > |>> On Apr 1, 2022, at 8:59 AM, Douglas McIlroy |>> du> wrote: > |>> The recent discussion about Research choosing BSD's paging over > |>> Reiser-London's brought to mind a stunning program by Reiser that > |>> Research did adopt. > |>> > |>> A critical primitive in the Blit terminal was bitblt (block transfer > |>> of a rectangular area). It was used ubiquitously, for example to > ... > |>> Bitblt got refined (i.e. elaborated) several times before Reiser did > |>> away with it entirely. Instead he wrote a just-in-time generator of > |>> optimal code. Thousands of distinct variants, which varied in size > |>> from 16 to 72 bytes, could be produced by the same 400 lines of > |>> assembler code. > ... > |> Does this exist for the rest of us to study? > ... > |It's not insanely complicated by modern standards. Without any knowledge > |of other work, I did the same thing for a 68020 based graphics system where > |the JIT code went into the I-cache and was amazingly fast for its day. > | > |If I remember correctly, things started with an outer-loop test to see > |if there were overlapping regions to determine whether to go forward > |to backwards to avoid having the destination trash the source. > ... > > Only to add that "modern standard" C libraries define > "overlapping" by means of exclusivity, meaning that memcpy(x, > &x[1], 1) is an invalid overlapping that requires memmove() to be > used. Uh, yeah, but not relevant at least to the code I did which was written in C but generated machine code, not calls to library functions. From jon at fourwinds.com Sun Apr 3 01:42:56 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 02 Apr 2022 08:42:56 -0700 Subject: [TUHS] LSI-11 Message-ID: <202204021542.232Fguwi3388491@darkstar.fourwinds.com> Someone on another list is getting rid of one of these. Lemme know if you want it and I'll put you in touch. From douglas.mcilroy at dartmouth.edu Sun Apr 3 10:35:12 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 2 Apr 2022 20:35:12 -0400 Subject: [TUHS] A Reiser tour do force Message-ID: > Does {Reiser's bitblt replacement] exist for the rest of us to study? A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c It appears to be a pre-Reiser bitblt, not what was asked for. But weighing in at over 800 lines of C, it vivifies the challenge that Reiser met in half the space. Doug From pnr at planet.nl Sun Apr 3 20:55:56 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 3 Apr 2022 12:55:56 +0200 Subject: [TUHS] A Reiser tour do force Message-ID: > A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c > It appears to be a pre-Reiser bitblt, not what was asked for. The Reiser code is in the V8 jerq tarball that Dan Cross donated: v8jerq.tar.bz2 It is in file blit/src/libj/bitblt.s (attached below for convenience). It is 750 lines of 68K assembler. It does not appear to have been ported to the Bellmac 32 CPU. Maybe it did not make sense in that context. Paul ===== # # bitblt(sm,r,dm,p,fc) # Bitmap *sm,*dm; # Rectangle r; # Point p; # int fc; # # by John F. Reiser summer 1982 # # Depending on the case at hand, generate very good code and execute it. # # offsets in a Point set x,0 set y,2 # offsets in a Rectangle set origin,0 set corner,4 # offsets in a Bitmap set base,0 set width,4 set rect,6 # parameter offsets from %fp set sm,8 set r,12 set dm,20 set p,24 set fc,28 set NREG,11 global bitblt bitblt: movm.l &0x3f3e,-(%sp) # save C registers movm.l NREG*4-4+sm(%sp),&0x001f # d1=r.o.x,,r.o.y; d2=r.c.x,,r.c.y; d4=p.x,,p.y; mov.l %d0,%a4 # sm mov.l %d3,%a5 # dm mov.w NREG*4-4+fc(%sp),%a6 # a6.w == fc movm.l rect(%a4),&0x9 # d0=sm.o.x,,sm.o.y; d3=sm.c.x,,sm.c.y; movm.l rect(%a5),&0x60 # d5=dm.o.x,,dm.o.y; d6=dm.c.x,,dm.c.y; lea.l $L50(%pc),%a0 L5: # clip r.y to sm.y mov.w %d0,%d7 # sm.o.y sub.w %d1,%d7 # - r.o.y ble.b L10 mov.w %d0,%d1 # r.o.y = sm.o.y; /* r.o.y was above sm.rect */ add.w %d7,%d4 # p.y parallels r.o.y L10: cmp.w %d2,%d3 # r.c.y : sm.c.y ble.b L20 mov.w %d3,%d2 # r.c.y = sm.c.y; /* bottom of r was below sm.rect */ L20: # clip (r.y at p.y) to dm.y mov.w %d5,%d7 # dm.o.y sub.w %d4,%d7 # -p.y ble.b L30 mov.w %d5,%d4 # p.y = dm.o.y; /* p.y was above dm.rect */ add.w %d7,%d1 # r.o.y parallels p.y L30: mov.w %d1,%d7 # r.o.y add.w %d6,%d7 # + dm.c.y sub.w %d4,%d7 # - p.y /* == max y that dm.rect allows in r */ cmp.w %d2,%d7 # r.c.y : limit ble.b L40 mov.w %d7,%d2 # r.c.y = limit L40: mov.w %d2,%d7 # r.c.y sub.w %d1,%d7 # - r.o.y sub.w &1,%d7 # /* == h-1 in bits */ blt.b ret jmp (%a0) retgen: lea.l gensiz(%sp),%sp ret8: add.l &8,%sp ret: movm.l (%sp)+,&0x7cfc rts L50: # mirror in pi/4 and reuse same code to clip x swap.w %d0; swap.w %d1; swap.w %d2; swap.w %d3 swap.w %d4; swap.w %d5; swap.w %d6; swap.w %d7 lea.l $L55(%pc),%a0 br.b L5 L55: mov.l %d1,%a1 mov.l %d4,%d6 # # So far # %d7 == h-1,,w-1 # %d6 == p.y,,p.x # %a6.w == fc # %a5 == dm # %a4 == sm # %a1 == r.o.y,,r.o.x # # Compute masks, and width in words # mov.w %d6,%d0 # p.x /* left endpoint of dst */ mov.w %d7,%d1 # w-1 add.w %d6,%d1 # right endpoint mov.l &-1,%d3 mov.l &15,%d2 and.w %d0,%d2 lsr.w %d2,%d3 # mask1 mov.l &-1,%d5 mov.l &15,%d2 and.w %d1,%d2 add.w &1,%d2 lsr.w %d2,%d5 not.w %d5 # mask2 swap.w %d5 mov.w %d3,%d5 # mask2,,mask1 asr.w &4,%d0 asr.w &4,%d1 sub.w %d0,%d1 sub.w &1,%d1 # inner-loop width in words mov.l &0,%d4 # assume LtoR mov.w width(%a5),%d3 add.w %d3,%d3 mov.w width(%a4),%d2 add.w %d2,%d2 # # So far # %d7 == h-1,,w-1 in bits # %d6 == p.y,,p.x # %d5 == mask2,,mask1 # %d4 == 0 (LtoR) # %d3.w == dm width in bytes # %d2.w == sm width in bytes # %d1.w == inner-loop width in words # %a6.w == fc # %a5 == dm # %a4 == sm # %a1 == r.o.y,,r.o.x # # If necessary, compensate for overlap of source and destination # cmp.l %a4,%a5 bne.b L80 # overlap not possible mov.l %d6,%d0 # p.y,,p.x mov.w %a1,%d0 # p.y,,r.o.x cmp.l %a1,%d0 # r.o.y : p.y bge.b L60 # if (r.o.y < p.y) mov.l %d7,%d0 # h-1,,w-1 clr.w %d0 # h-1,,0 add.l %d0,%a1 # r.o.y += h-1; add.l %d0,%d6 # p.y += h-1; neg.w %d3 # wdst = -wdst; neg.w %d2 # wsrc = -wsrc; L60: cmp.w %d7,&16 blt.b L70 # l<->r swap not needed for narrow cmp.w %d6,%a1 # p.x : r.o.x ble.b L70 # if (r.o.x < p.x) mov.l %a1,%d0 add.w %d7,%d0 mov.l %d0,%a1 # r.o.x += w-1; add.w %d7,%d6 # p.x += w-1; mov.l &-1,%d4 # RtoL swap.w %d5 # masks in other order L70: L80: # # Locate actual starting points # mov.l %d6,%d0 # p.y,,p.x swap.w %d0 mov.l %d0,-(%sp) # p mov.l %a5,-(%sp) # dm mov.l &15,%d0 lea.l $L82(%pc),%a0 # assume narrow cmp.w %d7,%d0 # w-1 : 15 ble.b L81 # guessed correctly lea.l $L85(%pc),%a0 # wide L81: mov.l %a0,-(%sp) # on return, go directly to wide/narrow code add.w %a6,%a6; add.w %a6,%a6 # with 4*fc mov.w %d1,%d7 # h-1 in bits,,inner width in words and.l %d0,%d6 # 0,,bit offset of p.x mov.l %a1,%d1 # r.o.y,,r.o.x and.w %d1,%d0 # bit offset of r.o.x sub.w %d0,%d6 # BO(p.x) - BO(r.o.x) /* amount of right rotation */ swap.w %d1 # r.o.x,,r.o.y mov.l %d1,-(%sp) # r.o mov.l %a4,-(%sp) # sm lea.l addr,%a3 jsr (%a3) mov.l %a0,%a2 # src = addr(sm,r.origin); add.l &8,%sp jmp (%a3) # %a0 = addr(dm,p); L82: mov.l &0,%d4 mov.w %d5,%d4 # 0,,mask1 swap.w %d5 # mask1,,mask2 (proper long mask; maybe 16 bits too wide) and.w %d5,%d4 # check for overlap of mask1 and mask2 beq.b L83 # no overlap ==> %d5 already correct mov.l %d4,%d5 # overlap ==> reduce %d5 by 16 bits swap.w %d5 # and put it in the proper half L83: swap.w %d7 # ,,height-1 lea.l $nrwtab(%pc,%a6.w),%a6 # -> optab tst.w %d6 # amount of right rotation bge.b L84 neg.w %d6 add.l &2,%a6 L84: add.w (%a6),%a6 jmp (%a6) nrwtab: short opMnwr-nrwtab- 0, opMnwl-nrwtab- 2 short opSnwr-nrwtab- 4, opSnwl-nrwtab- 6 short opCnwr-nrwtab- 8, opCnwl-nrwtab-10 short opXnwr-nrwtab-12, opXnwl-nrwtab-14 opMnwr: mov.l (%a2),%d0 mov.l (%a0),%d1 ror.l %d6,%d0 eor.l %d1,%d0 and.l %d5,%d0 eor.l %d1,%d0 mov.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opMnwr br ret8 opMnwl: mov.l (%a2),%d0 mov.l (%a0),%d1 rol.l %d6,%d0 eor.l %d1,%d0 and.l %d5,%d0 eor.l %d1,%d0 mov.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opMnwl br ret8 opSnwr: mov.l (%a2),%d0 ror.l %d6,%d0 and.l %d5,%d0 or.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opSnwr br ret8 opSnwl: mov.l (%a2),%d0 rol.l %d6,%d0 and.l %d5,%d0 or.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opSnwl br ret8 opCnwr: mov.l (%a2),%d0 ror.l %d6,%d0 and.l %d5,%d0 not.l %d0 and.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opCnwr br ret8 opCnwl: mov.l (%a2),%d0 rol.l %d6,%d0 and.l %d5,%d0 not.l %d0 and.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opCnwl br ret8 opXnwr: mov.l (%a2),%d0 ror.l %d6,%d0 and.l %d5,%d0 eor.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opXnwr br ret8 opXnwl: mov.l (%a2),%d0 rol.l %d6,%d0 and.l %d5,%d0 eor.l %d0,(%a0) add.w %d2,%a2 add.w %d3,%a0 dbr %d7,opXnwl br ret8 set DBR,0x51c8 set MOVLI,0x2000+074 # mov.l &..., set MOVWI,0x3000+074 # mov.w &..., set ADDWI,0x0640 # add.w &..., set FDFRAG,16 # first destination is a fragment set LDFRAG,17 # last destination is a fragment set NSHF1,18 set FD2D,19 # first destination should store 2 words set LD2D,20 # last destination should store 2 words set FSTORE,21 set DST1L,24 # dst inner count is 0 set SRC1L,25 # Nsrc is 2 set gensiz,80 widtab: mov.w %d0,(%a0)+; short 0 or.w %d0,(%a0)+; short 0 and.w %d0,(%a0)+; not.w %d0 eor.w %d0,(%a0)+; short 0 # # So far # %d7 == h-1 (bits),,w (words) # %d6 == 0,,rotate count # %d5 == mask2,,mask1 # %d4 == -RtoL # %d3.w == wdst (bytes) # %d2.w == wsrc (bytes) # %a6.w == 4*fc # %a2 -> src # %a0 -> dst # L85: lea.l $widtab(%pc,%a6.w),%a6 tst.w %d4; bpl.b L300; bset &31,%d6 L300: mov.w %d7,%d0 # inner word count bne.b L304; bset &DST1L,%d6 L304: add.w &1,%d0 # Nsrc = 1+Ninner mov.w %d0,%a1 # + ... add.w &1,%d0 # Ndst = 1+Ninner+1 add.w %d0,%d0 # magnitude of dst addressing side effects tst.l %d6; bpl.b L310 neg.w %d0; add.l &2,%a0 # RtoL L310: sub.w %d0,%d3 # compensate dst for autoincrement mov.w %d5,%d4 # mask1 swap.w %d5 # mask2 cmp.w %d4,&-1; beq.b L320; bset &FDFRAG,%d6 L320: cmp.w %d5,&-1; seq.b %d1; beq.b L330; bset &LDFRAG,%d6 L330: tst.w %d6; bne.b L360 # not NOSHIFT add.w &1,%a1 # Nsrc = 1+Ninner+1 mov.l %d6,%d0; swap.w %d0; ext.w %d0 # 0,,flag bits asr.w &1,%d7; roxl.w &1,%d0 # account for inner words odd mov.b $nstab(%pc,%d0.w),%d0 bpl.b L340; add.w &1,%d7 L340: add.b %d0,%d0 bpl.b L350; sub.w &1,%d7 L350: swap.w %d0; eor.l %d0,%d6 # the bits btst &DST1L,%d6; bne.b L355 btst &FD2D,%d6; beq.b L410 L355: ext.l %d4; bmi.b L410; swap.w %d4; not.w %d4 # NOSHIFT mask1 .l br.b L410 # NOSHIFT mask2 .l nstab: byte 0x82,0x80,0x04,0x80 # 0x80: +1 inner; 0x40: -1 inner byte 0x02,0x00,0x44,0x00 # 0x04: FD2D; 0x02: NSHF1 no first word L360: ext.w %d1; sub.w %d1,%d7 # extend inner loop mov.l &0xf,%d0 # 0 1 7 8 9 e f add.w &8,%d6 # 8 9 f 0 1 6 7 and.w %d0,%d6 sub.w &8,%d6 # 0 1 7 -8 -7 -2 -1 X=C= sign mov.w %d6,%d1; bge.b L367 # X unchanged neg.w %d1 # 8 7 2 1 X=C= 1 L367: roxl.w &1,%d1 # 0 2 e 11 f 5 3 and.w %d0,%d1 # 0 2 e 1 f 5 3 lsl.w &8,%d1 # magic position short ADDWI+001 ror.l &8,%d0 mov.w %d1,%a3 # the rotate instruction mov.l &0,%d1; not.w %d1 # 0,,-1 ror.l %d6,%d1 # where the bits are after a rotate mov.w %d1,%d0; and.w %d4,%d0; beq.b L370 # 1 src word covers dst frag not.w %d1; and.w %d4,%d1; beq.b L370 add.w &1,%a1; br.b L390 # fragment needs another src word L370: sub.w &1,%d7 # .l takes an inner word bset &FD2D,%d6 ext.l %d4; bmi.b L390 swap.w %d4; not.w %d4 # mask1 .l L390: swap.w %d1 mov.w %d1,%d0; and.w %d5,%d0; beq.b L400 # 1 src word covers dst frag not.w %d1; and.w %d5,%d1; beq.b L400 add.w &1,%a1; br.b L420 # fragment needs another src word L400: dbr %d7,L405 # .l takes an inner word clr.w %d7; br.b L420 # nothing there to take L405: L410: bset &LD2D,%d6 ext.l %d5; bmi.b L420 swap.w %d5; not.w %d5 # mask2 .l L420: tst.w NREG*4-4+fc+8(%sp); bne.b L430; bset &FSTORE,%d6 L430: mov.w %a1,%d0 # Nsrc add.w %d0,%d0 # magnitude of src addressing side effects tst.l %d6; bpl.b L431 neg.w %d0; add.l &2,%a2 # RtoL L431: sub.w %d0,%d2 # compensate src for autoincrement lea.l -gensiz(%sp),%sp mov.l %sp,%a5 swap.w %d3 swap.w %d2 cmp.w %a1,&2; bgt L445 short MOVWI+00000 mov.l (%a2)+,%d0 tst.l %d6; bpl.b L432; add.w &010,%d0 # RtoL L432: mov.w %d0,(%a5)+ mov.l &0,%d1; mov.w &-0x1000,%d2; mov.w &0100,%d3 lea.l $L438(%pc),%a1 mov.l &-1,%d0 # prepare bits to decide on "swap" tst.w %d6; bpl.b L432d; neg.w %d6 lsl.l %d6,%d0; br.b L432e L432d: lsr.l %d6,%d0 L432e: btst &DST1L,%d6; beq.b L434 bset &FD2D,%d6; bne.b L432a ext.l %d4; bmi.b L432a; swap.w %d4; not.w %d4 # mask1 .l L432a: bset &LD2D,%d6; bne.b L432b ext.l %d5; bmi.b L432b; swap.w %d5; not.w %d5 # mask2 .l L432b: and.l %d5,%d4; mov.l %d4,%d5 # single .l does it all add.l &1,%d4; beq L730 # all 32 bits sub.l &1,%d4 # need an "and" and.l %d5,%d0 cmp.l %d5,%d0 beq.b L432c short MOVWI+05300 swap.w %d0 L432c: tst.w %d6; bne L690 # and a rotate br.b L437 # NOSHIFT L434: mov.w %a3,(%a5)+ # the rotate instr short MOVWI+05300 mov.l %d0,%d1 # copy after rotate and.l %d4,%d0 cmp.l %d4,%d0 seq.b %d0; neg.b %d0; ext.w %d0 short ADDWI+000 swap.w %d0 mov.w %d0,(%a5)+ lea.l $L436(%pc),%a1 br.b L437 L436: and.w %d4,%d0 mov.w &01001,%d1; clr.w %d2; clr.w %d3 lea.l $L438(%pc),%a1 L437: br L700 L438: and.w %d5,%d0 br L545 L445: # # During compilation # %d7 == h-1,,w # %d6 == flags,,rotate count # %d5 == mask2 # %d4 == mask1 # %d3 == dst_dW,,bits for xxx.[wl] # %d2 == src_dW,,bits for mov.[wl] # %d1.w == parity # %a6 -> optab # %a5 -> next generated instruction # %a4 -> top of inner loop # %a3.w == rotate instruction # %a2 -> src # %a1 -> fragment "and" instruction # %a0 -> dst # tst.w %d6; bne.b L480 # not NOSHIFT ==> always need first word btst &NSHF1,%d6; bne.b L485 # interplay of NOSHIFT, odd, FDFRAG L480: mov.l &1,%d1 and.w %d7,%d1 # parity of inner word count lsl.w &2,%d1 # even ==> frag in %d0, odd ==> frag in %d1 bsr genwid # generate for first word and.w %d4,%d0 L485: cmp.w %d7,&2; ble.b L490 # inner dbr always falls through btst &FSTORE,%d6; beq.b L490 # no conflict "mov field" vs. %d6 short MOVWI+05300 # init inner count mov.w %a4,%d6 L490: mov.l %a5,%a4 # top of inner loop asr.w &1,%d7 # check inner word count blt.b L540 # single .l does it all bcc.b L500 # even beq.b L520 # 1 short MOVWI+05300 br.b L500 # jump into middle of inner loop add.l &1,%a4 # remember to fixup "br.b" add.w &1,%d7 # middle entry ==> no dbr offset L500: beq.b L530 # no inner words at all mov.l &4,%d1 # use %d1 in bsr.b genwid # even half of inner loop short 0 L510: mov.w %a4,%d0; neg.w %d0 bclr &0,%d0; beq.b L520 add.w %a5,%d0; mov.b %d0,(%a4)+ # fixup "br.b" into middle L520: mov.l &0,%d1 # use %d0 in bsr.b genwid # odd half of inner loop short 0 sub.w &1,%d7 # offset for inner dbr loop ble.b L530 # dbr always falls through mov.w &DBR+6,(%a5)+ sub.l %a5,%a4; mov.w %a4,(%a5)+ # dbr displacement L530: btst &LDFRAG,%d6; beq.b L540 # omit "and" for full last word mov.l &4,%d1 bsr.b genwid and.w %d5,%d0 L540: tst.w %d7; ble.b L545 # no inner loop btst &FSTORE,%d6; bne.b L545 # possible conflict "mov field" vs. %d6 short MOVWI+05300 # init inner count mov.w %a4,%d6 L545: swap.w %d3; tst.w %d3; beq.b L546 # wdst is full width of bitmap mov.w %d3,%a1 # dst_dW short MOVWI+05300 add.w %a1,%a0 L546: swap.w %d2; tst.w %d2; beq.b L547 # wsrc is full width of bitmap mov.w %d2,%a3 # src_dW short MOVWI+05300 add.w %a3,%a2 L547: mov.w &DBR+7,(%a5)+ mov.l %sp,%a4 # top of outer loop cmp.b (%a4),&0x60; bne.b L548 # not br.b mov.b 1(%a4),%d0; ext.w %d0; lea.l 2(%a4,%d0.w),%a4 # collapse branches L548: sub.l %a5,%a4; mov.w %a4,(%a5)+ # dbr displacement short MOVWI+05300 jmp (%a5) mov.w %d7,%a4 # init inner count mov.w %d7,%d6 # init inner count, 2nd case swap.w %d7 # h-1 lea.l $retgen(%pc),%a5 jmp (%sp) genwid: mov.l (%sp)+,%a1 # -> inline parameter mov.l $genget(%pc,%d1.w),%d0 tst.w %d1; beq.b L550; mov.w &01001,%d1; swap.w %d1 # parity bits L550: clr.w %d2; clr.w %d3 # .[wl] bits default to .w tst.l %d6; bpl.b L560; add.w &010,%d0 # RtoL L560: tst.w %d6; bne.b L569 # not NOSHIFT bclr &9,%d0 # NOSHIFT always %d0 mov.w (%a1),%d1; bne.b L564 # not inner loop btst &FSTORE,%d6; beq.b L562 # not "mov" mov.l &070,%d1; and.w %d0,%d1 lsl.w &3,%d1; or.w %d1,%d0 # copy RtoL mode add.w &-0x1000,%d0 # .w ==> .l mov.w %d0,(%a5)+ L561: jmp 2(%a1) genget: swap.w %d0; mov.w (%a2)+,%d0 swap.w %d1; mov.w (%a2)+,%d1 L562: mov.w &-0x1000,%d2; mov.w &0100,%d3 # .w +=> .l add.w %d2,%d0 L563: mov.l &0,%d1 # NOSHIFT always %d0 br L698 # assemble the fetch, then do the op L564: lsr.w &1,%d1; bcs.b L562 # NOSHIFT always LD2D btst &FD2D,%d6; bne.b L562 br.b L563 # alas, .w L569: mov.w (%a1),%d1; beq.b L630 # inner loop L570: lsr.w &1,%d1; bcs.b L580 # last word add.w &-0x1000,%d0 # force fetch .l mov.w %d0,(%a5)+ # the fetch .l short MOVLI+00000 mov.l %d0,%d1 swap.w %d0 clr.w %d1; eor.l %d1,%d0 # parity for mov.l %d[01],%d[10] tst.l %d1; sne.b %d1; sub.b %d1,%d0 # parity for swap.w %d[01] mov.l %d0,(%a5) # ran out of registers mov.l &0x4c80ec,%d0 # microcoded bits tst.l %d6; bpl.b L572; ror.l &1,%d0 # RtoL L572: tst.w %d6; bpl.b L574; ror.l &2,%d0 # rol L574: btst &FD2D,%d6; beq.b L576; ror.l &4,%d0 # first op .l mov.w &-0x1000,%d2; mov.w &0100,%d3 # .w +=> .l corrections L576: ror.l &1,%d0; bpl.b L578 # "swap" not needed add.l &2,%a5 ror.l &8,%d0; bpl.b L577 # existing "swap" parity OK eor.w &1,(%a5) L577: ror.l &8,%d0; bpl.b L578 # existing order OK sub.l &2,%a5 mov.l (%a5),%d0; swap.w %d0; mov.l %d0,(%a5) add.l &2,%a5 L578: add.l &2,%a5 swap.w %d1 # junk,,parity br.b L690 L580: btst &LD2D,%d6; beq.b L630 # operator .w mov.w &-0x1000,%d2 # mov.w +=> mov.l mov.w &0100,%d3 # xxx.w +=> xxx.l L630: tst.l %d6; smi.b %d1 eor.b %d6,%d1; bpl.b L650 # rotation in same direction as scan swap.w %d0 # interchange "swap" and "mov" L650: mov.l %d0,(%a5)+ swap.w %d1 # junk,,parity mov.w (%a1),%d0; lsr.w &1,%d0; bcs.b L660 # last word short MOVWI+000 mov.l %d0,%d1 eor.w %d1,%d0 mov.w %d0,(%a5)+ br.b L690 L660: tst.l %d6; bmi.b L690 # RtoL btst &LD2D,%d6; beq.b L690 # not .l tst.w %d6; bpl.b L670 # ror sub.l &2,%a5; br.b L690 # no "swap" L670: mov.w -4(%a5),(%a5)+ # extra "swap" L690: mov.w %a3,%d0 eor.b %d1,%d0 L698: mov.w %d0,(%a5)+ # the rotate instruction L700: mov.w (%a1),%d0; beq.b L730 # inner loop btst &0,%d0; bne.b L705 # last word btst &FDFRAG,%d6; beq.b L730 # no "and" L705: add.w %d3,%d0; add.w %d1,%d0; sub.b %d1,%d0 # and.[wl] %d[45],%d[01] btst &FSTORE,%d6; beq.b L720 # "mov" partial word swap.w %d0 # save the "and" short MOVWI+00000 # ,%d0 mov.w (%a0),%d6 add.w %d2,%d0 # mov.[wl] tst.l %d6; bpl.b L710; add.w &020,%d0 # RtoL; "(%a0)" ==> "-(%a0)" L710: mov.w %d0,(%a5)+ # instr to fetch memory part of word short MOVWI+00000 # ,%d0 eor.w %d6,%d0 add.w %d3,%d0; add.b %d1,%d0 # eor.[wl] %d6,%d[01] swap.w %d0; mov.l %d0,(%a5)+; swap.w %d0; mov.w %d0,(%a5)+ mov.w %d2,%d0; add.b %d1,%d0 # mov.[wl] %d[01], mov.l &-0100,%d1 # RtoL correction, if necessary br.b L770 L720: mov.w %d0,(%a5)+ # "and" for non-mov operators L730: mov.w 2(%a6),%d0; beq.b L740 # not F_CLR add.w %d3,%d0; add.b %d1,%d0 # not.[wl] %d[01] mov.w %d0,(%a5)+ L740: btst &FSTORE,%d6; beq.b L790 # non-"mov" mov.w %d2,%d0; add.b %d1,%d0 # mov.[wl] %d[01], mov.l &0100,%d1 # RtoL correction, if necessary L770: add.w (%a6),%d0 tst.l %d6; bpl.b L780 add.w %d1,%d0 # RtoL correction L780: mov.w %d0,(%a5)+ jmp 2(%a1) L790: mov.w %d1,%d0; clr.b %d0; add.w %d3,%d0 # xxx.[wl] %d[01] mov.l &010,%d1 # RtoL correction, if necessary br.b L770 # # During execution # %d[01] == rotator # %d2 [reserved for texture bits] # %d3 [reserved for texture index] # %d4 == mask1 # %d5 == mask2 # %d6.w == inner count # %d7.w == outer count # %a0 -> dst # %a1 == dst_dW # %a2 -> src # %a3 == src_dW # %a4.w == inner count init # %a5 -> retgen # %a6 [reserved for -> texture] # -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sun Apr 3 21:22:17 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 3 Apr 2022 13:22:17 +0200 Subject: [TUHS] A Reiser tour de force Message-ID: <7521B7CB-E1C7-44C2-BBF4-A97F63082545@planet.nl> >> A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c >> It appears to be a pre-Reiser bitblt, not what was asked for. > > > The Reiser code is in the V8 jerq tarball that Dan Cross donated: > v8jerq.tar.bz2 > > It is in file blit/src/libj/bitblt.s (attached below for convenience). It is 750 lines of 68K assembler. It does not appear to have been ported to the Bellmac 32 CPU. Maybe it did not make sense in that context. > > Paul There also is a file “bitblt.C” in that same directory (dated May 82, versus Aug 82 for the assembler file) that seems to have a similar approach coded up in C, with a big switch where each case has a lot of “asm()” statements. It is about 400 lines long. No author is mentioned. I have not investigated deeply, but at first glance it is possible that the approach was first coded up as a kind of threaded code in C (with inline asm) and later that Summer redone as fully hand coded assembler. Just a guess. Paul ==== #include #define LEFTDIR 8 #define NOSHIFT 4 #define DAMMIT 4 /* you'll see why */ #undef sw bitblt(sm,r,dm,p,fc) Bitmap *sm,*dm; Rectangle r; Point p; int fc; { register Word *source,*dest,*_source,*_dest; /* %a2-%a5 */ register UWord m,mask1,mask2; /* %d2,%d3,%d4 */ register int a,b,i; /* %d5,%d6,%d7 */ int j,h,w,dx1,sw,dw; /* clip to the destination Bitmap only */ #define rp dest #define pp source rp = (int *) &(dm->rect); pp = (int *) &p; if ((a = *rp++ - *pp++) > 0) { *(pp-1) += a; r.origin.x += a; } if ((a = *rp++ - *pp) > 0) { *pp += a; r.origin.y += a; } if ((a = r.origin.x + *rp++ - *(pp-1)) < r.corner.x) r.corner.x = a; if ((a = r.origin.y + *rp - *pp) < r.corner.y) r.corner.y = a; i = r.corner.y - r.origin.y; /* going to be h */ a = r.corner.x - r.origin.x - 1; /* going to be dx1 */ if (i <= 0 || a < 0) return; if (a < 16) goto narrow; h = i; dx1 = a; /* i and b are regs, avoid work! */ sw = sm->width << 1; /* sleazy hack to avoid shift */ dw = dm->width << 1; /* in outer, inner loops */ w = ((p.x+dx1) >> 4) - (p.x >> 4) - 1; /* inner loop */ mask1 = ~topbits[p.x & 15]; mask2 = topbits[((p.x+dx1) & 15) + 1]; if (sm == dm) { /* may have to mess with loop order */ if (r.origin.y < p.y) { /* swap top with bottom */ r.origin.y += h-1; p.y += h-1; sw = -sw; dw = -dw; } if (r.origin.x < p.x) { /* swap left with right */ fc |= LEFTDIR; r.origin.x += dx1; p.x += dx1; } } _dest = addr(dm,p); _source = addr(sm,r.origin); a = (p.x&15) - (r.origin.x&15); if (a < 0) a += 16; else /* a == 0 means no shift, remember that */ _source--; /* else grab long and shift right */ b = 16 - a; if (a == 0) fc |= NOSHIFT; source = _source; dest = _dest; switch (fc) { case F_STORE | NOSHIFT: b = w; _source++; source = _source; a = h; /* a is free => use it */ do { *dest++ = (~mask1 & *dest) | (mask1 & *source++); if ((i = b>>2) > 0) do { *((long *)dest)++ = *((long *)source)++; *((long *)dest)++ = *((long *)source)++; } while (--i > 0); if ((i = b&3) > 0) do { *dest++ = *source++; } while (--i > 0); *dest = (~mask2 & *dest) | (mask2 & *source); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_STORE: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ = (~mask1 & *dest) | (mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); *dest++ = m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest = (~mask2 & *dest) | (mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_STORE | NOSHIFT | LEFTDIR: b = w; _source++; source = _source; a = h; do { *dest = (~mask2 & *dest) | (mask2 & *source); if ((i = b>>2) > 0) do { *--((long *)dest) = *--((long *)source); *--((long *)dest) = *--((long *)source); } while (--i > 0); if ((i = b&3) > 0) do { *(--dest) = *(--source); } while (--i > 0); dest--; *dest = (~mask1 & *dest) | (mask1 & *(--source)); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_STORE | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest = (~mask2 & *dest) | (mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); *(--dest) = m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest = (~mask1 & *dest) | (mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_OR: case F_OR | NOSHIFT: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ |= (mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); *dest++ |= m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest |= (mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_OR | LEFTDIR: case F_OR | NOSHIFT | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest |= (mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); *(--dest) |= m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest |= (mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_CLR: case F_CLR | NOSHIFT: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ &= ~(mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); asm(" not.w %d2 # m = ~m"); *dest++ &= m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest &= ~(mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_CLR | LEFTDIR: case F_CLR | NOSHIFT | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest &= ~(mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); asm(" not.w %d2 # m = ~m"); *(--dest) &= m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest &= ~(mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_XOR | NOSHIFT: b = w; _source++; source = _source; a = h; do { *dest++ ^= (mask1 & *source++); if ((i = b>>2) > 0) do { *((long *)dest)++ ^= *((long *)source)++; *((long *)dest)++ ^= *((long *)source)++; } while (--i > 0); if ((i = b&3) > 0) do { *dest++ ^= *source++; } while (--i > 0); *dest ^= (mask2 & *source); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_XOR: default: do { asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); asm(" ror.l %d5,%d2 # rotate m right by a"); *dest++ ^= (mask1 & m); asm(" ror.l %d6,%d2 # rotate m right by b"); if ((i = w) > 0) do { m = *source++; asm(" ror.l %d5,%d2 # m >> a"); *dest++ ^= m; asm(" ror.l %d6,%d2 # m >> b"); } while (--i > 0); m = *source; asm(" ror.l %d5,%d2 # m >> a"); *dest ^= (mask2 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; case F_XOR | NOSHIFT | LEFTDIR: b = w; _source++; source = _source; a = h; do { *dest ^= (mask2 & *source); if ((i = b>>2) > 0) do { *--((long *)dest) ^= *--((long *)source); *--((long *)dest) ^= *--((long *)source); } while (--i > 0); if ((i = b&3) > 0) do { *(--dest) ^= *(--source); } while (--i > 0); dest--; *dest ^= (mask1 & *(--source)); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--a > 0); break; case F_XOR | LEFTDIR: do { asm(" mov.l (%a2),%d2 # (long) m = *source"); asm(" ror.l %d5,%d2 # m >> a"); *dest ^= (mask2 & m); asm(" rol.l %d5,%d2 # m << a"); if ((i = w) > 0) do { m = *(--source); asm(" rol.l %d6,%d2 # m << b"); *(--dest) ^= m; asm(" rol.l %d5,%d2 # m << a"); } while (--i > 0); m = *(--source); asm(" rol.l %d6,%d2 # m << b"); dest--; *dest ^= (mask1 & m); (char *) _source += sw; source = _source; (char *) _dest += dw; dest = _dest; } while (--h > 0); break; } return; narrow: /* * width is 16 bits or less, so we can do it by reading and * writing 32 bits at a time */ _source = (Word *) sm; _dest = (Word *) dm; mask1 = ((Bitmap *) _source)->width; /* source increment */ mask1 <<= 1; /* hack to add to an address register */ mask2 = ((Bitmap *) _dest)->width; /* dest increment */ mask2 <<= 1; if (_source == _dest && r.origin.y < p.y) { /* swap top with bottom */ r.origin.y += i-1; p.y += i-1; mask1 = -mask1; mask2 = -mask2; } asm(" mov &0,%d6 # (long) b = 0"); b = topbits[a+1]; a = (16 - (p.x & 15)); /* hocus pocus to get long mask */ asm(" rol.l %d5,%d6 # (long) b <<= a"); a = 16 - a - (r.origin.x & 15); /* shift constant */ if (a < 0) { /* guess what! -1 == 63 to the 68000!!! */ fc |= DAMMIT; /* not fatal, just slow */ } source = addr(_source,r.origin); dest = addr(_dest,p); switch (fc) { case F_STORE: case F_STORE | DAMMIT: asm(" mov.l %d6,%d1 # prepare inverse mask"); asm(" not.l %d1 "); do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" mov.l (%a3),%d0 # m |= *dest&~b"); asm(" and.l %d1,%d0 "); asm(" or.l %d0,%d2 "); asm(" mov.l %d2,(%a3) # *dest = m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_OR: case F_OR | DAMMIT: do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" or.l %d2,(%a3) # *dest |= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_CLR: case F_CLR | DAMMIT: do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" not.l %d2 # m = ^m"); asm(" and.l %d2,(%a3) # *dest &= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_XOR: do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" ror.l %d5,%d2 # rotate m right by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" eor.l %d2,(%a3) # *dest ^= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; case F_XOR | DAMMIT: a = -a; do { asm(" mov.l (%a2),%d2 # m = *source"); asm(" rol.l %d5,%d2 # rotate m left by a"); asm(" and.l %d6,%d2 # m &= b"); asm(" eor.l %d2,(%a3) # *dest ^= m"); (char *) source += (int) mask1; (char *) dest += (int) mask2; } while (--i > 0); break; } return; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Apr 3 22:24:46 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 3 Apr 2022 22:24:46 +1000 Subject: [TUHS] A Reiser tour de force In-Reply-To: <7521B7CB-E1C7-44C2-BBF4-A97F63082545@planet.nl> References: <7521B7CB-E1C7-44C2-BBF4-A97F63082545@planet.nl> Message-ID: That is not Reiser's implementation. It's not even a compiling implementation, it's just some loops. I think that's one of Bart's. Reiser's was just assembly language, in a single file, not pseudo-C. I went looking around github but couldn't find it. I've got some feelers out. -rob On Sun, Apr 3, 2022 at 9:25 PM Paul Ruizendaal via TUHS wrote: > > A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c > It appears to be a pre-Reiser bitblt, not what was asked for. > > > The Reiser code is in the V8 jerq tarball that Dan Cross donated: > v8jerq.tar.bz2 > > It is in file blit/src/libj/bitblt.s (attached below for convenience). It is 750 lines of 68K assembler. It does not appear to have been ported to the Bellmac 32 CPU. Maybe it did not make sense in that context. > > Paul > > > There also is a file “bitblt.C” in that same directory (dated May 82, versus Aug 82 for the assembler file) that seems to have a similar approach coded up in C, with a big switch where each case has a lot of “asm()” statements. It is about 400 lines long. No author is mentioned. > > I have not investigated deeply, but at first glance it is possible that the approach was first coded up as a kind of threaded code in C (with inline asm) and later that Summer redone as fully hand coded assembler. Just a guess. > > Paul > > ==== > > #include > #define LEFTDIR 8 > #define NOSHIFT 4 > #define DAMMIT 4 /* you'll see why */ > #undef sw > > bitblt(sm,r,dm,p,fc) > Bitmap *sm,*dm; > Rectangle r; > Point p; > int fc; > { > register Word *source,*dest,*_source,*_dest; /* %a2-%a5 */ > register UWord m,mask1,mask2; /* %d2,%d3,%d4 */ > register int a,b,i; /* %d5,%d6,%d7 */ > > int j,h,w,dx1,sw,dw; > > /* clip to the destination Bitmap only */ > #define rp dest > #define pp source > rp = (int *) &(dm->rect); > pp = (int *) &p; > if ((a = *rp++ - *pp++) > 0) { > *(pp-1) += a; > r.origin.x += a; > } > if ((a = *rp++ - *pp) > 0) { > *pp += a; > r.origin.y += a; > } > if ((a = r.origin.x + *rp++ - *(pp-1)) < r.corner.x) > r.corner.x = a; > if ((a = r.origin.y + *rp - *pp) < r.corner.y) > r.corner.y = a; > i = r.corner.y - r.origin.y; /* going to be h */ > a = r.corner.x - r.origin.x - 1; /* going to be dx1 */ > if (i <= 0 || a < 0) > return; > if (a < 16) > goto narrow; > h = i; > dx1 = a; /* i and b are regs, avoid work! */ > sw = sm->width << 1; /* sleazy hack to avoid shift */ > dw = dm->width << 1; /* in outer, inner loops */ > w = ((p.x+dx1) >> 4) - (p.x >> 4) - 1; /* inner loop */ > mask1 = ~topbits[p.x & 15]; > mask2 = topbits[((p.x+dx1) & 15) + 1]; > if (sm == dm) { /* may have to mess with loop order */ > if (r.origin.y < p.y) { /* swap top with bottom */ > r.origin.y += h-1; > p.y += h-1; > sw = -sw; > dw = -dw; > } > if (r.origin.x < p.x) { /* swap left with right */ > fc |= LEFTDIR; > r.origin.x += dx1; > p.x += dx1; > } > } > _dest = addr(dm,p); > _source = addr(sm,r.origin); > a = (p.x&15) - (r.origin.x&15); > if (a < 0) > a += 16; > else /* a == 0 means no shift, remember that */ > _source--; /* else grab long and shift right */ > b = 16 - a; > if (a == 0) > fc |= NOSHIFT; > source = _source; > dest = _dest; > switch (fc) { > case F_STORE | NOSHIFT: > b = w; > _source++; > source = _source; > a = h; /* a is free => use it */ > do { > *dest++ = (~mask1 & *dest) | (mask1 & *source++); > if ((i = b>>2) > 0) do { > *((long *)dest)++ = *((long *)source)++; > *((long *)dest)++ = *((long *)source)++; > } while (--i > 0); > if ((i = b&3) > 0) do { > *dest++ = *source++; > } while (--i > 0); > *dest = (~mask2 & *dest) | (mask2 & *source); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--a > 0); > break; > case F_STORE: > do { > asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > *dest++ = (~mask1 & *dest) | (mask1 & m); > asm(" ror.l %d6,%d2 # rotate m right by b"); > if ((i = w) > 0) do { > m = *source++; > asm(" ror.l %d5,%d2 # m >> a"); > *dest++ = m; > asm(" ror.l %d6,%d2 # m >> b"); > } while (--i > 0); > m = *source; > asm(" ror.l %d5,%d2 # m >> a"); > *dest = (~mask2 & *dest) | (mask2 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_STORE | NOSHIFT | LEFTDIR: > b = w; > _source++; > source = _source; > a = h; > do { > *dest = (~mask2 & *dest) | (mask2 & *source); > if ((i = b>>2) > 0) do { > *--((long *)dest) = *--((long *)source); > *--((long *)dest) = *--((long *)source); > } while (--i > 0); > if ((i = b&3) > 0) do { > *(--dest) = *(--source); > } while (--i > 0); > dest--; > *dest = (~mask1 & *dest) | (mask1 & *(--source)); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--a > 0); > break; > case F_STORE | LEFTDIR: > do { > asm(" mov.l (%a2),%d2 # (long) m = *source"); > asm(" ror.l %d5,%d2 # m >> a"); > *dest = (~mask2 & *dest) | (mask2 & m); > asm(" rol.l %d5,%d2 # m << a"); > if ((i = w) > 0) do { > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > *(--dest) = m; > asm(" rol.l %d5,%d2 # m << a"); > } while (--i > 0); > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > dest--; > *dest = (~mask1 & *dest) | (mask1 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_OR: > case F_OR | NOSHIFT: > do { > asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > *dest++ |= (mask1 & m); > asm(" ror.l %d6,%d2 # rotate m right by b"); > if ((i = w) > 0) do { > m = *source++; > asm(" ror.l %d5,%d2 # m >> a"); > *dest++ |= m; > asm(" ror.l %d6,%d2 # m >> b"); > } while (--i > 0); > m = *source; > asm(" ror.l %d5,%d2 # m >> a"); > *dest |= (mask2 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_OR | LEFTDIR: > case F_OR | NOSHIFT | LEFTDIR: > do { > asm(" mov.l (%a2),%d2 # (long) m = *source"); > asm(" ror.l %d5,%d2 # m >> a"); > *dest |= (mask2 & m); > asm(" rol.l %d5,%d2 # m << a"); > if ((i = w) > 0) do { > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > *(--dest) |= m; > asm(" rol.l %d5,%d2 # m << a"); > } while (--i > 0); > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > dest--; > *dest |= (mask1 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_CLR: > case F_CLR | NOSHIFT: > do { > asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > *dest++ &= ~(mask1 & m); > asm(" ror.l %d6,%d2 # rotate m right by b"); > if ((i = w) > 0) do { > m = *source++; > asm(" ror.l %d5,%d2 # m >> a"); > asm(" not.w %d2 # m = ~m"); > *dest++ &= m; > asm(" ror.l %d6,%d2 # m >> b"); > } while (--i > 0); > m = *source; > asm(" ror.l %d5,%d2 # m >> a"); > *dest &= ~(mask2 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_CLR | LEFTDIR: > case F_CLR | NOSHIFT | LEFTDIR: > do { > asm(" mov.l (%a2),%d2 # (long) m = *source"); > asm(" ror.l %d5,%d2 # m >> a"); > *dest &= ~(mask2 & m); > asm(" rol.l %d5,%d2 # m << a"); > if ((i = w) > 0) do { > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > asm(" not.w %d2 # m = ~m"); > *(--dest) &= m; > asm(" rol.l %d5,%d2 # m << a"); > } while (--i > 0); > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > dest--; > *dest &= ~(mask1 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_XOR | NOSHIFT: > b = w; > _source++; > source = _source; > a = h; > do { > *dest++ ^= (mask1 & *source++); > if ((i = b>>2) > 0) do { > *((long *)dest)++ ^= *((long *)source)++; > *((long *)dest)++ ^= *((long *)source)++; > } while (--i > 0); > if ((i = b&3) > 0) do { > *dest++ ^= *source++; > } while (--i > 0); > *dest ^= (mask2 & *source); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--a > 0); > break; > case F_XOR: > default: > do { > asm(" mov.l (%a2)+,%d2 # (long) m = *source++"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > *dest++ ^= (mask1 & m); > asm(" ror.l %d6,%d2 # rotate m right by b"); > if ((i = w) > 0) do { > m = *source++; > asm(" ror.l %d5,%d2 # m >> a"); > *dest++ ^= m; > asm(" ror.l %d6,%d2 # m >> b"); > } while (--i > 0); > m = *source; > asm(" ror.l %d5,%d2 # m >> a"); > *dest ^= (mask2 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > case F_XOR | NOSHIFT | LEFTDIR: > b = w; > _source++; > source = _source; > a = h; > do { > *dest ^= (mask2 & *source); > if ((i = b>>2) > 0) do { > *--((long *)dest) ^= *--((long *)source); > *--((long *)dest) ^= *--((long *)source); > } while (--i > 0); > if ((i = b&3) > 0) do { > *(--dest) ^= *(--source); > } while (--i > 0); > dest--; > *dest ^= (mask1 & *(--source)); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--a > 0); > break; > case F_XOR | LEFTDIR: > do { > asm(" mov.l (%a2),%d2 # (long) m = *source"); > asm(" ror.l %d5,%d2 # m >> a"); > *dest ^= (mask2 & m); > asm(" rol.l %d5,%d2 # m << a"); > if ((i = w) > 0) do { > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > *(--dest) ^= m; > asm(" rol.l %d5,%d2 # m << a"); > } while (--i > 0); > m = *(--source); > asm(" rol.l %d6,%d2 # m << b"); > dest--; > *dest ^= (mask1 & m); > (char *) _source += sw; > source = _source; > (char *) _dest += dw; > dest = _dest; > } while (--h > 0); > break; > } > return; > narrow: > /* > * width is 16 bits or less, so we can do it by reading and > * writing 32 bits at a time > */ > _source = (Word *) sm; > _dest = (Word *) dm; > mask1 = ((Bitmap *) _source)->width; /* source increment */ > mask1 <<= 1; /* hack to add to an address register */ > mask2 = ((Bitmap *) _dest)->width; /* dest increment */ > mask2 <<= 1; > if (_source == _dest && r.origin.y < p.y) { /* swap top with bottom */ > r.origin.y += i-1; > p.y += i-1; > mask1 = -mask1; > mask2 = -mask2; > } > asm(" mov &0,%d6 # (long) b = 0"); > b = topbits[a+1]; > a = (16 - (p.x & 15)); /* hocus pocus to get long mask */ > asm(" rol.l %d5,%d6 # (long) b <<= a"); > a = 16 - a - (r.origin.x & 15); /* shift constant */ > if (a < 0) { /* guess what! -1 == 63 to the 68000!!! */ > fc |= DAMMIT; /* not fatal, just slow */ > } > source = addr(_source,r.origin); > dest = addr(_dest,p); > switch (fc) { > case F_STORE: > case F_STORE | DAMMIT: > asm(" mov.l %d6,%d1 # prepare inverse mask"); > asm(" not.l %d1 "); > do { > asm(" mov.l (%a2),%d2 # m = *source"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > asm(" and.l %d6,%d2 # m &= b"); > asm(" mov.l (%a3),%d0 # m |= *dest&~b"); > asm(" and.l %d1,%d0 "); > asm(" or.l %d0,%d2 "); > asm(" mov.l %d2,(%a3) # *dest = m"); > (char *) source += (int) mask1; > (char *) dest += (int) mask2; > } while (--i > 0); > break; > case F_OR: > case F_OR | DAMMIT: > do { > asm(" mov.l (%a2),%d2 # m = *source"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > asm(" and.l %d6,%d2 # m &= b"); > asm(" or.l %d2,(%a3) # *dest |= m"); > (char *) source += (int) mask1; > (char *) dest += (int) mask2; > } while (--i > 0); > break; > case F_CLR: > case F_CLR | DAMMIT: > do { > asm(" mov.l (%a2),%d2 # m = *source"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > asm(" and.l %d6,%d2 # m &= b"); > asm(" not.l %d2 # m = ^m"); > asm(" and.l %d2,(%a3) # *dest &= m"); > (char *) source += (int) mask1; > (char *) dest += (int) mask2; > } while (--i > 0); > break; > case F_XOR: > do { > asm(" mov.l (%a2),%d2 # m = *source"); > asm(" ror.l %d5,%d2 # rotate m right by a"); > asm(" and.l %d6,%d2 # m &= b"); > asm(" eor.l %d2,(%a3) # *dest ^= m"); > (char *) source += (int) mask1; > (char *) dest += (int) mask2; > } while (--i > 0); > break; > case F_XOR | DAMMIT: > a = -a; > do { > asm(" mov.l (%a2),%d2 # m = *source"); > asm(" rol.l %d5,%d2 # rotate m left by a"); > asm(" and.l %d6,%d2 # m &= b"); > asm(" eor.l %d2,(%a3) # *dest ^= m"); > (char *) source += (int) mask1; > (char *) dest += (int) mask2; > } while (--i > 0); > break; > } > return; > } > From robpike at gmail.com Sun Apr 3 22:26:07 2022 From: robpike at gmail.com (Rob Pike) Date: Sun, 3 Apr 2022 22:26:07 +1000 Subject: [TUHS] A Reiser tour do force In-Reply-To: References: Message-ID: Ah, yes, that's the one. -rob On Sun, Apr 3, 2022 at 9:03 PM Paul Ruizendaal via TUHS wrote: > > A not-very-thorough search at tuhs turned up V9/jerq/src/lib/j/bitblt.c > It appears to be a pre-Reiser bitblt, not what was asked for. > > > The Reiser code is in the V8 jerq tarball that Dan Cross donated: > v8jerq.tar.bz2 > > It is in file blit/src/libj/bitblt.s (attached below for convenience). It is 750 lines of 68K assembler. It does not appear to have been ported to the Bellmac 32 CPU. Maybe it did not make sense in that context. > > Paul > > ===== > > # > # bitblt(sm,r,dm,p,fc) > # Bitmap *sm,*dm; > # Rectangle r; > # Point p; > # int fc; > # > # by John F. Reiser summer 1982 > # > # Depending on the case at hand, generate very good code and execute it. > # > > # offsets in a Point > set x,0 > set y,2 > # offsets in a Rectangle > set origin,0 > set corner,4 > # offsets in a Bitmap > set base,0 > set width,4 > set rect,6 > # parameter offsets from %fp > set sm,8 > set r,12 > set dm,20 > set p,24 > set fc,28 > > set NREG,11 > > global bitblt > bitblt: > movm.l &0x3f3e,-(%sp) # save C registers > movm.l NREG*4-4+sm(%sp),&0x001f > # d1=r.o.x,,r.o.y; d2=r.c.x,,r.c.y; d4=p.x,,p.y; > mov.l %d0,%a4 # sm > mov.l %d3,%a5 # dm > mov.w NREG*4-4+fc(%sp),%a6 # a6.w == fc > movm.l rect(%a4),&0x9 # d0=sm.o.x,,sm.o.y; d3=sm.c.x,,sm.c.y; > movm.l rect(%a5),&0x60 # d5=dm.o.x,,dm.o.y; d6=dm.c.x,,dm.c.y; > > lea.l $L50(%pc),%a0 > L5: > # clip r.y to sm.y > mov.w %d0,%d7 # sm.o.y > sub.w %d1,%d7 # - r.o.y > ble.b L10 > mov.w %d0,%d1 # r.o.y = sm.o.y; /* r.o.y was above sm.rect */ > add.w %d7,%d4 # p.y parallels r.o.y > L10: > cmp.w %d2,%d3 # r.c.y : sm.c.y > ble.b L20 > mov.w %d3,%d2 # r.c.y = sm.c.y; /* bottom of r was below sm.rect */ > L20: > # clip (r.y at p.y) to dm.y > mov.w %d5,%d7 # dm.o.y > sub.w %d4,%d7 # -p.y > ble.b L30 > mov.w %d5,%d4 # p.y = dm.o.y; /* p.y was above dm.rect */ > add.w %d7,%d1 # r.o.y parallels p.y > L30: > mov.w %d1,%d7 # r.o.y > add.w %d6,%d7 # + dm.c.y > sub.w %d4,%d7 # - p.y /* == max y that dm.rect allows in r */ > cmp.w %d2,%d7 # r.c.y : limit > ble.b L40 > mov.w %d7,%d2 # r.c.y = limit > L40: > mov.w %d2,%d7 # r.c.y > sub.w %d1,%d7 # - r.o.y > sub.w &1,%d7 # /* == h-1 in bits */ > blt.b ret > jmp (%a0) > > retgen: > lea.l gensiz(%sp),%sp > ret8: > add.l &8,%sp > ret: > movm.l (%sp)+,&0x7cfc > rts > > L50: > # mirror in pi/4 and reuse same code to clip x > swap.w %d0; swap.w %d1; swap.w %d2; swap.w %d3 > swap.w %d4; swap.w %d5; swap.w %d6; swap.w %d7 > lea.l $L55(%pc),%a0 > br.b L5 > > L55: > mov.l %d1,%a1 > mov.l %d4,%d6 > # > # So far > # %d7 == h-1,,w-1 > # %d6 == p.y,,p.x > # %a6.w == fc > # %a5 == dm > # %a4 == sm > # %a1 == r.o.y,,r.o.x > # > # Compute masks, and width in words > # > mov.w %d6,%d0 # p.x /* left endpoint of dst */ > mov.w %d7,%d1 # w-1 > add.w %d6,%d1 # right endpoint > > mov.l &-1,%d3 > mov.l &15,%d2 > and.w %d0,%d2 > lsr.w %d2,%d3 # mask1 > mov.l &-1,%d5 > mov.l &15,%d2 > and.w %d1,%d2 > add.w &1,%d2 > lsr.w %d2,%d5 > not.w %d5 # mask2 > swap.w %d5 > mov.w %d3,%d5 # mask2,,mask1 > > asr.w &4,%d0 > asr.w &4,%d1 > sub.w %d0,%d1 > sub.w &1,%d1 # inner-loop width in words > > mov.l &0,%d4 # assume LtoR > mov.w width(%a5),%d3 > add.w %d3,%d3 > mov.w width(%a4),%d2 > add.w %d2,%d2 > # > # So far > # %d7 == h-1,,w-1 in bits > # %d6 == p.y,,p.x > # %d5 == mask2,,mask1 > # %d4 == 0 (LtoR) > # %d3.w == dm width in bytes > # %d2.w == sm width in bytes > # %d1.w == inner-loop width in words > # %a6.w == fc > # %a5 == dm > # %a4 == sm > # %a1 == r.o.y,,r.o.x > # > # If necessary, compensate for overlap of source and destination > # > cmp.l %a4,%a5 > bne.b L80 # overlap not possible > mov.l %d6,%d0 # p.y,,p.x > mov.w %a1,%d0 # p.y,,r.o.x > cmp.l %a1,%d0 # r.o.y : p.y > bge.b L60 # if (r.o.y < p.y) > mov.l %d7,%d0 # h-1,,w-1 > clr.w %d0 # h-1,,0 > add.l %d0,%a1 # r.o.y += h-1; > add.l %d0,%d6 # p.y += h-1; > neg.w %d3 # wdst = -wdst; > neg.w %d2 # wsrc = -wsrc; > L60: > cmp.w %d7,&16 > blt.b L70 # l<->r swap not needed for narrow > cmp.w %d6,%a1 # p.x : r.o.x > ble.b L70 # if (r.o.x < p.x) > mov.l %a1,%d0 > add.w %d7,%d0 > mov.l %d0,%a1 # r.o.x += w-1; > add.w %d7,%d6 # p.x += w-1; > mov.l &-1,%d4 # RtoL > swap.w %d5 # masks in other order > L70: > L80: > # > # Locate actual starting points > # > mov.l %d6,%d0 # p.y,,p.x > swap.w %d0 > mov.l %d0,-(%sp) # p > mov.l %a5,-(%sp) # dm > > mov.l &15,%d0 > lea.l $L82(%pc),%a0 # assume narrow > cmp.w %d7,%d0 # w-1 : 15 > ble.b L81 # guessed correctly > lea.l $L85(%pc),%a0 # wide > L81: > mov.l %a0,-(%sp) # on return, go directly to wide/narrow code > add.w %a6,%a6; add.w %a6,%a6 # with 4*fc > > mov.w %d1,%d7 # h-1 in bits,,inner width in words > and.l %d0,%d6 # 0,,bit offset of p.x > mov.l %a1,%d1 # r.o.y,,r.o.x > and.w %d1,%d0 # bit offset of r.o.x > sub.w %d0,%d6 # BO(p.x) - BO(r.o.x) /* amount of right rotation */ > swap.w %d1 # r.o.x,,r.o.y > mov.l %d1,-(%sp) # r.o > mov.l %a4,-(%sp) # sm > lea.l addr,%a3 > jsr (%a3) > mov.l %a0,%a2 # src = addr(sm,r.origin); > add.l &8,%sp > jmp (%a3) # %a0 = addr(dm,p); > L82: > mov.l &0,%d4 > mov.w %d5,%d4 # 0,,mask1 > swap.w %d5 # mask1,,mask2 (proper long mask; maybe 16 bits too wide) > and.w %d5,%d4 # check for overlap of mask1 and mask2 > beq.b L83 # no overlap ==> %d5 already correct > mov.l %d4,%d5 # overlap ==> reduce %d5 by 16 bits > swap.w %d5 # and put it in the proper half > L83: > swap.w %d7 # ,,height-1 > lea.l $nrwtab(%pc,%a6.w),%a6 # -> optab > tst.w %d6 # amount of right rotation > bge.b L84 > neg.w %d6 > add.l &2,%a6 > L84: > add.w (%a6),%a6 > jmp (%a6) > > nrwtab: > short opMnwr-nrwtab- 0, opMnwl-nrwtab- 2 > short opSnwr-nrwtab- 4, opSnwl-nrwtab- 6 > short opCnwr-nrwtab- 8, opCnwl-nrwtab-10 > short opXnwr-nrwtab-12, opXnwl-nrwtab-14 > > opMnwr: > mov.l (%a2),%d0 > mov.l (%a0),%d1 > ror.l %d6,%d0 > eor.l %d1,%d0 > and.l %d5,%d0 > eor.l %d1,%d0 > mov.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opMnwr > br ret8 > > opMnwl: > mov.l (%a2),%d0 > mov.l (%a0),%d1 > rol.l %d6,%d0 > eor.l %d1,%d0 > and.l %d5,%d0 > eor.l %d1,%d0 > mov.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opMnwl > br ret8 > > opSnwr: > mov.l (%a2),%d0 > ror.l %d6,%d0 > and.l %d5,%d0 > or.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opSnwr > br ret8 > > opSnwl: > mov.l (%a2),%d0 > rol.l %d6,%d0 > and.l %d5,%d0 > or.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opSnwl > br ret8 > > opCnwr: > mov.l (%a2),%d0 > ror.l %d6,%d0 > and.l %d5,%d0 > not.l %d0 > and.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opCnwr > br ret8 > > opCnwl: > mov.l (%a2),%d0 > rol.l %d6,%d0 > and.l %d5,%d0 > not.l %d0 > and.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opCnwl > br ret8 > > opXnwr: > mov.l (%a2),%d0 > ror.l %d6,%d0 > and.l %d5,%d0 > eor.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opXnwr > br ret8 > > opXnwl: > mov.l (%a2),%d0 > rol.l %d6,%d0 > and.l %d5,%d0 > eor.l %d0,(%a0) > add.w %d2,%a2 > add.w %d3,%a0 > dbr %d7,opXnwl > br ret8 > > set DBR,0x51c8 > set MOVLI,0x2000+074 # mov.l &..., > set MOVWI,0x3000+074 # mov.w &..., > set ADDWI,0x0640 # add.w &..., > > set FDFRAG,16 # first destination is a fragment > set LDFRAG,17 # last destination is a fragment > set NSHF1,18 > set FD2D,19 # first destination should store 2 words > set LD2D,20 # last destination should store 2 words > set FSTORE,21 > set DST1L,24 # dst inner count is 0 > set SRC1L,25 # Nsrc is 2 > > set gensiz,80 > > widtab: > mov.w %d0,(%a0)+; short 0 > or.w %d0,(%a0)+; short 0 > and.w %d0,(%a0)+; not.w %d0 > eor.w %d0,(%a0)+; short 0 > > # > # So far > # %d7 == h-1 (bits),,w (words) > # %d6 == 0,,rotate count > # %d5 == mask2,,mask1 > # %d4 == -RtoL > # %d3.w == wdst (bytes) > # %d2.w == wsrc (bytes) > # %a6.w == 4*fc > # %a2 -> src > # %a0 -> dst > # > L85: > lea.l $widtab(%pc,%a6.w),%a6 > tst.w %d4; bpl.b L300; bset &31,%d6 > L300: > mov.w %d7,%d0 # inner word count > bne.b L304; bset &DST1L,%d6 > L304: > add.w &1,%d0 # Nsrc = 1+Ninner > mov.w %d0,%a1 # + ... > add.w &1,%d0 # Ndst = 1+Ninner+1 > add.w %d0,%d0 # magnitude of dst addressing side effects > tst.l %d6; bpl.b L310 > neg.w %d0; add.l &2,%a0 # RtoL > L310: > sub.w %d0,%d3 # compensate dst for autoincrement > > mov.w %d5,%d4 # mask1 > swap.w %d5 # mask2 > > cmp.w %d4,&-1; beq.b L320; bset &FDFRAG,%d6 > L320: > > cmp.w %d5,&-1; seq.b %d1; beq.b L330; bset &LDFRAG,%d6 > L330: > > tst.w %d6; bne.b L360 # not NOSHIFT > add.w &1,%a1 # Nsrc = 1+Ninner+1 > mov.l %d6,%d0; swap.w %d0; ext.w %d0 # 0,,flag bits > asr.w &1,%d7; roxl.w &1,%d0 # account for inner words odd > mov.b $nstab(%pc,%d0.w),%d0 > bpl.b L340; add.w &1,%d7 > L340: > add.b %d0,%d0 > bpl.b L350; sub.w &1,%d7 > L350: > swap.w %d0; eor.l %d0,%d6 # the bits > btst &DST1L,%d6; bne.b L355 > btst &FD2D,%d6; beq.b L410 > L355: > ext.l %d4; bmi.b L410; swap.w %d4; not.w %d4 # NOSHIFT mask1 .l > br.b L410 # NOSHIFT mask2 .l > nstab: > byte 0x82,0x80,0x04,0x80 # 0x80: +1 inner; 0x40: -1 inner > byte 0x02,0x00,0x44,0x00 # 0x04: FD2D; 0x02: NSHF1 no first word > L360: > ext.w %d1; sub.w %d1,%d7 # extend inner loop > > mov.l &0xf,%d0 # 0 1 7 8 9 e f > add.w &8,%d6 # 8 9 f 0 1 6 7 > and.w %d0,%d6 > sub.w &8,%d6 # 0 1 7 -8 -7 -2 -1 X=C= sign > mov.w %d6,%d1; bge.b L367 # X unchanged > neg.w %d1 # 8 7 2 1 X=C= 1 > L367: > roxl.w &1,%d1 # 0 2 e 11 f 5 3 > and.w %d0,%d1 # 0 2 e 1 f 5 3 > lsl.w &8,%d1 # magic position > short ADDWI+001 > ror.l &8,%d0 > mov.w %d1,%a3 # the rotate instruction > > mov.l &0,%d1; not.w %d1 # 0,,-1 > ror.l %d6,%d1 # where the bits are after a rotate > > mov.w %d1,%d0; and.w %d4,%d0; beq.b L370 # 1 src word covers dst frag > not.w %d1; and.w %d4,%d1; beq.b L370 > add.w &1,%a1; br.b L390 # fragment needs another src word > L370: > sub.w &1,%d7 # .l takes an inner word > bset &FD2D,%d6 > ext.l %d4; bmi.b L390 > swap.w %d4; not.w %d4 # mask1 .l > L390: > > swap.w %d1 > > mov.w %d1,%d0; and.w %d5,%d0; beq.b L400 # 1 src word covers dst frag > not.w %d1; and.w %d5,%d1; beq.b L400 > add.w &1,%a1; br.b L420 # fragment needs another src word > L400: > dbr %d7,L405 # .l takes an inner word > clr.w %d7; br.b L420 # nothing there to take > L405: > L410: > bset &LD2D,%d6 > ext.l %d5; bmi.b L420 > swap.w %d5; not.w %d5 # mask2 .l > L420: > > tst.w NREG*4-4+fc+8(%sp); bne.b L430; bset &FSTORE,%d6 > L430: > mov.w %a1,%d0 # Nsrc > add.w %d0,%d0 # magnitude of src addressing side effects > tst.l %d6; bpl.b L431 > neg.w %d0; add.l &2,%a2 # RtoL > L431: > sub.w %d0,%d2 # compensate src for autoincrement > > lea.l -gensiz(%sp),%sp > mov.l %sp,%a5 > swap.w %d3 > swap.w %d2 > > cmp.w %a1,&2; bgt L445 > short MOVWI+00000 > mov.l (%a2)+,%d0 > tst.l %d6; bpl.b L432; add.w &010,%d0 # RtoL > L432: > mov.w %d0,(%a5)+ > mov.l &0,%d1; mov.w &-0x1000,%d2; mov.w &0100,%d3 > lea.l $L438(%pc),%a1 > mov.l &-1,%d0 # prepare bits to decide on "swap" > tst.w %d6; bpl.b L432d; neg.w %d6 > lsl.l %d6,%d0; br.b L432e > L432d: > lsr.l %d6,%d0 > L432e: > btst &DST1L,%d6; beq.b L434 > bset &FD2D,%d6; bne.b L432a > ext.l %d4; bmi.b L432a; swap.w %d4; not.w %d4 # mask1 .l > L432a: > bset &LD2D,%d6; bne.b L432b > ext.l %d5; bmi.b L432b; swap.w %d5; not.w %d5 # mask2 .l > L432b: > and.l %d5,%d4; mov.l %d4,%d5 # single .l does it all > add.l &1,%d4; beq L730 # all 32 bits > sub.l &1,%d4 # need an "and" > and.l %d5,%d0 > cmp.l %d5,%d0 > beq.b L432c > short MOVWI+05300 > swap.w %d0 > L432c: > tst.w %d6; bne L690 # and a rotate > br.b L437 # NOSHIFT > L434: > mov.w %a3,(%a5)+ # the rotate instr > short MOVWI+05300 > mov.l %d0,%d1 # copy after rotate > and.l %d4,%d0 > cmp.l %d4,%d0 > seq.b %d0; neg.b %d0; ext.w %d0 > short ADDWI+000 > swap.w %d0 > mov.w %d0,(%a5)+ > lea.l $L436(%pc),%a1 > br.b L437 > L436: > and.w %d4,%d0 > mov.w &01001,%d1; clr.w %d2; clr.w %d3 > lea.l $L438(%pc),%a1 > L437: > br L700 > L438: > and.w %d5,%d0 > br L545 > L445: > # > # During compilation > # %d7 == h-1,,w > # %d6 == flags,,rotate count > # %d5 == mask2 > # %d4 == mask1 > # %d3 == dst_dW,,bits for xxx.[wl] > # %d2 == src_dW,,bits for mov.[wl] > # %d1.w == parity > # %a6 -> optab > # %a5 -> next generated instruction > # %a4 -> top of inner loop > # %a3.w == rotate instruction > # %a2 -> src > # %a1 -> fragment "and" instruction > # %a0 -> dst > # > tst.w %d6; bne.b L480 # not NOSHIFT ==> always need first word > btst &NSHF1,%d6; bne.b L485 # interplay of NOSHIFT, odd, FDFRAG > L480: > mov.l &1,%d1 > and.w %d7,%d1 # parity of inner word count > lsl.w &2,%d1 # even ==> frag in %d0, odd ==> frag in %d1 > bsr genwid # generate for first word > and.w %d4,%d0 > L485: > cmp.w %d7,&2; ble.b L490 # inner dbr always falls through > btst &FSTORE,%d6; beq.b L490 # no conflict "mov field" vs. %d6 > short MOVWI+05300 # init inner count > mov.w %a4,%d6 > L490: > mov.l %a5,%a4 # top of inner loop > asr.w &1,%d7 # check inner word count > blt.b L540 # single .l does it all > bcc.b L500 # even > beq.b L520 # 1 > short MOVWI+05300 > br.b L500 # jump into middle of inner loop > add.l &1,%a4 # remember to fixup "br.b" > add.w &1,%d7 # middle entry ==> no dbr offset > L500: > beq.b L530 # no inner words at all > mov.l &4,%d1 # use %d1 in > bsr.b genwid # even half of inner loop > short 0 > L510: > mov.w %a4,%d0; neg.w %d0 > bclr &0,%d0; beq.b L520 > add.w %a5,%d0; mov.b %d0,(%a4)+ # fixup "br.b" into middle > L520: > mov.l &0,%d1 # use %d0 in > bsr.b genwid # odd half of inner loop > short 0 > sub.w &1,%d7 # offset for inner dbr loop > ble.b L530 # dbr always falls through > mov.w &DBR+6,(%a5)+ > sub.l %a5,%a4; mov.w %a4,(%a5)+ # dbr displacement > L530: > > btst &LDFRAG,%d6; beq.b L540 # omit "and" for full last word > mov.l &4,%d1 > bsr.b genwid > and.w %d5,%d0 > L540: > > tst.w %d7; ble.b L545 # no inner loop > btst &FSTORE,%d6; bne.b L545 # possible conflict "mov field" vs. %d6 > short MOVWI+05300 # init inner count > mov.w %a4,%d6 > L545: > swap.w %d3; tst.w %d3; beq.b L546 # wdst is full width of bitmap > mov.w %d3,%a1 # dst_dW > short MOVWI+05300 > add.w %a1,%a0 > L546: > swap.w %d2; tst.w %d2; beq.b L547 # wsrc is full width of bitmap > mov.w %d2,%a3 # src_dW > short MOVWI+05300 > add.w %a3,%a2 > L547: > mov.w &DBR+7,(%a5)+ > mov.l %sp,%a4 # top of outer loop > cmp.b (%a4),&0x60; bne.b L548 # not br.b > mov.b 1(%a4),%d0; ext.w %d0; lea.l 2(%a4,%d0.w),%a4 # collapse branches > L548: > sub.l %a5,%a4; mov.w %a4,(%a5)+ # dbr displacement > short MOVWI+05300 > jmp (%a5) > > mov.w %d7,%a4 # init inner count > mov.w %d7,%d6 # init inner count, 2nd case > swap.w %d7 # h-1 > lea.l $retgen(%pc),%a5 > jmp (%sp) > > genwid: > mov.l (%sp)+,%a1 # -> inline parameter > mov.l $genget(%pc,%d1.w),%d0 > tst.w %d1; beq.b L550; mov.w &01001,%d1; swap.w %d1 # parity bits > L550: > clr.w %d2; clr.w %d3 # .[wl] bits default to .w > tst.l %d6; bpl.b L560; add.w &010,%d0 # RtoL > L560: > tst.w %d6; bne.b L569 # not NOSHIFT > bclr &9,%d0 # NOSHIFT always %d0 > mov.w (%a1),%d1; bne.b L564 # not inner loop > btst &FSTORE,%d6; beq.b L562 # not "mov" > mov.l &070,%d1; and.w %d0,%d1 > lsl.w &3,%d1; or.w %d1,%d0 # copy RtoL mode > add.w &-0x1000,%d0 # .w ==> .l > mov.w %d0,(%a5)+ > L561: > jmp 2(%a1) > genget: > swap.w %d0; mov.w (%a2)+,%d0 > swap.w %d1; mov.w (%a2)+,%d1 > > L562: > mov.w &-0x1000,%d2; mov.w &0100,%d3 # .w +=> .l > add.w %d2,%d0 > L563: > mov.l &0,%d1 # NOSHIFT always %d0 > br L698 # assemble the fetch, then do the op > L564: > lsr.w &1,%d1; bcs.b L562 # NOSHIFT always LD2D > btst &FD2D,%d6; bne.b L562 > br.b L563 # alas, .w > L569: > mov.w (%a1),%d1; beq.b L630 # inner loop > L570: > lsr.w &1,%d1; bcs.b L580 # last word > add.w &-0x1000,%d0 # force fetch .l > mov.w %d0,(%a5)+ # the fetch .l > short MOVLI+00000 > mov.l %d0,%d1 > swap.w %d0 > clr.w %d1; eor.l %d1,%d0 # parity for mov.l %d[01],%d[10] > tst.l %d1; sne.b %d1; sub.b %d1,%d0 # parity for swap.w %d[01] > mov.l %d0,(%a5) # ran out of registers > mov.l &0x4c80ec,%d0 # microcoded bits > tst.l %d6; bpl.b L572; ror.l &1,%d0 # RtoL > L572: > tst.w %d6; bpl.b L574; ror.l &2,%d0 # rol > L574: > btst &FD2D,%d6; beq.b L576; ror.l &4,%d0 # first op .l > mov.w &-0x1000,%d2; mov.w &0100,%d3 # .w +=> .l corrections > L576: > ror.l &1,%d0; bpl.b L578 # "swap" not needed > add.l &2,%a5 > ror.l &8,%d0; bpl.b L577 # existing "swap" parity OK > eor.w &1,(%a5) > L577: > ror.l &8,%d0; bpl.b L578 # existing order OK > sub.l &2,%a5 > mov.l (%a5),%d0; swap.w %d0; mov.l %d0,(%a5) > add.l &2,%a5 > L578: > add.l &2,%a5 > swap.w %d1 # junk,,parity > br.b L690 > L580: > btst &LD2D,%d6; beq.b L630 # operator .w > mov.w &-0x1000,%d2 # mov.w +=> mov.l > mov.w &0100,%d3 # xxx.w +=> xxx.l > L630: > tst.l %d6; smi.b %d1 > eor.b %d6,%d1; bpl.b L650 # rotation in same direction as scan > swap.w %d0 # interchange "swap" and "mov" > L650: > mov.l %d0,(%a5)+ > > swap.w %d1 # junk,,parity > mov.w (%a1),%d0; lsr.w &1,%d0; bcs.b L660 # last word > short MOVWI+000 > mov.l %d0,%d1 > eor.w %d1,%d0 > mov.w %d0,(%a5)+ > br.b L690 > L660: > tst.l %d6; bmi.b L690 # RtoL > btst &LD2D,%d6; beq.b L690 # not .l > tst.w %d6; bpl.b L670 # ror > sub.l &2,%a5; br.b L690 # no "swap" > L670: > mov.w -4(%a5),(%a5)+ # extra "swap" > L690: > mov.w %a3,%d0 > eor.b %d1,%d0 > L698: > mov.w %d0,(%a5)+ # the rotate instruction > L700: > > mov.w (%a1),%d0; beq.b L730 # inner loop > btst &0,%d0; bne.b L705 # last word > btst &FDFRAG,%d6; beq.b L730 # no "and" > L705: > add.w %d3,%d0; add.w %d1,%d0; sub.b %d1,%d0 # and.[wl] %d[45],%d[01] > btst &FSTORE,%d6; beq.b L720 > # "mov" partial word > swap.w %d0 # save the "and" > short MOVWI+00000 # ,%d0 > mov.w (%a0),%d6 > add.w %d2,%d0 # mov.[wl] > tst.l %d6; bpl.b L710; add.w &020,%d0 # RtoL; "(%a0)" ==> "-(%a0)" > L710: > mov.w %d0,(%a5)+ # instr to fetch memory part of word > short MOVWI+00000 # ,%d0 > eor.w %d6,%d0 > add.w %d3,%d0; add.b %d1,%d0 # eor.[wl] %d6,%d[01] > swap.w %d0; mov.l %d0,(%a5)+; swap.w %d0; mov.w %d0,(%a5)+ > mov.w %d2,%d0; add.b %d1,%d0 # mov.[wl] %d[01], > mov.l &-0100,%d1 # RtoL correction, if necessary > br.b L770 > L720: > mov.w %d0,(%a5)+ # "and" for non-mov operators > L730: > mov.w 2(%a6),%d0; beq.b L740 # not F_CLR > add.w %d3,%d0; add.b %d1,%d0 # not.[wl] %d[01] > mov.w %d0,(%a5)+ > L740: > btst &FSTORE,%d6; beq.b L790 # non-"mov" > mov.w %d2,%d0; add.b %d1,%d0 # mov.[wl] %d[01], > mov.l &0100,%d1 # RtoL correction, if necessary > L770: > add.w (%a6),%d0 > tst.l %d6; bpl.b L780 > add.w %d1,%d0 # RtoL correction > L780: > mov.w %d0,(%a5)+ > jmp 2(%a1) > > L790: > mov.w %d1,%d0; clr.b %d0; add.w %d3,%d0 # xxx.[wl] %d[01] > mov.l &010,%d1 # RtoL correction, if necessary > br.b L770 > > # > # During execution > # %d[01] == rotator > # %d2 [reserved for texture bits] > # %d3 [reserved for texture index] > # %d4 == mask1 > # %d5 == mask2 > # %d6.w == inner count > # %d7.w == outer count > # %a0 -> dst > # %a1 == dst_dW > # %a2 -> src > # %a3 == src_dW > # %a4.w == inner count init > # %a5 -> retgen > # %a6 [reserved for -> texture] > # > From jon at fourwinds.com Wed Apr 6 14:59:49 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 05 Apr 2022 21:59:49 -0700 Subject: [TUHS] Long term software archive Message-ID: <202204060459.2364xnP73608361@darkstar.fourwinds.com> So this is weird. My publisher contacted me this week asking for permission to send a copy of my book to these folks: https://archiveprogram.github.com/ Hadn't heard of them before. Looks like they're filling their archive with stuff from github which means that most of the stuff being preserved by TUHS is likely not there. Might be a good idea to see if it can be included. I have no contact with these folks but can probably get a contact from my publisher if this is something that y'all think is worth doing. Jon From crossd at gmail.com Fri Apr 8 02:32:05 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 7 Apr 2022 12:32:05 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. Message-ID: I came across this talk that, apparently, was meant to be part of a documentary about timesharing systems at MIT: https://www.youtube.com/watch?v=KZPYBDA6XVo This "episode" features McCarthy, Corbato, Fano, Fredkin, and Philip Morse talking about Multics. Starting at ~12:15m they talk about the triumvirate of MIT, GE and Bell Labs and some of the challenges with distributed work. Around the 14 minute mark, they talk about Bell Labs exiting the project, and touch briefly on the development of Unix. Interesting quotes include Fano talking about different objectives from the different organizations, Corby saying, "they [Bell Labs] dropped out three-quarters of the way through the race" (referring to Multics), Fano asserting that BTL left after the _research_ part of the project was essentially completed, and Corbato talking about the influence of Multics on Unix design (Corby refers to Multics as Ken and Dennis's "prototype" and calls Unix a "second generation Multics"). This was all shot in the early 1980s. The rest is interesting, but mostly unrelated to Unix. - Dan C. (PS: As an aside, Fano lighting up a cigarette at about 19:20 was particularly striking: my, how times have changed.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Apr 8 03:45:11 2022 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 7 Apr 2022 13:45:11 -0400 Subject: [TUHS] Why does shell write to stderr? Message-ID: Looking at https://unix.stackexchange.com/questions/380012/why-does-bash-interactive-shell-by-default-write-its-prompt-and-echoes-its-inter, in particular the first answer which has a link to http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/main%E2%80%8C%E2%80%8B.c Made me wonder: why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Fri Apr 8 07:11:00 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 7 Apr 2022 17:11:00 -0400 Subject: [TUHS] Why does shell write to stderr? Message-ID: How would you wish to interact with /bin/bash >file Doug From steffen at sdaoden.eu Fri Apr 8 07:32:34 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 07 Apr 2022 23:32:34 +0200 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: <20220407213234.7sGk5%steffen@sdaoden.eu> Douglas McIlroy wrote in : |How would you wish to interact with | /bin/bash >file While the POSIX standard defines an interactive shell as one with STDIN and STDERR being a terminal, i think the NetBSD shell did not until not too long (< half a decade?) ago, and the mailer you were using for a long time does not to this day. (Unfortunately.) APPLICATION USAGE Standard input and standard error are the files that determine whether a shell is interactive when -i is not specified. For example: sh > file and: sh 2> file create interactive and non-interactive shells, respectively. Although both accept terminal input, the results of error conditions are different, as described in Section 2.8.1 (on page 2363); in the second example a redirection error encountered by a special built-in utility aborts the shell. --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 rich.salz at gmail.com Fri Apr 8 07:36:24 2022 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 7 Apr 2022 17:36:24 -0400 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > How would you wish to interact with > /bin/bash >file > I am not sure. I could see the argument either way right now. On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > How would you wish to interact with > /bin/bash >file > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Apr 8 08:15:21 2022 From: robpike at gmail.com (Rob Pike) Date: Fri, 8 Apr 2022 08:15:21 +1000 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: I am indeed a throwback but programs calling stat or stty to examine their I/O state before deciding how to behave was a shock when I first saw it done, in Berkeley ls I think, and still feels misguided. I understand the convenience but not every convenience is good engineering. -rob On Fri, Apr 8, 2022 at 7:38 AM Richard Salz wrote: > On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> How would you wish to interact with >> /bin/bash >file >> > > I am not sure. I could see the argument either way right now. > > > On Thu, Apr 7, 2022 at 5:13 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> How would you wish to interact with >> /bin/bash >file >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Fri Apr 8 08:30:01 2022 From: ggm at algebras.org (George Michaelson) Date: Fri, 8 Apr 2022 08:30:01 +1000 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: I also had extreme WTF the first time I looked in code and saw an isatty() guard over some activity. "this program processes stdin to stdout, except.. if I decide otherwise" never appeared in man pages. But that said, it sort of made sense. Why ring bell in an editor, if you know the input pipe side can't hear it? A tty is a rather strange device being the join over stdout, stdin and stderr, and there is a (tiny?) set of things which need to know. more for instance, probably needs to know that waiting for a command to move pagination onward if there is no controlling terminal is not sensible. If you want your input in chunks, more is not the way to do it. I hate special cases. This is why people say english is so hard to learn but really all languages have them, its just that english having stolen words from everywhere has more instances of isatty() than others. -G From robpike at gmail.com Fri Apr 8 09:51:18 2022 From: robpike at gmail.com (Rob Pike) Date: Fri, 8 Apr 2022 09:51:18 +1000 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: If you never ring the bell in the editor, the issue never comes up, the code is simpler, and there's less to understand. -rob On Fri, Apr 8, 2022 at 8:33 AM George Michaelson wrote: > I also had extreme WTF the first time I looked in code and saw an > isatty() guard over some activity. > > "this program processes stdin to stdout, except.. if I decide > otherwise" never appeared in man pages. > > But that said, it sort of made sense. Why ring bell in an editor, if > you know the input pipe side can't hear it? A tty is a rather strange > device being the join over stdout, stdin and stderr, and there is a > (tiny?) set of things which need to know. > > more for instance, probably needs to know that waiting for a command > to move pagination onward if there is no controlling terminal is not > sensible. If you want your input in chunks, more is not the way to do > it. > > I hate special cases. This is why people say english is so hard to > learn but really all languages have them, its just that english having > stolen words from everywhere has more instances of isatty() than > others. > > -G > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Apr 8 15:30:41 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 08 Apr 2022 05:30:41 +0000 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: (Dan Cross's message of "Thu, 7 Apr 2022 12:32:05 -0400") References: Message-ID: <7wh774dtvi.fsf@junk.nocrew.org> Dan Cross wrote: > Interesting quotes include Fano talking about different objectives > from the different organizations, Corby saying, "they [Bell Labs] > dropped out three-quarters of the way through the race" (referring to > Multics), Fano asserting that BTL left after the _research_ part of > the project was essentially completed Multics was started in 1964 and first went online in 1967, although it seems likely it wasn't exactly at the top of its game yet. Bell Labs pulled out in 1969. If that was the 75% point, 100% would be around 1971. From pnr at planet.nl Fri Apr 8 19:34:24 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 8 Apr 2022 11:34:24 +0200 Subject: [TUHS] Why does shell write to stderr? Message-ID: > If you never ring the bell in the editor, the issue never comes up As natural language ambiguity was brought up: it makes the code less noisy :^) From clemc at ccc.com Fri Apr 8 23:34:31 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 8 Apr 2022 09:34:31 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <7wh774dtvi.fsf@junk.nocrew.org> References: <7wh774dtvi.fsf@junk.nocrew.org> Message-ID: On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff wrote: > Multics was started in 1964 and first went online in 1967, although it > seems likely it wasn't exactly at the top of its game yet. Bell Labs > pulled out in 1969. If that was the 75% point, 100% would be around 1971. > Not to put too fine a point on it, It seems like it would be fair to say Multics was 'complete' by the time Organick published his book: *"**The Multics System: An Examination of Its Structure**.*" Amazon says the 3rd printing was April 72, so that means he must have published it earlier. I don't know when it first appeared and can not seem to find it. My copy is in storage but I bet I have the 3rd printing. But I had >>thought<< that was still in the late 1960s. Anyone have a first edition around with the publication date? ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Apr 8 23:59:26 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 8 Apr 2022 09:59:26 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <7wh774dtvi.fsf@junk.nocrew.org> References: <7wh774dtvi.fsf@junk.nocrew.org> Message-ID: On Fri, Apr 8, 2022 at 1:30 AM Lars Brinkhoff wrote: > Dan Cross wrote: > > Interesting quotes include Fano talking about different objectives > > from the different organizations, Corby saying, "they [Bell Labs] > > dropped out three-quarters of the way through the race" (referring to > > Multics), Fano asserting that BTL left after the _research_ part of > > the project was essentially completed > > Multics was started in 1964 and first went online in 1967, although it > seems likely it wasn't exactly at the top of its game yet. Bell Labs > pulled out in 1969. If that was the 75% point, 100% would be around > 1971. > In context, I don't think Corby's statement was meant to be taken literally, but rather he used it as more of a colloquialism. His point was that (at least in his perception) the bulk of the work had been done when BTL dropped out of the project. Fano's statements are a bit overshadowed by Corby's here, but when he talked about each of the three participants in the Multics project at its outset working on one project but with different goals, he stated that his impression was that Bell Labs was interested in both the research products as well as a production system that they actually could use. In particular, they expected that the latter would be delivered on a specific timetable: when the research part basically wrapped and the system still wasn't production ready, they dropped out. MIT started offering timesharing access on Multics in 1969. A second site at Griffiss Air Force Base in Rome, NY was operational by 1970. Honeywell announced the 6180 running Multics as a product in 1973; throughout the 70s things were tuned, cleaned up, and new subsystems introduced. The "New Storage System", which started in 1973 and was delivered to customers in 1976. I think it's fair to say that, by the mid-70s, Multics had fully transitioned from "research project" to "commercial system." Bell Labs dropping out of Multics in 1969 was, of course, before Unix. This raises the question, what did Bell Labs use instead? I imagine 360s and either traditional batch processing or TSS or something? Of course, by 1976, Unix was at 6th Edition and I can see why no one would want to go back to Multics (or being tied to a machine costing an order of magnitude more than a PDP-11). But one wonders what would have happened had Multics started accepting timesharing, say, 9 months earlier than it did. It would be interesting to hear what it was like when Bell Labs withdrew from the Multics project. Does anyone have any stories? Perhaps Ken or Doug? Also, what was the relationship like with the MIT people after that? Corby et al seemed somewhat animated in insisting that Multics had been essential to the creation of Unix, almost as if that had not been sufficiently acknowledged; I imagine by the time this video was shot, they must have been feeling somewhat overshadowed by the success of Unix. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Apr 9 00:14:05 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 8 Apr 2022 10:14:05 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> Message-ID: On Fri, Apr 8, 2022 at 9:34 AM Clem Cole wrote: > On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff wrote: > >> Multics was started in 1964 and first went online in 1967, although it >> seems likely it wasn't exactly at the top of its game yet. Bell Labs >> pulled out in 1969. If that was the 75% point, 100% would be around >> 1971. >> > Not to put too fine a point on it, It seems like it would be fair to say > Multics was 'complete' by the time Organick published his book: *"**The > Multics System: An Examination of Its Structure**.*" Amazon says the 3rd > printing was April 72, so that means he must have published it earlier. I > don't know when it first appeared and can not seem to find it. My copy > is in storage but I bet I have the 3rd printing. But I had >>thought<< > that was still in the late 1960s. Anyone have a first edition around > with the publication date?ᐧ > I have a scanned copy of Organick from MIT that says Copyright 1972 (and has a stamp from the Barker Engineering Library listing May 16, 1972 as the acquisition date). I can't see any indication that this is anything other than the first printing. Corbato's forward is dated Dec 13, 1971. However, Organick's book is often said to describe an earlier version of the system, up to somewhere in the vicinity of 1968/1970 ( https://multicians.org/history.html, also message to the old Multicians list at Yahoo! I'm not sure about the archives of that, so don't have a link). I understand that Multics got much better after the move to the 6180 and DPS8/M; Organick's book describes GE 645 Multics only. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Apr 9 01:28:34 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 8 Apr 2022 08:28:34 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> Message-ID: <20220408152834.GE29186@mcvoy.com> On Fri, Apr 08, 2022 at 09:59:26AM -0400, Dan Cross wrote: > Of course, by 1976, Unix was at 6th Edition and I can see why no one would > want to go back to Multics (or being tied to a machine costing an order of > magnitude more than a PDP-11). But one wonders what would have happened had > Multics started accepting timesharing, say, 9 months earlier than it did. Do we have any people around who actively used Multics long enough to develop a feel for it? My only experience is the printout that Rob Gingell had on his office door which was a description of Multics paging in library after library before it actually ran the program. I have no idea if it was that bad. I guess what I'm trying to ask is if Multics had modern hardware under it, performed well, would we want to be running it? From crossd at gmail.com Sat Apr 9 01:35:20 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 8 Apr 2022 11:35:20 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <20220408152834.GE29186@mcvoy.com> References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: On Fri, Apr 8, 2022 at 11:28 AM Larry McVoy wrote: > On Fri, Apr 08, 2022 at 09:59:26AM -0400, Dan Cross wrote: > > Of course, by 1976, Unix was at 6th Edition and I can see why no one > would > > want to go back to Multics (or being tied to a machine costing an order > of > > magnitude more than a PDP-11). But one wonders what would have happened > had > > Multics started accepting timesharing, say, 9 months earlier than it did. > > Do we have any people around who actively used Multics long enough to > develop a feel for it? My only experience is the printout that Rob > Gingell had on his office door which was a description of Multics > paging in library after library before it actually ran the program. > I have no idea if it was that bad. > > I guess what I'm trying to ask is if Multics had modern hardware > under it, performed well, would we want to be running it? > I'm running Multics under emulation at home and I think it's actually pretty cool. I imagine that both Doug and Ken would remember it pretty well? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Apr 9 01:45:28 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 08 Apr 2022 08:45:28 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> Message-ID: <202204081545.238FjSGv3781664@darkstar.fourwinds.com> Dan Cross writes: > Bell Labs dropping out of Multics in 1969 was, of course, before Unix. This > raises the question, what did Bell Labs use instead? I imagine 360s and > either traditional batch processing or TSS or something? Someone who was older than me at the time like Heinz probably knows more than I do. My recollection is that many departments had their own random systems as minicomputers took over. We used 516-TSS on a Honeywell DDP-516/ I have no idea what Max Matthews ran on his DDP-224 but would guess that it was all custom stuff. I believe that the behemoth GE-635 aka Honeywell 6070 in the computer center ran GECOS. I don't know if that machine was originally there for the MULTICS project. From jnc at mercury.lcs.mit.edu Sat Apr 9 02:07:34 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 8 Apr 2022 12:07:34 -0400 (EDT) Subject: [TUHS] Interesting commentary on Unix from Multicians. Message-ID: <20220408160734.380DB18C0A8@mercury.lcs.mit.edu> > From: Clem Cole > Not to put too fine a point on it, It seems like it would be fair to > say Multics was 'complete' by the time Organick published his book This is a pretty ill-judged claim, IMO - but not for any particulars about the Organick book, etc. The problem is more global. When was UNIX 'complete' - when the first people were able to do real work on the PDP-7? When non-programmer clerks from the patent group were able to use the assembler UNIX on the PDP-11 to format parent documents? When it was re-written in C for the 4th Edition (since the _portability_ of UNIX was IMO perhaps the greatest factor in its eventual domination)? Etc, etc, etc. The exact same problem applies to the question of 'when was Multics 'complete''. > don't know when it first appeared and can not seem to find it. ... I > bet I have the 3rd printing. ... Anyone have a first edition around > with the publication date? The third printing _is_ the first edition. Anyway, it doesn't matter - see above. And of course even if the book _wriring_ was finished at time T, it wouldn't have been printed until some unknown time later. So that's really pretty useless as a temporal marker; we have much better ones availablw. > From: Dan Cross > I can't see any indication that this is anything other than the first > printing. My 3rd printing says 3rd was 1980, 2nd in 1976, and copyright 1972. > Organick's book is often said to describe an earlier version of the > system Yes; I'm not sure if the version described in it was ever available for general usege (which could be my definition of 'complete') - or even usage my Multics system programmers. I don't remember all the details of the differences (it's been way too long since I read it, and I don't know the details of the 'first operational' Multics well enough), but for instance: ISTR that it describes a version which had a linkage segment (holding intermediate locations in outbound links - since segment >a>b>c might well have different segment numbers assigned to it in the address spaces of processes X and Y, so one copy of >a>b>c, shared between X and Y, couldn't contain direct outbound links) _per segment_ (data or code) - but operational Multics (I don't know if this is from 'first available to users', or 'first available to Multics system programmers', or what) collapsed all the linkage info into a 'combined linkage segment', in which the linkage info from all the segments in a process' address space were combined (by copying) into a single linkage segment. Etc, etc, etc. > I understand that Multics got much better after the move to the 6180 I'm not sure that the 6180 made that big a difference to the environment the average use saw. My understanding (not having been there) was that the big _architectural_ difference was that cross-ring inter-segment references were done and monitored in hardware, so a host of security holes caused by insufficient checking of cross-ring inter-segment pointers were caught automatically. (The 6180 was also built out of SSI chips, unlike the 645 which was individual transistors, like a KA10.) Noel From rdm at cfcl.com Sat Apr 9 05:36:39 2022 From: rdm at cfcl.com (Rich Morin) Date: Fri, 8 Apr 2022 12:36:39 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <20220408152834.GE29186@mcvoy.com> References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: <39AB7949-36F3-4D28-9C4C-6AFE9ED3541F@cfcl.com> > On Apr 8, 2022, at 08:28, Larry McVoy wrote: > > ... I guess what I'm trying to ask is if Multics had modern hardware > under it, performed well, would we want to be running it? On a related note, I'd love to hear from some folks who have used both Multics and Unix(ish) systems about things that differ and how they affect the user experience. -r From clemc at ccc.com Sat Apr 9 06:48:57 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 8 Apr 2022 16:48:57 -0400 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. Message-ID: I personally lost two friends and former colleagues recently that these list probably wants to know about. I just heard from Lynne Jolitz, Bill's wife. It seems he passed away about a month ago after a long illness. Most of you know he was the original force behind the BSD 386 development. I know little more than what I have just reported at this time, but will pass on any info as I learn it. Also in other news, not Unix related, but PDP-11 and the computer graphics world. We lost Jack Burness a few weeks ago. Jack was the author of the original "Moonlander" for the PDP-11 with which many of us wasted many hours trying to pick up "a Big Mac with fries" at "Mare Assabet." [Note: There was no WWW/Wikipedia in those days to find it, but to look up Assabet River, so many people naively thought it was a legitimate lunar landmark - its the River that the DEC Maynard bldg sits]. He was a larger than life person [his joke's mailing list was a whos-who of the computer industry - it was an honor to be on it]. We all have a passel of stories about Jack. I have written separately about Jack a number of times and if you have never looked at the source to Moonlander, you own it yourself to read it. Remember he wrote it as a throw-away demo for the GT-40 for trade show [his integer transcendental funcs are quite instructive]. As one of the folks on the Masscomp Alumni list put it, 'Jack was someone that just does not deserve to die.' This is the announcement Maureen published in the DEC Alumni list. ************************** January 20, 2022 ******************************** Our sincere condolences to Maureen Burness and all friends in CXO and elsewhere on the passing of her husband, *Jack Burness*, 75, Colorado Springs, who left us on January 20, 2022. Maureen said: With his bigger than life personality, humor, and intellect, he was loved and respected by so many people, including his devoted family. Born in Brooklyn, NY in 1946, he received his Engineering Degree from Brooklyn Polytechnic Institute and was employed by DEC, Maynard in the early days and then here in Colorado Springs. Many of you knew he had a huge appetite for the outdoors of Colorado and Martha’s Vineyard and joined him in his sometimes-disastrous adventures. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Sat Apr 9 07:02:23 2022 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 08 Apr 2022 14:02:23 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <20220408152834.GE29186@mcvoy.com> References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. > > Do we have any people around who actively used Multics long enough to > develop a feel for it? My only experience is the printout that Rob > Gingell had on his office door which was a description of Multics > paging in library after library before it actually ran the program. > I have no idea if it was that bad. I used Multics for a couple of my undergrad years at University of Calgary (along with a PDP-11/60 and then a PDP-11/44 and a VAX 11/780, with the DEC equipment running Unix of course: V7 on the 11s, and 32V then 3BSD and finally 4BSD on the VAX). I never really appreciated Multics as much then (except for its LISP and Emacs implementations), but have grown far more fond of it now that it is effectively gone. > I guess what I'm trying to ask is if Multics had modern hardware > under it, performed well, would we want to be running it? I think it would be most excellent, assuming it had kept up to modern needs, used modern languages (there was already a C compiler for it) and if modern hardware had continued to support it into the 64-bit era. The famous "everything is a file" description of Unix is wrong, or at least misleadingly incomplete -- the correct description is more like: "everything is a file _descriptor_"; whereas in Multics everything is actually just a memory array (except for some communications devices). Single Level Storage is an awesome concept and removes so many ugly hacks from algorithms that otherwise have to process data in files. Doing data processing with read and write and pipes is effectively working through a straw whereas SLS allows all (reasonably sized) data to be presented in entirely complete randomly accessible arrays just by attaching a "file" to a segment. Mmap() is a very poor replacement that requires a great deal extra bookkeeping that's next to impossible to hide from; and also there's the problem of the consistency semantics being different between the I/O based filesystems and direct memory mapping of their files, which Mmap() reveals, and which SLS eliminates (by simply not having any I/O mechanism for files in the first place!). Multics dynamic linking makes any unix-ish implementation look most ugly, incredibly insecure, and horribly inefficient. Unix shared libraries are bad hack to simulate what Multics did natively and naturally, with elegance, and with direct hardware security support. Both of these features of course strongly desire (for decent performance) either something like the original hardware-based segmented addressing scheme (e.g. as offered in Intel IA-32 and also tried to offer in the iAPX432), or hardware similar to what capability-based addressing schemes found in some research systems today [1]. Intel was never pressured strongly enough into improving the performance of segmented addressing and memory management in the IA-32 (because nothing (but OS/2?) really used it heavily the way a multics-like OS would have, and of course the iAPX432 also failed to deliver good performance), then AMD never carried full segmentation support forward into their 64-bit architecture and instruction set where it would have made larger scale multics-like systems more practical. [1] The experimental CHERI architecture is an example: CHERI: Memory Segmentation to Support Secure Applications "A segment mechanism that implements the capability model of safe, programmatic memory protection" http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2013essos-cheri.pdf "CHERI can do anything Multics could do: segmentation, paging, dynamic linking, ring-structured software" -- Peter G. Neumann in "An Interview with..." by Rick Farrow in ;login:, Winter 2017 vol. 42, no. 4 -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From dave at horsfall.org Sat Apr 9 08:29:15 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 9 Apr 2022 08:29:15 +1000 (EST) Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022, Clem Cole wrote: [...] > Also in other news, not Unix related, but PDP-11 and the computer > graphics world.  We lost Jack Burness a few weeks ago.  Jack was the > author of the original "Moonlander" for the PDP-11 with which many of us > wasted many hours trying to pick up "a Big Mac with fries" at "Mare > Assabet."  [Note: There was no WWW/Wikipedia in those days to find it, > but to look up Assabet River, so many people naively thought it was a > legitimate lunar landmark - its the River that the DEC Maynard bldg > sits]. He was a larger than life person [his joke's mailing list was a > whos-who of the computer industry - it was an honor to be on it]. We all > have a passel of stories about Jack.  I have written separately about > Jack a number of times and if you have never looked at the source to > Moonlander, you own it yourself to read it.   Remember he wrote it as a > throw-away demo for the GT-40 for trade show [his integer > transcendental funcs are quite instructive].   As one of the folks on > the Masscomp Alumni list put it, 'Jack was someone that just does not > deserve to die.' I have fond memories of playing it on the GT-40, and if Andrew Hume is reading this he'll remember reverse-engineering the code and modifying it for three-play operation; I think Peter Ivanov also implemented reverse gravity... Eventually DEC Field Circus stopped replacing GT-40 switch registers if they'd suspected that they were used for playing it :-) The GT-40 had a primitive loader; it was Craig McGregor of the CSU (UNSW) who used it to download an 8-bit loader for things like Lunar Lander (I only wrote a simple "Life" program for it, using the light-pen). -- Dave From dave at horsfall.org Sat Apr 9 08:44:57 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 9 Apr 2022 08:44:57 +1000 (EST) Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: Message-ID: On Sat, 9 Apr 2022, Dave Horsfall wrote: > I have fond memories of playing it on the GT-40, and if Andrew Hume is > reading this he'll remember reverse-engineering the code and modifying > it for three-play operation; I think Peter Ivanov also implemented > reverse gravity... Oops; reverse gravity (for the Sun) was implemented for Space Wars (or whatever it was called; this was ~40 years ago, so don't expect my memory to be the best). -- Dave From andreww591 at gmail.com Sat Apr 9 09:34:27 2022 From: andreww591 at gmail.com (Andrew Warkentin) Date: Fri, 8 Apr 2022 17:34:27 -0600 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: On 4/8/22, Greg A. Woods wrote: > > Single Level Storage is an awesome concept and removes so many ugly > hacks from algorithms that otherwise have to process data in files. > Doing data processing with read and write and pipes is effectively > working through a straw whereas SLS allows all (reasonably sized) data > to be presented in entirely complete randomly accessible arrays just by > attaching a "file" to a segment. Mmap() is a very poor replacement that > requires a great deal extra bookkeeping that's next to impossible to > hide from; and also there's the problem of the consistency semantics > being different between the I/O based filesystems and direct memory > mapping of their files, which Mmap() reveals, and which SLS eliminates > (by simply not having any I/O mechanism for files in the first place!). > I think it's useful to have both I/O and memory views for files. Things like commands that work equally well whether stdout is a disk file or something like a pipe wouldn't work so well in a system where disk files can only be accessed through a memory-like interface. However, I guess the I/O interface could just be implemented with library functions rather than real I/O syscalls for disk-like files. Maybe I could try doing something like that in my OS but I'm not completely sure if it would affect performance because it will be QNX-like, and reads and writes would probably require the VFS to act as an intermediary sometimes whereas that wouldn't be the case with I/O since reads and writes would otherwise map onto kernel message passing without any intermediary servers. From andrew at humeweb.com Sat Apr 9 09:14:56 2022 From: andrew at humeweb.com (Andrew Hume) Date: Fri, 8 Apr 2022 16:14:56 -0700 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: Message-ID: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> i do fondly remember the gt-40 and the many hours playing on it. and i do remember the DEC engineers being bothered about replacing the registers. > On Apr 8, 2022, at 3:29 PM, Dave Horsfall wrote: > > I have fond memories of playing it on the GT-40, and if Andrew Hume is > reading this he'll remember reverse-engineering the code and modifying it > for three-play operation; I think Peter Ivanov also implemented reverse > gravity... > > Eventually DEC Field Circus stopped replacing GT-40 switch registers if > they'd suspected that they were used for playing it :-) > > The GT-40 had a primitive loader; it was Craig McGregor of the CSU (UNSW) > who used it to download an 8-bit loader for things like Lunar Lander (I > only wrote a simple "Life" program for it, using the light-pen). > > -- Dave From ggm at algebras.org Sat Apr 9 09:53:03 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 9 Apr 2022 09:53:03 +1000 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> References: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> Message-ID: I've never met anyone who did more than play on a gt40, myself included. I suspect it was something DEC sales loved, but maybe it made a lot less profit than vt52s, decwriters and other io devices attached to your normal 11 chassis. Perhaps some architects made good use of it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Sat Apr 9 10:28:04 2022 From: phil at ultimate.com (Phil Budne) Date: Fri, 08 Apr 2022 20:28:04 -0400 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> Message-ID: <202204090028.2390S49F085864@ultimate.com> George Michaelson wrote: > I've never met anyone who did more than play on a gt40, myself included. I > suspect it was something DEC sales loved, but maybe it made a lot less > profit than vt52s, decwriters and other io devices attached to your normal > 11 chassis. > > Perhaps some architects made good use of it? Inside DEC they were used (with DEC-20s) to run the Stanford SUDS CAD software. p From cowan at ccil.org Sat Apr 9 11:46:10 2022 From: cowan at ccil.org (John Cowan) Date: Fri, 8 Apr 2022 21:46:10 -0400 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: On Thu, Apr 7, 2022 at 7:53 PM Rob Pike wrote: If you never ring the bell in the editor, the issue never comes up, the > code is simpler, and there's less to understand. > Well, yes. And by the same token, you can eliminate the complexities of i18n by having only one diagnostic, namely "?" (or by pretending all the world is anglophone). But setting aside for the moment this style of argumentation, let's consider directory colorization. I have no dog in this fight, as I set all my terminals to black-on-white as God and Gutenberg intended, and set TERM to vt100 so the colors can't be changed. However, the feature seems to be extremely popular, and can't be readily done outboard in a pipeline], unlike most of the infamous options of cat(1). As things stand, the X3.64 control sequences output by colorization are *not* suppressed when the output of ls isn't a terminal, which means I have had to write a stripper for them. Another example is cal(1), which tries to output the current day in reverse video, which is equally annoying but fortunately can be suppressed more easily by piping it through more(1). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sat Apr 9 11:53:55 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 9 Apr 2022 11:53:55 +1000 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: > > Kinda think you're running Rob's argument for him by inductive reasoning. If those other progroids read env() they could learn if colour was du Jure or not. No isatty() required. I think there always will be some special cases and like cardamom pods in curry you hate them when you bite them. G > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sat Apr 9 12:03:22 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 9 Apr 2022 12:03:22 +1000 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <202204090028.2390S49F085864@ultimate.com> References: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> <202204090028.2390S49F085864@ultimate.com> Message-ID: Feels like a good fit. If they'd got into the right hands in a uni they'd have been doing the same thing, but my personal sense was they mostly got to CS departments, small volumes went to people with real world 2D and 3D design drive, and when commodity high res scan displays went mass market then CAD bust out and rotring pen shares went south. There was this weird dichotomy that architecture schools would have analogue computers because air conditioning engineers used them, but they had to walk to the computer centre to do programming (this was my experience at Leeds uni basically) Vector graphics were sweet-as. People liked pixels better. More people would have experienced vector scan as asteroids or the tank game that made it into video game parlours but by then 75% plus of the cabinets were raster displays. The Tektronix 4010 at York was almost always free, people went to the apl decwriter before they'd use it. I really loved it! On Sat, 9 Apr 2022, 10:54 am Phil Budne, wrote: > George Michaelson wrote: > > I've never met anyone who did more than play on a gt40, myself > included. I > > suspect it was something DEC sales loved, but maybe it made a lot less > > profit than vt52s, decwriters and other io devices attached to your > normal > > 11 chassis. > > > > Perhaps some architects made good use of it? > > Inside DEC they were used (with DEC-20s) to run the Stanford SUDS CAD > software. > p > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Apr 9 13:33:06 2022 From: athornton at gmail.com (Adam Thornton) Date: Fri, 8 Apr 2022 20:33:06 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: If anyone wants a login on a basically-stock Multics 12.7 system, let me know in private. It's running on a Raspberry Pi, and I've really never done anything with it other than a minimal amount of poking around. It's exposed to the 'net through https://mvsevm.fsf.net. If there are other systems there anyone wants access to, lmk. Adam On Fri, Apr 8, 2022 at 2:12 PM Greg A. Woods wrote: > At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy wrote: > Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. > > > > Do we have any people around who actively used Multics long enough to > > develop a feel for it? My only experience is the printout that Rob > > Gingell had on his office door which was a description of Multics > > paging in library after library before it actually ran the program. > > I have no idea if it was that bad. > > I used Multics for a couple of my undergrad years at University of > Calgary (along with a PDP-11/60 and then a PDP-11/44 and a VAX 11/780, > with the DEC equipment running Unix of course: V7 on the 11s, and 32V > then 3BSD and finally 4BSD on the VAX). > > I never really appreciated Multics as much then (except for its LISP and > Emacs implementations), but have grown far more fond of it now that it > is effectively gone. > > > I guess what I'm trying to ask is if Multics had modern hardware > > under it, performed well, would we want to be running it? > > I think it would be most excellent, assuming it had kept up to modern > needs, used modern languages (there was already a C compiler for it) and > if modern hardware had continued to support it into the 64-bit era. > > The famous "everything is a file" description of Unix is wrong, or at > least misleadingly incomplete -- the correct description is more like: > "everything is a file _descriptor_"; whereas in Multics everything is > actually just a memory array (except for some communications devices). > > Single Level Storage is an awesome concept and removes so many ugly > hacks from algorithms that otherwise have to process data in files. > Doing data processing with read and write and pipes is effectively > working through a straw whereas SLS allows all (reasonably sized) data > to be presented in entirely complete randomly accessible arrays just by > attaching a "file" to a segment. Mmap() is a very poor replacement that > requires a great deal extra bookkeeping that's next to impossible to > hide from; and also there's the problem of the consistency semantics > being different between the I/O based filesystems and direct memory > mapping of their files, which Mmap() reveals, and which SLS eliminates > (by simply not having any I/O mechanism for files in the first place!). > > Multics dynamic linking makes any unix-ish implementation look most > ugly, incredibly insecure, and horribly inefficient. Unix shared > libraries are bad hack to simulate what Multics did natively and > naturally, with elegance, and with direct hardware security support. > > Both of these features of course strongly desire (for decent > performance) either something like the original hardware-based segmented > addressing scheme (e.g. as offered in Intel IA-32 and also tried to > offer in the iAPX432), or hardware similar to what capability-based > addressing schemes found in some research systems today [1]. Intel was > never pressured strongly enough into improving the performance of > segmented addressing and memory management in the IA-32 (because nothing > (but OS/2?) really used it heavily the way a multics-like OS would have, > and of course the iAPX432 also failed to deliver good performance), then > AMD never carried full segmentation support forward into their 64-bit > architecture and instruction set where it would have made larger scale > multics-like systems more practical. > > [1] The experimental CHERI architecture is an example: > > CHERI: Memory Segmentation to Support Secure Applications > > "A segment mechanism that implements the capability model of safe, > programmatic memory protection" > > http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2013essos-cheri.pdf > > > "CHERI can do anything Multics could do: segmentation, paging, > dynamic linking, ring-structured software" > > -- Peter G. Neumann in "An Interview with..." by Rick Farrow in > ;login:, Winter 2017 vol. 42, no. 4 > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Apr 9 15:49:18 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 09 Apr 2022 05:49:18 +0000 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: (Dave Horsfall's message of "Sat, 9 Apr 2022 08:44:57 +1000 (EST)") References: Message-ID: <7wtub2dcwx.fsf@junk.nocrew.org> Dave Horsfall wrote: >> I have fond memories of playing it on the GT-40, and if Andrew Hume >> is reading this he'll remember reverse-engineering the code and >> modifying it for three-play operation; I think Peter Ivanov also >> implemented reverse gravity... > Oops; reverse gravity (for the Sun) was implemented for Space Wars (or > whatever it was called; this was ~40 years ago, so don't expect my memory > to be the best). I wonder how many GT40 Spacewar implementations there were? I have seen two: one from MIT, the other from Stanford. From robpike at gmail.com Sat Apr 9 18:07:08 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 9 Apr 2022 18:07:08 +1000 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <7wtub2dcwx.fsf@junk.nocrew.org> References: <7wtub2dcwx.fsf@junk.nocrew.org> Message-ID: The PDP-11/40 in the University of Toronto's Computer Research Facility (CRF) had a GT-40, and the lead EE prof there loved the screen editor RT-11 provided for it. I never used it, but I was intrigued. (I did land the LM a few times, though. More than a few.) Across the raised floor aisle was the PDP-11/45, which ran Unix from 5PM to 8AM if I remember right, RT-11 the rest of the time, until some date around 1976 or 1977 (?), when Unix became an unstoppable force for innovation. -rob On Sat, Apr 9, 2022 at 4:35 PM Lars Brinkhoff wrote: > Dave Horsfall wrote: > >> I have fond memories of playing it on the GT-40, and if Andrew Hume > >> is reading this he'll remember reverse-engineering the code and > >> modifying it for three-play operation; I think Peter Ivanov also > >> implemented reverse gravity... > > Oops; reverse gravity (for the Sun) was implemented for Space Wars (or > > whatever it was called; this was ~40 years ago, so don't expect my > memory > > to be the best). > > I wonder how many GT40 Spacewar implementations there were? > I have seen two: one from MIT, the other from Stanford. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Apr 9 19:20:36 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 09 Apr 2022 09:20:36 +0000 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <7wtub2dcwx.fsf@junk.nocrew.org> References: <7wtub2dcwx.fsf@junk.nocrew.org> Message-ID: If I recall there was a GT40 up on the fourth floor of UMCP's CS building. I don't remember spacewar, but there was a luner lander game where you tried to land near the lunar McDonalds (if you crashed in to it, it chided you for destroying the only McDonalds on the moon). ------ Original Message ------ From: "Lars Brinkhoff" >I wonder how many GT40 Spacewar implementations there were? >I have seen two: one from MIT, the other from Stanford. From ralph at inputplus.co.uk Sat Apr 9 20:46:13 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 09 Apr 2022 11:46:13 +0100 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> References: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> Message-ID: <20220409104613.15F8321EE0@orac.inputplus.co.uk> Hi, Dave Horsfall wrote: > Eventually DEC Field Circus stopped replacing GT-40 switch registers > if they'd suspected that they were used for playing it :-) Andrew Hume wrote: > i do remember the DEC engineers being bothered about replacing the > registers. There's nothing at https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre)#Lunar_Lander_(1973) about the switch registers being worn by playing Burness's Moonlander. What's the connection? There are a couple of links from that section to interesting pages with quotes from Burness, https://www.acriticalhit.com/moonlander-one-giant-leap-for-game-design https://www.technologizer.com/2009/07/19/lunar-lander/ which include a photo that's captioned as Burness and Moonlander from circa '74: https://www.acriticalhit.com/wp-content/uploads/2021/04/unnamed-LG-2.png -- Cheers, Ralph. From ggm at algebras.org Sat Apr 9 20:51:24 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 9 Apr 2022 20:51:24 +1000 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <20220409104613.15F8321EE0@orac.inputplus.co.uk> References: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> <20220409104613.15F8321EE0@orac.inputplus.co.uk> Message-ID: There was a hack to stop the game and reload fuel and go 4000 to continue. Maybe people who did not expect the front console to be used so heavily broke the funky rocker switches. G On Sat, 9 Apr 2022, 8:46 pm Ralph Corderoy, wrote: > Hi, > > Dave Horsfall wrote: > > Eventually DEC Field Circus stopped replacing GT-40 switch registers > > if they'd suspected that they were used for playing it :-) > > Andrew Hume wrote: > > i do remember the DEC engineers being bothered about replacing the > > registers. > > There's nothing at > > https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre)#Lunar_Lander_(1973) > about the switch registers being worn by playing Burness's Moonlander. > What's the connection? > > There are a couple of links from that section to interesting pages with > quotes from Burness, > https://www.acriticalhit.com/moonlander-one-giant-leap-for-game-design > https://www.technologizer.com/2009/07/19/lunar-lander/ > which include a photo that's captioned as Burness and Moonlander from > circa '74: > > https://www.acriticalhit.com/wp-content/uploads/2021/04/unnamed-LG-2.png > > -- > Cheers, Ralph. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Apr 9 21:10:07 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 9 Apr 2022 05:10:07 -0600 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: <7wtub2dcwx.fsf@junk.nocrew.org> Message-ID: On Sat, Apr 9, 2022, 2:10 AM Rob Pike wrote: > The PDP-11/40 in the University of Toronto's Computer Research Facility > (CRF) had a GT-40, and the lead EE prof there loved the screen editor RT-11 > provided for it. I never used it, but I was intrigued. (I did land the LM a > few times, though. More than a few.) > > Across the raised floor aisle was the PDP-11/45, which ran Unix from 5PM > to 8AM if I remember right, RT-11 the rest of the time, until some date > around 1976 or 1977 (?), when Unix became an unstoppable force for > innovation. > Also the approximate date of the rt11 emulation being viable on Unix... Warner -rob > > > On Sat, Apr 9, 2022 at 4:35 PM Lars Brinkhoff wrote: > >> Dave Horsfall wrote: >> >> I have fond memories of playing it on the GT-40, and if Andrew Hume >> >> is reading this he'll remember reverse-engineering the code and >> >> modifying it for three-play operation; I think Peter Ivanov also >> >> implemented reverse gravity... >> > Oops; reverse gravity (for the Sun) was implemented for Space Wars (or >> > whatever it was called; this was ~40 years ago, so don't expect my >> memory >> > to be the best). >> >> I wonder how many GT40 Spacewar implementations there were? >> I have seen two: one from MIT, the other from Stanford. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sat Apr 9 21:45:10 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 9 Apr 2022 07:45:10 -0400 Subject: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians Message-ID: > Single Level Storage is an awesome concept and removes so many ugly > hacks from algorithms that otherwise have to process data in files. This was Vic Vyssotsky's signature contribution to Multics, though in typical Vyssotsky fashion he never sought personal credit for it. Other awesome Vyssotsky inventions: BLODI (block diagram), the first data-flow language, for sample-data systems. Parallel flow analysis (later reinvented and published by John Cocke). Vic installed this in Fortran to produce diagnostics such as, "If the third branch of IF statement 15 is ever taken, then variable E will be used before being set". Darwin, the original game of predation and self-reproduction among programs. Corewars.org keeps a descendant version going 60 years later. A minimum-spanning-tree algorithm quite different from the well-known methods due to his colleagues Bob Prim and Joe Kruskal, again unpublished. Not long ago on TUHS, Andrew Hume told how Vic found the same isolated bug in dc by mathematically generating hard cases that Andrew stumbled on by accident, As you may infer, Vic is one of my personal computing heroes. Doug From tytso at mit.edu Sat Apr 9 22:10:21 2022 From: tytso at mit.edu (tytso) Date: Sat, 9 Apr 2022 08:10:21 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote: > Single Level Storage is an awesome concept and removes so many ugly > hacks from algorithms that otherwise have to process data in files. > Doing data processing with read and write and pipes is effectively > working through a straw whereas SLS allows all (reasonably sized) data > to be presented in entirely complete randomly accessible arrays just by > attaching a "file" to a segment. Mmap() is a very poor replacement that > requires a great deal extra bookkeeping that's next to impossible to > hide from; and also there's the problem of the consistency semantics > being different between the I/O based filesystems and direct memory > mapping of their files, which Mmap() reveals, and which SLS eliminates > (by simply not having any I/O mechanism for files in the first place!). To be fair, Multics had it a lot easier, because core memory meant that every single memory access could be considered "durable storage", so there was no real need for "fsync(2)" or "msync(2)". So I/O consistency could be done much like writing to persistent memory, except that there would be no need for "CLFLUSH" (Who needs multi-level memory caches when the clock cycle is pathetically slow?) and no need to worry about write endurance exhaustion with core memory, either. So how much of the consistency benefits are due to the hardware, and how much is due to the OS? We could just as easily claim that Multics is superior to Unix because it's immune to Spectre and Meltdown attacks --- except that Unix on a PDP-11 would be immune to cache based attacks as well. Of course, Unix on a PDP-11 is a lot slower than NetBSD on an modern x86_64 machines.... > Multics dynamic linking makes any unix-ish implementation look most > ugly, incredibly insecure, and horribly inefficient. Unix shared > libraries are bad hack to simulate what Multics did natively and > naturally, with elegance, and with direct hardware security support. What if we compared Multics dynamic linking to Solaris Doors? - Ted From crossd at gmail.com Sat Apr 9 23:09:10 2022 From: crossd at gmail.com (Dan Cross) Date: Sat, 9 Apr 2022 09:09:10 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: On Sat, Apr 9, 2022, 8:18 AM tytso wrote: > On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote: > > Single Level Storage is an awesome concept and removes so many ugly > > hacks from algorithms that otherwise have to process data in files. > > Doing data processing with read and write and pipes is effectively > > working through a straw whereas SLS allows all (reasonably sized) data > > to be presented in entirely complete randomly accessible arrays just by > > attaching a "file" to a segment. Mmap() is a very poor replacement that > > requires a great deal extra bookkeeping that's next to impossible to > > hide from; and also there's the problem of the consistency semantics > > being different between the I/O based filesystems and direct memory > > mapping of their files, which Mmap() reveals, and which SLS eliminates > > (by simply not having any I/O mechanism for files in the first place!). > > To be fair, Multics had it a lot easier, because core memory meant > that every single memory access could be considered "durable storage", > so there was no real need for "fsync(2)" or "msync(2)". > This may have been true of the very first Multics machines, but it appears they switched to solid state memory sometime in the 70s (it's not clear to me when the SCUs attached to the 6180 switched from core to DRAM: https://gunkies.org/wiki/Honeywell_6000_series). By the time the DPS8/M rolled out we must assume they had DRAM. Apparently a cache hierarchy was added eventually. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Sat Apr 9 23:09:39 2022 From: stewart at serissa.com (Larry Stewart) Date: Sat, 9 Apr 2022 09:09:39 -0400 Subject: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians In-Reply-To: References: Message-ID: <8421E032-BD2B-4512-833F-833382FDE559@serissa.com> I worked for Vic at the Digital Cambridge Research Lab. Entirely awesome. Another Vic story is how he got sent to visit the Pave Paws radar on Cape Cod because the locals were worried that software errors in the phased array controls could zap the populace. Vic talked to the radar people and found out that there was a hardware stop that prevented beam angles below 3 degrees, so there was no need to worry about bugs. Vic would always remember what the original problem was, rather than get lost in irrelevant details. -L > On Apr 9, 2022, at 7:48 AM, Douglas McIlroy wrote: > >  >> >> Single Level Storage is an awesome concept and removes so many ugly >> hacks from algorithms that otherwise have to process data in files. > > This was Vic Vyssotsky's signature contribution to Multics, though in typical > Vyssotsky fashion he never sought personal credit for it. Other awesome > Vyssotsky inventions: > > BLODI (block diagram), the first data-flow language, for sample-data systems. > > Parallel flow analysis (later reinvented and published by John Cocke). Vic > installed this in Fortran to produce diagnostics such as, "If the > third branch of IF > statement 15 is ever taken, then variable E will be used before being set". > > Darwin, the original game of predation and self-reproduction among programs. > Corewars.org keeps a descendant version going 60 years later. > > A minimum-spanning-tree algorithm quite different from the well-known methods > due to his colleagues Bob Prim and Joe Kruskal, again unpublished. > > Not long ago on TUHS, Andrew Hume told how Vic found the same isolated bug in > dc by mathematically generating hard cases that Andrew stumbled on by accident, > > As you may infer, Vic is one of my personal computing heroes. > > Doug From andrew at humeweb.com Sun Apr 10 00:30:54 2022 From: andrew at humeweb.com (Andrew Hume) Date: Sat, 9 Apr 2022 07:30:54 -0700 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <20220409104613.15F8321EE0@orac.inputplus.co.uk> References: <3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com> <20220409104613.15F8321EE0@orac.inputplus.co.uk> Message-ID: <54F35D50-9896-4146-927F-AE545FDE9358@humeweb.com> the connection is that these are switch registers on the front panel. they ae designed for occasional use, not for long sessions with multiple people flipping them on and off for hours on end. they did last well, but its certainly not what they were designed for. > On Apr 9, 2022, at 3:46 AM, Ralph Corderoy wrote: > > Hi, > > Dave Horsfall wrote: >> Eventually DEC Field Circus stopped replacing GT-40 switch registers >> if they'd suspected that they were used for playing it :-) > > Andrew Hume wrote: >> i do remember the DEC engineers being bothered about replacing the >> registers. > > There's nothing at > https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre)#Lunar_Lander_(1973) > about the switch registers being worn by playing Burness's Moonlander. > What's the connection? From clemc at ccc.com Sun Apr 10 02:23:40 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 9 Apr 2022 12:23:40 -0400 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: <7wtub2dcwx.fsf@junk.nocrew.org> Message-ID: On Sat, Apr 9, 2022 at 5:29 AM Ron Natalie wrote: > If I recall there was a GT40 up on the fourth floor of UMCP's CS > building. I don't remember spacewar, but there was a luner lander game > where you tried to land near the lunar McDonalds (if you crashed in to > it, it chided you for destroying the only McDonalds on the moon). > > That's Jack's Moonlander. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Apr 10 04:05:05 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 09 Apr 2022 20:05:05 +0200 Subject: [TUHS] Why does shell write to stderr? In-Reply-To: References: Message-ID: <20220409180505.bKC2a%steffen@sdaoden.eu> John Cowan wrote in : |On Thu, Apr 7, 2022 at 7:53 PM Rob Pike wrote: |If you never ring the bell in the editor, the issue never comes up, the |> code is simpler, and there's less to understand. | |Well, yes. And by the same token, you can eliminate the complexities of |i18n by having only one diagnostic, namely "?" (or by pretending all the |world is anglophone). | |But setting aside for the moment this style of argumentation, let's |consider directory colorization. I have no dog in this fight, as I set all |my terminals to black-on-white as God and Gutenberg intended, and set TERM Johannes Gutenberg? The bible was in parts red-on-white at least, and had beautiful coloured paintings, too. (They did not know about the communist Charlie Chaplin and his Modern Times by then.) ... --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 kenbob at gmail.com Sun Apr 10 04:25:41 2022 From: kenbob at gmail.com (Ken Thompson) Date: Sat, 9 Apr 2022 11:25:41 -0700 Subject: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians In-Reply-To: References: Message-ID: vic was my department head upon my arrival at bell labs (june 1966). i went to my assigned office and found vic, in combat boots, in a lotus position on top of my filing cabinet. it is a vision that i will never forget. he had just come to introduce himself. On Sat, Apr 9, 2022 at 4:48 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > Single Level Storage is an awesome concept and removes so many ugly > > hacks from algorithms that otherwise have to process data in files. > > This was Vic Vyssotsky's signature contribution to Multics, though in > typical > Vyssotsky fashion he never sought personal credit for it. Other awesome > Vyssotsky inventions: > > BLODI (block diagram), the first data-flow language, for sample-data > systems. > > Parallel flow analysis (later reinvented and published by John Cocke). Vic > installed this in Fortran to produce diagnostics such as, "If the > third branch of IF > statement 15 is ever taken, then variable E will be used before being set". > > Darwin, the original game of predation and self-reproduction among > programs. > Corewars.org keeps a descendant version going 60 years later. > > A minimum-spanning-tree algorithm quite different from the well-known > methods > due to his colleagues Bob Prim and Joe Kruskal, again unpublished. > > Not long ago on TUHS, Andrew Hume told how Vic found the same isolated bug > in > dc by mathematically generating hard cases that Andrew stumbled on by > accident, > > As you may infer, Vic is one of my personal computing heroes. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Sun Apr 10 05:14:43 2022 From: woods at robohack.ca (Greg A. Woods) Date: Sat, 09 Apr 2022 12:14:43 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: At Sat, 9 Apr 2022 08:10:21 -0400, tytso wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. > > To be fair, Multics had it a lot easier, because core memory meant > that every single memory access could be considered "durable storage", > so there was no real need for "fsync(2)" or "msync(2)". As Dan mentioned, actual "core" memory was long gone by the time Multics was in commercial use. Core memory was only used in the first-generation 6000 series (and presumably the GE-635 too), i.e. before 1975. One source says there was cache memory in the CPUs as early as 1974. The later machines, such as the DPS-8/70M ("M" for Multics) definitely came with 8KW cache memory that could be expanded up to 32KW. These systems were also generally used in multi-processing configurations, especially for Multics, with multiple CPUs, each with potentially multiple memory units (and multiple IOMm (I/O Multiplexer), later IMUs (Information Multiplexer Unit)). As for how this cache memory was used and how its consistency with main memory and with secondary storage was maintained, I don't know myself, but of course much documentation about Multics internals is available, along with all the source code, and it is running on simulators today. > > Multics dynamic linking makes any unix-ish implementation look most > > ugly, incredibly insecure, and horribly inefficient. Unix shared > > libraries are bad hack to simulate what Multics did natively and > > naturally, with elegance, and with direct hardware security support. > > What if we compared Multics dynamic linking to Solaris Doors? I don't think Doors is really relatable to Multics dynamic linking. As I understand it, Doors is more like RPC than directly shared code. In Multics all code, even kernel code, is generally shared -- in broad terms user processes just "gate" (i.e. jump) directly to code in a lower/inner "ring" to run system calls (e.g. Ring-0). Code doesn't even have to exist when first called (similar to how methods don't have to pre-exist in Smalltalk) -- the user gets a "linkage fault" and can write and compile the missing code and continue a program at the fault point. Also there's no such thing as "relocation" of code in Multics -- segmented memory means all segments have their own zero address and so all code is pure procedure and can be executed by many processes simultaneously simply by mapping the shared code segments into each process (as read-only, executable). Shared libraries of a sort (bound segments) do exist, partly because of performance issues (dynamic link faults are expensive in Multics, especially on hardware of the day), and partly because of addressing limitations (only a quite limited number of segments can be attached to any given process), and partly because otherwise there would be effectively one global namespace for all symbols exposed by each compilation unit in a user's $PATH. One of the difficult things for Unix people to wrap their heads around is the difference between a "process" in Unix and in Multics. One way to think about it that has helped me figure it out is this: In Multics you have a "shell" program which you interact with just like with "sh" in Unix, but it's not a separate process in Multics -- just a unit of code that effectively runs when no other program is running. So generally a user only runs one process at a time, even though it may transition through hundreds or thousands of programs during its existence. Multics did eventually have the concept of multi-threading and a form of co-operative multi-tasking too, though I don't know as much about these. I think the latter would/could effectively be like having multiple processes in one login session in Unix and it is said this facility was used to implement network service daemons for example. Now I don't believe the Multics concept of "process" is strictly necessary to support its concepts of Single Level Storage or even Dynamic Linking. I believe those could be used equally well in a system with more Unix-like processes, though some mix of concepts might be required to truly benefit from all the features of Multics-style dynamic linking. One way I've been thinking of Multics lately is that it's more like modern virtualization (e.g. Xen), but with added OS services such as a filesystem and controlled access to shared "inner ring" code; and indeed that's more or less how it was described in early Multics concept papers, assuming you transmogrify the old terminology of the day into modern lingo. Each user gets a computing environment that gives them the impression they have full use of the machine, and it comes along with pre-existing useful code and various useful services, including a filesystem the ability to communicate with other users and other machines. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From woods at robohack.ca Sun Apr 10 05:28:47 2022 From: woods at robohack.ca (Greg A. Woods) Date: Sat, 09 Apr 2022 12:28:47 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> Message-ID: At Fri, 8 Apr 2022 17:34:27 -0600, Andrew Warkentin wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. > > I think it's useful to have both I/O and memory views for files. > Things like commands that work equally well whether stdout is a disk > file or something like a pipe wouldn't work so well in a system where > disk files can only be accessed through a memory-like interface. > However, I guess the I/O interface could just be implemented with > library functions rather than real I/O syscalls for disk-like files. I/O is good for I/O of course (e.g. to devices, like terminals and printers and such), and if you can "attach" that I/O to a segment, or to another program's I/O, all the better: https://multicians.org/myths.html#nofile (One big complication forced by hardware limitations of the day was rather limited file (i.e. segment) size, and thus Multics developers invented multi-segment files, and as mentioned in that link, stream access to them was often through the I/O mechanism, but of course this was a simulation done by copying (I think) data from a mapped segment of the file to a buffer in a heap segment.) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From iain at csp-partnership.co.uk Sun Apr 10 20:14:26 2022 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Sun, 10 Apr 2022 11:14:26 +0100 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: References: <7wtub2dcwx.fsf@junk.nocrew.org> Message-ID: <56E98893-A6D1-48A5-9AC2-5CDD37638417@csp-partnership.co.uk> > On 9 Apr 2022, at 17:23, Clem Cole wrote: > > > > On Sat, Apr 9, 2022 at 5:29 AM Ron Natalie > wrote: > If I recall there was a GT40 up on the fourth floor of UMCP's CS > building. I don't remember spacewar, but there was a luner lander game > where you tried to land near the lunar McDonalds (if you crashed in to > it, it chided you for destroying the only McDonalds on the moon). > > That's Jack's Moonlander. It is OK for you Americans. We ran the GT40 in Scotland about 1974 (2nd year undergrad). When the astronaut got out and said “a big mac to go” we had absolutely no idea what he was talking about! “a big mac” meant nothing and “to go” was just bad grammar. Worse grammar than the split infinitives in star trek. I am sure we did not have a Macdonalds in Scotland at that time. We did have KFC under the uni - many a late-night chew while solving programming problems …. But Macdonalds? They were well into the 80s…... It was years later before any of us actually understood what was being said, but yes, a great way to spend debugging hours in the early hours of the morning. I can only just remember the use of the light pen - was that for thrust? I have no recollection of any keyboard inputs. Iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Apr 10 23:40:26 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 10 Apr 2022 09:40:26 -0400 Subject: [TUHS] Sad News - we last two wonderful people in the past few weeks. In-Reply-To: <56E98893-A6D1-48A5-9AC2-5CDD37638417@csp-partnership.co.uk> References: <7wtub2dcwx.fsf@junk.nocrew.org> <56E98893-A6D1-48A5-9AC2-5CDD37638417@csp-partnership.co.uk> Message-ID: Knowing Jack, I think I safely say he would have been amused by the different reactions. Just remember when he wrote that I do not think there was a mikyd’s anywhere close to Maynard. Jack was a child of the Bronx which made his love of the outdoors all the more real. Maynard (Mare Assabet) really was desolate in comparison. On Sun, Apr 10, 2022 at 6:14 AM Dr Iain Maoileoin < iain at csp-partnership.co.uk> wrote: > > On 9 Apr 2022, at 17:23, Clem Cole wrote: > > > > On Sat, Apr 9, 2022 at 5:29 AM Ron Natalie wrote: > >> If I recall there was a GT40 up on the fourth floor of UMCP's CS >> building. I don't remember spacewar, but there was a luner lander game >> where you tried to land near the lunar McDonalds (if you crashed in to >> it, it chided you for destroying the only McDonalds on the moon). >> >> That's Jack's Moonlander. > > > It is OK for you Americans. We ran the GT40 in Scotland about 1974 (2nd > year undergrad). > > When the astronaut got out and said “a big mac to go” we had absolutely > no idea what he was talking about! > “a big mac” meant nothing and “to go” was just bad grammar. Worse grammar > than the split infinitives in star trek. > > I am sure we did not have a Macdonalds in Scotland at that time. We did > have KFC under the uni - many a late-night chew while solving programming > problems …. > But Macdonalds? They were well into the 80s…... > > It was years later before any of us actually understood what was being > said, but yes, a great way to spend debugging hours in the early hours of > the morning. > I can only just remember the use of the light pen - was that for thrust? > I have no recollection of any keyboard inputs. > > Iain > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon Apr 11 03:14:22 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 10 Apr 2022 13:14:22 -0400 (EDT) Subject: [TUHS] Interesting commentary on Unix from Multicians. Message-ID: <20220410171422.600D018C0D5@mercury.lcs.mit.edu> > From: Rich Morin > I'd love to hear from some folks who have used both Multics and > Unix(ish) systems about things that differ and how they affect the > user experience. {This is a bit behind the flow of the conversation, because I wanted to ponder for a while what I was going to say on this, to me, important topic.} Technicaly, I don't quite qualify (more below), but I do have an interesting perspective: I was the very first Unix person in the 'Multics' group at MIT-LCS - the Computer Systems Group, which contained Corby and Jerry Saltzer. The interesting thing, which may surprise some people, is that I _never_ got any 'anti-Unix' static from anyone in the group, that I can remember. (Maybe one grad student, who was a bit abrasive, but he and I had a run-in that was mostly? caused by my fairly rapid assumption, as an un-paid undergrad, of a significant role in the group's on-going research work. So that may have bled across a bitt, to Unix, which was 'my' baby.) I'm not sure what _they_ all made of Unix. None of us knew, of course, where it was going to go. But I don't recall getting any 'oh, it's just a toy system' (an attitude I'm _very_ familiar with, since it was what the TCP/IP people got from _some_ members of what later became the ISO effort). Of course, our Unix was a tiny little PDP-11/40 - not a building-sized multi-processor 'information utility' mainframe - so they may well have not thought of it in the same frame as Multics. Also, by the time I arrived the group was doing nothing on Multics (except below); everyone was focused on networks. So OS's were no longer a topic of much research interest, which may also have contributed. Anyway, technically, I don't count for the above, because I never actualy wrote code on Multics. However, I had studied it extensively, and I worked very closely with Dave Clark (a younger Multics light, later a leading figure in the early TCP/IP work) on projects that involved Multics and my machine, so I got to see up close what Multics was like as a system environment, as he worked on his half of the overall project. I've also pondered Multics in the decades since; so here's my take. I really, really liked Unix (we were running what turns out to have been basicaly a PWB1 system - V6, with some minor upgrades). I learned about it the way many did; I read the manuals, and then dove into the system source (which I came to know quite well, as I was tasked with producing a piece that involved a major tweak - asynchronous 'raw' DMA I/O directly to user processes). Unfortunately, one of the two (to me) best things about Unix, is something it has since lost - which is its incredible bang/buck ratio - to be more precise, the functionality/complexity ratio of the early versions of the system. (Its other important aspect, I think, was that its minimal demands of the underlying hardware [unlike Multics, which was irretrievably bound to the segmentation, and the inter-segment data and code connection] along with its implementation in what turned out to be a fairly portable language (except for the types; I had to make up what amounted to new ones.) So, what was Multics' major difference from other systems - and why was it good? I'd say that it was Multics' overall structuring mechanisms - the single-level store, with the ability to have code and data pointers between segments - and what that implied for both the OS itself, and major 'applications' (some of them part of the OS, although not the 'kernel' - like networking code). Unix had (and still may have, I'm not up on Linux, etc) a really major, hard boundary beween 'user' code, in processes,and the kernel. There are 'instructions' that invoke system primitives - but not too many, and limited interactions across that boundary. So, restricted semantics. Which was good in that it helped keep the system simple and clear - but it limited the flexibilty and richness of the interface. (Imagine building a large application which had a hard boundary across the middle of it, with extremely limited interactions across the boundary. Just so with the interface in Unix between 'user' code, and the kernel.) Multics is very different. The interface to the OS is subroutine calls, and one can easily pass complex data structures, including pointers to other data, any of which can be in the 'user's' memory, as arguments to them. The _exact_ same _kind_ of interface was available to _other_ major subsystems, not just the OS kernel. As I've mentioned before, Dave's TCP/IP for Multics was not in the kernel - it was ordinary user code! And he was able to work on it, test and install new versions - while the system was up for normal useage! Dave's TCP/IP subsystem included i) a process, which received all incoming ackets, and also managed/handled a lot of the timers involved (e.g. retransmission timeouts); ii) data segment(s), which included things like buffered un-acknowledged data (so that if a retransmission timer went off, the process would wake up and retransmit the data); iii) code segment(s): iiia) some for use by the process, like incoming packet processing; iiib) some which were logically part of the subsystem, but which were called by subroutine calls from the _user_'s process; and iiic) some which were commands (called by the user's shell), which called those iiib) procedures. (There were issues in security because Multics didn't have the equivalent of 'set-user-id' on a cross-subsystem subroutine calls - although I think there had been plans early on for that. When Dave's code was taken over by Honeywell, for 'production' use, whole whole thing was moved into a lower ring, so the database didn't have to be world-writeable in the user ring.) This is typical of the kind of structure that was relatively easy to build in Multics. Yes, one can do similar application without all those underlying mechanism; but Turing-completeness says one doeesn't need stacks to compute anything - but would any of us want to work in a system that didn't have stacks? We have stacks because they are useful. True, simple user applications don't need all that - but as one builds more and more complex support subsytems, that kind of environment turns out to be good to have. Think of a window system, in that kind of environment. Those 'tools' (inter-segment subroutine calls, etc) were created to build the OS, but they turned out to be broadly useful for _other_ complicated subsystems. I'm not sure I've explained this all wel, but I'm not sure I can fully cover the topic with less than a book. Noel From lm at mcvoy.com Mon Apr 11 03:31:51 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 10 Apr 2022 10:31:51 -0700 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <20220410171422.600D018C0D5@mercury.lcs.mit.edu> References: <20220410171422.600D018C0D5@mercury.lcs.mit.edu> Message-ID: <20220410173151.GO6248@mcvoy.com> On Sun, Apr 10, 2022 at 01:14:22PM -0400, Noel Chiappa wrote: > Unfortunately, one of the two (to me) best things about Unix, is something it > has since lost - which is its incredible bang/buck ratio - to be more > precise, the functionality/complexity ratio of the early versions of the > system. Amen to that though I think our memory is clouded by V6 that was uniprocessor, no networking. With all due respect to Unix, that's not a hard problem. Systems today are more complex with SMP, NUMA, networking, etc. > Which was good in that it helped keep the system simple and clear - but it > limited the flexibilty and richness of the interface. (Imagine building a > large application which had a hard boundary across the middle of it, with > extremely limited interactions across the boundary. Just so with the > interface in Unix between 'user' code, and the kernel.) That has changed in the last decade or two. Pugs did the work to expose the IOMMU to user process and that has definitely blurred the line. Thanks for your thoughtful email, I'm still absorbing it. From cowan at ccil.org Mon Apr 11 06:41:36 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 10 Apr 2022 16:41:36 -0400 Subject: [TUHS] Interesting commentary on Unix from Multicians. In-Reply-To: <20220410171422.600D018C0D5@mercury.lcs.mit.edu> References: <20220410171422.600D018C0D5@mercury.lcs.mit.edu> Message-ID: On Sun, Apr 10, 2022 at 1:18 PM Noel Chiappa wrote: > Unix had (and still may have, I'm not up on Linux, etc) a really major, > hard > boundary beween 'user' code, in processes,and the kernel. There are > 'instructions' that invoke system primitives - but not too many, and > limited > interactions across that boundary. So, restricted semantics. > The same is true for the more recent Unix variants, modulo a few special cases such as Larry mentions, but broadly speaking userland and the kernel are still separated. > Imagine building a > large application which had a hard boundary across the middle of it, with > extremely limited interactions across the boundary. > You mean like the Web? :-) In 2000-2005 I wrote a substantial quasi-batch application that supported $EMPLOYER's main product and was written about half in shell scripts and half in Perl, or more accurately entirely in shell scripts, but if I needed a pipeline component that wasn't already available in SunOS or as third-party open source, I wrote it in Perl. (There was a single 10-line C program to eliminate a performance bottleneck.) So the application as a whole was full of hard boundaries across which nothing could pass except text streams; I found that this added substantially to its debuggability and maintainability. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Apr 12 05:24:40 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 11 Apr 2022 15:24:40 -0400 Subject: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians In-Reply-To: References: Message-ID: On Sat, Apr 9, 2022 at 2:29 PM Ken Thompson wrote: > vic was my department head upon my arrival at > bell labs (june 1966). i went to my assigned office > and found vic, in combat boots, in a lotus position > on top of my filing cabinet. it is a vision that i will > never forget. he had just come to introduce himself. > This is a great story, though I confess that the thought of sitting like that sounds rather uncomfortable. I wonder if either or both of you, Ken, and Doug, could talk a little about the Bell Labs withdrawal from Multics from your perspectives? What was that like, and what was your relationship with the folks at MIT still at Project MAC like afterwards? I gather it was friendly; was there any collaboration there beyond casual correspondence? - Dan C. On Sat, Apr 9, 2022 at 4:48 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> > Single Level Storage is an awesome concept and removes so many ugly >> > hacks from algorithms that otherwise have to process data in files. >> >> This was Vic Vyssotsky's signature contribution to Multics, though in >> typical >> Vyssotsky fashion he never sought personal credit for it. Other awesome >> Vyssotsky inventions: >> >> BLODI (block diagram), the first data-flow language, for sample-data >> systems. >> >> Parallel flow analysis (later reinvented and published by John Cocke). >> Vic >> installed this in Fortran to produce diagnostics such as, "If the >> third branch of IF >> statement 15 is ever taken, then variable E will be used before being >> set". >> >> Darwin, the original game of predation and self-reproduction among >> programs. >> Corewars.org keeps a descendant version going 60 years later. >> >> A minimum-spanning-tree algorithm quite different from the well-known >> methods >> due to his colleagues Bob Prim and Joe Kruskal, again unpublished. >> >> Not long ago on TUHS, Andrew Hume told how Vic found the same isolated >> bug in >> dc by mathematically generating hard cases that Andrew stumbled on by >> accident, >> >> As you may infer, Vic is one of my personal computing heroes. >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Apr 25 01:24:37 2022 From: rminnich at gmail.com (ron minnich) Date: Sun, 24 Apr 2022 08:24:37 -0700 Subject: [TUHS] whereis command Message-ID: can someone point me at the earliest version of whereis? I first saw it in 4.1, but maybe it came sooner. Also, if you've got a link to man pages, thanks in advance. I'm trying but failing to find it. My daughter says I suck at web search, which, given where I work, is a bid sad :-) From arnold at skeeve.com Mon Apr 25 01:48:16 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 24 Apr 2022 09:48:16 -0600 Subject: [TUHS] whereis command In-Reply-To: References: Message-ID: <202204241548.23OFmGSC002546@freefriends.org> ron minnich wrote: > can someone point me at the earliest version of whereis? I first saw > it in 4.1, but maybe it came sooner. Also, if you've got a link to man > pages, thanks in advance. > > I'm trying but failing to find it. My daughter says I suck at web > search, which, given where I work, is a bid sad :-) Looks like 2.79 BSD. From the TUHS archives: $ tar -tzvf 2.79bsd.tar.gz | grep /whereis -rwxr-xr-x 0/0 4412 1979-04-21 06:34 bin.v6/ucb/whereis -rw-r--r-- 0/0 1692 1981-01-13 17:37 man/whereis.u -rw-r--r-- 0/0 4519 1981-01-13 17:37 src/whereis.c -rw-r--r-- 0/0 3851 1979-04-19 07:04 upgrade/src/whereis.c Hope this helps. Arnold From rminnich at gmail.com Mon Apr 25 01:59:57 2022 From: rminnich at gmail.com (ron minnich) Date: Sun, 24 Apr 2022 08:59:57 -0700 Subject: [TUHS] whereis command In-Reply-To: <202204241548.23OFmGSC002546@freefriends.org> References: <202204241548.23OFmGSC002546@freefriends.org> Message-ID: Thanks. I did find a newer-ish version and I always get a kick out of stuff like this: free_dirlist(&ls, ALL_DIRS); right before the call to exit ... an inappropriate response to an inappropriate warning, I suppose I once had an intern ask me "but if you don't free memory before the program exits, then it can never get used again, right?" :-) (and yes, I know, in the paleo era, that was in fact true) I'll go try to find that archive ... ron On Sun, Apr 24, 2022 at 8:48 AM wrote: > > ron minnich wrote: > > > can someone point me at the earliest version of whereis? I first saw > > it in 4.1, but maybe it came sooner. Also, if you've got a link to man > > pages, thanks in advance. > > > > I'm trying but failing to find it. My daughter says I suck at web > > search, which, given where I work, is a bid sad :-) > > Looks like 2.79 BSD. From the TUHS archives: > > $ tar -tzvf 2.79bsd.tar.gz | grep /whereis > -rwxr-xr-x 0/0 4412 1979-04-21 06:34 bin.v6/ucb/whereis > -rw-r--r-- 0/0 1692 1981-01-13 17:37 man/whereis.u > -rw-r--r-- 0/0 4519 1981-01-13 17:37 src/whereis.c > -rw-r--r-- 0/0 3851 1979-04-19 07:04 upgrade/src/whereis.c > > Hope this helps. > > Arnold From david at kdbarto.org Mon Apr 25 02:31:35 2022 From: david at kdbarto.org (David Barto) Date: Sun, 24 Apr 2022 09:31:35 -0700 Subject: [TUHS] whereis command In-Reply-To: References: <202204241548.23OFmGSC002546@freefriends.org> Message-ID: <1CE39A9F-A3B5-45E3-A48E-D70010BB51E1@kdbarto.org> > On Apr 24, 2022, at 8:59 AM, ron minnich wrote: > > Thanks. > > I did find a newer-ish version and I always get a kick out of stuff like this: > > free_dirlist(&ls, ALL_DIRS); > > right before the call to exit ... an inappropriate response to an > inappropriate warning, I suppose > > I once had an intern ask me "but if you don't free memory before the > program exits, then it can never get used again, right?" :-) > > (and yes, I know, in the paleo era, that was in fact true) > > I'll go try to find that archive ... > > ron > At $WORK we have a standing rule that all memory must be freed before the program exits. This is to ensure that the rest of the program doesn’t have any memory leaks. ASAN, UBSAN, Valgrind and the rest are good and far from perfect for detection of problems. However making sure to free all memory before exit() does aid them in finding problems early. David > On Sun, Apr 24, 2022 at 8:48 AM wrote: >> >> ron minnich wrote: >> >>> can someone point me at the earliest version of whereis? I first saw >>> it in 4.1, but maybe it came sooner. Also, if you've got a link to man >>> pages, thanks in advance. >>> >>> I'm trying but failing to find it. My daughter says I suck at web >>> search, which, given where I work, is a bid sad :-) >> >> Looks like 2.79 BSD. From the TUHS archives: >> >> $ tar -tzvf 2.79bsd.tar.gz | grep /whereis >> -rwxr-xr-x 0/0 4412 1979-04-21 06:34 bin.v6/ucb/whereis >> -rw-r--r-- 0/0 1692 1981-01-13 17:37 man/whereis.u >> -rw-r--r-- 0/0 4519 1981-01-13 17:37 src/whereis.c >> -rw-r--r-- 0/0 3851 1979-04-19 07:04 upgrade/src/whereis.c >> >> Hope this helps. >> >> Arnold From dds at aueb.gr Mon Apr 25 02:27:57 2022 From: dds at aueb.gr (Diomidis Spinellis) Date: Sun, 24 Apr 2022 16:27:57 +0000 (UTC) Subject: [TUHS] whereis command In-Reply-To: References: Message-ID: <0ffe431b-6e0a-4bf6-b991-e78d4ac2dbf2@aueb.gr> According to the index of documented Unix facilities [1] it first appeared in 2 BSD [2]. [1] https://dspinellis.github.io/unix-history-man/man1.html [2] https://dspinellis.github.io/manview/?src=https%3A%2F%2Fraw.githubusercontent.com%2Fdspinellis%2Funix-history-repo%2FBSD-2%2Fman%2Fwhereis.u&name=BSD%202%3A%20whereis(1)&link=https%3A%2F%2Fgithub.com%2Fdspinellis%2Funix-history-repo%2Fblob%2FBSD-2%2Fman%2Fwhereis.u 24 Apr 2022 18:29:14 ron minnich : > can someone point me at the earliest version of whereis? I first saw > it in 4.1, but maybe it came sooner. Also, if you've got a link to man > pages, thanks in advance. > > I'm trying but failing to find it. My daughter says I suck at web > search, which, given where I work, is a bid sad :-) From clemc at ccc.com Mon Apr 25 02:48:16 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 24 Apr 2022 12:48:16 -0400 Subject: [TUHS] whereis command In-Reply-To: References: Message-ID: It was written for the Cory 11/70 IIRC. It's on my 2BSD tape with a date of 2/17/80 - which should be on Warren's archives. If you can't find it send me email off list and I'll send it to you. Clem On Sun, Apr 24, 2022 at 11:28 AM ron minnich wrote: > can someone point me at the earliest version of whereis? I first saw > it in 4.1, but maybe it came sooner. Also, if you've got a link to man > pages, thanks in advance. > > I'm trying but failing to find it. My daughter says I suck at web > search, which, given where I work, is a bid sad :-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Apr 25 02:54:07 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 24 Apr 2022 12:54:07 -0400 Subject: [TUHS] whereis command In-Reply-To: References: Message-ID: I don't trust my dates for that tape BTW. I'm pretty sure we got it in early 79, so I clearly rewrote it at some point if the dates show later -- although it might be a copy from Tektronix - which would match that date. Again my memory is that 1BSD and 2BSD are all a little different. They were written as needed and sent out, although I think they wrote them a few at a time. But my tape from CMU is likely to be different from one that says went to Harvard which was different from what went to Purdue or MIT. As for when whereis got put into SCCS control, I'm not sure. Take a peak at Kirk's archives. Clem On Sun, Apr 24, 2022 at 12:48 PM Clem Cole wrote: > It was written for the Cory 11/70 IIRC. It's on my 2BSD tape with a date > of 2/17/80 - which should be on Warren's archives. If you can't find it > send me email off list and I'll send it to you. > > Clem > > On Sun, Apr 24, 2022 at 11:28 AM ron minnich wrote: > >> can someone point me at the earliest version of whereis? I first saw >> it in 4.1, but maybe it came sooner. Also, if you've got a link to man >> pages, thanks in advance. >> >> I'm trying but failing to find it. My daughter says I suck at web >> search, which, given where I work, is a bid sad :-) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Apr 25 03:39:05 2022 From: rminnich at gmail.com (ron minnich) Date: Sun, 24 Apr 2022 10:39:05 -0700 Subject: [TUHS] whereis command In-Reply-To: References: Message-ID: clem and all, found it, thanks! On Sun, Apr 24, 2022 at 9:54 AM Clem Cole wrote: > > I don't trust my dates for that tape BTW. I'm pretty sure we got it in early 79, so I clearly rewrote it at some point if the dates show later -- although it might be a copy from Tektronix - which would match that date. Again my memory is that 1BSD and 2BSD are all a little different. They were written as needed and sent out, although I think they wrote them a few at a time. But my tape from CMU is likely to be different from one that says went to Harvard which was different from what went to Purdue or MIT. > > As for when whereis got put into SCCS control, I'm not sure. Take a peak at Kirk's archives. > > Clem > > On Sun, Apr 24, 2022 at 12:48 PM Clem Cole wrote: >> >> It was written for the Cory 11/70 IIRC. It's on my 2BSD tape with a date of 2/17/80 - which should be on Warren's archives. If you can't find it send me email off list and I'll send it to you. >> >> Clem >> >> On Sun, Apr 24, 2022 at 11:28 AM ron minnich wrote: >>> >>> can someone point me at the earliest version of whereis? I first saw >>> it in 4.1, but maybe it came sooner. Also, if you've got a link to man >>> pages, thanks in advance. >>> >>> I'm trying but failing to find it. My daughter says I suck at web >>> search, which, given where I work, is a bid sad :-) From jpl.jpl at gmail.com Mon Apr 25 04:38:39 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sun, 24 Apr 2022 14:38:39 -0400 Subject: [TUHS] whereis command In-Reply-To: <1CE39A9F-A3B5-45E3-A48E-D70010BB51E1@kdbarto.org> References: <202204241548.23OFmGSC002546@freefriends.org> <1CE39A9F-A3B5-45E3-A48E-D70010BB51E1@kdbarto.org> Message-ID: On Sun, Apr 24, 2022 at 12:35 PM David Barto wrote: > > > > On Apr 24, 2022, at 8:59 AM, ron minnich wrote: > > > > Thanks. > > > > I did find a newer-ish version and I always get a kick out of stuff like > this: > > > > free_dirlist(&ls, ALL_DIRS); > > > > right before the call to exit ... an inappropriate response to an > > inappropriate warning, I suppose > > > > I once had an intern ask me "but if you don't free memory before the > > program exits, then it can never get used again, right?" :-) > > > > (and yes, I know, in the paleo era, that was in fact true) > > > > I'll go try to find that archive ... > > > > ron > > > > At $WORK we have a standing rule that all memory must be freed before the > program exits. > > This is to ensure that the rest of the program doesn’t have any memory > leaks. ASAN, UBSAN, > Valgrind and the rest are good and far from perfect for detection of > problems. > > However making sure to free all memory before exit() does aid them in > finding problems early. > > Some colleagues took an external sort routine I wrote and tried to turn it into a subroutine in a larger system. (Why they didn't just pipe input into the sort process I never understood). I hadn't taken any care to free the memory it used (and it used a LOT of memory), so after it was invoked a few times, it ran out of space. I try to be more careful now about keeping track of memory (but that requires extra memory). -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Wed Apr 27 00:06:57 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 26 Apr 2022 08:06:57 -0600 Subject: [TUHS] [tuhs] Go programming language Message-ID: List readers may enjoy a new article about the history of the Go programming language published today: Russ Cox, Robert Griesemer, Rob Pike, Ian Lance Taylor, and Ken Thompson The Go programming language and environment Comm. ACM 65(5) 70--78 May 2022 https://doi.org/10.1145/3488716 https://dl.acm.org/doi/10.1145/3488716 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From wkt at tuhs.org Wed Apr 27 08:33:58 2022 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 27 Apr 2022 08:33:58 +1000 Subject: [TUHS] Pro/Venix 2.0: reconstructed Message-ID: <20220426223358.GA19528@minnie.tuhs.org> Hi all, I just received this in the e-mail a few days ago: [ now at https://www.tuhs.org/Archive/Distributions/DEC/Venix/ProVenix_2.0/ ] From: Peter Klapper Subject: PRO/VENIX 2.0 reconstructed ... ... and tested, for your collection ;-) Probably the best OS for the Pro, see the benchmark: PRO380 - PRO/VENIX V2.0: ======================== pk$ dryr Dhrystone(1.1) time for 50000 passes = 86 This machine benchmarks at 581 dhrystones/second pk$ drynr Dhrystone(1.1) time for 50000 passes = 95 This machine benchmarks at 526 dhrystones/second The four additional floppy disks contain also the source code which I used to rebuild the missing binaries. I wish you and the community much fun with the "new" resurrected PRO/VENIX V2.0. From alanglasser at gmail.com Fri Apr 29 07:05:06 2022 From: alanglasser at gmail.com (Alan Glasser) Date: Thu, 28 Apr 2022 17:05:06 -0400 Subject: [TUHS] {TUHS] Interesting Commentary on Unix from Multicians In-Reply-To: References: Message-ID: As the labs folks all probably know, Vic became the Executive Director of division 91(two levels beyond department head). This was after Research and Multics and, I think, Safeguard. One of the early things he asked after quizzing various folks about what was going on in the division was "Where is your source code control system?". The question fell to Rudd Canaday (then a department head under Vic). And SCCS was thus born. And who doesn't remember SP&E Aleph Null articles? Alan On Sat, Apr 9, 2022 at 7:47 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > Single Level Storage is an awesome concept and removes so many ugly > > hacks from algorithms that otherwise have to process data in files. > > This was Vic Vyssotsky's signature contribution to Multics, though in > typical > Vyssotsky fashion he never sought personal credit for it. Other awesome > Vyssotsky inventions: > > BLODI (block diagram), the first data-flow language, for sample-data > systems. > > Parallel flow analysis (later reinvented and published by John Cocke). Vic > installed this in Fortran to produce diagnostics such as, "If the > third branch of IF > statement 15 is ever taken, then variable E will be used before being set". > > Darwin, the original game of predation and self-reproduction among > programs. > Corewars.org keeps a descendant version going 60 years later. > > A minimum-spanning-tree algorithm quite different from the well-known > methods > due to his colleagues Bob Prim and Joe Kruskal, again unpublished. > > Not long ago on TUHS, Andrew Hume told how Vic found the same isolated bug > in > dc by mathematically generating hard cases that Andrew stumbled on by > accident, > > As you may infer, Vic is one of my personal computing heroes. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Sat Apr 30 20:45:46 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 30 Apr 2022 11:45:46 +0100 Subject: [TUHS] Aleph Null in Software Practice & Experience. In-Reply-To: References: Message-ID: <20220430104546.1C13022135@orac.inputplus.co.uk> Hi, Alan Glasser wrote: > > Darwin, the original game of predation and self-reproduction among > > programs. ... > And who doesn't remember SP&E Aleph Null articles? Doug has made the letter from him, Bob Morris, and Vic Vyssotsky to Software Practice & Experience which introduces Darwin available at https://www.cs.dartmouth.edu/~doug/darwin.pdf. The letter is addressed to C. A. Lang but accompanied by a note that Lang isn't א₀. http://bit-player.org/2013/who-was-aleph-null wonders if א₀ and side-kick Archimedes ‘might have been members of the Bell Labs gang that was so lively and prolific in the late 60s and early 70s’ before acknowledging the Darwin article rules it out. After a false start suspecting Lang, foiled by Doug's PDF of the letter, it goes on to finally identify א₀ as Brit Richard Parkins who explains how it came about on his own page at http://www.zen224037.zen.co.uk/SPE.shtml. Reading the front page of Parkins' site, http://www.zen224037.zen.co.uk, I see he ‘learnt his craft’ by programming assembler when at Cambridge, on the country's first PDP-7 which he was allowed to use by Lang and Neil Wiseman. Unusually, it had a separate graphics processor driving a 1024²-pixel monochrome display. Soon after, Parkins went on to build a graphics card for the Data General Nova which drove a flat screen storage tube before Tektronix released the 4010. The story is buried in http://www.zen224037.zen.co.uk/History.shtml. -- Cheers, Ralph. From ralph at inputplus.co.uk Sat Apr 30 22:52:07 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 30 Apr 2022 13:52:07 +0100 Subject: [TUHS] Aleph Null in Software Practice & Experience. In-Reply-To: References: <20220430104546.1C13022135@orac.inputplus.co.uk> Message-ID: <20220430125207.4DDE8200B5@orac.inputplus.co.uk> Hi John, > Note that on correct Unicode renderers this is being shown as > null-aleph instead of aleph-null. Thanks for explaining. I'm clearly using incorrect Unicode renderers. :-) -- Cheers, Ralph. From robpike at gmail.com Sat Apr 30 23:33:34 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 30 Apr 2022 23:33:34 +1000 Subject: [TUHS] Aleph Null in Software Practice & Experience. In-Reply-To: <20220430125207.4DDE8200B5@orac.inputplus.co.uk> References: <20220430104546.1C13022135@orac.inputplus.co.uk> <20220430125207.4DDE8200B5@orac.inputplus.co.uk> Message-ID: The output of "unicode 5d0-5e7" (robpike.io/cmd/unicode has the command) is fun. 05d0 א 05d1 ב 05d2 ג 05d3 ד 05d4 ה 05d5 ו 05d6 ז 05d7 ח 05d8 ט 05d9 י 05da ך 05db כ 05dc ל 05dd ם 05de מ 05df ן 05e0 נ 05e1 ס 05e2 ע 05e3 ף 05e4 פ 05e5 ץ 05e6 צ 05e7 ק For comparison, here is "unicode 3d0-3e7". It will be fun to watch how it's rendered. 03d0 ϐ 03d1 ϑ 03d2 ϒ 03d3 ϓ 03d4 ϔ 03d5 ϕ 03d6 ϖ 03d7 ϗ 03d8 Ϙ 03d9 ϙ 03da Ϛ 03db ϛ 03dc Ϝ 03dd ϝ 03de Ϟ 03df ϟ 03e0 Ϡ 03e1 ϡ 03e2 Ϣ 03e3 ϣ 03e4 Ϥ 03e5 ϥ 03e6 Ϧ 03e7 ϧ -rob