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: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
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: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
References: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
Message-ID: <44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org>
> On Apr 1, 2022, at 8:59 AM, Douglas McIlroy <douglas.mcilroy at dartmouth.edu> 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: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
<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 <douglas.mcilroy at dartmouth.edu> 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: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
<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 <douglas.mcilroy at dartmouth.e\
|>> 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 <string.h>
|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: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
<44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org>
<202204011726.231HQFm03349496@darkstar.fourwinds.com>
<20220401194159.HF6gb%steffen@sdaoden.eu>
Message-ID: <CAKzdPgzMcoN0gNp0nSDP9fvnXoZVOtecgm7+wVo0NgMs8oo_og@mail.gmail.com>
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: <CAKzdPgzMcoN0gNp0nSDP9fvnXoZVOtecgm7+wVo0NgMs8oo_og@mail.gmail.com>
References: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
<44FEFAE6-720F-4449-84DB-228B7A6C097C@kdbarto.org>
<202204011726.231HQFm03349496@darkstar.fourwinds.com>
<20220401194159.HF6gb%steffen@sdaoden.eu>
<CAKzdPgzMcoN0gNp0nSDP9fvnXoZVOtecgm7+wVo0NgMs8oo_og@mail.gmail.com>
Message-ID: <CAKzdPgwa+2S-XhpSuz_Pp=ywtWcQ-2BAZahf7VTr=XJfjpoTHQ@mail.gmail.com>
And yes, this _was_ bitblt, its apotheosis, not its elimination.
-rbo
On Sat, Apr 2, 2022 at 8:29 AM Rob Pike <robpike at gmail.com> 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: <CAKH6PiVu9GVoEpao=Ammiw_t8whf=yw8Ok49cQRDm1JDQ1x7dA@mail.gmail.com>
<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 <douglas.mcilroy at dartmouth.e\
> |>> 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: <CAKH6PiXa4Eh4S=KNg5VJemGFvzXbsB6Eg=L=5DEz+fAE1TPz6g@mail.gmail.com>
> 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: <BAA63FCE-06D1-415B-B86C-20C8256CCAE6@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 <https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220403/56695562/attachment-0001.htm>
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 <https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/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 <jerq.h>
#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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220403/306da971/attachment.htm>
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: <CAKzdPgw+s7_d2T4y2j7vM2Vbvth613XJ5Nmv5UWgVG5JWcvi7g@mail.gmail.com>
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
<tuhs at minnie.tuhs.org> 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 <jerq.h>
> #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: <BAA63FCE-06D1-415B-B86C-20C8256CCAE6@planet.nl>
References: <BAA63FCE-06D1-415B-B86C-20C8256CCAE6@planet.nl>
Message-ID: <CAKzdPgxGbn7dwnzDv5P=VRy8F-xKq-2iQ6X4+wMiksdY0kSr_A@mail.gmail.com>
Ah, yes, that's the one.
-rob
On Sun, Apr 3, 2022 at 9:03 PM Paul Ruizendaal via TUHS
<tuhs at minnie.tuhs.org> 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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220407/9b422443/attachment.htm>
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: <CAFH29tpjNq4AS7K1i2haEc=h4-KT6JD86ka5aWNETWHzSXT-zA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220407/d3735a9a/attachment.htm>
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: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
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: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
Message-ID: <20220407213234.7sGk5%steffen@sdaoden.eu>
Douglas McIlroy wrote in
<CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q at mail.gmail.com>:
|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: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
Message-ID: <CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220407/ddfe6141/attachment.htm>
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: <CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
<CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
Message-ID: <CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
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 <rich.salz at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/41788e94/attachment.htm>
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: <CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
<CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
<CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
Message-ID: <CAKr6gn0Nhn+YDtrmu_3SEphC_L879vcmvB_qkQUm8NPfJ-ND7A@mail.gmail.com>
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: <CAKr6gn0Nhn+YDtrmu_3SEphC_L879vcmvB_qkQUm8NPfJ-ND7A@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
<CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
<CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
<CAKr6gn0Nhn+YDtrmu_3SEphC_L879vcmvB_qkQUm8NPfJ-ND7A@mail.gmail.com>
Message-ID: <CAKzdPgzvWasb9gatMvoQT+EgQn65Ff+qbMK1tThdFr_D5qNSgg@mail.gmail.com>
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 <ggm at algebras.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/9deca4f1/attachment.htm>
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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
(Dan Cross's message of "Thu, 7 Apr 2022 12:32:05 -0400")
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
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: <EB8C67CC-5C71-48A3-8B80-AC2D2332807C@planet.nl>
> 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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
Message-ID: <CAC20D2P3Jn9WOC3pkwm-RP8FN+=ZS9OdYrbC48pB2+S5SbuPiw@mail.gmail.com>
On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/37be3758/attachment.htm>
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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
Message-ID: <CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
On Fri, Apr 8, 2022 at 1:30 AM Lars Brinkhoff <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/914aba4b/attachment.htm>
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: <CAC20D2P3Jn9WOC3pkwm-RP8FN+=ZS9OdYrbC48pB2+S5SbuPiw@mail.gmail.com>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAC20D2P3Jn9WOC3pkwm-RP8FN+=ZS9OdYrbC48pB2+S5SbuPiw@mail.gmail.com>
Message-ID: <CAEoi9W7hUrR-fmgbQMx7Gmjb0h=pkG8QuLvtdR4KSSfGCtCtUA@mail.gmail.com>
On Fri, Apr 8, 2022 at 9:34 AM Clem Cole <clemc at ccc.com> wrote:
> On Fri, Apr 8, 2022 at 1:33 AM Lars Brinkhoff <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/86dd0824/attachment.htm>
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: <CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com>
Message-ID: <CAEoi9W4bBzOHxHo0i5bUWA+xF-eXChBtMgM9tPoPcJmmToCKpA@mail.gmail.com>
On Fri, Apr 8, 2022 at 11:28 AM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/8dd87f45/attachment.htm>
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: <CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com>
Message-ID: <39AB7949-36F3-4D28-9C4C-6AFE9ED3541F@cfcl.com>
> On Apr 8, 2022, at 08:28, Larry McVoy <lm at mcvoy.com> 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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/9c03ba88/attachment.htm>
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: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com>
Message-ID: <m1ncvkN-000iJNC@more.local>
At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy <lm at mcvoy.com> 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 <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/ab672b4c/attachment.sig>
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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
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: <alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
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: <m1ncvkN-000iJNC@more.local>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com> <m1ncvkN-000iJNC@more.local>
Message-ID: <CAD-qYGr03bO2TUVfEw8qN2bTKnTcKzO-a0bpFCX868npV2i1Cw@mail.gmail.com>
On 4/8/22, Greg A. Woods <woods at robohack.ca> 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: <alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
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 <dave at horsfall.org> 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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com>
Message-ID: <CAKr6gn2yB-91+_Q+Lfh3k=fpE=YNnLyCdTa6RfhK-A_c_X6aCQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/e49602f4/attachment.htm>
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: <CAKr6gn2yB-91+_Q+Lfh3k=fpE=YNnLyCdTa6RfhK-A_c_X6aCQ@mail.gmail.com>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com>
<CAKr6gn2yB-91+_Q+Lfh3k=fpE=YNnLyCdTa6RfhK-A_c_X6aCQ@mail.gmail.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: <CAKzdPgzvWasb9gatMvoQT+EgQn65Ff+qbMK1tThdFr_D5qNSgg@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
<CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
<CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
<CAKr6gn0Nhn+YDtrmu_3SEphC_L879vcmvB_qkQUm8NPfJ-ND7A@mail.gmail.com>
<CAKzdPgzvWasb9gatMvoQT+EgQn65Ff+qbMK1tThdFr_D5qNSgg@mail.gmail.com>
Message-ID: <CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw@mail.gmail.com>
On Thu, Apr 7, 2022 at 7:53 PM Rob Pike <robpike at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/9b65e34a/attachment.htm>
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: <CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
<CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
<CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
<CAKr6gn0Nhn+YDtrmu_3SEphC_L879vcmvB_qkQUm8NPfJ-ND7A@mail.gmail.com>
<CAKzdPgzvWasb9gatMvoQT+EgQn65Ff+qbMK1tThdFr_D5qNSgg@mail.gmail.com>
<CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw@mail.gmail.com>
Message-ID: <CAKr6gn1N_NghSkvEkteE_v6AgYO-uMBZm7jXwy9G0R3tNPY6SA@mail.gmail.com>
>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/ec38d6d4/attachment.htm>
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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com>
<CAKr6gn2yB-91+_Q+Lfh3k=fpE=YNnLyCdTa6RfhK-A_c_X6aCQ@mail.gmail.com>
<202204090028.2390S49F085864@ultimate.com>
Message-ID: <CAKr6gn3Gq=Q_PiyihpzEQeQeh=PVLFOhC8uNH_22KvfHH0Rn+w@mail.gmail.com>
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, <phil at ultimate.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/a7837dab/attachment.htm>
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: <m1ncvkN-000iJNC@more.local>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com> <m1ncvkN-000iJNC@more.local>
Message-ID: <CAP2nic0etDSQshicSKaGCuorWSOr5JSq4KCq66hvh7j79H292A@mail.gmail.com>
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 <woods at robohack.ca> wrote:
> At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy <lm at mcvoy.com> 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 <gwoods at acm.org>
>
> Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
> Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220408/290deb3b/attachment.htm>
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: <alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
(Dave Horsfall's message of "Sat, 9 Apr 2022 08:44:57 +1000 (EST)")
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
<7wtub2dcwx.fsf@junk.nocrew.org>
Message-ID: <CAKzdPgw=Cmxc7WV8gkV7RFzXM1HMGZpne+YYcrLxwcsH3epLvg@mail.gmail.com>
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 <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/406bdf26/attachment.htm>
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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
<7wtub2dcwx.fsf@junk.nocrew.org>
Message-ID: <emcb1dc115-4064-4bfd-8a12-e3ab4298e767@alien>
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" <lars at nocrew.org>
>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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<3ECF77E9-232D-468E-9F85-2CA8026505C5@humeweb.com>
<20220409104613.15F8321EE0@orac.inputplus.co.uk>
Message-ID: <CAKr6gn3K1OP0MLn-uNdA_LCkC3m+4gu4d3KNu2tChVVQeUdnhQ@mail.gmail.com>
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, <ralph at inputplus.co.uk> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/c9d6cd90/attachment.htm>
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: <CAKzdPgw=Cmxc7WV8gkV7RFzXM1HMGZpne+YYcrLxwcsH3epLvg@mail.gmail.com>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
<7wtub2dcwx.fsf@junk.nocrew.org>
<CAKzdPgw=Cmxc7WV8gkV7RFzXM1HMGZpne+YYcrLxwcsH3epLvg@mail.gmail.com>
Message-ID: <CANCZdfqF=pxT8ZEXQoz5Jraw97GNtxwdHRZxyCnaaVw4RQH6tw@mail.gmail.com>
On Sat, Apr 9, 2022, 2:10 AM Rob Pike <robpike at gmail.com> 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 <lars at nocrew.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/2835cb43/attachment.htm>
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: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
> 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: <m1ncvkN-000iJNC@more.local>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com> <m1ncvkN-000iJNC@more.local>
Message-ID: <YlF3rb2m+AUfCPfj@mit.edu>
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: <YlF3rb2m+AUfCPfj@mit.edu>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com> <m1ncvkN-000iJNC@more.local>
<YlF3rb2m+AUfCPfj@mit.edu>
Message-ID: <CAEoi9W4Y1R28mg4uFy_=4H1h_ufcwrgSi0Yn9YxjorwQ6JehKw@mail.gmail.com>
On Sat, Apr 9, 2022, 8:18 AM tytso <tytso at mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/b324a513/attachment.htm>
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: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
References: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
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 <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
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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<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 <ralph at inputplus.co.uk> 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: <emcb1dc115-4064-4bfd-8a12-e3ab4298e767@alien>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
<7wtub2dcwx.fsf@junk.nocrew.org>
<emcb1dc115-4064-4bfd-8a12-e3ab4298e767@alien>
Message-ID: <CAC20D2ObvmXJTgXSw8XQuLrk6n-4uBe=oTXNv506zgf8M87Tew@mail.gmail.com>
On Sat, Apr 9, 2022 at 5:29 AM Ron Natalie <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/64ec2e31/attachment.htm>
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: <CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw@mail.gmail.com>
References: <CAKH6PiXBEZPyjUk=DD8moA8ZnA2kpfk=Z7+6WwckSQb5HPUX3Q@mail.gmail.com>
<CAFH29trish5gf20jUeWv3w3gS_B+frkqAqASg9ZA7jKSgScsdA@mail.gmail.com>
<CAKzdPgxhEZNihmag-GcDsWLhD1xW9XzO1tYSja=W3kPC=9kGQA@mail.gmail.com>
<CAKr6gn0Nhn+YDtrmu_3SEphC_L879vcmvB_qkQUm8NPfJ-ND7A@mail.gmail.com>
<CAKzdPgzvWasb9gatMvoQT+EgQn65Ff+qbMK1tThdFr_D5qNSgg@mail.gmail.com>
<CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw@mail.gmail.com>
Message-ID: <20220409180505.bKC2a%steffen@sdaoden.eu>
John Cowan wrote in
<CAD2gp_RsFWGUtj-9QDKSG3h8Otxb0ZY5M7G00ZAjV=dKEg+Rsw at mail.gmail.com>:
|On Thu, Apr 7, 2022 at 7:53 PM Rob Pike <robpike at gmail.com> 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: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
References: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
Message-ID: <CAMP=X_nsba2Py7u5Sz9mLcHwZOucYDp4ekinx+PJx4e7TqeCAA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/d64b75b9/attachment-0001.htm>
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: <YlF3rb2m+AUfCPfj@mit.edu>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com> <m1ncvkN-000iJNC@more.local>
<YlF3rb2m+AUfCPfj@mit.edu>
Message-ID: <m1ndGXl-000iJNC@more.local>
At Sat, 9 Apr 2022 08:10:21 -0400, tytso <tytso at mit.edu> 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 <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/96d278ab/attachment.sig>
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: <CAD-qYGr03bO2TUVfEw8qN2bTKnTcKzO-a0bpFCX868npV2i1Cw@mail.gmail.com>
References: <CAEoi9W7zf8owckJ5cTWgz4oW015FaDnvGE1+xg=6TbaMB9QjFg@mail.gmail.com>
<7wh774dtvi.fsf@junk.nocrew.org>
<CAEoi9W5DCi=FZsMCqm9tZdtFvRBfcT7SZbFWukfTJ8p8dkc=CQ@mail.gmail.com>
<20220408152834.GE29186@mcvoy.com> <m1ncvkN-000iJNC@more.local>
<CAD-qYGr03bO2TUVfEw8qN2bTKnTcKzO-a0bpFCX868npV2i1Cw@mail.gmail.com>
Message-ID: <m1ndGlL-000iJNC@more.local>
At Fri, 8 Apr 2022 17:34:27 -0600, Andrew Warkentin <andreww591 at gmail.com> 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 <gwoods at acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220409/c4e3f6b6/attachment.sig>
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: <CAC20D2ObvmXJTgXSw8XQuLrk6n-4uBe=oTXNv506zgf8M87Tew@mail.gmail.com>
References: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
<7wtub2dcwx.fsf@junk.nocrew.org>
<emcb1dc115-4064-4bfd-8a12-e3ab4298e767@alien>
<CAC20D2ObvmXJTgXSw8XQuLrk6n-4uBe=oTXNv506zgf8M87Tew@mail.gmail.com>
Message-ID: <56E98893-A6D1-48A5-9AC2-5CDD37638417@csp-partnership.co.uk>
> On 9 Apr 2022, at 17:23, Clem Cole <clemc at ccc.com> wrote:
>
>
>
> On Sat, Apr 9, 2022 at 5:29 AM Ron Natalie <ron at ronnatalie.com <mailto:ron at ronnatalie.com>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220410/4be1886e/attachment.htm>
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: <CAC20D2Npb2VZMft+aoHGV4=G3+SxHzhzOB49eiMYVKngZ0tsTA@mail.gmail.com>
<alpine.BSF.2.21.9999.2204090821440.48016@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2204090843050.48016@aneurin.horsfall.org>
<7wtub2dcwx.fsf@junk.nocrew.org>
<emcb1dc115-4064-4bfd-8a12-e3ab4298e767@alien>
<CAC20D2ObvmXJTgXSw8XQuLrk6n-4uBe=oTXNv506zgf8M87Tew@mail.gmail.com>
<56E98893-A6D1-48A5-9AC2-5CDD37638417@csp-partnership.co.uk>
Message-ID: <CAC20D2NBXw9cXFKyM8RMN0T5bmgSfqfjJq75XSJoTe0ZZr1tew@mail.gmail.com>
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 <clemc at ccc.com> wrote:
>
>
>
> On Sat, Apr 9, 2022 at 5:29 AM Ron Natalie <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220410/8f96afec/attachment.htm>
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 <rdm at cfcl.com>
> 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: <CAD2gp_RC3WLoKYnVTZhaaZd5G1tGor712p8Gu4_=S=GrWTF5Og@mail.gmail.com>
On Sun, Apr 10, 2022 at 1:18 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220410/abba729d/attachment.htm>
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: <CAMP=X_nsba2Py7u5Sz9mLcHwZOucYDp4ekinx+PJx4e7TqeCAA@mail.gmail.com>
References: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
<CAMP=X_nsba2Py7u5Sz9mLcHwZOucYDp4ekinx+PJx4e7TqeCAA@mail.gmail.com>
Message-ID: <CAEoi9W6zNPgjU4QxGkOKQh+Xsikc6bUCM-ZqHqRGxtb=arqdmg@mail.gmail.com>
On Sat, Apr 9, 2022 at 2:29 PM Ken Thompson <kenbob at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220411/d7774ad2/attachment.htm>
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: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
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: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
References: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
Message-ID: <202204241548.23OFmGSC002546@freefriends.org>
ron minnich <rminnich at gmail.com> 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: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
<202204241548.23OFmGSC002546@freefriends.org>
Message-ID: <CAP6exYLOsRcKkRZo12aABR1L_0a7xqNs+=jx_Q0va8vOJ-VxCw@mail.gmail.com>
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 <arnold at skeeve.com> wrote:
>
> ron minnich <rminnich at gmail.com> 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: <CAP6exYLOsRcKkRZo12aABR1L_0a7xqNs+=jx_Q0va8vOJ-VxCw@mail.gmail.com>
References: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
<202204241548.23OFmGSC002546@freefriends.org>
<CAP6exYLOsRcKkRZo12aABR1L_0a7xqNs+=jx_Q0va8vOJ-VxCw@mail.gmail.com>
Message-ID: <1CE39A9F-A3B5-45E3-A48E-D70010BB51E1@kdbarto.org>
> On Apr 24, 2022, at 8:59 AM, ron minnich <rminnich at gmail.com> 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 <arnold at skeeve.com> wrote:
>>
>> ron minnich <rminnich at gmail.com> 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: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
References: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
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 <rminnich at gmail.com>:
> 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: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
References: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
Message-ID: <CAC20D2OXeq07YTY18ZqWc4tVVtL_yCTez7Qtu2=m_WAN_BwQkg@mail.gmail.com>
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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220424/b4b96144/attachment.htm>
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: <CAC20D2OXeq07YTY18ZqWc4tVVtL_yCTez7Qtu2=m_WAN_BwQkg@mail.gmail.com>
References: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
<CAC20D2OXeq07YTY18ZqWc4tVVtL_yCTez7Qtu2=m_WAN_BwQkg@mail.gmail.com>
Message-ID: <CAC20D2NtZqbXVsUVgE43tHexxO+i2EpVRT7DMyaaPf9ZE6-E4Q@mail.gmail.com>
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 <clemc at ccc.com> 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 <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220424/998183a1/attachment.htm>
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: <CAC20D2NtZqbXVsUVgE43tHexxO+i2EpVRT7DMyaaPf9ZE6-E4Q@mail.gmail.com>
References: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
<CAC20D2OXeq07YTY18ZqWc4tVVtL_yCTez7Qtu2=m_WAN_BwQkg@mail.gmail.com>
<CAC20D2NtZqbXVsUVgE43tHexxO+i2EpVRT7DMyaaPf9ZE6-E4Q@mail.gmail.com>
Message-ID: <CAP6exYLhGEndnKz7uzvek2EidK97Qc7sw-KaC2y8RUM1BPVgzA@mail.gmail.com>
clem and all, found it, thanks!
On Sun, Apr 24, 2022 at 9:54 AM Clem Cole <clemc at ccc.com> 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 <clemc at ccc.com> 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 <rminnich at gmail.com> 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: <CAP6exYLNTwd8OG9LuLSS6fqq+gJL81sSOGEg26ncZk6kfCcTRg@mail.gmail.com>
<202204241548.23OFmGSC002546@freefriends.org>
<CAP6exYLOsRcKkRZo12aABR1L_0a7xqNs+=jx_Q0va8vOJ-VxCw@mail.gmail.com>
<1CE39A9F-A3B5-45E3-A48E-D70010BB51E1@kdbarto.org>
Message-ID: <CAC0cEp_8=bJKw-vU-qh-pMsC_q1aJT+DtiEP6R9jDiCuuGZb1A@mail.gmail.com>
On Sun, Apr 24, 2022 at 12:35 PM David Barto <david at kdbarto.org> wrote:
>
>
> > On Apr 24, 2022, at 8:59 AM, ron minnich <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220424/380c9ba0/attachment.htm>
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: <CMM.0.95.0.1650982017.beebe@gamma.math.utah.edu>
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: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
References: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
Message-ID: <CALpTLGqJyO3BUkqRXA2_tsVRETcNb6sXcNFUMRcurORc4ifNxQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220428/4a605fb3/attachment.htm>
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: <CALpTLGqJyO3BUkqRXA2_tsVRETcNb6sXcNFUMRcurORc4ifNxQ@mail.gmail.com>
References: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
<CALpTLGqJyO3BUkqRXA2_tsVRETcNb6sXcNFUMRcurORc4ifNxQ@mail.gmail.com>
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: <CAD2gp_SiBPRFETHzjtQRd5rHiTKYHE32DtK8neeUafa-G2N9cQ@mail.gmail.com>
References: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
<CALpTLGqJyO3BUkqRXA2_tsVRETcNb6sXcNFUMRcurORc4ifNxQ@mail.gmail.com>
<20220430104546.1C13022135@orac.inputplus.co.uk>
<CAD2gp_SiBPRFETHzjtQRd5rHiTKYHE32DtK8neeUafa-G2N9cQ@mail.gmail.com>
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: <CAKH6PiWSOKFRe0oi92iygvTF1guH=vm5UQ-2OHm5t4HAcJPsNg@mail.gmail.com>
<CALpTLGqJyO3BUkqRXA2_tsVRETcNb6sXcNFUMRcurORc4ifNxQ@mail.gmail.com>
<20220430104546.1C13022135@orac.inputplus.co.uk>
<CAD2gp_SiBPRFETHzjtQRd5rHiTKYHE32DtK8neeUafa-G2N9cQ@mail.gmail.com>
<20220430125207.4DDE8200B5@orac.inputplus.co.uk>
Message-ID: <CAKzdPgyBdUZ_8BY3koFCXC99woz+geUhEuVAqvLNH5A3QB+Dvw@mail.gmail.com>
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