On Sat, Sep 29, 2012 at 5:10 AM, Peter Gavin <[email protected]> wrote: > On Fri, Sep 28, 2012 at 11:10 PM, Stefan Kristiansson > <[email protected]> wrote: >> Although I could imagine the floating point unit could be >> another user of the register pair writing mechanism, but I digress. > > That is a good point, and I think it might be worth considering. > > I think it would be really cool if we could implement OR1K in a way > that it had a flag you could use to switch between 32 and 64 bits > with, and everything would be identical except address and data sizes. > You'd get a 128-bit multiply with that, though, which isn't all that > useful. And to maintain consistency, you'd have a 128-bit float, > which isn't really useful either. > > Anyways, 32x32 to 64-bit multiply actually *is* useful IMO and > something I think we should add an opcode for.
I believe we intend on extending the instruction set at some point, so I would suggest thoroughly documenting what you think is a good idea here: http://opencores.org/or1k/Architecture_Specification#Proposed_changes But to summarise the reset of the conversation, am I right in thinking we're fine with the sort of implementation which does the following: For unsigned, just take the 2 numbers, put them through the verilog * into a 64-bit output, and then detect overflow by if any bits [63:32] are set? (obviously stick result [31:0] into the result output) For signed, convert (if negative) values to positive, and convert back if either were negative (a[31] xor b[31]) and also detect overflow with |result[63:32]? I think that's what I do in the mor1kx (without overflow checking, and with serial multiply, anyway, I suspect the "threestage" multiplier doesn't do signed stuff right?): https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_execute_alu.v#L227 Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
