[Oberon] FP

[Paul Onyschuk]

On Tue, 15 Apr 2014 14:49:22 +0200
Peter De Wachter <pdewacht at gmail.com> wrote:

> No, that wouldn't work. Every architecture does floating point 
> differently. And RISC FP in particular doesn't implement the full
> IEEE standard, for example it doesn't support infinities and denormal 
> numbers. The current code in the emulator isn't pretty or fast but at 
> least it's accurate.

I did read/hear few times that translating whole floating point IEEE
standard into hardware requires at least 500 thousand transistors.
Hardly a surprise that RISC Oberon uses only part of that.

Every architecture right now means pretty much Intel and ARM (a little
bit of MIPS also, but that can be neglected).  As far I know when
you're using newer x86 processor (or x86_64 for that manner) floating
point numbers behave almost exactly the same, to the point where you
don't need to worry about it.

With ARM it is very different world.  Some older SoC don't have support
for floating points, some only have single precision, other aren't
completely standardized.  This is reflected by Linux distributions
like Debian that have both armel (software floating point) and armhf
(hardware floating point) ports.

Yet again in C world different architecture can mean standard
library.  You can expect that functions can yield different results,
especially when it comes to math library (libm) - rounding and so on,
dependant on implementation.

Correct me if I'm wrong.

To not make complete offtopic out of this, I'll provide one more scrap
of information.  Floating point numbers are tricky, to the point where
even IBM got it wrong at one point [1] - serious issues with precision
related to their model.  Guess this is best explanation why floating
point numbers from RISC Oberon were modeled after IEEE. 

[1] http://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture

-- 
Paul Onyschuk