[5920] in Athena Bugs
RT /usr/lib/libfp.a
daemon@ATHENA.MIT.EDU (John Carr)
Sun Sep 2 09:06:44 1990
To: bugs@ATHENA.MIT.EDU
Date: Sun, 02 Sep 90 09:06:29 EDT
From: John Carr <jfc@ATHENA.MIT.EDU>
The following block of assembly describing an RT floating point operation:
# data area offset = 5252
cas r0,r15,r0
.long FPGLUE
.byte 0x0c # DIV
.byte 2
.short 0x8001
.byte 216, 0
.byte 0x2,0xc # (float) r12
.byte 0x22,0x0 # (float) $
.long 0x40000000
.space 196
causes this code to be generated (when using the 68881):
_LineSegment+0x1484: cas r0,r13
_LineSegment+0x1486: mts mq,r11
_LineSegment+0x1488: lis r13,3
_LineSegment+0x148a: cau r11,0xfc1c
_LineSegment+0x148e: st r13,3(r11)
_LineSegment+0x1492: cal r13,-0x14(r1)
_LineSegment+0x1496: cau r11,0xfc40
_LineSegment+0x149a: st r13,-0x3ff9(r11)
_LineSegment+0x149e: clrsb cs,24
_LineSegment+0x14a0: cal r13,-8(r1)
_LineSegment+0x14a4: sts r12,0(r13)
_LineSegment+0x14a6: cau r11,0xfc01
_LineSegment+0x14aa: st r13,0x1e01(r11)
_LineSegment+0x14ae: cau r0,0x1004
_LineSegment+0x14b2: cal r0,-0x4e58
_LineSegment+0x14b6: cau r11,0xfc01
_LineSegment+0x14ba: st r0,0x1e81(r11)
_LineSegment+0x14be: cau r11,0xfc3e
_LineSegment+0x14c2: st r13,-0x61ff(r11)
_LineSegment+0x14c6: clrsb cs,24
_LineSegment+0x14c8: ls r12,0(r13)
_LineSegment+0x14ca: lis r13,3
_LineSegment+0x14cc: cau r11,0xfc1c
_LineSegment+0x14d0: st r13,3(r11)
_LineSegment+0x14d4: cal r13,-0x14(r1)
_LineSegment+0x14d8: cau r11,0xfc03
_LineSegment+0x14dc: st r13,0x4007(r11)
_LineSegment+0x14e0: clrsb cs,24
_LineSegment+0x14e2: mfs mq,r11
_LineSegment+0x14e4: brx r15
_LineSegment+0x14e6: cas r13,r0
There are 2 bugs. 1: r0 appears to be used to save and restore the value of
r13. It is also used as a temporary register holding an address of an
operand for the 68881. 2: r0 is a special register in address calculations,
so it is wrong to use a sequence cal, cau to load it. "cau r0,0x1004;cal
r0,-0x4e58" should be changed to "cal r0,-0x4e58;oiu r0,0x1004". I expect
these are related.
Comments:
The FP operation was generated by gcc, which is the likely reason
this bug has not been seen before. It matches the documented spec
(which is not totally accurate!), but may contain a register mask
and operand combination not normally seen.
I will probably end up fixing this myself. Check with me before
assigning someone to work on it in case I have fixed it or have made
progress on it.
