OpenCores

OpenCores

1 bit condition code register

no use

no use

1/1

no use

no use

1 bit condition code register by Unknown on May 13, 2004			Not available!
Hello, I have a Question about Condition code register. known cc code have Z, N, V and C flags and most instructions have to set these bits. ASAIK, this ways was used to ease branching and testing. I am designing a new processor and I want to know what are the performance drawbacks in hardrware and the complicatiosn in software (compiled programs) if I implement a 1 bit cc code register and I let only compare instructions set the above bit. Branch instruction check that bit and the change the program flow according to the branch type. Note: I just care about branch instructions for the time being. Many thanks for your help /Ben UEC,IS -------------- next part -------------- An HTML attachment was scrubbed... URL: <A HREF="http://www.opencores.org/forums/openrisc/attachments/20040513/a27f2cd9/attachment.htm">http://www.opencores.org/forums/openrisc/attachments/20040513/a27f2cd9/attachment.htm</A> Hello, I have a Question about Condition code register. known cc code have Z, N, V and C flags and most instructions have to set these bits. ASAIK, this ways was used to ease branching and testing. I am designing a new processor and I want to know what are the performance drawbacks in hardrware and the complicatiosn in software (compiled programs) if I implement a 1 bit cc code register and I let only compare instructions set the above bit. Branch instruction check that bit and the change the program flow according to the branch type. Note: I just care about branch instructions for the time being. Many thanks for your help /Ben UEC,IS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040513/a27f2cd9/attachment.htm

1 bit condition code register by Victor on May 13, 2004			Victor Posts: 9 Joined: Mar 1, 2002 Last seen: Jul 3, 2002
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 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 (A-B) 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 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 Acode... 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

