I would suggest leaving everything exactly as it is. A nice aspect of the current ISA is that OR32 code can run directly on OR64 with few (if any) alterations. Also, Immediates larger than 16 bits are usually only needed for constructing addresses, and so aren't needed for normal ALU operations or loads and stores. (In fact, immediates that even require all 16 bits are quite rare. Most load/store offsets only use a handful of bits.) You can already construct a 64-bit immediate value using the current ISA, although it might require several instructions. We might need to add some functionality to the assembler to allow access to the top 32 bits of an immediate, as well.
-Pete On Wed, Feb 26, 2014 at 1:13 PM, Luís Vitório Cargnini <[email protected] > wrote: > Ok, > > How could I propose an upgrade to that ? to assume 48-bits ? > > Because I would like to push a 64-bit implementation, in fact I'm working > on it. > > Regards, > Luis Vitorio. > > > > On Tue, Feb 25, 2014 at 5:59 PM, Peter Gavin <[email protected]> wrote: > >> On Tue, Feb 25, 2014 at 8:43 PM, Luís Vitório Cargnini < >> [email protected]> wrote: >> >>> Hello, >>> >>> Please I need some clarification regarding the 64-bits address space. >>> for example let's assume the add operation l.addi, in 32 bits it is >>> >>> opcode D,A,Imm >>> 6 5,5,16 (bits) >>> in 64-bits how would that be ? I'll assume 48b of Immediate ? >>> >> >> AFAIK OR64 still uses 32-bit instructions. So immediates are still 16 >> bits. >> >> Only the register file, address and data buses are 64 bits. >> >> In any case, OR64 hasn't really been developed. Binutils is probably >> partway there (I tried to keep the cgen stuff as compatible with it as >> possible) but that's about it. >> >> -Pete >> > >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
