From clemc at ccc.com Thu Feb 4 00:43:40 2021
From: clemc at ccc.com (Clem Cole)
Date: Wed, 3 Feb 2021 09:43:40 -0500
Subject: [COFF] [TUHS] for now to follow up - why a byte is 8-bits
Message-ID: <CAC20D2OzdbO8hD_K=HzN7zTV_+7mWht_xmt2q6jqix9B6JWNOA@mail.gmail.com>
I will ask Warren's indulgence here - as this probably should be continued
in COFF, which I have CC'ed but since was asked in TUHS I will answer
On Wed, Feb 3, 2021 at 6:28 AM Peter Jeremy via TUHS <tuhs at minnie.tuhs.org>
wrote:
> I'm not sure that 16 (or any other 2^n) bits is that obvious up front.
> Does anyone know why the computer industry wound up standardising on
> 8-bit bytes?
>
Well, 'standardizing' is a little strong. Check out my QUORA answer: How
many bits are there in a byte
<https://www.quora.com/How-many-bits-are-there-in-a-byte/answer/Clem-Cole>
and What is a bit? Why are 8 bits considered as 1 byte? Why not 7 bit or 9
bit?
<https://www.quora.com/What-is-a-bit-Why-are-8-bits-considered-as-1-byte-Why-not-7-bit-or-9-bit/answer/Clem-Cole>
for my details but the 8-bit part of the tail is here (cribbed from those
posts):
The Industry followed IBM with the S/360.The story of why a byte is 8- bits
for the S/360 is one of my favorites since the number of bits in a byte is
defined for each computer architecture. Simply put, Fred Brooks (who lead
the IBM System 360 project) overruled the chief hardware designer, Gene
Amdahl, and told him to make things power of two to make it easier on the
SW writers. Amdahl famously thought it was a waste of hardware, but Brooks
had the final authority.
My friend Russ Robeleon, who was the lead HW guy on the 360/50 and later
the ASP (*a.k.a.* project X) who was in the room as it were, tells his yarn
this way: You need to remember that the 360 was designed to be IBM's
first *ASCII
machine*, (not EBCDIC as it ended up - a different story)[1] Amdahl was
planning for a word size to be 24-bits and the byte size to be 7-bits for
cost reasons. Fred kept throwing him out of his office and told him not to
come back “until a byte and word are powers of two, as we just don’t know
how to program it otherwise.”
Brooks would eventually relent on the original pointer on the Systems 360
became 24-bits, as long as it was stored in a 32-bit “word”.[2] As a
result, (and to answer your original question) a byte first widely became
8-bit with the IBM’s Systems 360.
It should be noted, that it still took some time before an 8-bit byte
occurred more widely and in almost all systems as we see it today. Many
systems like the DEC PDP-6/10 systems used 5, 7-bit bytes packed into a
36-bit word (with a single bit leftover) for a long time. I believe that
the real widespread use of the 8-bit byte did not really occur until the
rise of the minis such as the PDP-11 and the DG Nova in the late
1960s/early 1970s and eventually the mid-1970s’ microprocessors such as
8080/Z80/6502.
Clem
[1] While IBM did lead the effort to create ASCII, and System 360 actually
supported ASCII in hardware, but because the software was so late, IBM
marketing decided not the switch from BCD and instead used EBCDIC (their
own code). Most IBM software was released using that code for the System
360/370 over the years. It was not until IBM released their Series 1
<https://en.wikipedia.org/wiki/IBM_Series/1>minicomputer in the late 1970s
that IBM finally supported an ASCII-based system as the natural code for
the software, although it had a lot of support for EBCDIC as they were
selling them to interface to their вЂMainframe’ products.
[2] Gordon Bell would later observe that those two choices (32-bit word and
8-bit byte) were what made the IBM System 360 architecture last in the
market, as neither would have been вЂfixable’ later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210203/d3d0c9b9/attachment.htm>
From joshnatis0 at gmail.com Thu Feb 4 18:41:29 2021
From: joshnatis0 at gmail.com (josh)
Date: Thu, 4 Feb 2021 03:41:29 -0500
Subject: [COFF] Holy Wars of Computing
Message-ID: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
Hello all,
I'm looking to compile a list of historic "wars" in computing, just for
personal interest cause they're fun to read about (I'll also put the list
up online for others' reference).
To explain what I mean, take for example, The Tcl War
<https://vanderburg.org/old_pages/Tcl/war/>. Other examples:
- TCP/IP wars (BBN vs Berkley, story by Kirk McKusick
<https://www.youtube.com/watch?v=DEEr6dT-4uQ>)
- The Tanenbaum-Torvalds Debate
<https://www.oreilly.com/openbook/opensources/book/appa.html> (it doesn't
have 'war(s)' in the name but it still counts IMO, could be called The
Microkernel Wars)
- UNIX Wars <https://en.wikipedia.org/wiki/Unix_wars>
Stuff like "vi vs. emacs" counts too I think, though I'm looking more for
historical significance, so maybe "spaces vs. tabs" isn't interesting
enough.
Thanks, any help is appreciated : )
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210204/1edd9ad6/attachment.htm>
From dave at horsfall.org Thu Feb 4 19:21:30 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 4 Feb 2021 20:21:30 +1100 (EST)
Subject: [COFF] Holy Wars of Computing
In-Reply-To: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
References: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.2102041950000.70858@aneurin.horsfall.org>
Unix vs. DEC, of course; been there, fought that, still got the scars.
Although there was Unix vs. Apollo (I could tell some stories about that,
but I'm unsure about the Statute of Limitations, whereby I called an
Apollo salesdroid a liar to his face in front of my $PHB; I survived).
And of course Unix vs. VMS; OK, they can have the commercial market...
Oh, the stories that I could tell, such as when the computing boss was
known to be having it off with his secretary, and had to be rolled out of
the computer room several times by the ops after he'd had a few for lunch.
∆As I said, Statute of Limitations; this stuff goes back to the 70s and
early 80s; not to mention when I once wasted a few months with NECISA,
whereby you did not get promoted unless you spoke Japanese (itself a long
story).
-- Dave, at 68 after the game with many stories
From lars at nocrew.org Thu Feb 4 19:23:11 2021
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 04 Feb 2021 09:23:11 +0000
Subject: [COFF] Holy Wars of Computing
In-Reply-To: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
(josh's message of "Thu, 4 Feb 2021 03:41:29 -0500")
References: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
Message-ID: <7w5z38kwzk.fsf@junk.nocrew.org>
MIT AI lab and ITS versus Stanford AI lab and WAITS.
From crossd at gmail.com Fri Feb 5 01:26:31 2021
From: crossd at gmail.com (Dan Cross)
Date: Thu, 4 Feb 2021 10:26:31 -0500
Subject: [COFF] [TUHS] 68k prototypes & microcode
In-Reply-To: <20210204013356.GA16541@mcvoy.com>
References: <E1l5RL3-0002iv-Qv@tanda>
<abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
Message-ID: <CAEoi9W5qLQSY25UT5szf1s4JPD6uf7_=JYny-8jMym+p5aMuAA@mail.gmail.com>
On Wed, Feb 3, 2021 at 8:34 PM Larry McVoy <lm at mcvoy.com> wrote:
> I have to admit that I haven't looked at ARM assembler, the M1 is making
> me rethink that. Anyone have an opinion on where ARM lies in the pleasant
> to unpleasant scale?
>
Redirecting to "COFF" as this is drifting away from Unix.
I have a soft spot for ARM, but I wonder if I should. At first blush, it's
a pleasant RISC-ish design: loads and stores for dealing with memory,
arithmetic and logic instructions work on registers and/or immediate
operands, etc. As others have mentioned, there's an inline barrel shifter
in the ALU that a lot of instructions can take advantage of in their second
operand; you can rotate, shift, etc, an immediate or register operand while
executing an instruction: here's code for setting up page table entries for
an identity mapping for the low part of the physical address space (the
root page table pointer is at phys 0x40000000):
MOV r1, #0x0000
MOVT r1, #0x4000
MOV r0, #0
.Lpti: MOV r2, r0, LSL #20
ORR r2, r2, r3
STR r2, [r1], #4
ADD r0, r0, #1
CMP r0, #2048
BNE .Lpti
(Note the `LSL #20` in the `MOV` instruction.)
32-bit ARM also has some niceness for conditionally executing instructions
based on currently set condition codes in the PSW, so you might see
something like:
1: CMP r0, #0
ADDNE r1, r1, #1
SUBNE r0, r0, #1
BNE 1b
The architecture tends to map nicely to C and similar languages (e.g.
Rust). There is a rich set of instructions for various kinds of arithmetic;
for instance, they support saturating instructions for DSP-style code. You
can push multiple registers onto the stack at once, which is a little odd
for a RISC ISA, but works ok in practice.
The supervisor instruction set is pretty nice. IO is memory-mapped, etc.
There's a co-processor interface for working with MMUs and things like it.
Memory mapping is a little weird, in that the first-level page table isn't
the same second-level tables: the first-level page table maps the 32-bit
address space into 1MiB "sections", each of which is described by a 32-bit
section descriptor; thus, to map the entire 4GiB space, you need 4096 of
those in 16KiB of physically contiguous RAM. At the second-level, 4KiB page
frames map page into the 1MiB section at different granularities; I think
the smallest is 1KIB (thus, you need 1024 32-bit entries). To map a 4KiB
virtual page to a 4KiB PFN, you repeat the relevant entry 4 times in the
second-level page. It ends up being kind of annoying. I did a little toy
kernel for ARM32 and ended up deciding to use 16KiB pages (basically, I map
4x4KiB contiguous pages) so I could allocate a single sized structure for
the page tables themselves.
Starting with the ARMv8 architecture, it's been split into 32-bit aarch32
(basically the above) and 64-bit aarch64; the latter has expanded the
number and width of general purpose registers, one is a zero register in
some contexts (and I think a stack pointer in others? I forget the
details). I haven't played around with it too much, but looked at it when
it came out and thought "this is reasonable, with some concessions for
backwards compatibility." They cleaned up the paging weirdness mentioned
above. The multiple push instruction has been retired and replaced with a
"push a pair of adjacent registers" instruction; I viewed that as a
concession between code size and instruction set orthogonality.
So...Overall quite pleasant, and far better than x86_64, but with some
oddities.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210204/56116de1/attachment.htm>
From athornton at gmail.com Fri Feb 5 01:39:01 2021
From: athornton at gmail.com (Adam Thornton)
Date: Thu, 4 Feb 2021 08:39:01 -0700
Subject: [COFF] Holy Wars of Computing
In-Reply-To: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
References: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
Message-ID: <9843D646-BED5-47AE-9FFB-CEFB534EED25@gmail.com>
> On Feb 4, 2021, at 1:41 AM, josh <joshnatis0 at gmail.com> wrote:
>
> To explain what I mean, take for example, The Tcl War <https://vanderburg.org/old_pages/Tcl/war/>. Other examples:
Peter da Silva. Now there’s a name I’ve not heard in a long time.
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210204/480b6381/attachment-0001.htm>
From clemc at ccc.com Fri Feb 5 02:13:25 2021
From: clemc at ccc.com (Clem Cole)
Date: Thu, 4 Feb 2021 11:13:25 -0500
Subject: [COFF] now COFF V- ISA's
Message-ID: <CAC20D2Oc-FGr8gLEwho1Fc3muN_R2waqSK1X-O35aPYYhQy_6g@mail.gmail.com>
On Thu, Feb 4, 2021 at 9:57 AM John Cowan <cowan at ccil.org> wrote:
>
> On Wed, Feb 3, 2021 at 8:34 PM Larry McVoy <lm at mcvoy.com> wrote:
>
>> The x86 stuff is about as far away from PDP-11 as you can get. Required
>> to know it, but so unpleasant.
>>
>
> Required? Ghu forbid. After doing a bunch of PDP-11 assembler work, I
> found out that the Vax had 256 opcodes and foreswore assembly thereafter.
> Still, that was nothing compared to the 1500+ opcodes of x86*. I think I
> dodged a bullet.
>
IMHO: the Vax instruction set was the assembler guys (like Culter) trying
to delay the future and keep assembler as king of the hill. That said,
Dave Pressotto, Scotty Baden, and I used to fight with Patterson in his
architecture seminar (during the writing of the RISC papers). DEC hit a
grand slam with that machine. Between the Vax and x86 plus being part of
Alpha, I have realized ISA has nothing to do with success (i.e. my previous
comments about economics vs. architecture).
Funny thing, Dave Cane was the lead HW guy on the 750, worked on the 780 HW
team, and lead the Masscomp HW group. Dave used to stay "Culter got his
way" whenever we talked about the VAX instruction set. It was supposed to
be the world's greatest assembler machine. The funny part is that DEC had
already started to transition to BLISS by then in the applications teams.
But Cutler was (is) an OS weenie and he famously hated BLISS. Only the
other hand, Culter (together with Dick Hustvedt and Peter Lipman), got the
SW out on that system (Starlet - *a.k.a.* VMS) quickly and it worked really
well/pretty much as advertised. [Iknowing all of them I suspect having
Roger Gourd as their boss helped a good bit also).
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210204/db34e556/attachment.htm>
From lm at mcvoy.com Fri Feb 5 03:34:49 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 4 Feb 2021 09:34:49 -0800
Subject: [COFF] Holy Wars of Computing
In-Reply-To: <9843D646-BED5-47AE-9FFB-CEFB534EED25@gmail.com>
References: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
<9843D646-BED5-47AE-9FFB-CEFB534EED25@gmail.com>
Message-ID: <20210204173449.GB13701@mcvoy.com>
On Thu, Feb 04, 2021 at 08:39:01AM -0700, Adam Thornton wrote:
>
>
> > On Feb 4, 2021, at 1:41 AM, josh <joshnatis0 at gmail.com> wrote:
> >
> > To explain what I mean, take for example, The Tcl War <https://vanderburg.org/old_pages/Tcl/war/>. Other examples:
>
> Peter da Silva. Now there???s a name I???ve not heard in a long time.
I used to argue with him on comp.arch quite a bit. Smart dude.
From athornton at gmail.com Fri Feb 5 04:11:08 2021
From: athornton at gmail.com (Adam Thornton)
Date: Thu, 4 Feb 2021 11:11:08 -0700
Subject: [COFF] Holy Wars of Computing
In-Reply-To: <20210204173449.GB13701@mcvoy.com>
References: <CAFZukdTDg4mKYf=TqDFqFm7sqsW-rgPTB8pD-VjQgMaENR_fwA@mail.gmail.com>
<9843D646-BED5-47AE-9FFB-CEFB534EED25@gmail.com>
<20210204173449.GB13701@mcvoy.com>
Message-ID: <96F7B407-FA52-4AA6-9D22-249C41517015@gmail.com>
> On Feb 4, 2021, at 10:34 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
> On Thu, Feb 04, 2021 at 08:39:01AM -0700, Adam Thornton wrote:
>>
>>
>>> On Feb 4, 2021, at 1:41 AM, josh <joshnatis0 at gmail.com> wrote:
>>>
>>> To explain what I mean, take for example, The Tcl War <https://vanderburg.org/old_pages/Tcl/war/>. Other examples:
>>
>> Peter da Silva. Now there???s a name I???ve not heard in a long time.
>
> I used to argue with him on comp.arch quite a bit. Smart dude.
I interviewed with him, for a job that would have involved a bunch of TCL, got the offer, but then decided on grad school instead.
Adam
From lm at mcvoy.com Fri Feb 5 12:53:49 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 4 Feb 2021 18:53:49 -0800
Subject: [COFF] [TUHS] 68k prototypes & microcode
In-Reply-To: <alpine.BSF.2.21.9999.2102051312440.70858@aneurin.horsfall.org>
References: <202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<alpine.BSF.2.21.9999.2102041316080.70858@aneurin.horsfall.org>
<4db6108e-73f0-6498-fe45-3fd422d1f389@kilonet.net>
<alpine.BSF.2.21.9999.2102051312440.70858@aneurin.horsfall.org>
Message-ID: <20210205025349.GM13701@mcvoy.com>
On Fri, Feb 05, 2021 at 01:16:08PM +1100, Dave Horsfall wrote:
> [ Directing to COFF, where it likely belongs ]
>
> On Thu, 4 Feb 2021, Arthur Krewat wrote:
>
> >>-- Dave, wondering whether anyone has ever used every VAX instruction
> >
> >Or every VMS call, for that matter. ;)
>
> Urk... I stayed away from VMS as much as possible (I had a network of
> PDP-11s to play with), although I did do a device driver course; dunno why.
Me too, though I did use Eunice, it was a lonely place, it did not let
me see who was on VMS. I was the only one. A far cry from BSD where
wall went to everyone and talk got you a screen where you talked.
From peter at rulingia.com Fri Feb 5 19:09:44 2021
From: peter at rulingia.com (Peter Jeremy)
Date: Fri, 5 Feb 2021 20:09:44 +1100
Subject: [COFF] [TUHS] 68k prototypes & microcode
In-Reply-To: <20210204013356.GA16541@mcvoy.com>
References: <E1l5RL3-0002iv-Qv@tanda>
<abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
Message-ID: <YB0LWOD/002LDlNP@server.rulingia.com>
On 2021-Feb-03 17:33:56 -0800, Larry McVoy <lm at mcvoy.com> wrote:
>The x86 stuff is about as far away from PDP-11 as you can get. Required
>to know it, but so unpleasant.
Warts upon warts upon warts. The complete opposite of orthogonal.
>I have to admit that I haven't looked at ARM assembler, the M1 is making
>me rethink that. Anyone have an opinion on where ARM lies in the pleasant
>to unpleasant scale?
I haven't spent enough time with ARM assembler to form an opinion but
there are a number of interesting interviews with the designers on YT:
* A set of videos by Sophie Wilson (original designer) starting at
https://www.youtube.com/watch?v=jhwwrSaHdh8
* A history of ARM by Dave Jaggar (redesigner) at
https://www.youtube.com/watch?v=_6sh097Dk5k
If you don't want to pony up for a M1, there are a wide range of ARM
SBCs that you could experiment with.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210205/b0fcf38a/attachment.sig>
From peter at rulingia.com Fri Feb 5 18:53:01 2021
From: peter at rulingia.com (Peter Jeremy)
Date: Fri, 5 Feb 2021 19:53:01 +1100
Subject: [COFF] [TUHS] AT&T 3B1 - Emulation available
In-Reply-To: <CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
References: <E1l5RL3-0002iv-Qv@tanda>
<abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
Message-ID: <YB0HbaQezaZ8MiaR@server.rulingia.com>
On 2021-Feb-03 09:58:37 -0500, Clem Cole <clemc at ccc.com> wrote:
>but the original released (distributed - MC68000) part was binned at 8 and
>10
There was also a 4MHz version. I had one in my MEX68KECB but I'm not
sure if they were ever sold separately. ISTR I got the impression
that it was a different (early) mask or microcode variant because some
of the interface timings weren't consistent with the 8/10 MHz versions
(something like one of the bus timings was a clock-cycle slower).
>as were the later versions with the updated paging microcode called the
>MC68010 a year later. When the 68020 was released Moto got the speeds up
>to 16Mhz and later 20. By the '040 I think they were running at 50MHz
I also really liked the M68k architecture. Unfortunately, as with the
M6800, Motorola lost out to Intel's inferior excuse for an architecture.
Moving more off-topic, M68k got RISC-ified as the ColdFire MCF5206.
That seemed (to me) to combine the feel of the M68k with the
clock/power gains from RISC. Unfortunately, it didn't take off.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210205/d80c6490/attachment.sig>
From clemc at ccc.com Sat Feb 6 00:36:20 2021
From: clemc at ccc.com (Clem Cole)
Date: Fri, 5 Feb 2021 09:36:20 -0500
Subject: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode
In-Reply-To: <20210204013356.GA16541@mcvoy.com>
References: <E1l5RL3-0002iv-Qv@tanda>
<abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
Message-ID: <CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
Moved to COFF - and I should prefix this note with a strongly worded --
these are my own views and do not necessarily follow my employers (and
often have not, as some of you know that have worked with me in the past).
On Wed, Feb 3, 2021 at 8:34 PM Larry McVoy <lm at mcvoy.com> wrote:
> The x86 stuff is about as far away from PDP-11 as you can get. Required
> to know it, but so unpleasant.
>
BTW: Once again we 100% agree *on the architecture part of* *the discussion*.
And frankly pre-386 days, I could not think how anyone would come up with
it. As computer architecture it is terrible, how did so many smart people
come up with such? It defies everything we are taught about 'good'
computer architectural design. But .... after all of the issues with the
ISA's of Vax and the x86/INTEL*64 *vs.* Alpha --- is how I came to the
conclusion, *architecture does not matter nearly as much as economics and
we need to get over it and stop whining. * Or in Christensen's view, a new
growing market is often made from a product that has technically not as
good as the one in the original mainstream market but has some value to the
new group of people.
x86 (and in particular once the 386 added linear 32 bit addressing), even
though DOS/Windows sucked compared to SunOS (or whatever), the job (work)
that the users needed to do was performed to the customer's satisfaction *and
for a lot less.* The ISVs could run their codes there and >>they<< sell
more copies of their code which is what they care about. The end-users,
really just care about getting a job done.
What was worse was at the time, it was the ISV's keep their own prices
higher on the 'high-value platform' - which makes the cost of those
platforms ever higher. During the Unix wars, this fact was a huge issue.
The same piece of SW for a Masscomp would cause 5-10 more than a Sun -- why
we were considered a minicomputer and Sun was a workstation. Same 10MHz
68000 inside (we had a better compiler so we ran 20% faster). This was
because the ISV's classified Masscomp's competition was considered the Vax
8600; not Sun and Apollo -- sigh.
In the end, the combination of x86 and MSFT did it to Sun. For example,
my college roommates (who were trained on the first $100K
architecture/drawing 3D systems developed at CMU on PDP-11/Unix and Triple
Drip Graphic's Wonder) Wintel running a 'boxed' AutoCAD was way more
economical than a Sun box with a custom architecture package -- economics
won, even though the solution was technically not as good. Another form
of the same issue did you ever try to write a technical >>publication<<
with Word (not a letter or a memo) -- it sucks -- The pro's liked FrameMaker
and other 'authoring tools' (hey I think even Latex and Troff are -- much '
better' for the author) -- but Frame costs way more and Word, so what do
the publishers want -- ugh Word DOC format [ask Steinhart about this issue,
he lived it a year ago].
In the case of the Arm, Intel #$%^'ed 101-15 yrs ago up when Jobs said he
wanted a $20 processor for what would become the iPhone and our execs told
him to take a hike (we were making too much money with high margin
Window's) boxes. At the time, Arm was 'not as good' - but it had two
properties Jobs cared about (better power - although at the time Arm was
actually not much better than the laptop x86s, but Apple got Samsung to
make/sell parts at less than $20 -- i.e. economics).
Again, I'm not a college professor. I'm an engineer that builds real
computer systems that sometimes people (even ones like the folks that read
this list) want to/have wanted buy. As much as I like to use sold
architecture principle to guide things, the difference is I know be
careful. Economics is really the higher bit. What the VAX engineers at
DEC or the current INTEL*64 folks (like myself) was/is not what some of the
same engineers did with Alpha -- today, we have to try to figure out how to
make the current product continue to be economically attractive [hence the
bazillion new instructions that folks like Paul W in the compiler team
figure out how to exploit, so the ISV's codes run better and can sell more
copies and we sell more chips to our customers to sell to end users].
But like Jobs's, DEC management got caught up in the high margin game, and
ignored the low end (I left Compaq after I managed to build the $1K Alpha
which management blew off -- it could be sold at 45% margins like the Alpha
TurboLaser or 4x00 series). Funny, one of the last things I had proposed
at Masscomp in the early 80s before I went to Stellar, was a low-end system
(also < $1K) and Masscomp management wanted to part of it -- it would have
meant competing with Sun and eventually the PC.
FWIW: Intel >>does<< know how to make a $20 SOC, but the margins will
suck. The question is what will management want to? I really don't
know. So far, we have liked the server chip margins (don't forget Intel
made more $s last year than it ever has - even in the pandemic).
I feel a little like Dr Seuss' 'Onceler' in the Lorax story ... if Arm can
go upscale from the phone platform who knows what will happen - Bell's Law
predicts Arm displaces INTEL*64:
“Approximately every decade a new computer class forms as a new “minimal”
computer either through using fewer components or use of a small fractional
part of the state-of-the-art chips.”
FWIW: Bell basically has claimed a technical point, based on Christenson's
observation; the 'lessor' technology will displace the 'better one.' Or
as I say it, sophisticated architecture always losses to better economics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210205/505a72e2/attachment-0001.htm>
From lm at mcvoy.com Sat Feb 6 00:56:18 2021
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 5 Feb 2021 06:56:18 -0800
Subject: [COFF] [SPAM] Re: Architectures -- was [TUHS] 68k prototypes &
microcode
In-Reply-To: <CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
References: <abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
<CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
Message-ID: <20210205145618.GE13916@mcvoy.com>
On Fri, Feb 05, 2021 at 09:36:20AM -0500, Clem Cole wrote:
> FWIW: Intel >>does<< know how to make a $20 SOC, but the margins will
> suck. The question is what will management want to? I really don't
> know. So far, we have liked the server chip margins (don't forget Intel
> made more $s last year than it ever has - even in the pandemic).
I think Intel is sort of in the same place Sun was. Fat, dumb, and
happy with the profits they are making and can't see what is coming.
It just didn't make sense to have $20,000 Sun workstations when a $2,000
PC was at least half as good. I advocated for SunOS on x86, to me,
it was the operating system that delivered the value, everything just
worked on SunOS, for any other OS you were doing the configure dance.
Offer SunOS on x86 and capture the low end market. The East coast Sun
did the road runner but West coast Sun sneered at it, patches for x86
were not processed very fast, if at all. It's a shame.
If Intel doesn't want to make money off of the cheap, but very high
volume, $20 SOC, Apple has shown that it has the chops to make a cheap,
fast, and power sipping M1 chip. Pretty impressive and if I were Intel,
I'd be nervous. Apple has shown they can switch architectures pretty
painlessly repeatedly. The x86 lock in isn't much of a lock in these
days.
From cym224 at gmail.com Sat Feb 6 03:41:09 2021
From: cym224 at gmail.com (Nemo Nusquam)
Date: Fri, 5 Feb 2021 12:41:09 -0500
Subject: [COFF] AT&T 3B1 - Emulation available
In-Reply-To: <YB0HbaQezaZ8MiaR@server.rulingia.com>
References: <E1l5RL3-0002iv-Qv@tanda>
<abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<YB0HbaQezaZ8MiaR@server.rulingia.com>
Message-ID: <8cf725f9-7f6c-1c3b-7212-a496692bc0ec@gmail.com>
On 02/05/21 03:53, Peter Jeremy via COFF wrote (in part):
> Moving more off-topic, M68k got RISC-ified as the ColdFire MCF5206.
> That seemed (to me) to combine the feel of the M68k with the
> clock/power gains from RISC. Unfortunately, it didn't take off.
I know not how much of the embedded market used ColdFire but I recall a
lot of our embedded projects used ColdFire.
N.
From david at kdbarto.org Sat Feb 6 04:31:20 2021
From: david at kdbarto.org (David Barto)
Date: Fri, 5 Feb 2021 10:31:20 -0800
Subject: [COFF] [SPAM] Re: Architectures -- was [TUHS] 68k prototypes &
microcode
In-Reply-To: <20210205145618.GE13916@mcvoy.com>
References: <abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
<CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
<20210205145618.GE13916@mcvoy.com>
Message-ID: <A5214B93-187F-4C6B-8B13-82F7330FF4E7@kdbarto.org>
> On Feb 5, 2021, at 6:56 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
> If Intel doesn't want to make money off of the cheap, but very high
> volume, $20 SOC, Apple has shown that it has the chops to make a cheap,
> fast, and power sipping M1 chip. Pretty impressive and if I were Intel,
> I'd be nervous. Apple has shown they can switch architectures pretty
> painlessly repeatedly. The x86 lock in isn't much of a lock in these
> days.
On my morning walk with a friend we discussed what iNtel is going to
do about the M1 and coming M2, M3 chips from Apple. His contention
was that iNtel can’t do much because each vendor will want a different
configuration of the chip; more cores fewer GPU’s, more GPU’s fewer
cores, more of both, more/less RAM on board, etc.
It is unlikely that a SOC from iNtel can’t meet this varied selection so
it is unlikely to move into that market. It does have a solid lock on the
server market and it may just stick with that for the foreseeable future.
The problem is that if the newer M2/M3 chips can perform at server
performance while retaining the low power consumption that the M1
has done, iNtel may see that its best days are past.
Disclaimer: I’ve got an M1 mini, and I have to say it is stunningly fast.
David
From athornton at gmail.com Sat Feb 6 05:16:21 2021
From: athornton at gmail.com (Adam Thornton)
Date: Fri, 5 Feb 2021 12:16:21 -0700
Subject: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode
In-Reply-To: <CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
References: <E1l5RL3-0002iv-Qv@tanda>
<abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
<CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
Message-ID: <A1E35439-2B94-4FBD-B7FE-6A6A01D264C6@gmail.com>
> On Feb 5, 2021, at 7:36 AM, Clem Cole <clemc at ccc.com> wrote:
>
> I feel a little like Dr Seuss' 'Onceler' in the Lorax story ... if Arm can go upscale from the phone platform who knows what will happen - Bell's Law predicts Arm displaces INTEL*64:
> “Approximately every decade a new computer class forms as a new “minimal” computer either through using fewer components or use of a small fractional part of the state-of-the-art chips.”
>
> FWIW: Bell basically has claimed a technical point, based on Christenson's observation; the 'lessor' technology will displace the 'better one.' Or as I say it, sophisticated architecture always losses to better economics.
…
As it happens, I got my M1 Macbook Air on Tuesday.
Nothing seems slower than my 2018 Air, which is kind of astonishing given that I know most of the applications are still Intel-native and being run under Rosetta emulation (and x86_64 is not a particularly easy architecture to emulate).
And, oh my goodness, the battery life.
I’ve been unplugging it first thing in the morning, and I don’t have to plug it in again until 2PM-ish. I have Slack and Discord open, both of which were horrendous CPU hogs on the Intel Air, and am doing light Python development with it, albeit not tons of compilation. My Intel Air’s CPU temperature was usually 65C, going up to 80C if I did a video call. The M1 is at 32.2C, which given that the ambient temperature in my office is probably 22C (Tucson, during the winter, with the doors and windows open), is pretty impressive, especially since it has no fan. Last night it did a 3-1/2 hour video call from the battery without any complaint whatsoever.
So…arm64 is cheap, fast, and remarkaby power-efficient[*]. I am impressed.
Adam
[*] not that I didn’t know this before. The first four items at https://mvsevm.fsf.net/ <https://mvsevm.fsf.net/> are running on a single Pi 3B+ running 64-bit Ubuntu. It doesn’t have a battery, but I think it’s drawing at most 5W, and the CPU temperature is 52C (also passively cooled).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210205/cd7c1760/attachment.htm>
From dave at horsfall.org Sat Feb 6 08:02:11 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 6 Feb 2021 09:02:11 +1100 (EST)
Subject: [COFF] [SPAM] Re: Architectures -- was [TUHS] 68k prototypes &
microcode
In-Reply-To: <20210205145618.GE13916@mcvoy.com>
References: <abf50209-5730-f5a0-0fd6-aec13ee68440@e-bbes.com>
<202102030759.1137x7C2013543@freefriends.org>
<CAHTagfHdykiYmqPCkhQkUQTU8fLqJBukPOyj-k1ef=Ur9rqH+Q@mail.gmail.com>
<202102030858.1138wuqd011051@freefriends.org>
<CAHTagfGOC7vgE2Os+kuP4oGzvot2kG3MERpQdLb2EoEhUoFpyg@mail.gmail.com>
<CAC20D2M_33YdQyuHdb7EM-UVNcdM0TXz9eJXpTftHekWxK0=Dg@mail.gmail.com>
<27567.1612399305@hop.toad.com>
<bce2c77e-dd8d-a0f2-5b27-0f9239c76738@kilonet.net>
<20210204013356.GA16541@mcvoy.com>
<CAC20D2ONCSvaHJTbiisp7EqnszbGDxVu0GgqeQq1CJf2KmN5AA@mail.gmail.com>
<20210205145618.GE13916@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.2102060834300.70858@aneurin.horsfall.org>
On Fri, 5 Feb 2021, Larry McVoy wrote:
> I think Intel is sort of in the same place Sun was. Fat, dumb, and
> happy with the profits they are making and can't see what is coming.
I guess we'll find out soon enough; there is a history of companies "too
big to fail" of failing.
> It just didn't make sense to have $20,000 Sun workstations when a $2,000
> PC was at least half as good. I advocated for SunOS on x86, to me, it
> was the operating system that delivered the value, everything just
> worked on SunOS, for any other OS you were doing the configure dance.
> Offer SunOS on x86 and capture the low end market. The East coast Sun
> did the road runner but West coast Sun sneered at it, patches for x86
> were not processed very fast, if at all. It's a shame.
I actually got to play with a Road Runner at a Sun conference (its
hostname was "milpitas" of course) and came away impressed that one of the
best OSes ran on the worst possible architecture :-)
> If Intel doesn't want to make money off of the cheap, but very high
> volume, $20 SOC, Apple has shown that it has the chops to make a cheap,
> fast, and power sipping M1 chip. Pretty impressive and if I were Intel,
> I'd be nervous. Apple has shown they can switch architectures pretty
> painlessly repeatedly. The x86 lock in isn't much of a lock in these
> days.
Well, when you're big enough to be able to make both your own HW and SW
then things will go smoothly (which is why my MacBook works so well). I
look forward to Brian Krebs' "Patch Tuesday" announcements; I can only
think that it's some form of "Stockholm Syndrome" despite there being many
free alternatives.
Heck, I remember in the days of the Pee-Cee "grey imports" that if it
didn't run Flight Simulator then it was illegal; shortly afterwards if it
didn't run FS then nobody would buy it...
Ah, "schadenfreude" is such a beautiful word :-)
-- Dave
From rudi.j.blom at gmail.com Sat Feb 6 13:01:07 2021
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sat, 6 Feb 2021 10:01:07 +0700
Subject: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode
(Clem Cole)
Message-ID: <CAMYpm86HP5jcqqROYi=s4p76OWfiQ0QBEfw-Eq0yOLHjwyeoAA@mail.gmail.com>
I have to agree with Clem here. Mind you I still mourn the demise of
Alpha and even Itanium but then I never had to pay for those systems.
I only make sure they run properly so the customer can enjoy their
applications.
My 32-1/2 cents (inflation adjusted).
Take care and stay as healthy as some of my 25 year old servers :-)
Cheers,
uncle rubl
>From: Clem Cole <clemc at ccc.com>
>To: Larry McVoy <lm at mcvoy.com>
>Cc: COFF <coff at minnie.tuhs.org>
>Bcc:
>Date: Fri, 5 Feb 2021 09:36:20 -0500
>Subject: Re: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode
<snip>
>BTW: Once again we 100% agree on the architecture part of the discussion. And frankly >pre-386 days, I could not think how anyone would come up with it. As computer >architecture it is terrible, how did so many smart people come up with such? It defies >everything we are taught about 'good' computer architectural design. But .... after all of >the issues with the ISA's of Vax and the x86/INTEL*64 vs. Alpha --- is how I came to the >conclusion, architecture does not matter nearly as much as economics and we need to >get over it and stop whining. Or in Christensen's view, a new growing market is often >made from a product that has technically not as good as the one in the original >mainstream market but has some value to the new group of people.
<snip>
--
The more I learn the better I understand I know nothing.
From rudi.j.blom at gmail.com Sat Feb 6 13:15:52 2021
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sat, 6 Feb 2021 10:15:52 +0700
Subject: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode
(Clem Cole)
In-Reply-To: <CAMYpm86HP5jcqqROYi=s4p76OWfiQ0QBEfw-Eq0yOLHjwyeoAA@mail.gmail.com>
References: <CAMYpm86HP5jcqqROYi=s4p76OWfiQ0QBEfw-Eq0yOLHjwyeoAA@mail.gmail.com>
Message-ID: <CAMYpm84cAgcQu5_Gdphth8=0ZKpzuyiX9iSNO2mV94ae7swcrQ@mail.gmail.com>
Before some start, I didn't mean 25-year old AlphaServers or Itanium
boxes. I meant some fine aDEC400Xp and DECpc MTE servers, powered by
Intel 80496 (some even 33MHz!). The oldest AlphaServer, a DS10, is
from 1996 (has a new motherboard though). The oldest HP rx-server, two
rx1620, are from 2006.
Cheers,
uncle 'miereneuker' rubl
On 06/02/2021, Rudi Blom <rudi.j.blom at gmail.com> wrote:
> I have to agree with Clem here. Mind you I still mourn the demise of
> Alpha and even Itanium but then I never had to pay for those systems.
> I only make sure they run properly so the customer can enjoy their
> applications.
>
> My 32-1/2 cents (inflation adjusted).
> Take care and stay as healthy as some of my 25 year old servers :-)
> Cheers,
> uncle rubl
>
>>From: Clem Cole <clemc at ccc.com>
>>To: Larry McVoy <lm at mcvoy.com>
>>Cc: COFF <coff at minnie.tuhs.org>
>>Bcc:
>>Date: Fri, 5 Feb 2021 09:36:20 -0500
>>Subject: Re: [COFF] Architectures -- was [TUHS] 68k prototypes & microcode
>
> <snip>
>>BTW: Once again we 100% agree on the architecture part of the discussion.
>> And frankly >pre-386 days, I could not think how anyone would come up with
>> it. As computer >architecture it is terrible, how did so many smart
>> people come up with such? It defies >everything we are taught about
>> 'good' computer architectural design. But .... after all of >the issues
>> with the ISA's of Vax and the x86/INTEL*64 vs. Alpha --- is how I came to
>> the >conclusion, architecture does not matter nearly as much as economics
>> and we need to >get over it and stop whining. Or in Christensen's view,
>> a new growing market is often >made from a product that has technically
>> not as good as the one in the original >mainstream market but has some
>> value to the new group of people.
> <snip>
> --
> The more I learn the better I understand I know nothing.
>
--
The more I learn the better I understand I know nothing.
From mparson at bl.org Wed Feb 10 03:58:34 2021
From: mparson at bl.org (Michael Parson)
Date: Tue, 09 Feb 2021 11:58:34 -0600
Subject: [COFF] [TUHS] Typing tutors
In-Reply-To: <YCDMJVmIcfrBmAAp@geeks.org>
References: <5cb7edc8-7d43-aa3a-334f-18e17aa2fa16@gmail.com>
<CAC20D2M5EOKO9TZoa0W2NWaC+9dGS3Ki3wVxcLhN2=w0Fm8E_w@mail.gmail.com>
<eme3130d78-0f3c-4769-b340-d536ae47f325@alien>
<2ffbcab8-b651-c3f9-d4ed-e9ff792cfde6@mhorton.net>
<alpine.BSF.2.21.9999.2102070930110.70858@aneurin.horsfall.org>
<1a7a35b7-4105-20b7-65ed-1eabb663d0ca@mhorton.net>
<60205C88.6070808@gmail.com> <YCDMJVmIcfrBmAAp@geeks.org>
Message-ID: <e9a290eb3e791617ee197acbc19a31ad@bl.org>
<moving to coff, less unix heritage content here>
On 2021-02-07 23:29, Doug McIntyre wrote:
> On Sun, Feb 07, 2021 at 04:32:56PM -0500, Nemo Nusquam wrote:
>> My Sun UNIX layout keyboards (and mice) work quite well with my Macs.
>> I share your sentiments.
>
> Most of the bespoke mechanical keyboard makers will offer a dipswitch
> for what happens to the left of the A, and with an option to print the
> right value there, my keyboards work quite well the right way.
I've been using the CODE[0] keyboard with 'clear' switches for the past
few years and have been very happy with it. Has the dipswitches for
swapping around CTRL/CAPS and the meta/Alt, probably others as well.
When I don't have hardware solutions to this, most modern OSes let you
remap keys in software. Being a gnu screen user, CTRL & A being right
next too each other makes life easier.
I've used enough keyboards over the years that didn't even have an ESC
key (Mac Plus, the Commodore 64, the keyboard on my Samsung tablet,
probably a few others), that I got in the habit of using CTRL-[ to
generate an ESC and still do that most of the time rather than reaching
for the ESC up there in the corner.
> I did use the Sun Type5 USB Unix layout for quite some years, but I
> always found it a but mushy, and liked it better switching back to
> mechanical keyboards with the proper layout.
Before I got this keyboard, I used a Sun Type 7 keyboard (USB with the
UNIX layout). It had the CTRL and ESC keys in the "right" places (as
noted above, ESC location doesn't bother me as much), but yeah, they're
mushy, and big. Much happier with the mechanical keyboard for my daily
driver.
I've been eyeballing the TEX Shinobi[1], a mechanical keyboard with the
ThinkPad type TrackPoint, cut down on reasons for my fingers to leave
the keyboard even more.
--
Michael Parson
Pflugerville, TX
[0] http://codekeyboards.com/
[1] https://tex.com.tw/products/shinobi?variant=16969884106842
From crossd at gmail.com Fri Feb 12 21:58:10 2021
From: crossd at gmail.com (Dan Cross)
Date: Fri, 12 Feb 2021 05:58:10 -0600
Subject: [COFF] Fwd: [TUHS] nothing to do with unix,
everything to do with history
In-Reply-To: <CAP6exY+SPiEEfCaYJe7Tn=RTB-f=2+0hM+TyPCDwFfGYC_Gzgg@mail.gmail.com>
References: <CAP6exY+SPiEEfCaYJe7Tn=RTB-f=2+0hM+TyPCDwFfGYC_Gzgg@mail.gmail.com>
Message-ID: <CAEoi9W5_bd0cgrm7PHnk7GBmkV0NRkkuNvM0NVXCSwKQo0GS3g@mail.gmail.com>
The COFF folks may have a bead on this if no one on TUHS does.
---------- Forwarded message ---------
From: ron minnich <rminnich at gmail.com>
Date: Wed, Feb 10, 2021, 9:33 AM
Subject: [TUHS] nothing to do with unix, everything to do with history
To: TUHS main list <tuhs at minnie.tuhs.org>
There's so much experience here, I thought someone might know:
"Our goal is to develop an emulator for the Burroughs B6700 system. We
need help to find a complete release of MCP software for the Burroughs
B6700.
If you have old magnetic tapes (magtapes) in any format, or computer
printer listings of software or micro-fiche, micro-film, punched-card
decks for any Burroughs B6000 or Burroughs B7000 systems we would like
to hear from you.
Email nw at retroComputingTasmania.com"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210212/91879571/attachment.htm>
From peter at rulingia.com Thu Feb 18 17:32:24 2021
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 18 Feb 2021 18:32:24 +1100
Subject: [COFF] [TUHS] cut, paste, join, etc.
In-Reply-To: <e11f295f-a4db-ae4f-0da6-85b6d52be7ad@spamtrap.tnetconsulting.net>
References: <CAKH6PiUq57sJws=Wk9dvaqN5umvBKLNYr8ow5Q0Z4ywGNbtaZQ@mail.gmail.com>
<26484818-2f05-37d3-adff-6e34d383e117@gmail.com>
<399f2cdc-d790-c4fe-18e3-0cb6b4c76554@spamtrap.tnetconsulting.net>
<55d60220-c22d-c99f-f40c-68a741183213@gmail.com>
<e11f295f-a4db-ae4f-0da6-85b6d52be7ad@spamtrap.tnetconsulting.net>
Message-ID: <YC4YCOXGU9whoZZG@server.rulingia.com>
=> COFF since it's left Unix history behind.
On 2021-Feb-16 21:08:15 -0700, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>I like SQLite and Berkeley DB in that they don't require a full RDBMS
>running. Instead, an application can load what it needs and access the
>DB itself.
I also like SQLite and use it quite a lot. It is a full RDBMS, it
just runs inside the client instead of being a separate backend
server. (BDB is a straight key:value store).
>I don't remember how many files SQLite uses to store a DB.
One file. I often ship SQLite DB files between systems for various
reasons and agree that the "one file" is much easier that a typical RDBMS.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210218/7de8d5b9/attachment.sig>
From gtaylor at tnetconsulting.net Sun Feb 21 03:23:35 2021
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 20 Feb 2021 10:23:35 -0700
Subject: [COFF] [TUHS] cut, paste, join, etc.
In-Reply-To: <YC4YCOXGU9whoZZG@server.rulingia.com>
References: <CAKH6PiUq57sJws=Wk9dvaqN5umvBKLNYr8ow5Q0Z4ywGNbtaZQ@mail.gmail.com>
<26484818-2f05-37d3-adff-6e34d383e117@gmail.com>
<399f2cdc-d790-c4fe-18e3-0cb6b4c76554@spamtrap.tnetconsulting.net>
<55d60220-c22d-c99f-f40c-68a741183213@gmail.com>
<e11f295f-a4db-ae4f-0da6-85b6d52be7ad@spamtrap.tnetconsulting.net>
<YC4YCOXGU9whoZZG@server.rulingia.com>
Message-ID: <c13dcfa3-43e3-07af-baf4-e701ed6c3c29@spamtrap.tnetconsulting.net>
On 2/18/21 12:32 AM, Peter Jeremy via COFF wrote:
> I also like SQLite and use it quite a lot. It is a full RDBMS, it
> just runs inside the client instead of being a separate backend server.
> (BDB is a straight key:value store).
Fair enough.
I was referring to an external and independent daemon with it's own
needs for care & feeding.
> One file. I often ship SQLite DB files between systems for various
> reasons and agree that the "one file" is much easier that a typical
> RDBMS.
*nod*
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20210220/f913224f/attachment.bin>
From rudi.j.blom at gmail.com Sun Feb 21 12:33:41 2021
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Sun, 21 Feb 2021 09:33:41 +0700
Subject: [COFF] [TUHS] cut, paste, join, etc. (Grant Taylor)
Message-ID: <CAMYpm85F54BXEL5OmORToFosKRF7wJHJ=eMp_AD33TgQ2-yAhw@mail.gmail.com>
I've been maintaining a customer's application which uses C-ISAM as
database interface on SCOUNIX, TRU64 and HP-UX. Simple and above all
in 'C' ! As wiki says
"IBM still recommends the use of the Informix Standard Engine for
embedded applications"
https://en.wikipedia.org/wiki/IBM_Informix_C-ISAM
Mind you, the page hasn't seen significant changes since 2006 :-)
Of course not having C-ISAM as a shared library can make executables a
bit big unless included in a custom made shared library which I never
really tried on SCOUNIX, but did on the newer UNIXes. A diskette used
on SCOUNIX for certain offline salvage actions just isn't 'spacious'
enough.
Cheers,
uncle rubl
.
>From: Grant Taylor <gtaylor at tnetconsulting.net>
>To: coff at minnie.tuhs.org
>Cc:
>Bcc:
>Date: Sat, 20 Feb 2021 10:23:35 -0700
>Subject: Re: [COFF] [TUHS] cut, paste, join, etc.
>On 2/18/21 12:32 AM, Peter Jeremy via COFF wrote:
>>I also like SQLite and use it quite a lot. It is a full RDBMS, it just runs inside the client >>instead of being a separate backend server. (BDB is a straight key:value store).
>
>Fair enough.
>
>I was referring to an external and independent daemon with it's own needs for care & >feeding.
>.
>>One file. I often ship SQLite DB files between systems for various reasons and agree >>that the "one file" is much easier that a typical RDBMS.
>
>*nod*
>
>--
>Grant. . . .
>unix || die
--
The more I learn the better I understand I know nothing.
From dave at horsfall.org Mon Feb 22 08:22:16 2021
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 22 Feb 2021 09:22:16 +1100 (EST)
Subject: [COFF] [TUHS] cut, paste, join, etc.
In-Reply-To: <c13dcfa3-43e3-07af-baf4-e701ed6c3c29@spamtrap.tnetconsulting.net>
References: <CAKH6PiUq57sJws=Wk9dvaqN5umvBKLNYr8ow5Q0Z4ywGNbtaZQ@mail.gmail.com>
<26484818-2f05-37d3-adff-6e34d383e117@gmail.com>
<399f2cdc-d790-c4fe-18e3-0cb6b4c76554@spamtrap.tnetconsulting.net>
<55d60220-c22d-c99f-f40c-68a741183213@gmail.com>
<e11f295f-a4db-ae4f-0da6-85b6d52be7ad@spamtrap.tnetconsulting.net>
<YC4YCOXGU9whoZZG@server.rulingia.com>
<c13dcfa3-43e3-07af-baf4-e701ed6c3c29@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.2102220916460.70858@aneurin.horsfall.org>
On Sat, 20 Feb 2021, Grant Taylor via COFF wrote:
>> I also like SQLite and use it quite a lot. It is a full RDBMS, it just
>> runs inside the client instead of being a separate backend server. (BDB
>> is a straight key:value store).
>
> Fair enough.
+1 for another happy SQLite user; it "just works".
-- Dave, who implemented "join" under BDB