RTX-2000 processor PC/AT add-in card (any takers?)

[Sean Conner]

It was thus said that the Great Jecel Assumpcao Jr. via cctalk once stated:
> Chuck Guzis via cctalk wrote on Date: Mon, 10 Apr 2017 15:21:08 -0700
> > Thanks for the list--I was aware of the various Java engines and the WD
> > P-code engine, but had never run into the SCAMP.
> 
> I just found an academic Pascal microprocessor from 1980 called EM-1 and
> described all the way to the chip layout level:
> 
> http://authors.library.caltech.edu/27046/1/TR_2883.pdf
> 
> > Okay, I've got to ask--exactly what made the 8086 unsuitable for C, but
> > work with Pascal?  I'll admit to puzzlement about this statement.
> 
> I talked about the problem with far pointers and C in the post about the
> iAPX 432.
> 
> The 64KB segments in the 8086 were not a problem for Pascal (or
> Smalltalk, as shown by the Xerox PARC Notetaker computer) because each
> heap object and each proceedure can live in a different segment to take
> advantage of the whole memory. A single object (like an array) can't be
> split into multiple segments which limits us to small objects (this is
> not a problem for Smalltalk which can completely hide such splits as
> shown in the Mushroom computer).

  There's nothing here that makes it a problem for C.  You will end up with
using large pointers (segment, offset) but that would be the same for your
hypothetical Pascal compiler.

> One big difference between Pascal and C is that while C seems to have
> nested lexical scoped like Algol at first glance (and indeed it is often
> list as being part of the "Algol family") it really doesn't. 

  It does.


> An object
> either lives in the heap or is in the local stack frame. 

  The same is true for Pascal or any other language in the "Algol" family.  

> You can declare
> new variables inside { ... } and they will shadow variables with the
> same name declared outside of these brackets but this has no effect on
> the runtime structures.
> 
> Pascal, on the other hand, allows proceedures to be declared inside
> other proceedures and these nested scopes can access stuff declared in
> the more external scopes. 

  Yes.  You cannot do this in C because unlike Pascal (and I support others
in the Algol family), C allows you to pass functions to other functions via
function pointers.  Pascal does not allow this [1], because of exactly this
reason---external scopes.  [2]  It becomes more difficult to support.  Not
impossible, just real ugly (and most likely a special case).

> This requires some runtime structures that can
> be awkward to implement in many processor architectures. An expression
> like:
> 
>      x := y;
> 
> might generate quite a bit of code if "x" was declared one level up and
> "y" was declared three levels up. But on the 8086 we could have pointers
> to the frames of the various lexical levels saved at the start of the
> current frame just like the "display registers" in the Burroughs B5000.

  Yes, and so can the VAX, 6809, 68000, MIPS, SPARC.  It might be a bit more
convenient to do on the Intel x86 line, but almost no compiler I know of
actually *use* the x86 instructions dedicated for this feature (they're too
slow).

> We could have something like:
> 
>      mov di,[bp-2*3] ; lexical level 3
>      mov ax,[di-20] ; y
>      mov di,[bp-2*1] ; lexical level 1
>      mov [di-8],ax ; x

  Ah yes, the ENTER instruction.

> Filling up those pointers on each proceedure entry can take some time so
> a popular alternative for when nested references were not too common was
> to have a linked list of runtime frames and code like:
> 
>      mov di,[bp-2] ; lexical level 1
>      mov di,[di-2] ; lexical level 2
>      mov di,[di-2] ; lexical level 3
>      mov ax,[di-20] ; y
>      mov di,[bp-2] ; lexical level 1
>      mov [di-8],ax ; x

  You mean:

	mov	di,[bp]	; up one level
	mov	di,[di]	; up two levels
	mov	di,[di]	; up three levels
	mov	ax,[di - 20],ax
	mov	di,[bp]	; up one level
	mov	[di - 8],ax

  -spc


[1]	Standard Pascal.  I'm willing to conceed a system might have a
	Pascal with non-standard extensions that allow function pointers,
	but then it isn't standard Pascal, is it?

[2]	GCC does allow you to declare nested functions in C, but again,
	that's a non-standard C extension.