I remember learning in my computer architecture course about a memory
model by which you could address more memory than using a simple linear
addressing scheme. I forget the exact name of this memory system but
from what I remember you used some of the most significant bits in an
address to choose between a number of segment tables and the rest of
the bits were used to index into that segment table. The prof. said
that this would allow you to address more memory than if you just
translated the address bits directly into a memory address without any
translation.

I never understood at the time how this mechanism allowed you to
address more memory and I am still curious. Can someone tell me the
name of that memory model and explain how it allows you to address more
memory?

Thanks.

From:	joshc
Subject:	Re: increasing addressable memory via paged memory?
Date:	13 Jan 2005 15:45:53 -0800

Thanks to all those who replied. You've all clarified what my prof. was
talking about. Someone named Brian personally e-mailed me and brought
up the PDP-11's memory architecture and that is actually exactly what
the prof was talking about the PDP-11...it is similar to what you have
all described above.

On a related note, what is the proper terminology to describe the
different kinds of memory "architectures"? In other words what do you
call the different ways of organizing memory like paged memory,
segmented memory,e tc...are these memory organizations, memory layouts,
memory architectures, etc...

From:	del cecchi
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 13 Jan 2005 20:13:59 -0600

"joshc" wrote in message
news:1105659953.375947.42430@c13g2000cwb.googlegroups.com...
> Thanks to all those who replied. You've all clarified what my prof.
was
> talking about. Someone named Brian personally e-mailed me and brought
> up the PDP-11's memory architecture and that is actually exactly what
> the prof was talking about the PDP-11...it is similar to what you have
> all described above.
>
> On a related note, what is the proper terminology to describe the
> different kinds of memory "architectures"? In other words what do you
> call the different ways of organizing memory like paged memory,
> segmented memory,e tc...are these memory organizations, memory
layouts,
> memory architectures, etc...
>

Don't forget the IBM System/36 which expanded the memory by having a
bunch (in an SRAM) of what we called Address Translation Registers.
Access to Main Storage by the Main Storage Processor (MSP) used some of
the high bits to access this RAM, which output more bits. The RAM was
written by the Control Storage Processor (CSP) .

Del Cecchi

From:	joshc
Subject:	Re: increasing addressable memory via paged memory?
Date:	13 Jan 2005 03:50:53 -0800

What you said makes a lot of sense above. It's just that the way the
professor explained it he didn't really mention changing b/w segment
tables through setting I/O ports. As I remember the only determination
of which segment to table to use was made by using some number of bits
from the most significant bits of the address. But like you said that
doesn't allow me to address more memory.

