Page sizes

Are there any processors/PMMUs for which the following would be true (nonzero)?

(pagesize - 1) & pagesize

On 27.06.2020 06:45, Don Y wrote:
> Are there any processors/PMMUs for which the following would be true 
> (nonzero)?
> 
> (pagesize - 1) & pagesize

That would imply that the page size is not an integral power of 2.
Very unlikely.

Regards
--
Bernd

On 6/26/2020 11:33 PM, Bernd Linsel wrote:
> On 27.06.2020 06:45, Don Y wrote:
>> Are there any processors/PMMUs for which the following would be true (nonzero)?
>>
>> (pagesize - 1) & pagesize
> 
> That would imply that the page size is not an integral power of 2.

Yes, that was the point of the question.

> Very unlikely.

As, for my needs, this is one of those "fundamental assumptions", I'm
looking for more assurance than "very unlikely" -- just as one wouldn't
pick one SPECIFIC page size and assume it to be ubiquitous (or even
expecting a single page size to be supported at any given instant)  :>

But, I don't see any VALUE in other sizes as it needlessly complicates
any *hardware* implementation (though poses little barrier to a software
implementation!)

On Fri, 26 Jun 2020 21:45:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>Are there any processors/PMMUs for which the following would be true (nonzero)?
>
>(pagesize - 1) & pagesize

On a decimal (BCD) computer, the page size might have been 10 or 100
words.

However, I much doubt that these ancient computer had MMU hardware,

On 27.06.2020 09:32, Don Y wrote:
> On 6/26/2020 11:33 PM, Bernd Linsel wrote:
> 
> Yes, that was the point of the question.
> 
> 
> As, for my needs, this is one of those "fundamental assumptions", I'm
> looking for more assurance than "very unlikely" -- just as one wouldn't
> pick one SPECIFIC page size and assume it to be ubiquitous (or even
> expecting a single page size to be supported at any given instant)  :>
> 
> But, I don't see any VALUE in other sizes as it needlessly complicates
> any *hardware* implementation (though poses little barrier to a software
> implementation!)

Commonly (in all current mainstream processor architectures like iA32, 
AMD64, ARM, MIPS etc.) a MMU divides a logical address at bit boundaries 
into a page address and an offset.
As a result, the page address on these platforms is always a power of two.

Yes, there _may_ exist some exotic MMUs that let you choose protection 
areas (to avoid the term 'pages') with arbitrary base addresses and 
sizes. This flexibility requires heavily increased hardware efforts and 
cost and complicates an OS's memory management, so it's unlikely to be 
used at all.
One example were the i286/i386's Protected Mode segments, but even there 
was a granularity of 4K/1M, so the assertion 'segment base address is a 
power of two' was also true, you just couldn't be sure each segment had 
the same size. Setting up and maintaining the segment descriptor tables 
was so complicated that mainstream OS's on i386 (NT, Linux) only set up 
the most necessary segments and went on using a flat 4GB address space 
and the page tables of the additional MMU.
Furthermore, using segments slowed down hardware memory accesses 
considerably, that in the '486 and successors added Segment Descriptor 
Caches etc etc.

Conclusion: No, you cannot fundamentally assume that page sizes on any 
existing MMU are powers of two. Hardware designers can implement 
whatever weird and complicated adressing patterns they like.

On 6/26/2020 9:45 PM, Don Y wrote:
 > Are there any processors/PMMUs for which the following would be true
 > (nonzero)?
 >
 > (pagesize - 1) & pagesize

I'm curious why it's important to you. A nice binary round number is 
easy to work with on the programming side and simplifies the silicon 
design side.

JJS

On 27/06/2020 09:32, Don Y wrote:
> On 6/26/2020 11:33 PM, Bernd Linsel wrote:
>> On 27.06.2020 06:45, Don Y wrote:
>>> Are there any processors/PMMUs for which the following would be true
>>> (nonzero)?
>>>
>>> (pagesize - 1) & pagesize
>>
>> That would imply that the page size is not an integral power of 2.
> 
> Yes, that was the point of the question.

