RE: [9fans] fp stack overflow -- hypot

RE: [9fans] fp stack overflow -- hypot

[Trickey, Howard W (Howard)]

> ape was a 'failure of vision'.
> 

The 'vision' for ape was unrelated to plan 9.

Andrew Hume and I wanted a way to use the same
source for our 1127-developed programs on the
diverse set of machines we had in the late 80's -
Research Unix (v10), Suns, SGI's, and Plan 9.
Before the days of very good ANSI/POSIX compliance.

Yes, we could remove ape from plan 9 now,
if someone cares to port the remaining ape-using
programs to pure plan 9 - I'd be happy to see that.

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> Yes, we could remove ape from plan 9 now,
> if someone cares to port the remaining ape-using
> programs to pure plan 9 - I'd be happy to see that.

i'm with you, captain ...

RE: [9fans] fp stack overflow -- hypot

[Gorka Guardiola Múzquiz]

> 
> Yes, we could remove ape from plan 9 now,
> if someone cares to port the remaining ape-using
> programs to pure plan 9 - I'd be happy to see that.

I would like to see the programs ported, but I wouldn't dump
ape lightly. It is useful for little programs like converters
for exotic file types you don't really care to port. It is also
useful for gradually porting programs (like links for example...).




					G.

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> I would like to see the programs ported, but I wouldn't dump
> ape lightly. 

NO!!

    This is not LINUX!  This is Plan 9.  There are rules.  -boyd/walter

Re: [9fans] fp stack overflow -- hypot

[Gorka Guardiola Múzquiz]

>   This is not LINUX!  This is Plan 9.  There are rules.

Yes. Things are done for reasons. I have given mines. What are
yours?.  :-).

						G.

Re: [9fans] fp stack overflow -- hypot

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 67 bytes --]

Sorry boyd, I'll cancel his account.
Just didn't notice earlier.

[-- Attachment #2: Type: message/rfc822, Size: 1804 bytes --]

From: Gorka Guardiola Múzquiz <paurea@lsub.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fp stack overflow -- hypot
Date: Fri, 5 Mar 2004 13:36:22 +0100
Message-ID: <141825a1464a7a5d69ff1261bd3f2198@plan9.escet.urjc.es>

>   This is not LINUX!  This is Plan 9.  There are rules.

Yes. Things are done for reasons. I have given mines. What are
yours?.  :-).

						G.

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> Sorry boyd, I'll cancel his account.
> Just didn't notice earlier.

i'm all for helping people out, but this is not AA.

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> Yes. Things are done for reasons. I have given mines. What are
> yours?.  :-).

mine?  i think ken summed it up best:

    oh, boyd, he's a unix enthusiast

ca 198[89], just as the plan 9 rubber was about to hit the road.

RE: [9fans] fp stack overflow -- hypot

[David Tolpin]

>
> Yes, we could remove ape from plan 9 now,
> if someone cares to port the remaining ape-using
> programs to pure plan 9 - I'd be happy to see that.

I trust your experience and philosophy; however, with
the very purpose of converting non plan9 programs to 
plan9 layout (mk instead of make, and posix source or
native APIs), one could consider keeping APE.

Ape helps eat an elephant -- one bite at a time.  
If one is able to compile a program under ape, and make it
run, he has a value under Plan9 he may wish to increase
by continuing development in Plan9 enviroment with Plan9
tools.

If one has to spend that effort just to initially get the
value he has on many other platforms, he will simply use
it elsewhere.

David Tolpin

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> I trust your experience and philosophy; however, with
> the very purpose of converting non plan9 programs to
> plan9 layout (mk instead of make, and posix source or
> native APIs), one could consider keeping APE.

mk has been around since [reaches for 9th Ed manual]  9th Ed -- ca sept 1986

RE: [9fans] fp stack overflow -- hypot

[a]

i'd rather see ape stick around. imperfect, sure, but certainly
still useful. there's a significant body of code that i either
run on plan 9 (ghostscript, troff) or would like to see running
on plan 9. given a finite set of plan 9 development resources
(read: people), i'd rather see our efforts spent on other things
than porting (and keeping current) the stuff we already have
under ape.

that aside, for the few programs i've written for unix, i've
found ape to be a wonderful testbed for conformance and
likely portability.

granted, today i'd probably use rsc's 9libs instead...
ア

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> i'd rather see ape stick around. imperfect, sure, but certainly
> still useful. there's a significant body of code that i either
> run on plan 9 (ghostscript, troff) ...

ken reversed engineered it for unix ?Ed, 'cos of the unfortunate death of
...

Re: [9fans] fp stack overflow -- hypot

[Douglas A. Gwyn]

boyd, rounin wrote:
>>i'd rather see ape stick around. imperfect, sure, but certainly
>>still useful. there's a significant body of code that i either
>>run on plan 9 (ghostscript, troff) ...
> ken reversed engineered it for unix ?Ed, 'cos of the unfortunate death of
> ...

