[OpenRISC] Openrisc 64-bits

[lvcargnini]

Hello to everyone,

Please I'm trying to develop a 64b OR1K. I understood that the instructions
are 32-bits, the question I have is: according with the specification it
seems as two instructions per word of 64b, fetched every time, so is the
compiler packing two inst into the same word ? Or it will place as {32'b0,
instr} /{inst,'32b0}, assuming 64b registers ?

I ask because this will affect the way I map my wires into the decoding
phase of the datapath. And teh question before, is also important to help me
understand how to make the arrangements between cPU<->MMU, to decode the
instructions coming from a L1, that has 64b words.



--
View this message in context: http://openrisc.2316802.n4.nabble.com/Openrisc-64-bits-tp4641930.html
Sent from the OpenRISC mailing list archive at Nabble.com.

[Peter Gavin]

Post by lvcargnini
Hello to everyone,
Please I'm trying to develop a 64b OR1K. I understood that the instructions
are 32-bits, the question I have is: according with the specification it
seems as two instructions per word of 64b, fetched every time, so is the
compiler packing two inst into the same word ? Or it will place as {32'b0,
instr} /{inst,'32b0}, assuming 64b registers ?

IMO you should treat instructions the same way as you would in a 32-bit
core. You could probably mostly reuse the mor1kx instruction cache and
fetch datapath if you wanted to (you'd only need to widen any registers
that store an address or MMU page number). There's no reason the
instruction size needs to be tied to the register size, and I don't see any
reason to pack pairs of instructions. IOW, a perfectly valid
implementation could fetch a single 32-bit instruction per cycle.

-Pete

[lvcargnini]

Thanks Pete,

My problem is to find: assuming 64b regiusters, for a 64b processor, how the
INSTRUCTIONS are placed into a 64b reg ? So I asked before is {32'b0,inst}
or {inst,32'b0} ?Because the compiler has to generate it in some way, as
well the architecture has to interpret the 64b reg in a specific manner, I
understand that the instr only needs 4-bytes, no prob, so which ones the
31:16 or 15:0 ? that is it ., the problem is so far in the architecture
specification I didn't found such information. Thanks for the the Mor1k
suggestion, I will check it in more details once I start to implement the
cache set-associativity.



--
View this message in context: http://openrisc.2316802.n4.nabble.com/Openrisc-64-bits-tp4641930p4641933.html
Sent from the OpenRISC mailing list archive at Nabble.com.