[9fans] Arithmetic on Plan 9

[9fans] Arithmetic on Plan 9

[tlaronde]

Hello,

I'm working on KerGIS, a BSD licenced revival of CERL GRASS, in order to
make it compile and run on Plan 9 too---at the moment, it compiles and
runs on any POSIX Unix flavour.

Even if a huge amount of work has already been done for cleaning,
reorganizing and extending the original sources, confrontation with Plan
9 shows that it is far from being, if not ideal, even sensible in some
area.

The first step---for Plan 9---will be a compilation using APE, and the
development of a graphical visualization using Plan 9 libdraw.

But I need too, for Plan 9 and others, to isolate correctly arithmetic
operations (I include not only integers but floats too in this
expression) in order to identify correctly the domain of definition of
the algorithms.

AFAIK, ISO C for examples does not mandate anything about integer
overflows (may silently wraps). C99 has added some support for IEEE754,
but the handling of "exceptions"---that may or may not be faults---is
still fuzzy for me.

Calculus is, if I'm not mistaken, a typical "userland" stuff. But it
involves, obviously the machine---MMIX[1] for example has distinct
instructions for not signaling integer arithmetic and signaling i.e.
unsigned integers operations silently wrap while signed overflow---, the
language and the compiler---is C enough to access all the capabilities
of the hardware or is assembly required---, and the operating
system---for the policy on notes.

So some questions (hoping at least some of them make sense):

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

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?

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?

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)?

I just discover libgeometry and arith(2) etc. so I suspect reading these
sources will help.

But if somebody has a résumé or pointers, it will be greatly
appreciated.

TIA,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

[9fans] Re: Arithmetic on Plan 9

[tlaronde]

[I forgot the references]:

On Wed, Jul 25, 2007 at 05:51:55PM +0200, tlaronde wrote:
> involves, obviously the machine---MMIX[1] for example has distinct

MMIX is the mythical RISC machine described by Donald E. Knuth in:

1 The Art of Computer Programming, Volume 1, Fascicle 1: MMIX, A RISC
Computer for the New Millenium, Addison-Wesley, 2005.

and

2 MMIXware, A RISC Computer for the Third Millennium, Springer, Lecture
Notes in Computer Science n°1750, 1999.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Arithmetic on Plan 9

[andrey mirtchovski]

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.

Re: [9fans] Arithmetic on Plan 9

[tlaronde]

On Wed, Jul 25, 2007 at 10:25:28AM -0600, andrey mirtchovski wrote:
> [good stuff]
> 
> hope that helps.

Yes, definitively. Thank you very much!

It's almost clear that I need for KerGIS to orthogonalize things, so
that in the libgis are indeed system dependant (POSIX or Plan 9)
facilities and only these, and in a libarithm sys dep and machine 
dependant arithmetic.

All the rest should be userland computation and almost usable as
is---minus the idiosynchrasies about C and libc [headers].


Thanks once more,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Arithmetic on Plan 9

[tlaronde]

On Wed, Jul 25, 2007 at 10:25:28AM -0600, andrey mirtchovski wrote:
>[...] 
> 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

Perhaps a hint on this. In The Intel documentation (Intel64 and IA32
Architectures Software Developer's Manual, Volume 1, §4.8.3.4):

------quote
SNaNs are typically used to trap or invoke an exception handler.
They must be inserted by software; that is, the processor never
generates an SNaN as a result of a loating-point operation.
------endquote

As a result, on x87, the invalid operations all cause an exception, and
it is the responsability of software to create/insert NaNs, whether
sNaN or qNAN.

And furthermore (§4.8.3.6):

------quote
· If one of the source operands is an SNaN and the floating-point
invalid-operating exception is not masked (see Section 4.9.1.1,
"Invalid Operation Exception (#I)"), the a floating-point
invalid-operation exception is signaled and no result is stored in
the destination operand.

· If either or both of the source operands are NaNs and floating-point
invalid- operation exception is masked, the result is as shown in
Table 4-7. When an SNaN is converted to a QNaN, the conversion is
handled by setting the most- significant fraction bit of the SNaN
to 1. Also, when one of the source operands is an SNaN, the
floating-point invalid-operation exception flag it set. Note that
for some combinations of source operands, the result is different
for x87 FPU operations and for SSE/SSE2/SSE3 operations.

· When neither of the source operands is a NaN, but the operation
generates a floating-point invalid-operation exception (see Tables
8-10 and 11-1), the result is commonly an SNaN source operand
converted to a QNaN or the QNaN floating- point indefinite value.
------endquote

So masking the floating-point invalid-operation, even in case of QNaN,
if I understand correctly, was indeed required to shut up the exception.


Note: I have the documentation for Plan 9 in hardcopy (from Vita Nuova),
and I just found some information about IEEE support in the paper called:
"The Various Ports".

To summarize: for Motorola MC68020 and x86, there is IEEE754 hardware
support and there is full IEEE support.

For chips where there is a FPU but only a partial support, in hardware,
for IEEE754, there is emulation, but not a complete one: "we implement
non trapping-underflow as truncation to zero and do nothing about
denormalized numbers and not-a-numbers."

There is also notes about transcendantal functions (built-in or emulated
in library).
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C