[Beowulf] Stroustrup regarding multicore

[Perry E. Metzger]

"Robert G. Brown" <rgb at phy.duke.edu> writes:
> I don't know how much of current compiler design was bent by Intel's
> original segmented memory model.  They had code data stack and extra (or
> something like that -- but I recall EX,SX,DX, and CX).  But then
> motorola's memory model was flat instead of segmented, and it wasn't
> until the 386 or 486 or thereabouts before one "could" run an x86 flat
> and there was too much legacy code about at that point and it never
> really happened.

The Unix memory model pretty much hasn't changed since long before
there was a version of Unix for the 386. The memory layout on 32V on
the Vax and later 4BSD wasn't terribly different from the sort of
stuff we see now.

> But way, way long ago -- on IBM mainframes and with cards -- my original
> and only "real computer science course" was on computer architecture and
> microprogramming and so on, and IIRC even then the subroutine call
> ritual was push arguments onto the stack, allocate locals by moving the
> stack pointer, then dereference both by relative displacement from the
> stack pointer.  C calls by reference in part because a function return
> simply restores the pointer (de facto losing the locals) and then pops
> the stack (de facto losing the arguments, although one "can" get them
> if one is working in assembler and can prevent stack movement in
> the meantime.

Most ALGOL-descended languages, like Pascal, C, etc. have procedure
calls that look pretty much like that, with activation records (local
variables and arguments) on a single stack and a return simply popping
everything off by simply changing the stack pointer and restoring the
program counter. Languages in this family that allow pass by reference
(see arguments declared VAR in Pascal and the like) simply pass
pointers and deal with the "paperwork" in the compiler -- it looks to
the programmer like a normal variable but it is a pointer "inside". C,
being pretty lightweight, makes you do the "paperwork" yourself by
passing a pointer and dereferencing it.

There are very, very different systems in some modern languages. Some
of them allocate all their activation records in the same garbage
collected arena used for everything else, rather than using the stack,
which allows for games like saving continuations merely by keeping a
reference to an activation chain (read up on
call-with-current-continuation if you want to have your mind twisted...)
I haven't looked at the inside of Haskell, but I suspect it gets even
weirder.

Perry
-- 
Perry E. Metzger		perry at piermont.com