Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: a bit of history, Stealing a Great Idea from the 6600
Date: Sat, 4 May 2024 21:14:41 +0000
Organization: Rocksolid Light
Message-ID: <fdfd2d7fde1050cbad7dd647f1cd991a@www.novabbs.org>
References: <71acfecad198c4e9a9b14ffab7fc1cb5@www.novabbs.org> <2024May3.173347@mips.complang.tuwien.ac.at> <v139qt$121r$1@gal.iecc.com> <v151fp$15b28$1@dont-email.me> <v162bc$1623$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="94834"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$nbHrSVL/8299iPpJwbvSMuRHGSDxSXA.FR2lOgPu5WbT0nxaGyphu
Bytes: 2702
Lines: 38

John Levine wrote:

> According to Thomas Koenig  <tkoenig@netcologne.de>:
>>John Levine <johnl@taugh.com> schrieb:
>>
>>> It is my impression that
>>> trapping on fixed point overflow is not very useful, and it's easier
>>> to do a jump on overflow in the few cases where you care, or the x86
>>> INTO which you put after the arithmetic operaion to trap if the
>>> overflow flag is set.
>>
>>Sanitzers would benefit greatly from trapping math.
>>
>>However, this could get into murky territory - to be really
>>general, you would also need a version for trapping math with
>>unsigned numbers.  Just think of doing a unsigned loop with a
>>lower bound that, due to some error in the code or input, has an
>>upper bound of 0-1...

> I suppose but my experience was always that the trap was the easy
> part. 

If it is the easy part, why does it take ~1,000* cycles ??

(*) x86 takes craploads of cycles to cross the trap barrier and back
{including the saving and restoration of registers}
Something like My 66000 takes 10 each way including the saving and 
restoring of registers, and the change of MMU state.

>       Figuring out what to do after the trap happens is much harder.

Depends on what the trap delivers to the "other side", and also dependent
on the range of options the handler has to consider; and sometimes on
how many instructions go through that trap !?!

> I've seen designs with instructions like "trap if greater than N" so
> if you want to go that route, you can check for the range the
> programemr declared rather than whatever word size it was rounded up
> to.