From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,da46977c58c329df X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-08 05:06:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!opentransit.net!fu-berlin.de!uni-berlin.de!ppp-2-132.5800-13.telinco.NET!not-for-mail From: nickroberts@ukf.net (Nick Roberts) Newsgroups: comp.lang.ada Subject: Re: Ada's Slide To Oblivion ... Date: Fri, 08 Feb 2002 13:08:43 GMT Message-ID: <3c63c7a5.398689067@news.cis.dfn.de> References: <4519e058.0201310714.650888e1@posting.google.com> <3C598CAA.7040801@home.com> <3C59FCD3.928144FB@adaworks.com> <7v8za79id0.fsf@vlinux.voxelvision.no> <3C6288CB.3227AF20@cfmu.eurocontrol.be> <3C62D397.8040001@mail.com> <%rC88.3860$oC3.2148048@typhoon.san.rr.com> <3C63AB8A.F52337D8@cfmu.eurocontrol.be> <7vlme4w4ax.fsf@vlinux.voxelvision.no> NNTP-Posting-Host: ppp-2-132.5800-13.telinco.net (212.1.135.132) X-Trace: fu-berlin.de 1013173564 45725018 212.1.135.132 (16 [25716]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:19771 Date: 2002-02-08T13:08:43+00:00 List-Id: On Fri, 08 Feb 2002 12:23:48 GMT, Ole-Hjalmar Kristensen wrote: >Ian Wild writes: > >> David Brown wrote: >> On, say, a high end PDP-11, or a 68000, or an 8086 (but not its >> progeny!), code space and data space are physically separate. There >> are wires that come out of the processor to say which space to use. On >> such a system there's NO WAY to write to code space, and it's not >> impossible that > >??? This is pure fantasy. How do you think the code got into the code >space in the first place? It is not fantasy, but I think factually slightly imperfect. As far as I recall, neither the 8086 nor the 8088 (nor any of their progeny) ever had this kind of control signal. I'm not sure, but I don't think the 68000 did either (and certainly didn't need it, since it had 24-bit physical addressing at the outset). I don't actually know about the PDPs. However, I do know that the Zilog Z8002 processor (a typical 16-bit processor of the 1980s) did indeed have such control signals, which could be used by onboard circuitry to physically separate instruction space from data space (and indeed stack space from heap space). Some configurations merely overlapped them, sticking with the traditional 64KB; others used this as a way of getting 128KB or 192KB address space, at the expense of much more complex extra decoding logic. To answer the question: >How do you think the code got into the code >space in the first place? The circuitry also distinguished between normal (user) mode and privileged (supervisor) mode. It was necessary for a buffer to be provided which allowed the supervisor (operating system) to gain access to all the different address spaces, precisely so as to be able to load program code (and static data) and to prime other spaces. >> On >> such a system there's NO WAY to write to code space, and it's not >> impossible that It is necessary for processors that do have separate program space to provide a way for user programs to access data in that space, since static data associated with the program will also reside there. The Z8000 processors actually had a 'relative address' mode which provided just this capability, and the capability it provided included writing as well as reading; however the aforementioned control signals also distinguished between reads and writes, and so the control circuitry could (and sometimes did) prevent writing into code space in normal mode. So it would be better to say that on some targets it would be impossible (for a user program) to write into code space, but on other targets it would be possible to do so. (Even considering just targets which have the differentiation between program space and data space.) -- Nick Roberts