Thread View: net.bugs.usg
3 messages
3 total messages
Started by Dennis D. Jurgensen
Wed, 21 May 1986 21:57
bug in System V c compiler for 3b2
Author: Dennis D. Jurgensen
Date: Wed, 21 May 1986 21:57
Date: Wed, 21 May 1986 21:57
43 lines
2287 bytes
2287 bytes
*** REPLACE THIS LINE WITH YOUR MESSAGE ***
I compiled a 68000 cross-compiler on a 3b2 successfully I thought.
However when I tried to use it to compile some floating point
libraries the compiler core-dumped due to an illegal instruction.
Here is the sdb output:
Source path: .:Mcc:mip
No core image
*makety:1341 b
*Breakpoint at
makety:1341: if( ISUNSIGNED(pt) ){
*0x808088a6 (makety:1341+3): BGUB 0x11 <808088b7> [0x11]
*0x808088a8 (makety:1341+5): CMPW &0xc,0(%fp) [0xc]
*0x808088ab (makety:1341+8): BLUB 0xc <808088b7> [0xc]
*0x808088b7 (makety:1345): MOVWD 0x2c(%r8),%r0 [p,%r0]
* r0/ 7 r1/ 0xfffffff2 r2/ 0x29
r3/ 0x80896bc0 r4/ 0x80896b8c r5/ 4
r6/ 7 r7/ 0x72 r8/ 0x80896bc0
ap/ 0xc00205c0 fp/ 0xc00205f4 sp/ 0xc00205f8
psw/ 0x241f0b pc/ 0x808088b7
0x808088b7 (makety:1345): MOVWD 0x2c(%r8),%r0 [p,%r0]
*0x80896bc0
*Illegal Instruction (4) (sig 4)
- core dumped
Process terminated
*
The c statement that is involved is:
p->fpn.dval = p->tn.lval;
where fpn and tn are structures in an union and dval is a double
and lval is a long. Here is the disassembly of the c statement.
[37] 2111: 85 c8 2c 40 MOVWD 0x2c(%r8),%r0
2115: a5 40 c8 14 MOVDD %r0,0x14(%r8)
if somebody could tell me what is wrong with the instruction,
i.e. is the opcode invalid, is the addressing mode invalid, etc.
and if so is there a fix for this problem please send mail to
{ihnp4!}[mtuxo, mtx5a, mtx5c]!ddj
Thank you in advance.
Dennis D. Jurgensen
Re: bug in System V c compiler for 3b2
Author: Ron Thompson
Date: Fri, 23 May 1986 02:12
Date: Fri, 23 May 1986 02:12
10 lines
1071 bytes
1071 bytes
> I compiled a 68000 cross-compiler on a 3b2 successfully I thought.
> However when I tried to use it to compile some floating point
> libraries the compiler core-dumped due to an illegal instruction.
Try using the -f option to include floating point software - then
be prepared for snail-speed execution.
--
Ron Thompson AT&T Information Systems Customer Programming
(404) 982-4217 Atlanta, Georgia Services Center
..{ihnp4,akgua}!cpsc53!rt (Opinions expressed are mine alone.)
Re: bug in System V c compiler for 3b2
Author: Robert Viduya
Date: Sat, 24 May 1986 18:24
Date: Sat, 24 May 1986 18:24
26 lines
1786 bytes
1786 bytes
>ddj@mtx5a.UUCP (Dennis D. Jurgensen) (ddj@mtx5a.UUCP, <1327@mtx5a.UUCP>): > > I compiled a 68000 cross-compiler on a 3b2 successfully I thought. > However when I tried to use it to compile some floating point > libraries the compiler core-dumped due to an illegal instruction. > My guess as to what the problem is is that a 3B2/300 (don't know about 3B2/310s or 3B2/400s) doesn't support hardware floating point instructions, but the C compiler will generate them. In order to compile programs that use floats or doubles, the C compiler has to be called with the '-f' option (this is, of course, undocumented, at least in all the 3B2 manuals I have). Note that the compiler will still generate floating point instructions; the -f option merely loads up a different runtime object file (/lib/fcrt0.o instead of /lib/crt0.o). I don't know for sure, but I think fcrt0.o enables an illegal instruction trap to catch all illegal instructions and simulate the floating point ones in software. Slow, but effective. robert -- Robert Viduya 01111000 Office of Computing Services Georgia Institute of Technology UUCP: ..gatech!gitpyr!robert BITNET: CC100RV @ GITVM1
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads