Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Thu, 10 Oct 2024 08:57:17 -0400
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <ve8ivf$35i51$1@dont-email.me>
References: <vbd6b9$g147$1@dont-email.me> <O2DHO.184073$kxD8.113118@fx11.iad>
 <vcso7k$2s2da$1@dont-email.me> <efXIO.169388$1m96.45507@fx15.iad>
 <ve1aqu$1qjrq$2@dont-email.me> <KNzNO.209961$EEm7.115549@fx16.iad>
 <ve6o3p$2on4l$1@dont-email.me>
 <d47dee46ffc34977018ff316e0e6ec03@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Oct 2024 14:57:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b7ebef52583c5b046ec1651a99a8240f";
	logging-data="3328161"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/G+33l8HdI+ABlxov2MnQ0zMY3kCHKiS8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6F4Svpw469OZDtPcZHvvcvd96uY=
In-Reply-To: <d47dee46ffc34977018ff316e0e6ec03@www.novabbs.org>
Content-Language: en-US
Bytes: 4243

On 2024-10-09 5:36 p.m., MitchAlsup1 wrote:
> On Wed, 9 Oct 2024 20:12:40 +0000, Robert Finch wrote:
> 
>> On 2024-10-09 2:16 p.m., EricP wrote:
>>> Kent Dickey wrote:
>>>
>>> But crash on overflow *IS* the correct behavior in 99.999% of cases.
>>> Branch on overflow is ALSO needed in certain rare cases and I showed how
>>> it is easily detected.
>>>
>>>> And crash-on-overflow just isn't a popular use model, as I use the
>>>> example
>>>> of x86 in 32-bit mode having a 1-byte INTO instruction which crashes,
>>>> and no compiler seems to use it.  Especially since branch-on-overflow
>>>> is almost as good in every way.
>>>>
>>>> Kent
>>>
>>> Because C doesn't require it. That does not make the capability useless.
>>>
>>> Removing error detectors does not make the errors go away,
>>> just your knowledge of them.
>>>
>>>
>> Slightly confused on trap versus branch. Trapping on overflow is not a
>> good solution, but a branch on overflow is? A trap is just a slow
>> branch. The reason for trapping was to improve code density and
>> non-exceptional performance.
>> If it is the overhead of performing a trap operation that is the issue,
> 
> x86 has seriously distorted peoples view on how much overhead is
> associated with a trap*. MIPS had trap handlers measuring in the
> 17 cycle range both getting to the handler, handling the exception,
> and getting back to the instruction that trapped. Since GBOoO windows
> have mispredicted branches in this kind of latency, too; then a
> properly designed architecture should be able to do similarly to MIPS.
> 
> Whereas x86 may take 1,000 cycles to get to the handler. This is due
> to all the Descriptor table stuff, call-gates, protection rings, and
> segmentation.
> 
> (*) trap == exception == fault == any unpredicted control flow
> cause by the instruction stream itself (SVC-et-al not included
> because it is requested by the instruction stream).
> 
>> then a special register could be dedicated to holding the overflow
>> handler address, and instructions defined to automatically jump through
>> the overflow handler address register (a branch target address
>> register).
>> Overflow detecting instructions are just a fusion of the instruction and
>> the following branch on overflow operation.
>>
>> addjo r1,r2,r3    <- does a jump (instead of a trap) to branch 
>> register #7
>> for instance, on overflow.
>>
>> Having an overflow branch register might be better for code density /
>> performance.
> 
> What if you want to handle multiply overflow differently than
> addition overflow ??

The branch register could be reloaded before the operation with a 
different handler address. It would be one instruction to load a PC 
relative address perhaps. Slightly better than having one instruction 
after every op.
For Q+ there would be room in the instruction to specify a branch 
register, so multiple handler targets could be supported.