If you mean troff, that was BWK and "..." was Osanna.
(Not Been Laudin'.)  The original was in PDP-11 Unix
assembly language and made substantial use of tricks
such as packing two character codes into a word.
troff was rewritten again later (by BWK) to make a
"device independent" version.  I think the Plan 9
version represents one more overhaul to work better
with "runes"; I rather lost track of it after it
diverged from the DWB 2.0 version, which is the last
one my org. paid for the right to use.

Re: [9fans] fp stack overflow -- hypot

[Bruce Ellis]

you rather lost track of it.

----- Original Message ----- 
From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: <9fans@cse.psu.edu>
Sent: Monday, March 08, 2004 9:14 PM
Subject: Re: [9fans] fp stack overflow -- hypot


> boyd, rounin wrote:
> >>i'd rather see ape stick around. imperfect, sure, but certainly
> >>still useful. there's a significant body of code that i either
> >>run on plan 9 (ghostscript, troff) ...
> > ken reversed engineered it for unix ?Ed, 'cos of the unfortunate death of
> > ...
> 
> If you mean troff, that was BWK and "..." was Osanna.
> (Not Been Laudin'.)  The original was in PDP-11 Unix
> assembly language and made substantial use of tricks
> such as packing two character codes into a word.
> troff was rewritten again later (by BWK) to make a
> "device independent" version.  I think the Plan 9
> version represents one more overhaul to work better
> with "runes"; I rather lost track of it after it
> diverged from the DWB 2.0 version, which is the last
> one my org. paid for the right to use.

Re: [9fans] fp stack overflow -- hypot

[Douglas A. Gwyn]

Bruce Ellis wrote:
> you rather lost track of it.

Not as badly as Boyd, however!

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> Not as badly as Boyd, however!

err, i beg to differ.

Re: [9fans] fp stack overflow -- hypot

[Bruce Ellis]

I guess you don't know him.

----- Original Message ----- 
From: "Douglas A. Gwyn" <dagwyn@comcast.net>
To: <9fans@cse.psu.edu>
Sent: Tuesday, March 09, 2004 8:47 PM
Subject: Re: [9fans] fp stack overflow -- hypot


> Bruce Ellis wrote:
> > you rather lost track of it.
> 
> Not as badly as Boyd, however!

Re: [9fans] fp stack overflow -- hypot

[Douglas A. Gwyn]

Bruce Ellis wrote:
> I guess you don't know him.

At least I know who reverse-engineered troff.

[9fans] fp stack overflow -- hypot

[David Tolpin]

The offending function is hypot(2). If I replace it with sqrt(p*p+q*q),
no more stack overflows no matter what are shapes and how complex the graph
is.

I think it is a compiler bug. But need more time or someone's help.

David

Re: [9fans] fp stack overflow -- hypot

[Bruce Ellis]

i just discovered that the ape hypot and the libc hypot
are different, and the ape one does in fact blowup.
i'll look into a bit more.  good that you tracked it down
this far.

brucee
----- Original Message ----- 
From: "David Tolpin" <dvd@davidashen.net>
To: <9fans@cse.psu.edu>
Sent: Friday, March 05, 2004 9:18 AM
Subject: [9fans] fp stack overflow -- hypot


> 
> The offending function is hypot(2). If I replace it with sqrt(p*p+q*q),
> no more stack overflows no matter what are shapes and how complex the graph
> is.
> 
> I think it is a compiler bug. But need more time or someone's help.
> 
> David

Re: [9fans] fp stack overflow -- hypot

[boyd, rounin]

> i just discovered that the ape hypot and the libc hypot
> are different, and the ape one does in fact blowup.

ape was a 'failure of vision'.

Re: [9fans] fp stack overflow -- hypot

[Bruce Ellis]

ok, i've found the problem.  take a look in:

/386/include/ape/math.h

and you'll see that hypot() is not declared unless

_RESEARCH_SOURCE is.

hence the compiler presumes that the function returns
int and picks up AX rather than popping the fp stack.

solution: either define _RESEARCH_SOURCE, or if
that introduces conflicts then simply copy the prototype
from math.h to somewhere visible.

it may really be a "faulty", in the posix sense, math.h
but i'm avoiding investigating that.

brucee
----- Original Message ----- 
From: "David Tolpin" <dvd@davidashen.net>
To: <9fans@cse.psu.edu>
Sent: Friday, March 05, 2004 9:18 AM
Subject: [9fans] fp stack overflow -- hypot

> The offending function is hypot(2). If I replace it with sqrt(p*p+q*q),
> no more stack overflows no matter what are shapes and how complex the graph
> is.
> 
> I think it is a compiler bug. But need more time or someone's help.
> 
> David

Re: [9fans] fp stack overflow -- hypot

[David Tolpin]

> ok, i've found the problem.  take a look in:
>
> /386/include/ape/math.h
>
> and you'll see that hypot() is not declared unless
>
> _RESEARCH_SOURCE is.
>
> hence the compiler presumes that the function returns
> int and picks up AX rather than popping the fp stack.
>
> solution: either define _RESEARCH_SOURCE, or if
> that introduces conflicts then simply copy the prototype
> from math.h to somewhere visible.
>
> it may really be a "faulty", in the posix sense, math.h
> but i'm avoiding investigating that.

Yes, you are right, I am wrong, I wrote about it to the list;
my apologies. hypot is not POSIX.

I just didn't realize that, unlike pcc, cc does not issue warnings
by default.

David

Re: [9fans] fp stack overflow -- hypot

[Charles Forsyth]

>>I just didn't realize that, unlike pcc, cc does not issue warnings
>>by default.

no, presumably because too many old programs lacked prototypes,
which indeed they did.
-A stops it turning the checking off.

Re: [9fans] fp stack overflow -- hypot

[Bruce Ellis]

right on that charles, yes the reason that -A is needed to
make ape/cc ANSI has to do with all the crap code
that has to be compiled with it.

anyone gonna conjecture why the ape hypot is not as
good as the libc one ... can it just be preplaced?
(prototype issues aside.)

brucee
----- Original Message ----- 
From: "Charles Forsyth" <forsyth@terzarima.net>
To: <9fans@cse.psu.edu>
Sent: Friday, March 05, 2004 6:32 AM
Subject: Re: [9fans] fp stack overflow -- hypot


> >>I just didn't realize that, unlike pcc, cc does not issue warnings
> >>by default.
> 
> no, presumably because too many old programs lacked prototypes,
> which indeed they did.
> -A stops it turning the checking off.