If that was the point, why didn't you write that?  Writing a C
expression like that is appropriate if you are writing C code, but it
would make more sense to write what you mean - and /why/ you are asking.

> 
>> Very unlikely.
> 
> As, for my needs, this is one of those "fundamental assumptions", I'm
> looking for more assurance than "very unlikely" -- just as one wouldn't
> pick one SPECIFIC page size and assume it to be ubiquitous (or even
> expecting a single page size to be supported at any given instant)  :>

You might conceivably get an answer "this cpu has non-power-of-two page
sizes".  But you'll never get anything better than "very unlikely" the
other way.  You can't expect anyone (or even a combination of people) in
this newsgroup to have used /every/ cpu design ever made, or that ever
will be made.

If you say why you think page sizes are relevant, however, then it's
conceivable that people could give you more useful answers.


> 
> But, I don't see any VALUE in other sizes as it needlessly complicates
> any *hardware* implementation (though poses little barrier to a software
> implementation!)

Hi Don,


On Fri, 26 Jun 2020 21:45:54 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>Are there any processors/PMMUs for which the following would be
>true (nonzero)?
>
>(pagesize - 1) & pagesize

Not anything you can buy.

George

On Sat, 27 Jun 2020 00:32:00 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 6/26/2020 11:33 PM, Bernd Linsel wrote:
>> On 27.06.2020 06:45, Don Y wrote:
>>> Are there any processors/PMMUs for which the following would be true (nonzero)?
>>>
>>> (pagesize - 1) & pagesize
>> 
>> That would imply that the page size is not an integral power of 2.
>
>Yes, that was the point of the question.
>
>> Very unlikely.
>
>As, for my needs, this is one of those "fundamental assumptions", I'm
>looking for more assurance than "very unlikely" -- just as one wouldn't
>pick one SPECIFIC page size and assume it to be ubiquitous (or even
>expecting a single page size to be supported at any given instant)  :>
>
>But, I don't see any VALUE in other sizes as it needlessly complicates
>any *hardware* implementation (though poses little barrier to a software
>implementation!)

Power-of-2 pages are ubiquitous in available hardware.

4KB is directly supported by almost all CPUs.  Some allow smaller
pages, many allow larger pages, but (excepting Alpha and UltraSparc)
it's hard to find something that can't work with 4KB (perhaps by
combining smaller pages).

https://en.wikipedia.org/wiki/Page_(computer_memory)#Multiple_page_sizes
https://en.wikipedia.org/wiki/Memory_management_unit#Examples

George

Hi George,

Hope you are keeping well...  bad pandemic response, here; really
high temperatures; increasing humidity; and lots of smoke in the
air (but really cool "displays" at night!)  :<   Time to make some
ice cream and enjoy the ride!  :>

On 6/27/2020 2:37 PM, George Neuner wrote:
> Hi Don,
> On Fri, 26 Jun 2020 21:45:54 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
> 
>> Are there any processors/PMMUs for which the following would be
>> true (nonzero)?
>>
>> (pagesize - 1) & pagesize
> 
> Not anything you can buy.

I'm wondering if some of the "classic" designs might scale to newer
device geometries better than some of the newer architectures?

E.g., supporting ~100 (variable sized) segments concurrently and
binding each to a particular "object" (for want of a better word).
If the segment management hardware automatically reloads (in a manner
similar to the TLBs functionality), then this should yield better
(or comparable) performance to the fixed page-size approach (if
you assume the fixed pages poorly "fit" the types of "objects"
that you are mapping)

[I think we discussed this -- or something similar -- a while ago]

You still have a "packing problem" but with a virtual address space
per process, you'd only have to address the "objects" with which a
particular process interacted in any particular address space.
And, that binding (for PIC) could be done at compile time *or*
load time (the latter being more flexible) -- or even RUN-time!