* Marko Mlinar (markom@opencores.org) wrote:

the l.exths insn though might be worth keeping. (as Paul already hinted)

Why are _l.nop_, _l.extbz_, and _l.exthz_ provided when they can be synthesized from other instructions. (It seems that most architectures select one of the incidental no-ops [e.g., OR R0 R0 R0] as the preferred no-op [one that hardware is likely to not have consume execution resources]. [BTW, the definition in the specification of _l.nop_ sounds like a superscalar no-op {i.e., fills execution resources for one cycle even on a superscalar processor}, which I assume is unintended.]) _l.extbz_ and _l.exthz_ can be synthesized with _l.andi_ (with immediate values of 0xff and 0xffff, respectively). It might be too late to replace _l.nop_ in OR1000--having already reached silicon--, but the others can (I assume) still be removed? Paul A. Clayton just a technophile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040921/9182ec58/attachment.htm

Paul, I think l.ext* instructions are obsolete. Regarding the nop -- nop is used together with immediate for various purposes including simulation reporting, etc. Another benefit may be that HW can detect NOP from fewer bits. Otherwise I completely agree with you that l.or could be used as nop. Marko On Tuesday 21 September 2004 14:11, Dysthymicdolt@aol.com wrote:

Actually technically are not obsolete, even though nobody uses them. The main idea behind these instructions was to have fast FPGA implementations. For example a full 32-bit barrel shifter is very slow and the idea was to have specific instructions for doing sign/zero extension of operands. Today extensions are done with shift instructions.... Anyway for implementations targeting ASICs these are not useful instructions, but for FPGA implementations, maybe. For example early Microblaze had a shift by 1 instructions, because this is how they could do it fast on FPGA (I don't know about the latest ISA though...) regards, Damjan ----- Original Message ----- From: "Marko Mlinar" markom@opencores.org> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Tuesday, September 21, 2004 2:36 PM Subject: Re: [openrisc] Redundant instructions?

pheonix@opencores.org wrote: How so? Most assemblers can handle pseudo-assembly like: l.mov rd rs; translated to l.or rd r0 rs The problem would be with _binary_ compatibility. WRT "using the immediate for simulation purposes". One could use l.ori R0 Rn imm. Treating any l.* operation with an R0 destination as a no-op would be similarly easy to detect, correct? Paul A. Clayton just a technophile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040923/577a90e5/attachment.htm

* Dysthymicdolt@aol.com (Dysthymicdolt@aol.com) wrote:

you are right. one could change the assembler
to emit 'l.ori r0,r0,K' instead of 'l.nop K' or similar. but it
wouldn't be so amusing, when you'd compile code with l.nop's and get
dissasembly with l.ori's. ;). i don't really know, but i'd think
that gain in hardware complexity wouldn't be noticable.



that's for sure.



you are right, not a problem at all.

i think one would consider this option of removing l.nop if we'd run out
of opcode encoding space....

regards,
p.

phoenix@opencores.org wrote:

you are right, not a problem at all.

i think one would consider this option of removing l.nop if we'd run out
of opcode encoding space....