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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,af0c6ea85f3ed92d
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.204.132.72 with SMTP id a8mr1055064bkt.5.1329593141532;
        Sat, 18 Feb 2012 11:25:41 -0800 (PST)
Path: 
 t13ni42722bkb.0!nntp.google.com!news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Arbitrary Sandbox
Date: Sat, 18 Feb 2012 21:24:31 +0200
Organization: Tidorum Ltd
Message-ID: <9qac7gFk0nU1@mid.individual.net>
References: <bfeb9869-9323-4ad5-bdf8-af20593734ef@q8g2000pbb.googlegroups.com>
 <2aaee0a4-e820-4a75-bbaf-d9d09c366d2c@f5g2000yqm.googlegroups.com>
 <4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com>
 <jh7739$9os$1@munin.nbi.dk>
 <203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com>
 <jhh6qr$9av$1@munin.nbi.dk>
 <e10bf38c-3c48-4fa4-bb0a-e61211aee90d@f30g2000yqh.googlegroups.com>
 <193cr8xol0ysi.14p4cp2yxnb0r$.dlg@40tude.net>
 <op.v9veuwe6ule2fv@douda-yannick>
 <1jleu301thnd3$.s23priwn3ajb$.dlg@40tude.net>
 <wccobswc6ob.fsf@shell01.TheWorld.com>
Mime-Version: 1.0
X-Trace: individual.net 49pydd3jDgpLyW+GiId5+wfF1YsdJt882OLhideWPXhkNkTQwG
Cancel-Lock: sha1:YU5tjfghVclfz73ATTGugTsFRSM=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
In-Reply-To: <wccobswc6ob.fsf@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-02-18T21:24:31+02:00
List-Id: <comp.lang.ada>

On 12-02-18 20:55 , Robert A Duff wrote:
> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  writes:
>
>> I wonder what kind of architecture could require a safe implementation of
>> Ada, e.g. when private parts of packages and protected objects would be
>> mapped onto the memory physically inaccessible from public contexts.

  ...

> Why do work at run time that can be done at compile time?
> Implementing things in hardware doesn't magically make
> them free.
>
> Putting high-level support for higher-level languages in hardware
> has been tried a number of times, and it's always been a bad idea.

For some critical systems, having checks at more than one level is good.

I seem to remember that the Burroughs mainframe computers had rather 
poor hardware-level protections. A buggy or malicious compiler could 
generate code that had harmful effects that were not restricted to the 
user running the code, if I remember correctly. A consequence was that 
an ordinary user was not allowed to create a compiler; special 
privileges were required to label a program as a "compiler" and thus let 
it generate executable code.

I agree with Bob that high-level things like visibility do not benefit 
from hardware support. But I wish hardware could detect erroneous 
executions of Ada programs.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .