From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <14ec7b180707250925r27e6b8f1vdc53a2dc4430432f@mail.gmail.com>
Date: Wed, 25 Jul 2007 10:25:28 -0600
From: "andrey mirtchovski" <mirtchovski@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Arithmetic on Plan 9
In-Reply-To: <20070725155155.GA2324@polynum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070725155155.GA2324@polynum.com>
Topicbox-Message-UUID: 9742e9de-ead2-11e9-9d60-3106f5b1d025

i may not be qualified to answer all those questions for you, but i'll
try my best. i was dealing with FP exceptions last week and
consequently may have some of the answers:

> 1) Is there a Plan 9 policy concerning the "notes" (exceptions) on
> arithmetic operations, both integer and float?

i don't think there's anything about integers, but float exception
behaviour can be controlled via the getfcr/setfcr routines described
in getfcr(2). that man page will also tell you how to figure out
whether a particular machine supports those.

in my particular case the code I was porting defined NaN as a constant
and threw an exception whenever it ran. one particular quirk that i
observed was that an exception was thrown regardless of whether I
defined a silent or a non-silent NaN... my "solution" was simply to
turn off FPINVAL via setfcr(). if you're porting via ape, as i was
doing, the best solution is to get the little bits of assembly that
constitute the *fcr routines, compile them with 8a and link them
against the

> 2) Concerning float, if the FPU is a (from the ISA point of
> view) separate entity, are registers put in a known state on process
> entry?

yes. here are the floating point registers of a brand spanking new process:

parr% acid /bin/links
/bin/links:386 plan 9 executable

/sys/lib/acid/port
/sys/lib/acid/386
acid: new()
18031: system call	_main	SUBL	$0xc,SP
18031: breakpoint	main+0x3	MOVL	$_IO_stream+0x40(SB),AX
acid: fpr()
F0	0
F1	0
F2	0
F3	0
F4	0
F5	0
F6	0
F7	0
control	0x0000
status	0x0000
tag	0x0000
ip offset	0x00000000
cs selector	0x0000
opcode	0x81f3
data operand offset	0x0000
operand selector	0x0000


> 3) Is there some high level arithmetic homogeneous behavior between
> machines---a IEEE754 behavior even on machines lacking a compliant FPU,
> or lacking a FPU?

i believe the answer is No.

> 4) Is there a way, via C, to handle extended precision on IEEE754, or is
> assembly required (even if the assembler does not provide directly the
> symbolic opcodes, embedding directly the values is possible)?
>


not sure if that's what you're asking exactly, but from getfcr(2):

          Precision is
          controlled by installing in fcr, under mask FPPMASK, one of
          the values FPPEXT (extended precision), FPPSGL (single pre-
          cision), and FPPDBL (double precision).

hope that helps.