The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bqt@update.uu.se (Johnny Billquist)
Subject: [TUHS] /dev/drum
Date: Wed, 9 May 2018 00:39:36 +0200	[thread overview]
Message-ID: <56c4a8d3-c4dc-5876-7ca3-acda31ee9dc7@update.uu.se> (raw)
In-Reply-To: <mailman.1.1525744802.16322.tuhs@minnie.tuhs.org>

On 08.05.18 04:00, jnc at mercury.lcs.mit.edu  (Noel Chiappa) wrote:
>      > From: Johnny Billquist
> 
>      > My point being that ... pages are invisible to the process segments are
>      > very visible. And here we talk from a hardware point of view.
> 
> So you're saying 'segmentation means instructions explicitly include segment
> numbers, and the address space is a two-dimensional array', or 'segmentation
> means pointers explicitly include segment numbers', or something like that?

Not really. I'm trying to understand your argument.

You said:
"BTW, this reminds me of another key differentiator between paging and
segments, which is that paging was originally _invisible_ to the user 
(except
for setting the total size of the process), whereas segmentation is 
explicitly
visible to the user."

And then you used MERT as an example of this.

My point then is, how is MERT any different from mmap() under Unix? 
Would you then say that the paging is visible under Unix, meaning that 
this is then segmentation?

In my view, you are talking about a software concept. And as such, it 
has no bearing on whether a machine have pages or segments, as that is a 
hardware thing and distinction, while anything done as a service by the 
OS is a completely different, and independent question.

> I'm more interested in the semantics that are provided, not bits in
> instructions.

Well, if we talk semantics instead of the hardware, then you can just 
say that any machine is segmented, and you can say that any machine is 
have pages. Because I can certainly make it appear both ways from the 
software point of view for applications running under an OS.
And I can definitely do that on a PDP-11. The OS can force pages to 
always be 8K in size, and the OS can (as done by lots of OSes) provide a 
mechanism that gives you something you call segments.

> It's true that with a large address space, one can sort of simulate
> segmentation. To me, machines which explicitly have segment numbers in
> instructions/pointers are one end of a spectrum of 'segmented machines', but
> that's not a strict requirement. I'm more concerned about how they are used,
> what the system/user gets.

So, again. Where does mmap() put you then?
And, just to point out the obvious, any machine with pages have a page 
table, and the page table entry is selected based on the high bits of 
the virtual address. Exactly the same as on the PDP-11. The only 
difference is the number of pages, and the fact that the page on the 
PDP-11 do not have a fixed length, but can be terminated earlier if wanted.
So, pages are explicitly numbered in pointers on any machine with pages.

> Similarly for paging - fixed sizes (or a small number of sizes) are part of
> the definition, but I'm more interested in how it's used - for demand loading,
> and to simplify main memory allocation purposes, etc.

I don't get it. So, in which way are you still saying that a PDP-11 
don't have pages?

>      >> the semantics available for - and_visible_  to - the user are
>      >> constrained by the mechanisms of the underlying hardware.
> 
>      > That is not the same thing as being visible.
> 
> It doesn't meet the definition above ('segment numbers in
> instructions/pointers'), no. But I don't accept that definition.

I'm trying to find out what your definition is. :-)
And if it is consistent and makes sense... :-)

