[net.arch] Sparse addressing info wanted

kvc@scgvaxd.UUCP (Kevin Carosso) (07/08/85)

In article <306@cstvax.UUCP> db@cstvax.UUCP (Dave Berry) writes:
>
>Some implementations of untyped trendy languages (LISP, PROLOG etc.) use a 
>form of soft-tagging (aka bounds checking) whereby the top byte of the address
>of an object depends on the type of that object.  This makes run-time type 
>checking relatively painless.
>
>  a) if I'm talking bullshit, in which case I apologise for wasting your time
>  b) which hardware allows sparse addressing (e.g. I think Pyramids do, Vaxes
>	don't; I've no idea about Suns, IBMs etc).
>  c) if software can get in the way - e.g. UNIX malloc seems to be a hindrance.
>	If this is so, are there any OS which do a better job?
>

I don't quite see what the hardware has to do with this.  As far as I
know, most (all?) memory management schemes simply map virtual to physical
addresses.  Thus, although address must be contiguous within a segment
or page, the segments/pages themselves need not be contiguous.  It's
entirely possible that I just take this for granted in the systems I
use, however, and everyone else does it wrong... :-)

In any case, to be more specific, I don't see how you can say VAXen
don't support "sparse addressing".  Under VMS (I don't know about UNIX)
you can map whatever addresses you want.  In general, address space
for a process is never completely contiguous.

If you really want (and for your purposes you do) you can use system
services to map virtual address ranges of your own choosing.  Thus,
you could map a range of whatever size you like for each type you need.

	/Kevin Carosso    {allegra | ihnp4 | seismo}!scgvaxd!engvax!kvc
	 Hughes Aircraft Co.        engvax!kvc @ CIT-VAX.ARPA

paul@greipa.UUCP (Paul A. Vixie) (07/09/85)

I think when he said "vaxes don't have sparse addressing" he was alluding to
the 30-bit addresses.  The top 2 bits of VAX/VMS memory addresses denote "P0"
or "P1" space; addresses above 0x80000000 cannot be mapped into without some
special priviledge and then *very carefully* lest you map out your SYS$------
vectors.

Just thought I'd clear that up.  Except for this error, the VAX would be as
nice to write code for as a NS32000.
-- 

	Paul Vixie
	{decwrl dual pyramid}!greipa!paul

db@cstvax.UUCP (Dave Berry) (07/09/85)

[follow-ups will go to net.arch]

Some implementations of untyped trendy languages (LISP, PROLOG etc.) use a 
form of soft-tagging (aka bounds checking) whereby the top byte of the address
of an object depends on the type of that object.  This makes run-time type 
checking relatively painless.
As I understand things, some virtual memory manglement implementations require 
all memory allocated to a process to be contiguous.  Implementations which don't
force this are said to allow "sparse addressing", and are more efficient for
soft-tagging language subsystems since they don't have to allocate large numbers
of redundant page table entries (and swap space?).
I'd like to know
  a) if I'm talking bullshit, in which case I apologise for wasting your time
  b) which hardware allows sparse addressing (e.g. I think Pyramids do, Vaxes
	don't; I've no idea about Suns, IBMs etc).
  c) if software can get in the way - e.g. UNIX malloc seems to be a hindrance.
	If this is so, are there any OS which do a better job?

This info is for a report a friend is having to write for her boss.
As ever, most replies should be by mail.
-- 
	Dave Berry. CS postgrad, Univ. of Edinburgh		
					...mcvax!ukc!{hwcs,kcl-cs}!cstvax!db

chris@umcp-cs.UUCP (Chris Torek) (07/10/85)

Actually, I think you're both wrong about what he meant (isn't this
fun? :-) ).  The Vax can do sparse addressing, but it takes a lot
of page table entries to do it in system space since there is only
a single level lookup.  However, no ordinary programs should really
want to fiddle with system space maps anyway, so just think of a
Vax as a 2GB virtual machine, rather than a 4GB machine, and you'll
be OK.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland