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.