1 bit condition code register by Unknown on May 13, 2004			Not available!
(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: <A HREF="http://www.amazon.com/exec/obidos/tg/detail/-/1558603298/002-5198740-1254438?v=glance">http://www.amazon.com/exec/obidos/tg/detail/-/1558603298/002-5198740-1254438?v=glance</A> --William. ----- Original Message ----- From: "Victor" <<A HREF="mailto:victor.lopez@alumnos.unican.es">victor.lopez@alumnos.unican.es</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Thursday, May 13, 2004 1:34 PM Subject: Re: [openrisc] 1 bit condition code register [q] 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 _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] (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@alumnos.unican.es> To: openrisc@opencores.org> 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 (A-B) = B which requires N=0 and with A http://www.opencores.org/mailman/listinfo/openrisc

1 bit condition code register by Unknown on May 14, 2004			Not available!
>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... j I understand it very well now. One more question.. assume that we have Z and N flags that can be set only by compare instructions. If we consider the other flags (C(carry) and V(overflow)). Should I let all instructions operating on data values set these flags? If so , how about if more that one instruction wants (forced to ) to set one of these flags? Does this make a problem ? Thanks Lopez /Ben ----- Original Message ----- From: "Victor" <<A HREF="mailto:victor.lopez@alumnos.unican.es">victor.lopez@alumnos.unican.es</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Thursday, May 13, 2004 9: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 > > > > > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> > >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 code... j I understand it very well now. One more question.. assume that we have Z and N flags that can be set only by compare instructions. If we consider the other flags (C(carry) and V(overflow)). Should I let all instructions operating on data values set these flags? If so , how about if more that one instruction wants (forced to ) to set one of these flags? Does this make a problem ? Thanks Lopez /Ben ----- Original Message ----- From: "Victor" victor.lopez@alumnos.unican.es> To: openrisc@opencores.org> Sent: Thursday, May 13, 2004 9: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 (A-B) > 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 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 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 >

1 bit condition code register by kavi on May 14, 2004			kavi Posts: 5 Joined: Apr 14, 2004 Last seen: Feb 27, 2020
Dear friends, i recall the example of the DEC Alpha, e.g. the 21264 architecture. It has no condition code register, all compares return result in a register. General-purpose registers are also read in conditional move instructions. As the developers state, this permits for higher performance in terms of cycle time as well as deeper pipelines. Nikolaos Kavvadias <A HREF="mailto:nkavv@skiathos.physics.auth.gr">nkavv@skiathos.physics.auth.gr</A> Dear friends, i recall the example of the DEC Alpha, e.g. the 21264 architecture. It has no condition code register, all compares return result in a register. General-purpose registers are also read in conditional move instructions. As the developers state, this permits for higher performance in terms of cycle time as well as deeper pipelines. Nikolaos Kavvadias nkavv@skiathos.physics.auth.gr

1 bit condition code register by Unknown on May 14, 2004			Not available!
On Fri, 14 May 2004, kavi wrote: : As the developers state, this permits for higher performance in terms of : cycle time : as well as deeper pipelines. That might very well be true, but I'm afraid that it's a bit too late to change the OpenRISC 1000 ISA. ~j On Fri, 14 May 2004, kavi wrote: : As the developers state, this permits for higher performance in terms of : cycle time : as well as deeper pipelines. That might very well be true, but I'm afraid that it's a bit too late to change the OpenRISC 1000 ISA. ~j

1 bit condition code register by Unknown on May 14, 2004			Not available!
On Sat, 15 May 2004, Damjan Lampret wrote: : Actually, I was doing a lot of analysis in 1999 looking at the Alpha model : and comparing it to the traditional model of flags. If you remember at the : time I defined only one true flag and that is "F" flag; the one set by sfXX : instructions. Everything else like CY came later and these are not real : flags... The alpha model doesn't have much advantage. I do not have any problems at all with having a single -flag- register. But I wouldn't miss a "set register if flag is set" instruction, or simply a copy-flag-to-gpr instruction. This would not break the current ISA, but could be seen as an extension. Maybe something to think about for the next revision? Hope you're feeling better, Damjan. ~j On Sat, 15 May 2004, Damjan Lampret wrote: : Actually, I was doing a lot of analysis in 1999 looking at the Alpha model : and comparing it to the traditional model of flags. If you remember at the : time I defined only one true flag and that is "F" flag; the one set by sfXX : instructions. Everything else like CY came later and these are not real : flags... The alpha model doesn't have much advantage. I do not have any problems at all with having a single -flag- register. But I wouldn't miss a "set register if flag is set" instruction, or simply a copy-flag-to-gpr instruction. This would not break the current ISA, but could be seen as an extension. Maybe something to think about for the next revision? Hope you're feeling better, Damjan. ~j

1 bit condition code register by Unknown on May 14, 2004			Not available!
Much can be done with only a carry bit. For (A<B) you can check the carry from (NOT A) + B Or in the special case of (A==0) check the carry from negating A (same as (NOT A) + 1) Jim ----- Original Message ----- From: Ben A. Abderazek To: List about OpenRISC project Sent: Thursday, May 13, 2004 9:41 PM Subject: Re: [openrisc] 1 bit condition code register >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... j I understand it very well now. One more question.. assume that we have Z and N flags that can be set only by compare instructions. If we consider the other flags (C(carry) and V(overflow)). Should I let all instructions operating on data values set these flags? If so , how about if more that one instruction wants (forced to ) to set one of these flags? Does this make a problem ? Thanks Lopez /Ben ----- Original Message ----- From: "Victor" <<A HREF="mailto:victor.lopez@alumnos.unican.es">victor.lopez@alumnos.unican.es</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Thursday, May 13, 2004 9: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 > > > > > _______________________________________________ > <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> > _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> -------------- next part -------------- An HTML attachment was scrubbed... URL: <A HREF="http://www.opencores.org/forums/openrisc/attachments/20040514/b43a6278/attachment.htm">http://www.opencores.org/forums/openrisc/attachments/20040514/b43a6278/attachment.htm</A> Much can be done with only a carry bit. For (AYou 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 code... j I understand it very well now. One more question.. assume that we have Z and N flags that can be set only by compare instructions. If we consider the other flags (C(carry) and V(overflow)). Should I let all instructions operating on data values set these flags? If so , how about if more that one instruction wants (forced to ) to set one of these flags? Does this make a problem ? Thanks Lopez /Ben ----- Original Message ----- From: "Victor" victor.lopez@alumnos.unican.es> To: openrisc@opencores.org> Sent: Thursday, May 13, 2004 9: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 (A-B) > 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 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 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 > _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040514/b43a6278/attachment.htm

1 bit condition code register by Unknown on May 15, 2004			Not available!
Actually, I was doing a lot of analysis in 1999 looking at the Alpha model and comparing it to the traditional model of flags. If you remember at the time I defined only one true flag and that is "F" flag; the one set by sfXX instructions. Everything else like CY came later and these are not real flags... The alpha model doesn't have much advantage. regards, Damjan ----- Original Message ----- From: "Johan Rydberg" <<A HREF="mailto:jrydberg@gnu.org">jrydberg@gnu.org</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Friday, May 14, 2004 11:48 AM Subject: Re: [openrisc] 1 bit condition code register [q] On Fri, 14 May 2004, kavi wrote: : As the developers state, this permits for higher performance in terms of : cycle time : as well as deeper pipelines. That might very well be true, but I'm afraid that it's a bit too late to change the OpenRISC 1000 ISA. ~j _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] Actually, I was doing a lot of analysis in 1999 looking at the Alpha model and comparing it to the traditional model of flags. If you remember at the time I defined only one true flag and that is "F" flag; the one set by sfXX instructions. Everything else like CY came later and these are not real flags... The alpha model doesn't have much advantage. regards, Damjan ----- Original Message ----- From: "Johan Rydberg" jrydberg@gnu.org> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Friday, May 14, 2004 11:48 AM Subject: Re: [openrisc] 1 bit condition code register On Fri, 14 May 2004, kavi wrote: : As the developers state, this permits for higher performance in terms of : cycle time : as well as deeper pipelines. That might very well be true, but I'm afraid that it's a bit too late to change the OpenRISC 1000 ISA. ~j _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.