>      > All of this is so similar to mmap() that we could in fact be having this
>      > exact discussion based on mmap() instead .. I don't see you claiming
>      > that every machine use a segmented model
> 
> mmap() (and similar file->address space mapping mechanisms, which a bunch of
> OS's have supported - TENEX/TOP-20, ITS, etc) are interesting, but to me,
> orthagonal - although it clearly needs support from memory management hardware.

Can you explain how mmap() is any different from the service provided by 
MERT?

> And one can add 'sharing memory between two processes' here, too; very similar
> _mechanisms_  to mmap(), but different goals. (Although I suppose two processes
> could map the same area of a file, and that would give them IPC mapping.)

That how a single copy of shared libraries happen under Unix.
Exactly what happens if you modify the memory depends on what flags you 
give to mmap().

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


       reply	other threads:[~2018-05-08 22:39 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1.1525744802.16322.tuhs@minnie.tuhs.org>
2018-05-08 22:39 ` Johnny Billquist [this message]
2018-05-07 15:36 Noel Chiappa
  -- strict thread matches above, loose matches on Subject: below --
2018-05-06 13:07 Noel Chiappa
2018-05-06 15:57 ` Johnny Billquist
2018-05-05 13:06 Noel Chiappa
2018-05-05 20:53 ` Johnny Billquist
2018-05-03 11:39 Noel Chiappa
2018-05-03 21:22 ` Johnny Billquist
2018-04-30 15:05 Noel Chiappa
2018-04-30 16:43 ` Paul Winalski
2018-04-30 21:41 ` Johnny Billquist
2018-05-03  2:54 ` Charles Anthony
2018-04-28 20:40 Noel Chiappa
2018-04-29 15:37 ` Johnny Billquist
2018-04-29 16:34   ` Steve Nickolas
2018-04-29 16:48     ` Warner Losh
2018-04-28  0:19 Noel Chiappa
2018-04-28 10:41 ` Johnny Billquist
2018-04-28 12:19   ` Rico Pajarola
2018-04-27 23:01 Noel Chiappa
2018-04-27 23:10 ` Johnny Billquist
2018-04-27 23:39   ` Warner Losh
     [not found] <mailman.1.1524708001.6296.tuhs@minnie.tuhs.org>
2018-04-27 22:41 ` Johnny Billquist
2018-04-26  1:53 Noel Chiappa
     [not found] <mailman.143.1524696952.3788.tuhs@minnie.tuhs.org>
2018-04-25 23:08 ` Johnny Billquist
2018-04-25 22:55 Noel Chiappa
     [not found] <mailman.139.1524690859.3788.tuhs@minnie.tuhs.org>
2018-04-25 22:54 ` Johnny Billquist
2018-04-25 22:46 Noel Chiappa
     [not found] <mailman.137.1524667148.3788.tuhs@minnie.tuhs.org>
2018-04-25 21:43 ` Johnny Billquist
2018-04-25 22:24 ` Johnny Billquist
2018-04-26  5:51   ` Tom Ivar Helbekkmo
2018-04-25 22:37 ` Johnny Billquist
2018-04-24  7:10 Rudi Blom
     [not found] <mailman.125.1524526228.3788.tuhs@minnie.tuhs.org>
2018-04-23 23:44 ` Johnny Billquist
2018-04-23 23:57   ` Steve Nickolas
2018-04-24  0:24   ` Ronald Natalie
2018-04-24  0:25   ` Warren Toomey
2018-04-24  0:31     ` Dave Horsfall
2018-04-24  1:02   ` Lyndon Nerenberg
2018-04-24  4:32   ` Grant Taylor
2018-04-24  4:49     ` Bakul Shah
2018-04-24  4:59       ` Warner Losh
2018-04-24  6:22         ` Bakul Shah
2018-04-24 14:57           ` Warner Losh
2018-04-24  6:46   ` Lars Brinkhoff
2018-04-23 22:01 Noel Chiappa
2018-04-23 22:09 ` Warner Losh
2018-04-23 18:41 Noel Chiappa
2018-04-23 19:09 ` Clem Cole
2018-04-23 23:01 ` Dave Horsfall
2018-04-23 23:49   ` Dave Horsfall
2018-04-24  0:26   ` Ronald Natalie
2018-04-22 18:06 Norman Wilson
2018-04-20 16:45 Noel Chiappa
2018-04-20 16:53 ` Charles Anthony
2018-04-20 17:16 ` William Pechter
2018-04-20 23:35   ` Dave Horsfall
2018-04-22 11:48     ` Steve Simon
2018-04-20 15:02 Tim Bradshaw
2018-04-20 15:58 ` Clem Cole
2018-04-20 16:00 ` David Collantes
2018-04-20 16:12   ` Dan Cross
2018-04-20 16:21     ` Clem Cole
2018-04-20 16:33     ` Warner Losh
2018-04-20 19:17       ` Ron Natalie
2018-04-20 20:23         ` Clem Cole
2018-04-20 22:10         ` Dave Horsfall
2018-04-22 17:01     ` Lars Brinkhoff
2018-04-22 17:37       ` Clem Cole
2018-04-22 19:14         ` Bakul Shah
2018-04-22 20:58         ` Mutiny
2018-04-22 22:37           ` Clem cole
2018-04-22 21:51         ` Dave Horsfall
2018-04-25  1:27           ` Dan Stromberg
2018-04-25 12:18             ` Ronald Natalie
2018-04-25 13:39               ` Tim Bradshaw
2018-04-25 14:02                 ` arnold
2018-04-25 14:59                   ` tfb
2018-04-25 14:33               ` Ian Zimmerman
2018-04-25 14:46                 ` Larry McVoy
2018-04-25 15:03                   ` ron minnich
2018-04-25 20:29               ` Paul Winalski
2018-04-25 20:45                 ` Larry McVoy
2018-04-25 21:14                   ` Lawrence Stewart
2018-04-25 21:30                     ` ron minnich
2018-04-25 23:01                 ` Bakul Shah
2018-04-23 16:42         ` Tim Bradshaw
2018-04-23 17:30           ` Ron Natalie
2018-04-23 17:51             ` Clem Cole
2018-04-23 18:30               ` Ron Natalie
2018-04-25 14:02                 ` Tom Ivar Helbekkmo
2018-04-25 14:38                   ` Clem Cole
2018-04-23 20:47               ` Grant Taylor
2018-04-23 21:06                 ` Clem Cole
2018-04-23 21:14                   ` Dan Mick
2018-04-23 21:27                     ` Clem Cole
2018-04-23 22:07                 ` Tim Bradshaw
2018-04-23 22:15                   ` Warner Losh
2018-04-23 23:30                     ` Grant Taylor
2018-04-24  9:37                       ` Michael Kjörling
2018-04-24  9:57                         ` Dave Horsfall
2018-04-24 13:01                           ` Nemo
2018-04-24 13:03                         ` Arthur Krewat
2018-04-23 23:45                   ` Arthur Krewat
2018-04-24  8:05                     ` tfb

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=56c4a8d3-c4dc-5876-7ca3-acda31ee9dc7@update.uu.se \
    --to=bqt@update.uu.se \
    /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).