OpenCores

OpenCores

load pc-relative

First

Prev

2/2

no use

no use

load pc-relative by Unknown on Mar 13, 2005			Not available!
* GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q]> Is this the only instruction you couldn't map to > or1200 instructions ? (if not which are the > others). I'd suggest you a deal: if you implement the mapping > from ARM Thumb to or1200 ISA i'll provide you the missing instruction.[/q] OpenRISC is its own architechture. While I agree that haveing a Thumb-style instruction set for openrisc is not a bad thing, adding instructions to the or1200 ISA just because arm has them is IMHO not a good enough reason. Like I still can't see where a load pc relative instruction (I see the same problems with this that Damjan and I discussed about the NPC spr) would be usefull I just don't see why we should bloat the or1200 ISA with a useless instruction just on the grounds that THEY have it so it must be usefull. If the designers of the openrisc architechture wanted an architechture that is basically arm, they would have implemented that architechture and not go to the pain of porting a whole toolchain, maintaining the architechture, write a simulator, etc. I don't wish to deter you from your work but we should keep in mind this little comment from kernel developer Ingo Molnar, who put it best: "The Linux acceptance process is not about "whose patch sucks least", but whether it hits a subsystem-specific bar of architectural requirements or not.... We'll rather live on with one less feature for another year than with a crappy feature that is twice as hard to get rid of!" While we aren't discussing the linux kernel, IMO this comment should be valid about the openrisc development process (except that we CAN'T get rid of crappy features...). I hope I'm not going to be taken to suggest that no more instruction should be added to the openrisc ISA, I'm just saying that there should be atleast one good (practical) reason to add an instruction and the reason posted here is not good enough (IMHO).[/q] Your points are valid, but i do not see how would thumb style instruction set for OpenRISC do any harm. Remember, openrisc is a softcore, and i had assumed all the time that this mode would be provided as one of the options. (like you can synthesise openrisc with or without mmu, hw. multiplication, devision and a dozen of other options). 30-40% smaller code size can be a big/deciding factor for some usages, so i believe that having it implemented can not hurt. I belive that if Stefano thinks thumb-mode would help his project he'll go and implement it anyway. So why shouldn't we give him a chance to do it and when (and if) we see the patch decide if and under what conditions we want to merge it with openrisc. (and i'm sure that it woun't get merged unless it has a clean interface to present openrisc core). In the end if such an approach is found useful adding one instruction (again as an option or as a costum instruction) is good IMHO, since it would allow you to reuse the complete (optimized, well proven) arm toolchain. best regards, p. * GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: > Is this the only instruction you couldn't map to > or1200 instructions ? (if not which are the > others). I'd suggest you a deal: if you implement the mapping > from ARM Thumb to or1200 ISA i'll provide you the missing instruction. OpenRISC is its own architechture. While I agree that haveing a Thumb-style instruction set for openrisc is not a bad thing, adding instructions to the or1200 ISA just because arm has them is IMHO not a good enough reason. Like I still can't see where a load pc relative instruction (I see the same problems with this that Damjan and I discussed about the NPC spr) would be usefull I just don't see why we should bloat the or1200 ISA with a useless instruction just on the grounds that THEY have it so it must be usefull. If the designers of the openrisc architechture wanted an architechture that is basically arm, they would have implemented that architechture and not go to the pain of porting a whole toolchain, maintaining the architechture, write a simulator, etc. I don't wish to deter you from your work but we should keep in mind this little comment from kernel developer Ingo Molnar, who put it best: "The Linux acceptance process is not about "whose patch sucks least", but whether it hits a subsystem-specific bar of architectural requirements or not.... We'll rather live on with one less feature for another year than with a crappy feature that is twice as hard to get rid of!" While we aren't discussing the linux kernel, IMO this comment should be valid about the openrisc development process (except that we CAN'T get rid of crappy features...). I hope I'm not going to be taken to suggest that no more instruction should be added to the openrisc ISA, I'm just saying that there should be atleast one good (practical) reason to add an instruction and the reason posted here is not good enough (IMHO). Your points are valid, but i do not see how would thumb style instruction set for OpenRISC do any harm. Remember, openrisc is a softcore, and i had assumed all the time that this mode would be provided as one of the options. (like you can synthesise openrisc with or without mmu, hw. multiplication, devision and a dozen of other options). 30-40% smaller code size can be a big/deciding factor for some usages, so i believe that having it implemented can not hurt. I belive that if Stefano thinks thumb-mode would help his project he'll go and implement it anyway. So why shouldn't we give him a chance to do it and when (and if) we see the patch decide if and under what conditions we want to merge it with openrisc. (and i'm sure that it woun't get merged unless it has a clean interface to present openrisc core). In the end if such an approach is found useful adding one instruction (again as an option or as a costum instruction) is good IMHO, since it would allow you to reuse the complete (optimized, well proven) arm toolchain. best regards, p.

