5b38fe900d
alpha, operations involving non-finite numbers or denormalised numbers or operations which should generate such numbers will cause an arithmetic exception. For programs which follow some strict code generation rules, the kernel trap handler can then 'complete' the operation by emulating the faulting instruction. To use software completion, a program must be compiled with the arguments '-mtrap-precision=i' and '-mfp-trap-mode=su' or '-mfp-trap-mode=sui'. Programs compiled in this way can use non-finite and denormalised numbers at the expense of slightly less efficient code generation of floating point instructions. Programs not compiled with these options will receive a SIGFPE signal when non-finite or denormalised numbers are used or generated. Reviewed by: John Polstra <jdp@polstra.com>
67 lines
2.4 KiB
C
67 lines
2.4 KiB
C
/* $Id: pcb.h,v 1.1.1.1 1998/03/09 05:43:16 jb Exp $ */
|
|
/* From: NetBSD: pcb.h,v 1.6 1997/04/06 08:47:33 cgd Exp */
|
|
|
|
/*
|
|
* Copyright (c) 1994, 1995, 1996 Carnegie-Mellon University.
|
|
* All rights reserved.
|
|
*
|
|
* Author: Chris G. Demetriou
|
|
*
|
|
* Permission to use, copy, modify and distribute this software and
|
|
* its documentation is hereby granted, provided that both the copyright
|
|
* notice and this permission notice appear in all copies of the
|
|
* software, derivative works or modified versions, and any portions
|
|
* thereof, and that both notices appear in supporting documentation.
|
|
*
|
|
* CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
|
|
* CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND
|
|
* FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
|
|
*
|
|
* Carnegie Mellon requests users of this software to return to
|
|
*
|
|
* Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU
|
|
* School of Computer Science
|
|
* Carnegie Mellon University
|
|
* Pittsburgh PA 15213-3890
|
|
*
|
|
* any improvements or extensions that they make and grant Carnegie the
|
|
* rights to redistribute these changes.
|
|
*/
|
|
|
|
#include <machine/frame.h>
|
|
#include <machine/reg.h>
|
|
|
|
#include <machine/alpha_cpu.h>
|
|
|
|
/*
|
|
* PCB: process control block
|
|
*
|
|
* In this case, the hardware structure that is the defining element
|
|
* for a process, and the additional state that must be saved by software
|
|
* on a context switch. Fields marked [HW] are mandated by hardware; fields
|
|
* marked [SW] are for the software.
|
|
*
|
|
* It's said in the VMS PALcode section of the AARM that the pcb address
|
|
* passed to the swpctx PALcode call has to be a physical address. Not
|
|
* knowing this (and trying a virtual) address proved this correct.
|
|
* So we cache the physical address of the pcb in the md_proc struct.
|
|
*/
|
|
struct pcb {
|
|
struct alpha_pcb pcb_hw; /* PALcode defined */
|
|
unsigned long pcb_context[9]; /* s[0-6], ra, ps [SW] */
|
|
struct fpreg pcb_fp; /* FP registers [SW] */
|
|
u_int64_t pcb_fp_control; /* IEEE control word [SW] */
|
|
unsigned long pcb_onfault; /* for copy faults [SW] */
|
|
unsigned long pcb_accessaddr; /* for [fs]uswintr [SW] */
|
|
};
|
|
|
|
/*
|
|
* The pcb is augmented with machine-dependent additional data for
|
|
* core dumps. For the Alpha, that's a trap frame and the floating
|
|
* point registers.
|
|
*/
|
|
struct md_coredump {
|
|
struct trapframe md_tf;
|
|
struct fpreg md_fpstate;
|
|
};
|