Re: catch and throw, was Is multi-level function return possible?

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Sat, 29 Mar 2014 03:38:01 +0000 (UTC)

          From comp.compilers
Related articles
[4 earlier articles]
Re: catch and throw, was Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-27)
Re: catch and throw, was Is multi-level function return possible? gneuner2@comcast.net (George Neuner) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? acolvin@efunct.com (mac) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? ivan@ootbcomp.com (Ivan Godard) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-29)
Re: catch and throw, was Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-29)
Re: catch and throw, was Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-29)
Re: catch and throw, was Is multi-level function return possible? ivan@ootbcomp.com (Ivan Godard) (2014-03-28)
Re: precise and imprecise, was catch and throw, was Is multi-level fun ivan@ootbcomp.com (Ivan Godard) (2014-03-28)
Re: catch and throw, was Is multi-level function return possible? alan@scooby-doo.csail.mit.edu (Alan Bawden) (2014-03-29)
| List of all articles for this month |
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Sat, 29 Mar 2014 03:38:01 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 14-03-065 14-03-068 14-03-070 14-03-076 14-03-077
Keywords: errors, history, architecture
Posted-Date: 29 Mar 2014 00:54:47 EDT

Ivan Godard <ivan@ootbcomp.com> wrote:
> On 3/28/2014 4:08 PM, mac wrote:


>> Not quite the same. ON defined a handler invoked at the signal site. It
>> could attempt repair and return. more like an interrupt. However, the
>> typical handler did a non-local GOTO to bail out, clearing any calls
>> between the signal and the gone-to label.


>> I still think that the ability to resume can be useful.


> Useful or no, the ability to resume requires retaining the illusion of
> sequential execution. You have no idea how expensive, in power and
> performance, that illusion is. And it's flat-out impossible on wide
> issue machine such as VLIWs.


That is true, and was already true for the IBM 360/91.


But there are different kinds of exception.


There are software generated exceptions (even if the underlying source
is hardware) that can be resumed. As I noted previously PL/I had
ENDPAGE that allows one to print page headers during I/O operations. A
single I/O statement may produce multiple lines of output, and the
ENDPAGE may occur during that output.


CONVERSION (an illegal character in a numeric field) also can
be corrected and resumed.


But yes, resuming hardware exception is complicated. S/360 required
operands to be properly aligned. It was believe that Fortran required
COMMON blocks to be packed, without any padding, even if alignment
requirements were violated. The fix was an interrupt routine to copy
the operand to a properly aligned buffer, preform the offending
instruction, and then return. That worked (though was very slow) for
most S/360 models, but not at all for the 360/91, which allowed for
out-of-order execution. The address reported for the interrupt might
be nowhere near the offending instruction, and more instructions using
the data might have been executed. Most languages now allow for
padding and data to be aligned.


On the other hand, VLIW is pretty much dead. (I have an actual RX2600
Itanium based system, though don't use it much.)


-- glen

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.