异常的语义资源-CSDN文库

需积分: 10 42 浏览量 2015-09-14 09:59:16 上传评论收藏 256KB PDF 举报

### 异常的语义 #### 摘要与背景本文探讨了现代超标量微处理器中的不精确异常处理机制，并提出了一种在懒惰函数式编程语言Haskell中实现这种机制的方法。作者们首先指出，一些现代微处理器为了提高性能或减少芯片面积而牺牲了异常处理的精确性。例如，Alpha处理器执行多个指令时可能会出现并行或乱序执行的情况，这就导致无法保证异常被正确地报告。 #### 不精确异常的概念在计算机体系结构中，传统上处理器需要确保其行为能够完全符合程序的顺序执行逻辑。这意味着对于任何特定的程序状态，如果程序抛出异常，则必须确保异常被捕获和处理的位置与程序按顺序执行的结果一致。然而，在追求更高性能的过程中，某些现代处理器（如Alpha）采取了一种称为“不精确异常”的设计策略。这种策略允许处理器通过并行执行、指令乱序等技术来提高性能，但代价是可能无法准确地识别异常发生的点。 #### 为什么需要不精确异常？不精确异常的设计在一定程度上反映了性能与精确性之间的权衡。通过放弃对异常精确性的要求，处理器可以在更小的物理空间内达到更高的运行速度。这对于移动设备和其他对功耗敏感的应用尤为重要。 #### Haskell中的实现在文章中，作者们讨论了几种不同的设计方案，并最终确定了一个方案，该方案能够在保持Haskell现有的丰富的代数转换能力的同时引入不精确异常。他们认为，要维持语言的灵活性和强大之处，就必须接受某种程度的不精确性。 #### 语义定义为了实现这一目标，作者们还给出了一个扩展了异常处理特性的Haskell语言的形式化语义定义。这个定义涵盖了两种主要的语义类型：操作语义（Operational Semantics）和指称语义（Denotational Semantics）。 1. **操作语义**：操作语义描述了程序如何按照一系列步骤执行。在这种情况下，它需要定义当程序遇到异常时，处理器是如何执行异常处理过程的。这包括了如何捕获异常、如何恢复执行流以及如何处理并行执行过程中可能出现的问题。 2. **指称语义**：指称语义则是从数学的角度来定义程序的意义。在这个场景下，它涉及到如何将异常处理的行为形式化为数学对象，使得可以进行形式化的验证和证明。 #### 结论虽然作者们提出的方法在理论上是可行的，并且能够有效地在Haskell中实现不精确异常处理，但他们也承认目前还缺乏足够的实践经验来判断这种方法是否能够在实际应用中找到恰当的性能与表达能力之间的平衡。此外，这种设计方法是否会引入新的问题或者对现有编译器产生不利影响仍然需要进一步的研究。本文提供了一个深入的技术视角，不仅解释了不精确异常的基本概念和技术细节，而且还展示了如何在高级编程语言中实现这些概念。这对于那些希望了解现代计算机系统内部运作方式以及探索编程语言设计新方向的研究者来说是非常有价值的参考资料。

资源推荐

资源详情

资源评论

A semantics for imprecise exceptions

Simon Peyton Jones

Microsoft Research Ltd, Cambridge

simonpj@microsoft.com

Alastair Reid

Yale University

reid-alastair@cs.yale.edu

Tony Hoare



Cambridge University Computer Lab oratory

carh@comlab.ox.ac.uk

Simon Marlow

Microsoft Research Ltd, Cambridge

t-simonm@microsoft.com

Fergus Henderson

The University of Melbourne

fjh@cs.mu.oz.au

Abstract

Some modern sup erscalar micropro cessors provide only

im-

precise exceptions

. That is, they do not guarantee to re-

port the same exception that would be encountered by a

straightforward sequential execution of the program. In ex-

change, they oer increased performance or decreased chip

area (which amount to much the same thing).

This performance/precision tradeo has not so far b een

much explored at the programming language level. In this

paper we propose a design for imprecise exceptions in the

lazy functional programming language Haskell. We discuss

