Xref: utzoo comp.arch:6503 comp.lang.misc:1963 Path: utzoo!attcan!uunet!super!rminnich From: rminnich@super.ORG (Ronald G Minnich) Newsgroups: comp.arch,comp.lang.misc Subject: Re: Machine-independent intermediate languages Keywords: virtual machine language design Message-ID: <815@super.ORG> Date: 7 Oct 88 14:02:40 GMT References: <853@goofy.megatest.UUCP> <905@sword.bellcore.com> <5933@june.cs.washington.edu> <30151@oliveb.olivetti.com> Sender: uucp@super.ORG Reply-To: rminnich@duper.UUCP (Ronald G Minnich) Organization: Supercomputing Research Center, Lanham, MD Lines: 21 In article <30151@oliveb.olivetti.com> chase@Ozona.UUCP (David Chase) writes: >In case you are wondering, the virtual machine chosen for BCPL can present >problems to efficient implementation on some machines. There was some >paper in SP&E within the last decade or so describing a port of BCPL to >a Burroughs machine, and the task was Not Pretty. you betcha. For example, the Burroughs machine supported arrays and such via segments, but since BCPL really wants a flat address space they decided to take one BIG segment and use that for a program's entire address space, thus throwing away all the nice part of that architecture and paying the performance price for segmentation they did not use. Lots of other problems but the memory model was definitely the worst. I went through this same go-round too when we looked at putting C on that architecture. Let's see now, if i change BCPL to C and Burroughs to 386 in the above, i think that describes what C on the 386 does- each process uses one BIG segment for its entire address space, thus not using the 386 segments. Most (if not all) of the machines that run Unix now share certain assumptions that we all pretty much take for granted. But if you work on a machine that breaks those assumptions you hit them pretty fast. ron