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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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 04:51:31 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Message-ID: <3C63CB16.645FE25E@cfmu.eurocontrol.be> From: Ian Wild Reply-To: ian.wild@eurocontrol.int Organization: Eurocontrol X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.30 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada's Slide To Oblivion ... 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cache-Post-Path: ecw.eurocontrol.be!unknown@193.221.189.77 X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Date: Fri, 08 Feb 2002 12:51:26 GMT NNTP-Posting-Host: 193.221.170.178 X-Complaints-To: abuse@Belgium.EU.net X-Trace: nreader3.kpnqwest.net 1013172686 193.221.170.178 (Fri, 08 Feb 2002 13:51:26 MET) NNTP-Posting-Date: Fri, 08 Feb 2002 13:51:26 MET Xref: archiver1.google.com comp.lang.ada:19770 Date: 2002-02-08T12:51:26+00:00 List-Id: Ole-Hjalmar Kristensen wrote: > > ??? This is pure fantasy. How do you think the code got into the code > space in the first place? (sigh) Let's take the example of a 68000 'cos I've got the data sheet readily available. There are three lines coming out of the processor which distinguish various spaces. Of interest are: supervisor code supervisor data user code user data If the OS is clever, and many of them were, it's set up the MMU tables such that 'user code' exists at some point in 'supervisor data', at least long enough to load the executable from disc. At some later point it may re-map things so that 'user data' exists at that same address in 'supervisor data', letting it initialise the bss. At some late stage it initialises the MMU so that 'user code' starts at address 0, 'user data' starts at address 0 (but with the first page unmapped to catch NULL pointers), and does a mode switch. There is then NO WAY from user mode to write to the 'user code' space, and only limited (ie PC relative) access for reading. Oh - before anyone suggest it, no, the MMU is not visible from user mode either. Is this really rocket science? I would've though the above sufficiently obvious that I could have got a patent on it.