The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah <bakul@bitblocks.com>
To: Clem cole <clemc@ccc.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
Date: Fri, 30 Aug 2019 20:38:14 -0700	[thread overview]
Message-ID: <C48679EC-7E4D-489E-8EC0-092AA204965B@bitblocks.com> (raw)
In-Reply-To: <E829BD14-88B7-4469-A1A4-7849BC87CB67@ccc.com>

One thing I can think of is something like this:
IIRC 68k had 24 address bits. So with a 4K page size, you can have one level
pagetable. If the pagetable is in fast SRAM, may be 1 or 2 clock cyles would
be added. If you allow 2^N processes, you need 2^(12+N) entry page table. The
width of the table would depend on the number of 4K pages in the physical
memory. Context switch would be to simply set the 2^N bit process "base"
register. Going beyond 2^N you'd have to swap out a process. Each process can
then grow up to 16MB. I don't think a real translation lookaside buffer would
help much.

It would be interesting to see the actual details.

> On Aug 30, 2019, at 7:57 PM, Clem cole <clemc@ccc.com> wrote:
> 
> Btw. The issue with the 68k was Nick Tredenick’s original Microcode did not save enough information during some of the faults.  Les Crudele once told me, that it turns out he had tried to fix it but there were a series of errors and some short cuts they used to fit it in the store.  They gave up trying to fix it as the part was purely skunkworks and they could not respin it at the time.  After it succeeded and were a real project, the difference between the original and the 10 was Nick redid the microcode but they had made a larger microstore - otherwise basically the same Si.    
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>> On Aug 30, 2019, at 10:46 PM, Clem cole <clemc@ccc.com> wrote:
>> 
>> There was most definitely a TLB or as Dave called it ‘The TB’ ***
>> 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 
>> 
>> 
>> *** west coast VS east coast training - calling it a TB vs a TLB.  
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
>>>> 
>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>>>> 
>>>> Actually not in lock step.  They were independent.  One was called the
>>>> executor and the other the fixer.  When a fault was detected the executor
>>>> 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.    Btw
>>>> when the 68010 was released the pals on the board were changed to allow the
>>>> executor to actually take the fault and do something else while the fixer
>>>> replaced the TLB entry
>>> 
>>> 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?
>>> 
>>> 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.


  parent reply	other threads:[~2019-08-31  3:38 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30 20:21 Norman Wilson
2019-08-30 20:28 ` Larry McVoy
2019-08-30 20:39 ` Clem Cole
2019-08-30 21:52   ` Larry McVoy
2019-08-31  0:58     ` Clem Cole
2019-08-31  1:13       ` Bakul Shah
2019-08-31  2:46         ` Clem cole
2019-08-31  2:57           ` Clem cole
2019-08-31  3:14             ` Gregg Levine
2019-08-31  3:47               ` Clem cole
2019-08-31  3:38             ` Bakul Shah [this message]
2019-08-31  5:37             ` Dave Horsfall
2019-08-31 19:03               ` Clem Cole
2019-09-05  5:11                 ` Al Kossow
2019-09-02  8:28               ` Peter Jeremy
2019-09-02 23:26                 ` Dave Horsfall
2019-08-31  3:19           ` Bakul Shah
  -- strict thread matches above, loose matches on Subject: below --
2019-09-01  2:36 [TUHS] dmr streams & networking [was: Re: If not Linux, then what? Rudi Blom
2019-09-01  2:16 [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] Rudi Blom
2019-08-31  9:43 Rudi Blom
2019-08-31 15:41 ` Clem Cole
2019-08-28 18:41 Doug McIlroy
2019-08-28 18:49 ` arnold
2019-08-28 19:03   ` Chet Ramey
2019-08-28 19:05     ` Larry McVoy
2019-08-29 14:58       ` Jason Stevens
2019-08-29 16:25         ` arnold
2019-08-29 16:38           ` Ralph Corderoy
2019-08-29 17:35             ` arnold
2019-08-28 21:55 ` Rob Pike
2019-08-28 22:29   ` George Michaelson
2019-08-28 22:36     ` William Pechter
2019-08-28 23:02       ` Arthur Krewat
2019-08-29  0:11       ` Clem cole
2019-08-29  0:18         ` George Michaelson
2019-08-29  6:27         ` Lars Brinkhoff
2019-08-28 17:57 Doug McIlroy
2019-08-28 18:05 ` Adam Thornton
2019-08-28 18:08 ` arnold
2019-08-28 18:27 ` Warner Losh
2019-08-28 18:34   ` Warner Losh
2019-08-28 21:54 ` Rob Pike
2019-08-29  6:43   ` arnold
2019-08-29  7:39     ` Rob Pike
2019-08-29 16:26       ` arnold
2019-08-29  3:29 ` Lawrence Stewart
2019-08-29  4:10   ` Larry McVoy
2019-08-28  9:17 Paul Ruizendaal
2019-08-28 10:44 ` Angelo Papenhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C48679EC-7E4D-489E-8EC0-092AA204965B@bitblocks.com \
    --to=bakul@bitblocks.com \
    --cc=clemc@ccc.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).