load pc-relative by Unknown on Mar 13, 2005			Not available!
[q] So even without any other usefullnes of the particular instruction it has a value if it allows a reuse of complete arm toolchain (just imagine how much work is needed to produce a stable toolchain...). I'm not saying we should add it, but we shouldn't just disregard it. The custom instructions (reserved in openrisc ISA) seam ideal for this case...[/q] Don't disregard it but put some thought into it. We really don't want a feature that we later find to cause more headaches than is worth and by that stage we can't remove it. Stefano, if you're still reading this thread, I don't want to discourage you from doing any work on or1200. My opinions are only that: my opinions. They do not reflect those of the maintainers of the architechture in any way what so ever. nog. So even without any other usefullnes of the particular instruction it has a value if it allows a reuse of complete arm toolchain (just imagine how much work is needed to produce a stable toolchain...). I'm not saying we should add it, but we shouldn't just disregard it. The custom instructions (reserved in openrisc ISA) seam ideal for this case... Don't disregard it but put some thought into it. We really don't want a feature that we later find to cause more headaches than is worth and by that stage we can't remove it. Stefano, if you're still reading this thread, I don't want to discourage you from doing any work on or1200. My opinions are only that: my opinions. They do not reflect those of the maintainers of the architechture in any way what so ever. nog.

load pc-relative by Unknown on Mar 13, 2005			Not available!
* GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q]> Your points are valid, but i do not see how would thumb style instruction set for > OpenRISC do any harm. Remember, openrisc is a softcore, and i had assumed all the > time that this mode would be provided as one of the options. (like you can synthesise > openrisc with or without mmu, hw. multiplication, devision and a dozen > of other options).[/q] I knew I was going to get missinterpreted. I never said that a thumb style instruction set would be any harm. I'll reiterate: I don't think that adding random, useless, instructions (I'm talking about the core openrisc ones, not the thumb ones) just because others are doing it will do us any good. [q]> In the end if such an approach is found useful adding one instruction > (again as an option or as a costum instruction) is good IMHO, since > it would allow you to reuse the complete (optimized, > well proven) arm toolchain.[/q] We can `base' `our' thumb-style ISA on the arm one (ie. implement everything except the instructions that we find useless), no problem there. Ofcourse if I am really missing the point of this one instruction, feel free to enlighten me.[/q] The idea was to have binary compatibility with arm thumb ISA, so that we could reuse their tools. This ofcourse brings us to legal issues, and i have no idea if we are allowed to do so ... So even without any other usefullnes of the particular instruction it has a value if it allows a reuse of complete arm toolchain (just imagine how much work is needed to produce a stable toolchain...). I'm not saying we should add it, but we shouldn't just disregard it. The custom instructions (reserved in openrisc ISA) seam ideal for this case... best regards, p. * GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: > Your points are valid, but i do not see how would thumb style instruction set for > OpenRISC do any harm. Remember, openrisc is a softcore, and i had assumed all the > time that this mode would be provided as one of the options. (like you can synthesise > openrisc with or without mmu, hw. multiplication, devision and a dozen > of other options). I knew I was going to get missinterpreted. I never said that a thumb style instruction set would be any harm. I'll reiterate: I don't think that adding random, useless, instructions (I'm talking about the core openrisc ones, not the thumb ones) just because others are doing it will do us any good. > In the end if such an approach is found useful adding one instruction > (again as an option or as a costum instruction) is good IMHO, since > it would allow you to reuse the complete (optimized, > well proven) arm toolchain. We can `base' `our' thumb-style ISA on the arm one (ie. implement everything except the instructions that we find useless), no problem there. Ofcourse if I am really missing the point of this one instruction, feel free to enlighten me. The idea was to have binary compatibility with arm thumb ISA, so that we could reuse their tools. This ofcourse brings us to legal issues, and i have no idea if we are allowed to do so ... So even without any other usefullnes of the particular instruction it has a value if it allows a reuse of complete arm toolchain (just imagine how much work is needed to produce a stable toolchain...). I'm not saying we should add it, but we shouldn't just disregard it. The custom instructions (reserved in openrisc ISA) seam ideal for this case... best regards, p.

load pc-relative by Unknown on Mar 13, 2005			Not available!
[q] Agreed. What issues do you see except the implementation problems (problems with PC) and 'headache feature we can not remove' ? Let's assume for moment that there aren't any major problems implementing the instruction. (i know this may be wrong assumption) The other we can easily address by not putting the instruction in toolchain (or at least gcc) and explicitly forbid it's use in the arch manual, or even better, including it in the core _only_ for thumb mode use.[/q] Let's packpedal abit here. Now you are saying that the instructions need to be put into our (openrisc) toolchain??? But agreed with your comment below, let's wait for the actual implementation. [q] But let's just wait for now to see if this thumb mode ever gets really implemented. I'm sure when and if it's done in right way and we can see some real benefits of it's usage we'll find a proper way to include the missing instruction. hey, we may even omit it at that time. really my only point was, if it's one instruction that is a problem don't worry about it now. the right solution will probably just pop up when everythig else is working.[/q] Agreed. No need to preemptivly try and solve problems that we don't even know for sure are problems. nog. Agreed. What issues do you see except the implementation problems (problems with PC) and 'headache feature we can not remove' ? Let's assume for moment that there aren't any major problems implementing the instruction. (i know this may be wrong assumption) The other we can easily address by not putting the instruction in toolchain (or at least gcc) and explicitly forbid it's use in the arch manual, or even better, including it in the core _only_ for thumb mode use. Let's packpedal abit here. Now you are saying that the instructions need to be put into our (openrisc) toolchain??? But agreed with your comment below, let's wait for the actual implementation. But let's just wait for now to see if this thumb mode ever gets really implemented. I'm sure when and if it's done in right way and we can see some real benefits of it's usage we'll find a proper way to include the missing instruction. hey, we may even omit it at that time. really my only point was, if it's one instruction that is a problem don't worry about it now. the right solution will probably just pop up when everythig else is working. Agreed. No need to preemptivly try and solve problems that we don't even know for sure are problems. nog.

load pc-relative by Unknown on Mar 13, 2005			Not available!
* GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q]> So even without any other usefullnes of the particular instruction > it has a value if it allows a reuse of complete arm toolchain (just > imagine how much work is needed to produce a stable toolchain...). > > I'm not saying we should add it, but we shouldn't just disregard it. The > custom instructions (reserved in openrisc ISA) seam ideal for this case...[/q] Don't disregard it but put some thought into it. We really don't want a feature that we later find to cause more headaches than is worth and by that stage we can't remove it.[/q] Agreed. What issues do you see except the implementation problems (problems with PC) and 'headache feature we can not remove' ? Let's assume for moment that there aren't any major problems implementing the instruction. (i know this may be wrong assumption) The other we can easily address by not putting the instruction in toolchain (or at least gcc) and explicitly forbid it's use in the arch manual, or even better, including it in the core _only_ for thumb mode use. But let's just wait for now to see if this thumb mode ever gets really implemented. I'm sure when and if it's done in right way and we can see some real benefits of it's usage we'll find a proper way to include the missing instruction. hey, we may even omit it at that time. really my only point was, if it's one instruction that is a problem don't worry about it now. the right solution will probably just pop up when everythig else is working. best regards, p. * GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: > So even without any other usefullnes of the particular instruction > it has a value if it allows a reuse of complete arm toolchain (just > imagine how much work is needed to produce a stable toolchain...). > > I'm not saying we should add it, but we shouldn't just disregard it. The > custom instructions (reserved in openrisc ISA) seam ideal for this case... Don't disregard it but put some thought into it. We really don't want a feature that we later find to cause more headaches than is worth and by that stage we can't remove it. Agreed. What issues do you see except the implementation problems (problems with PC) and 'headache feature we can not remove' ? Let's assume for moment that there aren't any major problems implementing the instruction. (i know this may be wrong assumption) The other we can easily address by not putting the instruction in toolchain (or at least gcc) and explicitly forbid it's use in the arch manual, or even better, including it in the core _only_ for thumb mode use. But let's just wait for now to see if this thumb mode ever gets really implemented. I'm sure when and if it's done in right way and we can see some real benefits of it's usage we'll find a proper way to include the missing instruction. hey, we may even omit it at that time. really my only point was, if it's one instruction that is a problem don't worry about it now. the right solution will probably just pop up when everythig else is working. best regards, p.

