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>