This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More OLD PROBLEMS problems


Peter Barada <peter@the-baradas.com> writes:

> On the 68000, the only divide instructions were the
> divs.w/divu.w, and the result is the quotient and remainder, both in
> 16 bits.  This meant that extra code had to be added to check for
> overflow and calculate the result in software:
> 
>  divs.w %d0,%d1  ; if successful, quotient in low word of %d0,
>                  ; remainder in high word
>  jvc.s L1
>  jsr _divs       ; assume _divs divides %d0 by %d1, leaving quotient in %d0
>  bra.s L2
> L1:
>  ext.l %d0
> L2:
> 
> So using the divs.w/divu.w instructions for truncated divides will
> require the extra code...

I think the idea of the original suggestion in the PROBLEMS file was
that if the result of the division is being stored in a 16-bit
variable, then you don't have to worry about the overflow check.
    int a;
    short b;
    short c = a / b;


> Hmm,  uberbaum compiles the following code for --target=m68k, -O2 -m5200:
> 
> short foo;
> extern int bar(int);
> int x(void)
> {
>   if (foo & 0x0080)
>     return bar(1);
>   else
>     return bar(9);
> }
> 
> 
> into:
> 
> #NO_APP
> 	.file	"test.c"
> 	.text
> 	.align	2
> 	.globl	x
> 	.type	x, @function
> x:
> 	link.w %fp,#0
> 	move.b foo+1,%d0	| 58	*m68k.md:752/1
> 	lsr.l #7,%d0	| 13	lshrsi3
> 	btst #0,%d0	| 15	*m68k.md:562
> 	jbeq .L2	| 16	beq
> 	...
> 
> Which could have been shortened to the following(and doesn't use a register):
> 
> x:
> 	link.w %fp,#0
> 	tst.b foo+1
> 	jbpl .L2
> 	...

File an report in bugzilla, I think.


> >>   <li value="96">Can do SImode bitfield insns without reloading, but must
> >>   alter the operands in special ways.</li>
> >> 
> >> Another one that could use some explaining.
> >
> >I would guess that this refers to m68k instructions like bfset which
> >can take a memory operand.  In memory they refer to a single byte, and
> >as such using them on SImode would require adjusting to the right byte
> >and changing the bit number.  This does not appear to be implemented
> >although it's not clear that anybody cares.
> 
> This is implemented on m68k/ColdFire for the btst, bclr, bset, bchg
> instructions where adjust_address is called to fix the address if the
> operand is in memory. See output_xorsi3, output_iorsi3, output_andsi3,
> output_btst in gcc/config/m68k/m68k.c

Cool.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]