On Fri, Nov 9, 2012 at 4:28 AM, R. Diez <[email protected]> wrote:
> Yes, that's the reason I started the previous discussion thread about the > multiplication instructions. What I mean is that, in my implementation, the > unsigned multiplication instruction sets CY if necessary for unsigned > overflow, and the signed multiplication instructions set OV if necessary > for signed overflow. Unsigned multiplication only calculates unsigned > overflow, and signed multiplication only calculates signed overflow. > Yeah, I didn't consider that CY is essentially unsigned overflow in addition. I guess the most consistent thing is to always treat CY as unsigned overflow, and OV as signed overflow, no matter the instruction. This makes sense. Have you considered adding a separate trap for the CY flag instead, like I > mentioned in my last e-mail? That could benefit other arithmetic > instructions too, and would probably be less of an impact on existing > software. I suppose that makes sense. And both flags should probably trigger a RANGE exception if that was the case. The exception handler can determine which was raised by inspecting SR. (Both might be raised in the case of addition.) I was busy a lot of with other things during the last round of emails and I couldn't remember if we had decided on anything. > > >l.mulf, l.mulfu: do a full signed/unsigned 32x32-to-64 bit multiply, > storing results to MACLO/HI > > The 'f' suffix might may programmers think about floating point numbers. > How about using 'd' for double-word, 'q' for quad, or something else? > That's true, but I figured it would be distinguished by the 'l.' prefix instead of the 'lf.' prefix. I don't think 'q' is appropriate because there are no quad-words involved here, unless you're in 64-bit mode I suppose. Maybe 'd' is best. Ok, so I'll summarize this on the wiki today. -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
