Re: [oc] Processor Instruction reply for Andreas

["Jim Dempsey" <dempsey@northnet.net>]

RISC does have simpler and fewer instruction but does not
necessarily execute them quicker nor necessarily in shorter
cycle times than for CISC machines. There are examples that
can illustrate the favor for each instruction set.

----- Original Message -----
From: "Morris, Scott J" <morris.scott@pnl.gov>
To: <cores@opencores.org>
Sent: Monday, December 10, 2001 5:36 PM
Subject: RE: [oc] Processor Instruction reply for Andreas


> This seems to be the difference between RISC and CISC machines.  RISC has
> fewer and simpler instructions but can execute them quicker, shorter cycle
> times.  CISC has more and complex instructions but takes longer to execute
> them, longer cycle times.
>
> Just a thought
>
> Scott
> -----Original Message-----
> From: Paul McFeeters [mailto:paul.mcfeeters@ntlworld.com]
> Sent: Monday, December 10, 2001 10:32 AM
> To: cores@opencores.org
> Subject: [oc] Processor Instruction reply for Andreas
>
>
> Andreas,
>
> > > Old Way:
> > >
> > > CMP AX,$2000
> > > JC  #4000
> > >
> > > Two instructions to do that? Why use two clock cycles for that? Can't
we
> > > just have a CMPJxx instruction? Takes two values/register combinations
> and
> > > based upon the results of the comparisons jumps to the destination or
> not.
>
> > There are two things to be done.  A subtraction and a conditional jump.
> > Just because you put them in the same instruction doesn't make them in
> > one cycle.  If they do execute in one cycle, I guess the cycles on that
> > machine are generally longer.
>
> Wrong. I tested it out and it makes simple sense. When a compare is done
> then
> the HDL copies the value of '1' into the relevant flag. As any HDL
> programmer
> will tell you copying a 32bit value versus 1 bit doesn't take a ps longer
so
> my way is quicker.
>
> > > This might also eliminate quite a few status bits which may make the
ILP
> > > much easier?
>
> > So you'd always need an extra compare instead of just using the status
> > bits set by previous arithmetic.  Overall a slower architecture, I
> > assume.
>
> I don't remember any language except assembler doing a IF...THEN statement
> like they do. If you write it out in as a high level language it looks
> really silly doesn't it?
>
> SF is Status Flag
> Value1 and Value2 can obviously be immediate values, registers or memory
>
> SF = IF Value1 < Value2
> IF SF = 1 THEN
> PC = JumpPC ;
>
> I have never seen (or personally written) an assembler program that waits
> to test the bits set from a 'much' previous compare operation. As any
> instruction
> could (conceivably) alter the status flags the rule in assembler
programming
> is test and act. No delay = no chance for problems to creep in. I only
> worked as a professional x86 assembly programmer for 2 years so maybe
people
> on this list with more experience may have their own preferences/ideas.
> Remember
> the days when people didn't have a SWAP instruction? They would do
something
> like the following
>
> MOV Reg1 to SpareReg
> MOV Reg2 to Reg1
> MOV SpareReg to Reg2
>
> 3 cycles whereas now we only take one for it. My point is more intelligent
> instructions (even on RISC processors) will enable more work to be
performed
> in the same cycle count. It may even reduce the gate count required.
> Obviously
> this would be much easier with larger instructions vs. more instructions
> like 64bit. Okay another example to see if it helps.
>
> You have a value of 10 in register A, you want to add 5 to it and store
the
> result
> in register B, how many CPU cycles does it take?
>
> Currently 2 but in mine only one as my MOV instructions can also modify
the
> data
> in various ways before it arrives at its destination.
>
> MOV+, A, 5, B
>
> My new commands are all designed to still execute in exactly the same
clock
> cycle
> as there wouldn't be any point in developing an instruction to replace 2
> instructions
> and then taking twice as long now would there?
>
> Hope this helps your understanding of my point
>
> If any people with on this list with actual experience of developing CPU
> cores wants
> to correct me on any points here then feel free. Whilst I count my HDL
time
> in days
> I am always eager to learn more.
>
> Paul
>
> --
> To unsubscribe from cores mailing list please visit
> http://www.opencores.org/mailinglists.shtml
> --
> To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml