LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: William Stoye<william.stoye@t...>
    Date: Thu May 13 15:02:15 CEST 2004
    Subject: [openrisc] 1 bit condition code register
    Top
    (my first message to this group! hello!)

    The classic CPU combination is to have 4 condition code bits,
    with 4 bits in the branch instruction to see what the condition is.
    ARM does this, copied originally from 6502 I think,
    back when dinosaurs ruled the earth.

    Or you can have 1 condition code bit, and just have more varieties
    of 'compare' instruction. I think the HP-PA does this,
    in the name of making it easier to construct pipelined
    implementations?

    For the full story, get Hennessy and Patterson:
    http://www.amazon.com/exec/obidos/tg/detail/-/1558603298/002-5198740-1254438?v=glance

    --William.

    ----- Original Message -----
    From: "Victor" <victor.lopez@a...>
    To: <openrisc@o...>
    Sent: Thursday, May 13, 2004 1:34 PM
    Subject: Re: [openrisc] 1 bit condition code register


    > Hello Ben
    >
    > I am not an authority in this subject but if I am not mistaken the
    > condition codes that you mention are Z for Zero, N for Negative, C for
    > Carry and V? I guess it stands for Overflow, anyways the thing is that
    > maybe this 1 bit condition code is a bit uneffective as many
    > comparisons in a software program involve checking at least two of the
    > condition codes. Let's just take a look at comparisons between numbers:
    >
    > We have number A and number B both are 2's complement signed integers.
    > The comparisons in the lowest level are usually done by substracting
    > one number from the other and doing the comparison of the result with
    > zero:
    >
    > A > B? ====> (A-B) > 0? (See? it is the same comparison)
    >
    > This way the comparison would be true if bit Z=0 and bit N=0 (the
    > result of the substraction is not zero (as it has to be greater than
    > zero) and it is not negative)
    >
    > Another example which only needs one comparison code bit:
    >
    > A < B? ====> (A-B) < 0?
    >
    > To be True, the comparison ought to check only the N bit to be 1, as
    > this indicates that the result is negative (that is, less than zero).
    >
    > And the same goes with A >= B which requires N=0
    > and with A <= B which requires (N=1 OR (Z=1 AND N=0)) which is the same
    > as, in simplified form, (N=1 OR Z=1)
    >
    > A=B and A!=B imply only checking the Z bit (after the substraction A-B)
    > but as you can see there are cases in which it is wiser to have all the
    > condition code bits at hand, as we are not messing with a picky program
    > that checks first if there has been an Overflow (quite a natural thing
    > to do) or the carry bit. You must have in mind that if you have just
    > one bit then the programs will have to repeat the operations that are
    > checked as many times as bits in the complete comparison codes are
    > needed (that is two times for a A<B) and also many branches inside this
    > code... just try to assemble by hand any simple program which has to
    > make integer comparisons and you will see how performance can be
    > affected. I hope this helped. Regards,
    >
    > Victor Lopez
    >
    >
    >
    >
    > _______________________________________________
    > http://www.opencores.org/mailman/listinfo/openrisc
    >
    >

    ReferenceAuthor
    [openrisc] 1 bit condition code registerVictor

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.