Path: ...!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Bill Findlay <findlaybill@blueyonder.co.uk>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 17 Sep 2024 15:13:43 +0200
Organization: none
Lines: 81
Message-ID: <0001HW.2C99B8070187840B306B4D38F@news.individual.net>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <vbcob9$dvp4$1@dont-email.me> <vbd6ia$e0ld$2@dont-email.me> <UxpCO.174965$Hld5.7714@fx15.iad> <vc41rl$1fhjd$1@dont-email.me> <2024Sep14.152652@mips.complang.tuwien.ac.at> <d93c1dc0455692767c89ea9f7bd47ed1@www.novabbs.org> <vc4o0l$1kuqf$1@dont-email.me> <vc6vno$285g2$1@dont-email.me> <vc8qor$2od9v$1@dont-email.me> <vc99fi$2re3k$2@dont-email.me> <20240916160402.0000087f@yahoo.com> <vc9e72$2smso$1@dont-email.me> <tkYFO.77534$kxD8.10093@fx11.iad> <20240916185857.000011ef@yahoo.com> <lkradoFp9aeU1@mid.individual.net> <4J3GO.141734$FzW1.6413@fx14.iad>
Reply-To: findlaybill@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net OAaPCUFQN6i63BobNeYuuQrhFLz/FiMYz5SoyU8O+jRnt9Qps1
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:dNSiSxLizaPNdbw7ykdg9UpmjvA= sha256:7OvlNlZHAh5ZNRcflhv5Letl/qw40bBovuF3jXSP/uI=
User-Agent: Hogwasher/5.24
Bytes: 4848

On 17 Sep 2024, EricP wrote
(in article <4J3GO.141734$FzW1.6413@fx14.iad>):

> Niklas Holsti wrote:
> > On 2024-09-16 18:58, Michael S wrote:
> > > On Mon, 16 Sep 2024 11:39:55 -0400
> > > EricP <ThatWouldBeTelling@thevillage.com>  wrote:
> > >
> > > > David Brown wrote:
> > > > > On 16/09/2024 15:04, Michael S wrote:
> > > > >
> > > > > > With one exception that usize overflow panics under debug
> > > > > > build.
> > > > >
> > > > > I'm quite happy with unsigned types that are not allowed to
> > > > > overflow, as long as there is some other way to get efficient
> > > > > wrapping on the rare occasions when you need it.
> > > > >
> > > > > But I am completely against the idea that you have different
> > > > > defined semantics for different builds. Run-time errors in a
> > > > > debug/test build and undefined behaviour in release mode is fine -
> > > > > defining the behaviour of overflow in release mode (other than
> > > > > possibly to the same run-time checking) is wrong.
> > > >
> > > > In the compilers that do checking which I have worked with
> > > > there was always a distinction between checked builds and debug
> > > > builds. In my C code I have Assert() and AssertDbg(). Assert stay in
> > > > the production code, AssertDbg are only in the debug builds.
> > > >
> > > > Debug builds disable optimizations and spill all variable updates
> > > > to memory to make life easier for the debugger.
> > > > One usually compiles debug builds with no-optimize and all checks
> > > > enabled.
> > > >
> > > > But debug, optimize, and checking are separate controls.
> > > >
> > > > In the compilers for checking languages I've worked with,
> > > > checking and optimization are compatible.
> > > > For example, if the compiler uses an AddFaultOverflow x = x + 1
> > > > instruction to increment 'x' then it knows no overflow is possible
> > > > and then can make all the other optimizations that C assumes are true.
> > > >
> > > > And on those compilers checks can be controlled with quite fine
> > > > resolution. Checks can be enabled/disabled based on kind of check,
> > > > eg scalar overflow, array bounds,
> > > > for a compilation unit, a routine, a section of code,
> > > > a particular data type, a particular object.
> > > >
> > > > This was all standard on DEC Ada85 so if Rust compilers do not
> > > > do this now they may in the near future.
> > >
> > > If ability to control compilers checks was standard on DEC Ada then it
> > > made DEC Ada none-standard.
> >
> > No, it means that DEC Ada could be used as a standard-conforming Ada
> > compiler or as a non-conforming compiler, to a user-chosen extent.
> >
> > The recommended approach today (for applications where it matters) is to
> > use static analysis of the Ada code (e.g. SPARK or other tools) to prove
> > that run-time errors cannot happen, which then makes it possible to omit
> > the corresponding run-time checks while staying compliant.
>
> DEC Ada did that too. It seems to me this optimization to be a relatively
> straight forward "propagation of constants" type of problem.
Not just that, many language forms actually preclude the need for checks,
e.g.:

for i in this_array'Range loop
.... this_array(i) ...
end loop;

cannot fail on access to this_array(i), and:

this_array := that_array;

cannot fail in any of the ways that are endlessly debated
here in relation to *mem* C routines.

-- 
Bill Findlay