Path: ...!weretis.net!feeder8.news.weretis.net!news.neodome.net!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Mon, 9 Sep 2024 20:44:00 +0000
Organization: Rocksolid Light
Message-ID: <b600ed88d1ede37171831e0f3cdd4e31@www.novabbs.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1461306"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$mHaMhj8ZaLnM9AOGbfDSkuyld5e1rsJ5L0GeivDBcg5NniJrmW446
Bytes: 2981
Lines: 43

On Mon, 9 Sep 2024 19:38:52 +0000, Brett wrote:

> MitchAlsup1 <mitchalsup@aol.com> wrote:
>> On Sun, 8 Sep 2024 21:09:39 +0000, Lawrence D'Oliveiro wrote:
>>
>>> On Sun, 8 Sep 2024 17:56:55 +0000, MitchAlsup1 wrote:
>>>
>>>> The problem with VAX was NOT that one could not put a lot of work in a
>>>> single instruction;
>>>>
>>>> no,
>>>>
>>>> The problem with VAX is that it made putting too much work in a single
>>>> instruction easy.
>>>
>>> Perhaps there is also the issue of the wildly-variable instruction
>>> length.
>>> A single VAX operand descriptor could be up to 6 bytes; I think the
>>> instruction with the most general-format operands could have 6 of them:
>>> so, plus opcode, such an instruction could be 37 bytes long.
>>
>> I have not heard an argument that the complex things in VAX ISA are
>> a) desirable
>> b) performance helpful
>
> 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.

Unlike RISC-V and may others; My 66000 has maskable integer exceptions.
An exception can be routed directly to a signal handler of the current
application (without a trip through GuestOS). GuestOS just has to
configure where exceptions are delivered.

> The future of programming languages is type safe with checks, you need
> to get on that bandwagon early.

This would/will happen faster when type-safe with checks are well
represented in benchmarks used to measure various architectural
things, and the exceptions and checks are actually utilized showing
performance degradation of lesser endowed architectures.