Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: unconventional architectures
Message-ID: <3312@bd.sei.cmu.edu>
Date: 8 May 89 13:20:10 GMT
References: <912@aber-cs.UUCP>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Distribution: eunet,world
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 40

In article <912@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

>Well, the problem with the Intel architecture is that it was designed for
>Pascal, whose pointers can only point to heap allocated objects (and no
>arithmetic on them is allowed). As far as Pascal is concerned, the Intel
>architecture has (three/four) flat address spaces, and the fact that they
>are "distinct" is not a problem.

Leaving aside the question whether the Intel 8086 architecture was
"designed" for anything, let alone Pascal, I still have some
difficulty with the above claim.

True Pascal pointers, things of type ^T, indeed point into a heap,
and moreover the heap can be segmented by type, so that, for instance,

	p1 : ^T1
	p2 : ^T2

can each be represented as a 16-bit offset into a segment bound to
the type.  There is some inefficiency, but it can be made to work,
within the 64k limit per heap-allocated type.

However, Pascal also has implicit pointers by virtue of the VAR
parameter mode.  Consider for instance

	procedure Munge ( var X : T );

This can be called with any of

(a) an actual of type T declared at the outermost level

(b) an actual of type T declared locally

(c) an actual expression p^, where p is of type ^T

If you want to implement all that and still pass only a 16-bit
pointer as the actual parameter, then you must map static,
stack-based, and heap spaces all on top of each other.  Otherwise,
every VAR parameter is 32 bits and can be accessed only by
first loading the segment base into ES.  Very expensive.