bvs@light.uucp (Bakul Shah) (05/18/88)
In article <11532@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <240@sdba.UUCP> stan@sdba.UUCP (Stan Brown) writes: >>... the machine that I am working on is a Fortune 32:16 >>(a 68000) box. The error that I am geting occcurs during the compliation >>of perl.c and is something like: >> ... compiler error: no table entry for SASG ... >> arg[j++] = node[1]; >> ^^^^^^^^^^^^^^^^^^^ > >This is somewhat curious, as delay() should have deferred the j++. >But who knows what lurks in the heart of an ancient PCC. I somehow missed the original article... Anyway, Fortune's compiler was hacked quite a bit and in the process the compiler people may have deleted a table entry or two. Atleast that is what I have suspected all along. >At any rate, there is no way to fix this sort of thing without compiler >sources, and I imagine those are hard to get (did not Fortune quit >making 32:16s?). About all you can do is experiment with rephrasing >the line of code that triggers the compiler bug. I don't think one can get to Fortune's C compiler sources (and GNU C is too damn big to fit on a fortune 32:16). Generally simplifying expressions works on the fortune C compiler. The following fix worked for me. diff -r perl/perly.c perl.dist/perly.c 2197,2198c2197 < register ARG * a = &arg[j++]; < *a++ = node[1]; --- > arg[j++] = node[1]; 2200c2199 < *a = node[2]; --- > arg[j] = node[2]; BTW, if ``printf("%.20g", 5.0);'' gives you 5.0000000000000000 instead of just 5, you may need to patch ecvt.o. Without this fix perl is not happy. Unfortunately I don't remember all the gory details at this moment and that'll have to wait until I find the original ecvt.o from my backup floppies (ugh...) and prepare a patch. Drop me a line if any of you netfolks have any fortune 32:16 related questions. -- Bakul Shah <..!{ucbvax,sun}!amdcad!light!bvs>
greim@sbsvax.UUCP (Michael Greim) (05/27/88)
In article <1988May17.192100.17287@light.uucp> from May 18 Bakul Shah writes concerning problems when compiling perl : >BTW, if ``printf("%.20g", 5.0);'' gives you 5.0000000000000000 instead >of just 5, you may need to patch ecvt.o. Without this fix perl is not >happy. Unfortunately I don't remember all the gory details at this >moment and that'll have to wait until I find the original ecvt.o from my >backup floppies (ugh...) and prepare a patch. I installed perl (patchlevel 14) on our machines and had a similar problem on a SIEMENS PC-MX2 running SINIX v2.0 (derived from Sys3 and/or GENIX). printf("%.20g", 10.0) would give me "1.e+01". Maybe the following workaround is of use for some people. Look at the comments to see what is done. (Excuse the bad English :-) *** old.str.c Fri May 27 13:25:33 1988 --- str.c Fri May 27 13:22:42 1988 *************** *** 70,76 **** --- 70,87 ---- GROWSTR(&(str->str_ptr), &(str->str_len), 24); s = str->str_ptr; if (str->str_nok) { + # ifdef SINIX + /* + * mg, 24.feb.88 + * on mx2 the following returns for 10 : 1.e+01. I just try first, if + * the number happens to be an integer number, then i print it with + * %d, else with %g. To produce integers I use an eps condition. + * This may return false results, but I think it is better. + */ + fiddle (str->str_nval, s); + # else sprintf(s,"%.20g",str->str_nval); + # endif while (*s) s++; } *s = '\0'; *************** *** 536,538 **** --- 547,582 ---- str_numset(str,n); return str; } + + # ifdef SINIX + static + fiddle (d, s) + double d; + char * s; + /* mg, 24.feb.88 + * this routine tries to work around the faulty g-format on SIEMENS + * SINIX MX2 (for 10.0 it generates 1.e+01), by first checking, whether + * the argument lies near enough at an integer. This may be false for + * some real (!) double values. A better fix would be to remember + * int's and double's + */ + { + int i; + static double imin = -2147483648.0; + static double imax = 2147483647.0; + double b, c; + + if (d < imin || d > imax ) { + sprintf (s, "%.20g", d); + return; + } + c = d < 0.0 ? -d : d; + i = d; + b = i; + b = (b-d) < 0 ? (d-b) : (b-d); + if (b < d * 1.0e-5) + sprintf (s, "%1d", i); + else + sprintf (s, "%.20g", d); + } + # endif SINIX Michael -- snail-mail : Michael Greim, Universitaet des Saarlandes, FB 10 - Informatik (Dept. of CS), Bau 36, Im Stadtwald 15, D-6600 Saarbruecken 11, West Germany E-mail : greim@sbsvax.UUCP
bvs@light.uucp (Bakul Shah) (05/29/88)
Michael Greim writes: >In article ... Bakul Shah (me) writes >concerning problems when compiling perl : > >>BTW, if ``printf("%.20g", 5.0);'' gives you 5.0000000000000000 instead >>of just 5, you may need to patch ecvt.o. ... > >I installed perl (patchlevel 14) on our machines and had a similar problem >on a SIEMENS PC-MX2 running SINIX v2.0 (derived from Sys3 and/or GENIX). [a description of a work around deleted] I claim that the problem is with the runtime library in both cases. While a quick fix gets the job done, I hope you would complain to Siemens about this bug. In general it is not a good idea to mess with other people's (useful) sources and besides, you can't go on fixing legit. C programs because *your* library can't handle them. Meanwhile, I am interested in a public domain printf & friends. -- Bakul Shah <..!{ucbvax,sun}!amdcad!light!bvs>
greim@sbsvax.UUCP (Michael Greim) (05/30/88)
In <1988May28.141939.11272@light.uucp> Bakul Shah writes: >Michael Greim writes: >>In article ... Bakul Shah (me) writes >>concerning problems when compiling perl : >> >>>BTW, if ``printf("%.20g", 5.0);'' gives you 5.0000000000000000 instead >>>of just 5, you may need to patch ecvt.o. ... >> >>I installed perl (patchlevel 14) on our machines and had a similar problem >>on a SIEMENS PC-MX2 running SINIX v2.0 (derived from Sys3 and/or GENIX). >[a description of a work around deleted] >I claim that the problem is with the runtime library in both cases. Of course it is. >While a quick fix gets the job done, I hope you would complain to >Siemens about this bug. In general it is not a good idea to mess with >... When it comes to complaints SIEMENS is just like /dev/null. >... >other people's (useful) sources and besides, you can't go on fixing >legit. C programs because *your* library can't handle them. Of course I have to fix such programs. How do you think I could make them work on my machine ? What I wrote was *NOT* intended as a fix to perl. I just wanted to help people who encountered such an error in their library routines. >Meanwhile, I am interested in a public domain printf & friends. In the implementations I saw, printf was just an interface to _doprnt, which was written in assembler. Some time ago, I needed an extension to printf, so I rewrote part of printf in C. It isn't very fast, but it works. (No I can't give you the code :-) Michael # include <disclaimer.std> -- snail-mail : Michael Greim, Universitaet des Saarlandes, FB 10 - Informatik (Dept. of CS), Bau 36, Im Stadtwald 15, D-6600 Saarbruecken 11, West Germany E-mail : greim@sbsvax.UUCP
allbery@ncoast.UUCP (Brandon S. Allbery) (06/08/88)
As quoted from <512@sbsvax.UUCP> by greim@sbsvax.UUCP (Michael Greim): +--------------- | >Meanwhile, I am interested in a public domain printf & friends. | In the implementations I saw, printf was just an interface to _doprnt, +--------------- (1) There is a printf() replacement in the UNaXcess 1.0.2 sources, in the function "writef()" in io.c. I've mailed the code out to the original requestor. (2) Plexus System III (and, presumably, some other systems) did not use _doprnt; the function doesn't exist. They use _print with the FILE structure stored in "extern FILE _pfile" (no, that's not a typo; it's an actual structure, not a pointer). I don't remember the calling sequence, but I can look it up. (3) I think v*printf() is now common enough that it should be used instead. The interface is much cleaner than _doprnt. -- Brandon S. Allbery | "Given its constituency, the only uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore