Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 10 Sep 2024 15:42:25 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 78
Message-ID: <2024Sep10.174225@mips.complang.tuwien.ac.at>
References: <vbd6b9$g147$1@dont-email.me> <memo.20240905225550.19028d@jgd.cix.co.uk> <2024Sep6.080535@mips.complang.tuwien.ac.at> <vbiftm$ui9$1@gal.iecc.com> <2024Sep8.155511@mips.complang.tuwien.ac.at> <73c6d21457c487c61051ec52fe25ea5d@www.novabbs.org> <vbl3qj$22a2q$1@dont-email.me> <09ce1622b872f0b0fa944e868a8c97be@www.novabbs.org> <vbnisc$2hb59$1@dont-email.me> <2024Sep10.094353@mips.complang.tuwien.ac.at> <20240910120840.000071e1@yahoo.com>
Injection-Date: Tue, 10 Sep 2024 18:27:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f21f15281580639cd9bc25764f54f587";
	logging-data="3216556"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19y2Ueaa1qSgP8UA+GGyBnb"
Cancel-Lock: sha1:ADjJEvUhL2NHxFFDXJCfZLZ0qNY=
X-newsreader: xrn 10.11
Bytes: 4324

Michael S <already5chosen@yahoo.com> writes:
>On Tue, 10 Sep 2024 07:43:53 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Brett <ggtgp@yahoo.com> writes:
>> >Speaking of complex things, have you looked at Swift output, as it
>> >checks all operations for overflow?
>> >
>> >You could add an exception type for that, saving huge numbers of
>> >correctly predicted branch instructions.
>> >
>> >The future of programming languages is type safe with checks, you
>> >need to get on that bandwagon early.  
>> 
>> MIPS got on that bandwagon early.  It has, e.g., add (which traps on
>> signed overflow) in addition to addu (which performs modulo
>> arithmetic).  
>
>Trapping variants were deprecated in Release 6 of MIPS ISA.

Interesting.  So they abandoned the supposed bandwagon in 2014, after
Swift was introduced.

What they did add in the same release are branch instructions that
check whether the sum of two signed integers overflows.  That's useful
for languages with arbitrarily large integers (also knowns as Big
Integers or Bignums), while the trapping adds are too cumbersome for
that purpose.

And it seems to me that Swift with its trapping arithmetic is a blast
from the past (with Algol, Pascal etc. usually erroring out on
overflow, and Ada raising an exception (with famously explosive
consequences for the Ariane 5)), and that the trend in safe languages
is to eliminate integer overflow by allowing arbitrarily large
integers.

>>>It has been abandoned and replaced by RISC-V several
>> years ago.
>
>I don't think that "replaced by RISC-V" is a correct description of
>proceedings.

I don't know anything about the proceedings, just what Wikipedia tells
me:

|In March 2021, MIPS announced that the development of the MIPS
|architecture had ended as the company is making the transition to
|RISC-V.

Sounds like a replacement to me.

>How does Intel MPX fit in your picture?

I don't know anything about MPX beyond what Wikipedia says, which
includes:

|In practice, there have been too many flaws discovered in the design
|for it to be useful, and support has been deprecated or removed from
|most compilers and operating systems.

Maybe a less flawed concept would have been more successful, but
apparently MPX has had no such successor.

Overall, languages that perform bounds checking seem on the rise,
unlike languages that trap on signed integer overflow, so the window
of opportunity for architectural support gets bigger.

However, the question is if there is architectural support that is
significantly better than what can be done with the current
architectural features.  SPARC has architectural tagging support for
LISP, yet a comp.arch poster who worked on a major LISP implementation
(Franz LISP IIRC) reported that their LISP implementation does not use
these instructions.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>