Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!samsung!aplcen!haven!decuac!shlump.nac.dec.com!mountn.dec.com!minow
From: minow@mountn.dec.com (Martin Minow)
Newsgroups: comp.lang.c
Subject: Re: PDP-11 data and function address spaces (was External ptrs and arrays)
Message-ID: <1048@mountn.dec.com>
Date: 10 Nov 89 14:46:22 GMT
References: <530@dftsrv.gsfc.nasa.gov> <225800239@uxe.cso.uiuc.edu> <11567@smoke.BRL.MIL> <20642@mimsy.umd.edu>
Reply-To: minow@mountn.dec.com (Martin Minow)
Organization: Digital Equipment Corporation
Lines: 43

In article <20642@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>In article <11567@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>By the way, the PDP-11 is the main example of a system where data and
>>function address spaces are distinct ....
>
>Before anyone jumps in and `corrects' Doug with stories of 11s in their
>college days ...

Hmmph, in my college days, computers used these funny-looking glass bottles
called tubes.
>
>This is reflected in C in that
>
>	char *p;
>	int fn();
>
>	p = (char *)fn;
>
>is non-portable, and hence, even after such an assignment, the result of
>
>	(*(int (*)())p)();
>
>is at best non-standard.

However, it should work, since the only thing that distinguished an
"instruction" reference from a "data" reference was the instruction
(actually, the register address) used to reference it.  What you
couldn't do (easily), however, was
	short function[] = {
	    012700,		/* Move value to R0		*/
	    012345,		/* Random value			*/
	    000207,		/* Return			*/
	};
	int	(*fn)();	/* Address of a function	*/
	...
	    fn = &function[0];
	    result = (*fn)();
The problem here is that the value you assign to "fn" is a virtual
address in data space, but the same virtual address in instruction
space may be a completely different physical address.

Martin Minow
minow@thundr.enet.dec.com