From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 7a15bb56 for ; Sat, 31 Aug 2019 02:57:55 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1FA619C0DB; Sat, 31 Aug 2019 12:57:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 7CFF79C092; Sat, 31 Aug 2019 12:57:29 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="WyPu4Ohl"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 376689C092; Sat, 31 Aug 2019 12:57:27 +1000 (AEST) Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by minnie.tuhs.org (Postfix) with ESMTPS id 87A6A9C00B for ; Sat, 31 Aug 2019 12:57:26 +1000 (AEST) Received: by mail-qt1-f196.google.com with SMTP id g4so9830767qtq.7 for ; Fri, 30 Aug 2019 19:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jpO87WyKCd727k0EipuL8x6zXUHHg8WbCNUfUUuWd8c=; b=WyPu4OhlzJQ0bywHDMuuYTfKBaY6xUKt3/7zCcuPfAYwKin+3r4o36hR0xa4xoeTZ2 2JVYJtn4xwiuklRKyLyYeHGtSn5XBEWO51Mzm9Lxtw76R0uRiNJ+XbglaLB8DlJuz1Mj bjn3kPQcxbNbY3PIPj6F1E1xDaioUglH/oTeU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jpO87WyKCd727k0EipuL8x6zXUHHg8WbCNUfUUuWd8c=; b=I9fOIFvG2pGEHyanjuqCGSAP2XTQyYMogEZcLZ+nOBMAUfkErXe+rVxC7b5KOST5yK F76Ksxhetx4hrcb0A/2z58sTUy2iuSORXr9j4gPz6MgHuN63gWrFtLKRFYs8Qt/vk+1w 67r+LDQkcLQvQFkK6RZl3WG95gVaQpYYeg8iaQeAfFoSWdDqiU7ysxf5m8jND7/92zE6 l0ynfoWZCVzAmf5IKJolmj7QxwLhtH/M0DL5Qq4Db+GSGctBLAYOZ55vdEHBYBVRMMCb v98V0ckJ8/d4uu9qXs6QQSyygP+v6PdZeAHKrdPXabF4HuPZ5IbAM9wrFNIQmv/C/BT1 mtQA== X-Gm-Message-State: APjAAAVxi8+X9dmYKxll2a8/JWuJRllVt4UUUEbu7yHAGAD6gZIEMqsp y7gtenHZejsVURBSaxEainJ8tpjREmWlgA== X-Google-Smtp-Source: APXvYqyTnFqUtkruxwVEFuKIMtWWLiJen9DfdCy824xcOyZYeQqVhP1bT3r1KK0ecWIqZ6PX4uva5A== X-Received: by 2002:a0c:aad4:: with SMTP id g20mr5347093qvb.139.1567220245094; Fri, 30 Aug 2019 19:57:25 -0700 (PDT) Received: from [192.168.10.108] (pool-173-48-42-254.bstnma.fios.verizon.net. [173.48.42.254]) by smtp.gmail.com with ESMTPSA id h29sm4507404qtb.46.2019.08.30.19.57.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Aug 2019 19:57:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Clem cole X-Mailer: iPhone Mail (16G77) In-Reply-To: <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> Date: Fri, 30 Aug 2019 22:57:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> To: Bakul Shah Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Btw. The issue with the 68k was Nick Tredenick=E2=80=99s original Microcode d= id not save enough information during some of the faults. Les Crudele once t= old me, that it turns out he had tried to fix it but there were a series of e= rrors and some short cuts they used to fit it in the store. They gave up tr= ying to fix it as the part was purely skunkworks and they could not respin i= t at the time. After it succeeded and were a real project, the difference b= etween the original and the 10 was Nick redid the microcode but they had mad= e a larger microstore - otherwise basically the same Si. =20 Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.= =20 > On Aug 30, 2019, at 10:46 PM, Clem cole wrote: >=20 > There was most definitely a TLB or as Dave called it =E2=80=98The TB=E2=80= =99 *** > Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and= designed the BI before he left dec. He was a bus and memory specialist=20 >=20 >=20 > *** west coast VS east coast training - calling it a TB vs a TLB. =20 >=20 > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quit= e.=20 >=20 >>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: >>>=20 >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >>>=20 >>> Actually not in lock step. They were independent. One was called the >>> executor and the other the fixer. When a fault was detected the executo= r >>> was sent wait stated while the fixer handled the fault and refilled the >>> TLB. Once the TLB was set to instruction was allowed to complete. B= tw >>> when the 68010 was released the pals on the board were changed to allow t= he >>> executor to actually take the fault and do something else while the fixe= r >>> replaced the TLB entry >>=20 >> As I remember, the issue with 68000 was that instructions were >> not restartable so in case of accessing memory that didn't >> exist, you couldn't take a segfault and do anything useful. >> This is why you needed a second processor to deal with an >> external MMU. There would have been no TLB unless you actually >> added an external TLB -- but an external CAM would've been >> very expensive. May be a direct map? >>=20 >> What we did at Fortune was to utilize a 4 entry external map: >> text, data, extra and stack. When a new function was invoked >> it would do a 'probe'. If the probe caused a segfault, stack >> was extended in the handler. The probe didn't have to be >> restartable. So we didn't need a second 68k. This logic may >> have been in the V7 port we started from.