Nothing. That's exactly what ^ and $ do.
-rob
The Plan 9 C compilers do not appear to be compliant with the IEEE floating
point standard when making comparisons with NaN (not a number) values.
The standard says a comparison with one or both operands NaN is unordered,
ie all relations evaluate to false, except != which is always true.
amd64 does yet something else.
amd64 (a == b) (a = b) (a b) (b == a) (b = a) (b a)
386 (a b) (a = b) (a == b) (b a) (b = a) (b == a)
arm (a b) (a = b) (a != b) (b a) (b = a) (b != a)
mips(a b) (a = b) (a != b) (b a) (b = a) (b != a)
mainly the assumption, in the compiler
how about another option, just a bug.
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
- erik
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone needs in normal
day-to-day computation, but sometimes boxes must be ticked.
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone needs in normal
day-to-day
On Aug 21, 2013, at 9:55 AM, erik quanstrom quans...@quanstro.net wrote:
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't come up
Actually it was a test suite that revealed the NaN
On Wed Aug 21 13:43:54 EDT 2013, ba...@bitblocks.com wrote:
On Aug 21, 2013, at 9:55 AM, erik quanstrom quans...@quanstro.net wrote:
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
at least in terms of passing floating point test suites
(like python's) the NaN issue doesn't
On Wed Aug 21 13:43:54 EDT 2013, ba...@bitblocks.com wrote:
On Aug 21, 2013, at 9:55 AM, erik quanstrom quans...@quanstro.net wrote:
On Wed Aug 21 12:09:26 EDT 2013, 9f...@hamnavoe.com wrote:
Actually it was a test suite that revealed the NaN errors.
I wouldn't think it's something anyone
by this i ment to refer to -0.
But the subject line says comparisons with NaN. Start another
thread about signed zero if you like. (I'm not facing a test
suite objecting to those at the moment.)
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
Well, there is also the question of whether anything at all will break
if the bug is fixed. If not, then the answer is simple.
++L
I think that if there is a generally-accepted standard for the behaviour of
a language's handling of floating-point numbers,
it would be reasonable to try to follow the standard, unless it's stupid,
ill-advised, or impossible (or all three).
That reply to the Stack Overflow post -- and this might
On Wed Aug 21 14:23:48 EDT 2013, lu...@proxima.alt.za wrote:
what i mean is, the need for fixing it depends on how much
havoc this issue causes.
Well, there is also the question of whether anything at all will break
if the bug is fixed. If not, then the answer is simple.
fortunately,
vc vlongs are broken for cast
for example, _v2uc produces the code:
acid; asm(_v2uc)
_v2uc 0x5360MOVWrv+8(FP),R1
_v2uc+0x4 0x5364JMP (R31)
_v2uc+0x8 0x5368AND $0xff,R1
i think this should be
MOVWrv+12(FP),R1
JMP (R31)
AND
On Wed, 21 Aug 2013 14:36:40 EDT erik quanstrom quans...@quanstro.net wrote:
uvlong x;
x = 0x012345678abcdefull;
print((uchar)x %.2ux\n, (uchar)x);
...
x = 0012345678abcdef
(uchar)x ef
You're casting a large int into a small int and this seems right.
Just as
You're casting a large int into a small int and this seems right.
Just as (uchar)0x1234 = 0x34
marshalling a 64-bit pointer in this way will lay down the
bytes with the hi and lo reversed.
Perhaps you meant to do *(uchar*)x?
you're right. what was i thinking. still, pointers are
On Aug 21, 2013, at 11:57 AM, erik quanstrom quans...@quanstro.net wrote:
You're casting a large int into a small int and this seems right.
Just as (uchar)0x1234 = 0x34
marshalling a 64-bit pointer in this way will lay down the
bytes with the hi and lo reversed.
Perhaps you meant to do
How %p is treated is really upto the implementation but
it should not crash since p is never dereferenced. Does
this work?
uintptr q;
print(%p, q);
no. if i change the print to print an integer, it still fails.
in fact, it's really the indirect call in print that fails.
this
On 21 August 2013 07:11, smi...@icebubble.org wrote:
Maybe someone here can help me make sense of this simple sam session:
,c
this is a file, one of
many files with singular
and/or plurals
.
,y/ / g/.+s$/ p
plurals
I would expect that to have responded with thisfilesplurals.
,y/ /
#include u.h
#include libc.h
void
f(void)
{
write(1, hello\n, 6);
}
void (*call)(void) = f;
void
main(void)
{
call();
exits();
}
the asm is the same when compiled on any arch,
; acid 6.crash4-mips
6.crash4-mips:amd64 plan 9 executable
/sys/lib/acid/port
20 matches
Mail list logo