load pc-relative by Unknown on Mar 13, 2005			Not available!
* GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q]> Agreed. What issues do you see except the implementation > problems (problems with PC) and 'headache feature we can not remove' ? > > Let's assume for moment that there aren't any major problems implementing the > instruction. (i know this may be wrong assumption) > > The other we can easily address by not putting the instruction > in toolchain (or at least gcc) and explicitly forbid it's use in the > arch manual, or even better, including it in the core _only_ for thumb > mode use.[/q] Let's packpedal abit here. Now you are saying that the instructions need to be put into our (openrisc) toolchain??? But agreed with your comment below, let's wait for the actual implementation.[/q] No, no, you missunderstood me. I don't want it in the toolchain (unless it's proven that it's usefull). So to be clear, if by some chance ends in the openrisc (that's what i ment with core) i certainly don't want it to be used by anything but thumb mode. (and suggest forcing this somehow in the openrisc). So now we wait ... ;) best regards, p. * GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: > Agreed. What issues do you see except the implementation > problems (problems with PC) and 'headache feature we can not remove' ? > > Let's assume for moment that there aren't any major problems implementing the > instruction. (i know this may be wrong assumption) > > The other we can easily address by not putting the instruction > in toolchain (or at least gcc) and explicitly forbid it's use in the > arch manual, or even better, including it in the core _only_ for thumb > mode use. Let's packpedal abit here. Now you are saying that the instructions need to be put into our (openrisc) toolchain??? But agreed with your comment below, let's wait for the actual implementation. No, no, you missunderstood me. I don't want it in the toolchain (unless it's proven that it's usefull). So to be clear, if by some chance ends in the openrisc (that's what i ment with core) i certainly don't want it to be used by anything but thumb mode. (and suggest forcing this somehow in the openrisc). So now we wait ... ;) best regards, p.

load pc-relative by Unknown on Mar 14, 2005			Not available!
[q] The idea was to have binary compatibility with arm thumb ISA, so that we could reuse their tools. This ofcourse brings us to legal issues, and i have no idea if we are allowed to do so ...[/q] ARM patented the THUMB architecture and instruction set. Copying it would certainly put us in the line of fire. And THEY have certainly more lawyers than we do ;-) The idea was to have binary compatibility with arm thumb ISA, so that we could reuse their tools. This ofcourse brings us to legal issues, and i have no idea if we are allowed to do so ... ARM patented the THUMB architecture and instruction set. Copying it would certainly put us in the line of fire. And THEY have certainly more lawyers than we do ;-)

First

Prev

2/2

no use

no use

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