Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
Path: utzoo!watmath!clyde!burl!we13!ihnp4!dual!mats
From: mats@dual.UUCP (Mats Wichmann)
Newsgroups: net.unix
Subject: Re: need memory syscall
Message-ID: <477@dual.UUCP>
Date: Sun, 6-May-84 14:31:36 EDT
Article-I.D.: dual.477
Posted: Sun May  6 14:31:36 1984
Date-Received: Mon, 7-May-84 01:10:46 EDT
References: <29300011@uiucuxc.UUCP> <1346@brl-vgr.ARPA>
Organization: Dual Systems, Berkeley, CA
Lines: 21

Phys(2) is a lovely way to step on yourself. When we had a floating-
point processor board added to our system, a phys() call went into
the floating-point support library which mapped the board into an 
`appropriate' memory address. This `appropriate' address was picked 
right up by one of our compiler vendors. Current revisions of our kernel 
have UEND defined to a different value, since that phys() call happened 
to map the I/O addresses for the board into the middle of the stack......

Anyway, phys() is a VERY hardware-dependant piece of code, which
probably explians why it is found in so few `standard' releases.
I would guess that most micro-UNIX vendors provide something like
phys (UniSoft implements it for all of their ports, V7, Sys III, Sys V, etc),
because in the micro world it is considered more appropriate to be
able to talk directly to specific pieces of hardware not supported by
device drivers. I guess it beats adding peek() and poke() to C.....

Sigh.....

	    Mats Wichmann
	    Dual Systems Corp.
	    ...{ucbvax,amd70,ihnp4,cbosgd,decwrl,fortune}!dual!mats