several designs, and conclude that imprecision is essential if

the language is still to enjoy its current rich algebra of trans-

formations. We sketch a precise semantics for the language

extended with exceptions.

The paper shows how to extend Haskell with exceptions

without crippling the language or its compilers. We do not

yet have enough experience of using the new mechanism to

know whether it strikes an appropriate balance b etween ex-

pressiveness and performance.

1 Intro duction

All current programming languages that support exceptions

take it for granted that the language denition should sp ec-

ify, for a given program, what exception, if any, is raised

when the program is executed. That used to b e the case

in micropro cessor architecture to o, but it is no longer so.

Some pro cessors, notably the Alpha, provide so-called

im-

precise exceptions

. These CPUs execute many instructions

in parallel, and p erhaps out of order; it follows that the

rst exception (divide-by-zero, say) that is encountered is



On study leave from the Oxford University Computing

Laboratory

This pap er appears in Pro ceedings of the SIGPLAN

Symposium on Programming Language Design and Im-

plementation (PLDI'99), Atlanta

not necessarily the rst that would b e encountered in sim-

ple sequential execution. One approach is to provide lots of

hardware to sort the mess out, and maintain the program-

mer's illusion of a simple sequential execution engine; this

is what the Pentium does. Another, taken by the Alpha, is

to give a less precise indication of the whereabouts of the

exception.

In this paper we explore this same idea at the level of the

programming language. The compiler, or the programmer,

might want to improve performance by changing the pro-

gram's evaluation order. But changing the evaluation order

may change which exception is encountered rst. One so-

lution is to ban such transformations, or to restrict them

to evaluations that provably cannot raise exceptions [19].

The alternative we prop ose here is to trade precision for

performance: permit richer transformations, and make the

language semantics less precise with resp ect to which excep-

tion is raised.

Note that the use of imprecise exceptions at the program-

ming language level is not due to the use of imprecise ex-

ceptions at the hardware level. (Indeed, the latter may

well prove ephemeral.) Rather, b oth of these arise from

the same motivation: permitting b etter optimization. It's

quite p ossible to have imprecise exceptions at the program-

ming language level but not at the hardware level, or vice

versa. However, the use of imprecise exceptions at the pro-

gramming language level may make it much easier for im-

plementations to generate ecient code on hardware that

has imprecise exceptions.

We make all this concrete by considering a particular pro-

gramming language, Haskell, that currently lacks excep-

tions. Our contributions are as follows:



We review and critique the folk-lore on exception-

handling in a lazy language like Haskell (Section 2).

Non-functional programmers may nd the idea of

exceptions-as-values, as opp osed to exceptions-as-

control-ow, interesting.



We present a new design, based on

sets

of exceptions,

to model imprecision about which exceptions can occur

(Section 3).



We sketch a semantics for the resulting language, using

two layers: a denotational semantics for pure expres-

sions (including exception-raising ones), and an oper-

ational semantics \on top" that deals with exception

handling, as well as input/output (Section 4).



Informed by this semantics, we show that various ex-

tensions of the basic idea, such as resource-exhaustion

interrupts, can readily be accommo dated; while oth-

ers, such as a \pure" exception handler, are more trou-

blesome (Section 5).

There has b een a small urry of recent prop osals and pap ers

on exception-handling in Haskell [3, 13 , 12]. The distinctive

feature of this pap er is its fo cus on the semantics of the

resulting language. The trick lies in getting the nice fea-

tures of exceptions (eciency, implicit propagation, and the

like) without throwing the baby out with the bath-water

and crippling the language design.

Those less interested in functional programming

per se

may

nevertheless nd interesting our development of the (old)

idea of exceptions-as-values, and the trade-o b etween pre-

cision and p erformance.

2 The status quo ante

Haskell has managed without exceptions for a long time,

so it is natural to ask whether they are either necessary or

appropriate. We briey explore this question, as a way of

setting the scene for the rest of the pap er.

Before we b egin, it is worth identifying three dierent ways

in which exceptions are typically used in languages that sup-

port them:

Disaster recovery

uses an exception to signal a (hop efully

rare) error condition, such as division by zero or an

assertion failure. In a language like ML or Haskell we

may add pattern-match failure, when a function is ap-

plied to a value for which it do es not have a dening

equation (e.g.

head

of the empty list). The program-

mer can usually also raise an exception, using a prim-

itive such as

raise

The exception handler typically catches exceptions

from a large chunk of code, and p erforms some kind of

recovery action.

Exception handling used in this way provides a degree

of modularity: one part of a system can protect itself

against failure in another part of the system.

Alternative return.

Exceptions are sometimes used as an

alternative way to return a value from a function,

where no error condition is necessarily implied. An

example might be lo oking up a key in a nite map:

it's not necessarily an error if the key isn't in the map,

but in languages that support exceptions it's not un-

usual to see them used in this way.

The exception handler typically catches exceptions

from a relatively circumscrib ed chunk of code, and

serves mainly as an alternative continuation for a call.

Asynchronous events.

In some languages, an asyn-

chronous external event, such as the programmer typ-

ing \

" or a timeout, are reected into the program-

mer's mo del as an exception. We call such things

asyn-

chronous exceptions

, to distinguish them from the two

previous categories, which are b oth

synchronous ex-

ceptions

2.1 Exceptions as values

No lazy functional programming language has so far sup-

ported exceptions, for two apparently persuasive reasons.

Firstly,

lazy evaluation scrambles control ow

. Evaluation

is demand-driven; that is, an expression is evaluated only

when its value is required [14]. As a result, programs don't

have a readily-predictable control ow; the only pro ductive

way to think ab out an expression is to consider the

value

it computes

, not the

way in which the value is computed

Since exceptions are typically explained in terms of changes

in control ow, exceptions and lazy evaluation do not appear

very compatible.

Secondly,

exceptions can be explicitly encoded in values

, in

the existing language, so p erhaps exceptions are in any case

unnecessary. For example, consider a function,

, that takes

an integer argument, and either returns an integer or raises

an exception. We can encode it in Haskell thus:

data ExVal a = OK a

| Bad Exception

f :: Int -> ExVal Int

f x = ...defn of f...

The

data

declaration says that a value of type

ExVal t

either of the form

(Bad ex)

, where

has type

Exception

or is of the form

(OK val)

, where

val

has type

. The

type signature of

declares that

returns a result of type

ExVal Int

; that is, either an

Int

or an exception value. In

short,

the exception is encoded into the value returned by

Any consumer of

's result is forced, willy nilly, to rst p er-

form a case analysis on it:

case (f 3) of

OK val -> ...normal case...

Bad ex -> ...handle exception...

There are goo d things ab out this approach: no extension to

the language is necessary; the type of a function makes it

clear whether it can raise an exception; and the type system

makes it imp ossible to forget to handle an exception.

The idea of exceptions as values is very old [10, 18 ]. Subse-

quently it was realised that the exception type constructor,

ExVal

, forms a

monad

[6, 9]. Rather than having lots of

hoc

pattern matches on

and

Bad

, standard monadic ma-

chinery such as Haskell's

notation, can hide away much

of the plumbing.

剩余11页未读，继续阅读

评论收藏

内容反馈

dop20002003

粉丝: 0
资源: 6

异常的语义

c-semantics:K中C的语义

信息检索和语义

语义化版本号

语义检索系统

异常说明

异常详解

异常示例(Exception)

异常信息

异常的简单介绍

异常处理.doc

实验三_编译原理语义分析_语义分析_sectionnef_

语义分析实验报告和代码

基于UNET-DinoV2 对 X 射线照片进行牙齿语义分割-内含源码和说明书(可自己修改).zip

论文研究-基于协议语义序列的应用层交互行为异常检测.pdf

HTML5新语义

语义网基础

语义网访谈录

语义栈11

语义html

vscode中的语法高亮和语义高亮(Syntax Highlight and Semantic Highlight)

语义分析器，编译原理课程设计，c++，c

语义分析程序的设计与实现

编译原理语义分析

编译语言语义分析源程序

语义分割1

语义网介绍

语义网本体

Modelica语义

最新资源