keith@gwsd.UUCP (Keith OHara) (06/15/85)
[]
The following program came out of the K&R book, page 8.
When compiled on a 3b2 (SYS-V.2)...
$ cc -g temperature.c
$ a.out
Illegal instruction - core dumped
$ sdb a.out
main:15: fahr = lower;
*q
-----program follows-----
#include <stdio.h>
/* print Fahrenheit-Celsius table
for f = 0,20,...,300 */
main()
{
int lower, upper, step;
float fahr, celsius;
lower = 0; /*lower limit of temperature table */
upper = 300; /*upper limit */
step = 20; /* step size */
fahr = lower;
while (fahr <= upper) {
celsius = (5.0/9.0) * (fahr-32.0);
printf("%4.0f %6.1f\n",fahr,celsius);
fahr = fahr + step;
}
}
-------end of file-------
If I'm missing a semicolon or something, I'll feel like a fool...
Keith - {sdcsvax|sdcc3}!gwsd!keithrobert@gitpyr.UUCP (Robert Viduya) (06/16/85)
> > The following program came out of the K&R book, page 8. > When compiled on a 3b2 (SYS-V.2)... > > $ cc -g temperature.c > $ a.out > Illegal instruction - core dumped > $ sdb a.out > main:15: fahr = lower; > *q > The problem isn't in the the program. Basically, the 3B2 (or as I understand it, the old 3B2) doesn't have hardware floating point. If you notice, the program died at the point where the first floating point variable was referenced. The C compiler doesn't know about the missing hardware and gen- erates floating point instructions which the machine promptly pukes on. There's an undocumented flag for the cc command which enables generation of software floating point support. Simply change your cc command line to: $ cc -g -f temperature.c and everything should work fine. robert -- Robert Viduya 01111000 Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
heiby@cuae2.UUCP (Ron Heiby) (06/18/85)
In article <476@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: >There's an undocumented flag for the cc command which enables generation >of software floating point support. I think it should be pointed out that the flag is documented in every System V User Reference manual I could lay my hands on, including the manual for the 3B2 (which needs the flag) and the manual for the 3B20 (which doesn't). Here's the text from the man page: -f Link the object program with the floating-point interpreter for systems without hardware floating-point. Have fun! -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
carlm@grpwre.UUCP (Carl McConnell) (06/18/85)
I think the problem was that the floating-point interpreter wasn't
loaded; i.e., the program should have been compiled with
"cc -g -f temperature.c".
Carl McConnell
Groupware Systems
{ucbvax,decvax}!tektronix!reed!grpwre!carlm
(Relevant portion of the original article follows...)
> The following program came out of the K&R book, page 8.
> When compiled on a 3b2 (SYS-V.2)...
>
> $ cc -g temperature.c
> $ a.out
> Illegal instruction - core dumped
> $ sdb a.out
> main:15: fahr = lower;
> *q
>
> -----program follows-----
>
> #include <stdio.h>
>
> /* print Fahrenheit-Celsius table
> for f = 0,20,...,300 */
> main()
> {
> int lower, upper, step;
> float fahr, celsius;
>
> lower = 0; /*lower limit of temperature table */
> ...(etc)robert@gitpyr.UUCP (Robert Viduya) (06/20/85)
> In article <476@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: > >There's an undocumented flag for the cc command which enables generation > >of software floating point support. > > I think it should be pointed out that the flag is documented in every > System V User Reference manual I could lay my hands on, including the > manual for the 3B2 (which needs the flag) and the manual for the 3B20 > (which doesn't). Here's the text from the man page: > -f Link the object program with the floating-point > interpreter for systems without hardware floating-point. Well it isn't in any of my 3B2 manuals. These are the manuals that came with System V R 1.something-or-other. We found out by calling the AT&T support center and they admitted that it was undocumented (at the time). They may have changed documentation between release levels. BTW, we got our 3B20's up and running a few weeks ago, and yes, the -f flag is documented on that machine. robert -- Robert Viduya 01111000 Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
jsdy@hadron.UUCP (Joseph S. D. Yao) (06/22/85)
In article <339@cuae2.UUCP> heiby@cuae2.UUCP (Ron Heiby) writes: >In article <476@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: >>There's an undocumented flag for the cc command which enables generation >>of software floating point support. >I think it should be pointed out that the flag is documented ... > -f Link the object program with the floating-point > interpreter for systems without hardware floating-point. I think a major point is, if the 3B2 n e e d s the '-f' flag, it should automagically be included at compile time. We did this for PDP-11's without floating point: there was a compile-time option (when compiling the C compiler!) to determine whether -f was a compiler option or requirement. (We == the UNIX community; reference == V5/V6 ff -- pre-COFF days.) Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
cdl@mplvax.UUCP (Carl Lowenstein) (06/23/85)
In article <485@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: >> In article <476@gitpyr.UUCP> robert@gitpyr.UUCP (Robert Viduya) writes: >> >There's an undocumented flag for the cc command which enables generation >> >of software floating point support. >> >> I think it should be pointed out that the flag is documented in every >> System V User Reference manual I could lay my hands on, including the >> manual for the 3B2 (which needs the flag) and the manual for the 3B20 >> (which doesn't). Here's the text from the man page: >> -f Link the object program with the floating-point >> interpreter for systems without hardware floating-point. > >Well it isn't in any of my 3B2 manuals. These are the manuals that came >with System V R 1.something-or-other. We found out by calling the AT&T >support center and they admitted that it was undocumented (at the time). To add a bit of fuel: The 'C language system' floppies that came with our 3b2's had *no manual pages at all* to cover the software in the package. This is carrying unbundling a bit too far. -- carl lowenstein marine physical lab u.c. san diego {ihnp4|decvax|akgua|dcdwest|ucbvax} !sdcsvax!mplvax!cdl
robert@gitpyr.UUCP (Robert Viduya) (06/25/85)
> > I think a major point is, if the 3B2 n e e d s the '-f' flag, it > should automagically be included at compile time. We did this for > PDP-11's without floating point: there was a compile-time option > (when compiling the C compiler!) to determine whether -f was a > compiler option or requirement. (We == the UNIX community; > reference == V5/V6 ff -- pre-COFF days.) > > Joe Yao hadron!jsdy@seismo.{ARPA,UUCP} I disagree with this, since using the -f increases the size of the program, *regardless* of whether you use floating point numbers in the program or not. I was doing some futzing around earlier this evening with the 3B2 and discovered that a (non-floating point) program compiled with -f can sometimes be up to 10K larger than it would be compiled without (I used ls(1) to get my numbers, not size(1)). From what I understand, floating point simulation is done by trapping the "illegal instructions" as the program executes and calling a subroutine to handle the instruction. The assembler does not generate calls to the floating point subroutines. This means that the loader cannot tell if the floating point library is needed or not (unless it examines each instruction, looking for a floating point one) and because of that it will always load in the floating point library if the -f option was given. I've heard rumors that AT&T is coming out with, or already sells, a new 3B2 with the WE32100 (did I get that number right?) processor which *does* support hardware floating point. robert -- Robert Viduya 01111000 Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
keith@gwsd.UUCP (Keith OHara) (06/28/85)
[] I just want to thank everybody for their help with the -f compile. I innocently discovered an "undocumented feature" while trying to teach myself the C language. Because of the enthusiatic response, I've fallen in love with the UNIX culture. Thanks again, Keith Keith O'Hara ...sdcsvax!gwsd!keith Gateway Computer Systems (619) 457-2701 4980 Carroll Canyon Road San Diego, CA 92121
cmf@cwruecmp.UUCP (Carl Fongheiser) (06/30/85)
I would like to point out that it shouldn't be too difficult for things to figure out if there are floating point instructions in a program. After all, the assembler should know, right? Maybe there should be an extension to COFF with a bit saying there are floating point instructions in a given object module. Of course, any extension would obviate COFF. Oh well. Carl Fongheiser ...!decvax!cwruecmp!cmf cmf%cwruecmp.CSNET@CSnet-relay.ARPA