This question has really been bothering me and unfortunately I can't
contact him anymore to ask him myself :(.

From:	Yousuf Khan
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 13 Jan 2005 08:14:32 -0500

joshc wrote:
> What you said makes a lot of sense above. It's just that the way the
> professor explained it he didn't really mention changing b/w segment
> tables through setting I/O ports.

That was just the example Terje used about EMS memory. EMS memory was
external memory, so it plugged into an ISA bus expansion slot and
therefore it was a plug-in board, and it needed to be controlled via i/o
ports. But that's generally irrelevant to the discussion about
addressing more memory than is addressable. The important point was that
the processor addresses only a small amount of memory in the external
memory through a moveable window or a frame.

> As I remember the only determination
> of which segment to table to use was made by using some number of bits
> from the most significant bits of the address. But like you said that
> doesn't allow me to address more memory.

Wonder if he wasn't referring to the using these bits as some sort of
pointer into a hash table. As you know, hash table entries can be
pointers into more than one real address at the same time. The software
then uses some cleverness to determine which specific real address is
being referred to after going through the hash table.

Yousuf Khan

From:	Stephen Fuld
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 13 Jan 2005 17:44:13 GMT

"joshc" wrote in message
news:1105617053.175817.302700@c13g2000cwb.googlegroups.com...
> What you said makes a lot of sense above. It's just that the way the
> professor explained it he didn't really mention changing b/w segment
> tables through setting I/O ports.

using I/O ports is just the way it was done on one particular
implementation. One could easily have (and have had and still have today)
architectures where changing the segment tables was done via an instruction.
So you could access more memory than could be addressed in a single
instruction, but it took two instructions (one to change the segment table
and one for the load/store) to do it.

--
- Stephen Fuld
e-mail address disguised to prevent spam

From:	Grumble
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 13 Jan 2005 16:29:42 +0100

joshc wrote:

> What you said makes a lot of sense above. It's just that the way the
> professor explained it he didn't really mention changing b/w segment
> tables through setting I/O ports. As I remember the only determination
> of which segment to table to use was made by using some number of bits
> from the most significant bits of the address. But like you said that
> doesn't allow me to address more memory.
>
> This question has really been bothering me and unfortunately I can't
> contact him anymore to ask him myself :(.

Are you sure you don't have the 8086's segmentation in mind?

It had 16-bit registers, but could address 1 MB using so-called
segment registers.

--
Regards, Grumble

From:	John R. Levine
Subject:	Re: increasing addressable memory via paged memory?
Date:	14 Jan 2005 00:36:24 -0500

>I remember learning in my computer architecture course about a memory
>model by which you could address more memory than using a simple linear
>addressing scheme. I forget the exact name of this memory system but
>from what I remember you used some of the most significant bits in an
>address to choose between a number of segment tables and the rest of
>the bits were used to index into that segment table.

Sounds like swizzled pointers. Google has lots of references.

From:	Terje Mathisen
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 13 Jan 2005 08:14:26 +0100

From:	lynn at garlic.com
Subject:	Re: increasing addressable memory via paged memory?
Date:	14 Jan 2005 09:32:04 -0800

josh.curtz@gmail.com wrote:
> I remember learning in my computer architecture course about a memory
> model by which you could address more memory than using a simple
linear
> addressing scheme. I forget the exact name of this memory system but
> from what I remember you used some of the most significant bits in an
> address to choose between a number of segment tables and the rest of
> the bits were used to index into that segment table. The prof. said
> that this would allow you to address more memory than if you just
> translated the address bits directly into a memory address without
any
> translation.
>
> I never understood at the time how this mechanism allowed you to
> address more memory and I am still curious. Can someone tell me the
> name of that memory model and explain how it allows you to address
more
> memory?

maybe not what you were referring to, but 3033 announced support for
32mbyte real storage ... even tho it was limited to 24bit/16mbyte
addressing.

one could claim that cluster of six (single processor) 4341s ... was
about the same price as 3033, with aggregate mip rate almost 50percent
more than single 3033, and each machine could have 16mbytes of real
storage.

a two-processor 3033 SMP faired even worse ... because it was nominally
limited to 16mbytes real storage.

so the gimick was that the standard 370 page table entry was 16bits
..... with 12bits used for specifying up to 4096 4096-byte pages (i.e.
12+12 == 24bits/16mbytes). the low-order 4bits had 2bits defined and
2bits reserved/undefined. The gimic was that the two reserved/undefined
bits could be redefined and used to specifying up to 16384 4096-byte
(real pages) ... instruction addressing was still limited to 24bits ...
but the page tables and TLB could map a 24-bit virtual address 4kpage
into a 26bit effective real address 4kpage.

there was games played with some pages involving certain kinds of
structures that had to be below the 16mbyte line .... so there was a
move below the line function.

fortunately original 370 architecture had defined a IDAL for doing i/o
transfers ... which happened to be a full-word field (base 360 & 370
i/o infrastructure only supported 24-bit real addressing). This allowed
page in/out to be done directly above the 16mbyte line ... w/o a whole
lot of copying above/below line

From:	Anne & Lynn Wheeler
Subject:	Re: increasing addressable memory via paged memory?
Date:	Sun, 16 Jan 2005 06:54:08 -0700

another was the original description for romp/801
http://www.garlic.com/~lynn/subtopic.html#801

801 hardware was originally described as hardware/software complexity
trade-off ... originally making the hardware simpler so it could fit
in single chip (or small number of chips and/or instructions operate
in single cycle ... depending on whos telling the story).

hardware virtual address segmentation was simplified by just having 16
segments (in 32-bit virtual address space), inverse tables, no
protection domains in the hardware. compiler was responsible for
generating correct code ... and program loader was responsible for
making sure that loaded executables came from certified compiler.

with only 16 segments ... the ability to address memory objects was
somewhat limited ... however the claim was that in-line application
code could change a segment register value as easily as it could
change a general purpose register and/or address register (w/o having
to cross a kernel/protection domain boundary). thru an application had
potentially as much addressing as there were total possible segments
(as opposed to 32bit addressing).

so for romp, there was 32bit virtual addressing ... with 4bits used to
select a segment register and 28bits (256mbytes) used to address
within a segment. a romp segment register held a 12bit segment id
value ... and if you added the 12bits in the segment-id value to the
28bit segment displacement value ... you came up with 40bits. A lot of
the early pc/rt documentation described romp has having 40bit virtual
addressing.

romp was targeted as an office product's displaywriter replacement
using PL.8 programming language and a proprietary closed CPr operating
system. when the displaywriter project was canceled, it was decided to
retarget ROMP to the unix workstation market. Note that this involved
subcontracting a Unix port to the company that had done the PC/IX port
.... and moving to a more traditional kernel protection domain model
.... including added protected/kernel mode & unprotected/non-kernel
mode domains to the hardware. This in turn resulted in eliminating
application programs from doing inline code changing the segment
register value (and using more traditional kernel call mechanism to
manipulate segment register values).

the romp follow-on, RIOS/power/6000, doubled the number of bits in the
segment-id from 12 to 24bits ... and you find some of the early
rios/power/6000 documentationd describing virtual addressing as 52bits
(24bit segment-id plus 28bit segment displacement).

having more traditional kernel/non-kernel protection calls for
manipulating segment register values ... then made the inverted table
design of romp/rios with 12/24 bit segment-ids, more analogous to the
total number of unique page tables that a system could support across
all possible virtual address spaces. say amount of total real storage
devoted to page tables ... although i had developed & shipped
"pageable" page table support as part of the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

so you can have systems that actually had more defined
segments/page-tables that there was real-storage to contain them at
any single moment.

previous post talking about 3033 page table hack allowing addressing
32mbyte real memory with only 24bit/16mbyte addressing:
http://www.garlic.com/~lynn/2005.htm#34 increasing addressable memory via paged memory?

misc. past posts mentioning 3033 page table hack for 32mbyte real:
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/