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.