OpenCores

OpenCores

a few questions

no use

no use

1/2

Next

Last

a few questions by Unknown on Mar 7, 2004			Not available!
Hi, I'm in the business of getting back into the OpenCores business. I've forgotten one or two things along the way, though: 1) Why is the architecture called or32 in the configuration tuple? A more logical name, which also follows the conventions, would be openrisc-- or openrisc1000-- . The ISA is normally specified with an option to the tool (gcc -m32, for example). FWIW, I think it would be better to follow the convention. See how they have solved it for MIPS (which is a similar architecture.) 2) Has work begun on supporting the 64-bit part of the ISA? Both in the simulator and the tools? 3) Are there an effort to get the GNU toolchain ports into the official distributions? 4) What is the status of GCC, GDB and binutils as of now? I saw that GCC 3.2.3 has been imported into the CVS repo. What about GDB? 5) Has any configuration of OpenRISC 1200 (or any other impl) been tested in little endian mode? Can the simulator be configured for little endian? best regards, johan Hi, I'm in the business of getting back into the OpenCores business. I've forgotten one or two things along the way, though: 1) Why is the architecture called or32 in the configuration tuple? A more logical name, which also follows the conventions, would be openrisc-- or openrisc1000-- . The ISA is normally specified with an option to the tool (gcc -m32, for example). FWIW, I think it would be better to follow the convention. See how they have solved it for MIPS (which is a similar architecture.) 2) Has work begun on supporting the 64-bit part of the ISA? Both in the simulator and the tools? 3) Are there an effort to get the GNU toolchain ports into the official distributions? 4) What is the status of GCC, GDB and binutils as of now? I saw that GCC 3.2.3 has been imported into the CVS repo. What about GDB? 5) Has any configuration of OpenRISC 1200 (or any other impl) been tested in little endian mode? Can the simulator be configured for little endian? best regards, johan

a few questions by Unknown on Mar 9, 2004			Not available!
In practice everybody just calls it openrisc. In case of architecture it is simply called openrisc architecture. But also if you look at the MIPS. You have terms like MIPS (general arch indication, also company name), MIPS32 (suset of MIPS arch identifying the 32-bit subpart), MIPS 4000/5000/12000 (implementation, where did these numbers came from, a.k.a. MIPS 4K, 5K, 12K etc), and then you have code names for specific MIPS cores can't remember any right now. And there are revision of the MIPS arhcitecture called MIPS I, MIPS II and the latest I think MIPS IV... Anyway it is a big mess, I think much bigger than with the openrisc. I don't mind if you simply refer it is OR32 or OR64 etc. And the implementations can be called like in case of MIPS, ie OR1200, OR1500 etc. Let me also explain my original idea. The architecture is openrisc 1000 and then you have openrisc 1x00 where the x specifies specific implementation. Adn then you have openrisc 12yy where yy would be implementation specific, for example defining exact configuration of the core (handy when you have a soft core like openrisc 1200 which can be configured in many different ways). If you look at the VR register, you have Version, which is 12hex (for 12yy) and you have revision field yy for the 12yy. BTW openrisc 1200 is same as short OR1200. So the general idea is that you either use openrisc or short OR. So openrisc32 or OPENRISC32 would be the same as OR32... regards, Damjan [q] : > : > 1) Why is the architecture called or32 in the configuration[/q] tuple? [q] : > Isn't or16 an ISA, much like the MIPS16 or Thumb? : yes. Then I think the architecture in the tuple should be called "openrisc". There is nothing that says that openrisc--gcc can't support OR32, OR64 and OR16 at the same time. SPARC and MIPS compilers are often bi-arch.[/q] In practice everybody just calls it openrisc. In case of architecture it is simply called openrisc architecture. But also if you look at the MIPS. You have terms like MIPS (general arch indication, also company name), MIPS32 (suset of MIPS arch identifying the 32-bit subpart), MIPS 4000/5000/12000 (implementation, where did these numbers came from, a.k.a. MIPS 4K, 5K, 12K etc), and then you have code names for specific MIPS cores can't remember any right now. And there are revision of the MIPS arhcitecture called MIPS I, MIPS II and the latest I think MIPS IV... Anyway it is a big mess, I think much bigger than with the openrisc. I don't mind if you simply refer it is OR32 or OR64 etc. And the implementations can be called like in case of MIPS, ie OR1200, OR1500 etc. Let me also explain my original idea. The architecture is openrisc 1000 and then you have openrisc 1x00 where the x specifies specific implementation. Adn then you have openrisc 12yy where yy would be implementation specific, for example defining exact configuration of the core (handy when you have a soft core like openrisc 1200 which can be configured in many different ways). If you look at the VR register, you have Version, which is 12hex (for 12yy) and you have revision field yy for the 12yy. BTW openrisc 1200 is same as short OR1200. So the general idea is that you either use openrisc or short OR. So openrisc32 or OPENRISC32 would be the same as OR32... regards, Damjan : > : > 1) Why is the architecture called or32 in the configuration tuple? : > Isn't or16 an ISA, much like the MIPS16 or Thumb? : yes. Then I think the architecture in the tuple should be called "openrisc". There is nothing that says that openrisc--gcc can't support OR32, OR64 and OR16 at the same time. SPARC and MIPS compilers are often bi-arch.

a few questions by Unknown on Mar 9, 2004			Not available!
[q] added support for l.mac[i] instructions (I have to work a bit more on this, though. Right now[/q] Can you actually test if this works - I tried it in the past and never could get it working. regards, Damjan added support for l.mac instructions (I have to work a bit more on this, though. Right now Can you actually test if this works - I tried it in the past and never could get it working. regards, Damjan

a few questions by Unknown on Mar 9, 2004			Not available!
Hi Johan! Welcome back! [q] 1) Why is the architecture called or32 in the configuration tuple? A more logical name, which also follows the conventions, would be openrisc-- or openrisc1000-- . The ISA is normally specified with an option to the tool (gcc -m32, for example). FWIW, I think it would be better to follow the convention. See how they have solved it for MIPS (which is a similar architecture.)[/q] there was also or16 architecture which is not currently used. [q] 2) Has work begun on supporting the 64-bit part of the ISA? Both in the simulator and the tools?[/q] no, not yet. [q] 3) Are there an effort to get the GNU toolchain ports into the official distributions?[/q] AFAIK, binutils is already in the official, gdb and gcc are not there yet. Matjaz is working on the tools more than I do. [q] 4) What is the status of GCC, GDB and binutils as of now? I saw that GCC 3.2.3 has been imported into the CVS repo. What about GDB?[/q] 5.0 version. [q] 5) Has any configuration of OpenRISC 1200 (or any other impl) been tested in little endian mode? Can the simulator be configured for little endian?[/q] no, not yet, but these are small changes. I don't know whether there is interest in this. Maybe it would be better to leave architecture just big-endian. As you see, there is much work to do, so any help would be greatly appreciated ;) best regards, Marko Hi Johan! Welcome back! 1) Why is the architecture called or32 in the configuration tuple? A more logical name, which also follows the conventions, would be openrisc-- or openrisc1000-- . The ISA is normally specified with an option to the tool (gcc -m32, for example). FWIW, I think it would be better to follow the convention. See how they have solved it for MIPS (which is a similar architecture.) there was also or16 architecture which is not currently used. 2) Has work begun on supporting the 64-bit part of the ISA? Both in the simulator and the tools? no, not yet. 3) Are there an effort to get the GNU toolchain ports into the official distributions? AFAIK, binutils is already in the official, gdb and gcc are not there yet. Matjaz is working on the tools more than I do. 4) What is the status of GCC, GDB and binutils as of now? I saw that GCC 3.2.3 has been imported into the CVS repo. What about GDB? 5.0 version. 5) Has any configuration of OpenRISC 1200 (or any other impl) been tested in little endian mode? Can the simulator be configured for little endian? no, not yet, but these are small changes. I don't know whether there is interest in this. Maybe it would be better to leave architecture just big-endian. As you see, there is much work to do, so any help would be greatly appreciated ;) best regards, Marko

a few questions by Unknown on Mar 9, 2004			Not available!
Marko Mlinar <<A HREF="mailto:markom@opencores.org">markom@opencores.org</A>> wrote: : Hi Johan! : Welcome back! Thanks Marko! : > 1) Why is the architecture called or32 in the configuration tuple? : there was also or16 architecture which is not currently used. Isn't or16 an ISA, much like the MIPS16 or Thumb? : > 5) Has any configuration of OpenRISC 1200 (or any other impl) : > been tested in little endian mode? Can the simulator be : > configured for little endian? : no, not yet, but these are small changes. I don't know whether there is : interest in this. Maybe it would be better to leave architecture just : big-endian. Are there any interest of adding little endian support to GCC? -- Johan Rydberg, Free Software Developer, Sweden <A HREF="http://rtmk.sf.net">http://rtmk.sf.net</A> \| <A HREF="http://www.nongnu.org/guss/">http://www.nongnu.org/guss/</A> Playing Incubus - Nice To Know You Marko Mlinar markom@opencores.org> wrote: : Hi Johan! : Welcome back! Thanks Marko! : > 1) Why is the architecture called or32 in the configuration tuple? : there was also or16 architecture which is not currently used. Isn't or16 an ISA, much like the MIPS16 or Thumb? : > 5) Has any configuration of OpenRISC 1200 (or any other impl) : > been tested in little endian mode? Can the simulator be : > configured for little endian? : no, not yet, but these are small changes. I don't know whether there is : interest in this. Maybe it would be better to leave architecture just : big-endian. Are there any interest of adding little endian support to GCC? -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net \| http://www.nongnu.org/guss/ Playing Incubus - Nice To Know You

a few questions by Unknown on Mar 9, 2004			Not available!
Marko Mlinar <<A HREF="mailto:markom@opencores.org">markom@opencores.org</A>> wrote: [I'm CC'ing the list aswell] : > : > 1) Why is the architecture called or32 in the configuration tuple? : > Isn't or16 an ISA, much like the MIPS16 or Thumb? : yes. Then I think the architecture in the tuple should be called "openrisc". There is nothing that says that openrisc--gcc can't support OR32, OR64 and OR16 at the same time. SPARC and MIPS compilers are often bi-arch. : > Are there any interest of adding little endian support to GCC? : I would not say so. I believe none of the current applications would work and : the effort of maintaining both little and big endian is too big. I'll leave it alone then. -- Johan Rydberg, Free Software Developer, Sweden <A HREF="http://rtmk.sf.net">http://rtmk.sf.net</A> \| <A HREF="http://www.nongnu.org/guss/">http://www.nongnu.org/guss/</A> Playing Ratatat - Desert Eagle Marko Mlinar markom@opencores.org> wrote: [I'm CC'ing the list aswell] : > : > 1) Why is the architecture called or32 in the configuration tuple? : > Isn't or16 an ISA, much like the MIPS16 or Thumb? : yes. Then I think the architecture in the tuple should be called "openrisc". There is nothing that says that openrisc--gcc can't support OR32, OR64 and OR16 at the same time. SPARC and MIPS compilers are often bi-arch. : > Are there any interest of adding little endian support to GCC? : I would not say so. I believe none of the current applications would work and : the effort of maintaining both little and big endian is too big. I'll leave it alone then. -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net \| http://www.nongnu.org/guss/ Playing Ratatat - Desert Eagle

a few questions by Unknown on Mar 9, 2004			Not available!
* Johan Rydberg (<A HREF="mailto:jrydberg@night.trouble.net">jrydberg@night.trouble.net</A>) wrote: [q] Marko Mlinar <<A HREF="mailto:markom@opencores.org">markom@opencores.org</A>> wrote: [I'm CC'ing the list aswell] : > : > 1) Why is the architecture called or32 in the configuration tuple? : > Isn't or16 an ISA, much like the MIPS16 or Thumb? : yes. Then I think the architecture in the tuple should be called "openrisc". There is nothing that says that openrisc--gcc can't support OR32, OR64 and OR16 at the same time. SPARC and MIPS compilers are often bi-arch.[/q] i would go with such patch as a cleanup, but only if there is no argument against it and if it's for the whole toolchain. the last thing we'd want is to have or32 in some tools and openrisc in others. as far as linux is concearned though you have seperate arch directories for 32 and 64 bits 'bi-archs'. i386 & x86_64 mips & mips64 ppc & ppc64 sparc & sparc64 regards, p. Johan Rydberg (jrydberg@night.trouble.net) wrote: Marko Mlinar markom@opencores.org> wrote: [I'm CC'ing the list aswell] : > : > 1) Why is the architecture called or32 in the configuration tuple? : > Isn't or16 an ISA, much like the MIPS16 or Thumb? : yes. Then I think the architecture in the tuple should be called "openrisc". There is nothing that says that openrisc-*-gcc can't support OR32, OR64 and OR16 at the same time. SPARC and MIPS compilers are often bi-arch. i would go with such patch as a cleanup, but only if there is no argument against it and if it's for the whole toolchain. the last thing we'd want is to have or32 in some tools and openrisc in others. as far as linux is concearned though you have seperate arch directories for 32 and 64 bits 'bi-archs'. i386 & x86_64 mips & mips64 ppc & ppc64 sparc & sparc64 regards, p.

a few questions by Unknown on Mar 9, 2004			Not available!
On Tue, 9 Mar 2004, Matjaz Breskvar wrote: [q]> Then I think the architecture in the tuple should be called "openrisc". > There is nothing that says that openrisc--gcc can't support OR32, OR64 > and OR16 at the same time. SPARC and MIPS compilers are often bi-arch.[/q] i would go with such patch as a cleanup, but only if there is no argument against it and if it's for the whole toolchain. the last thing we'd want is to have or32 in some tools and openrisc in others.[/q] That's what I'm doing. I'm cleaning up our GCC target (and doing some modifcations) so that it fits with CVS HEAD. So far I've cleaned up the tm.c and tm.h files (i.e., openrisc.c and openrisc.h), fixed the conditonal branch issues (l.sfCC+l.bX) and added support for l.mac[i] instructions (I have to work a bit more on this, though. Right now using normal "l.mul" generates better code. I'll try to eliminate moves to and from the MACLO register as much as possible.) I will also take a look at the code size problem. [q] as far as linux is concearned though you have seperate arch directories for 32 and 64 bits 'bi-archs'.[/q] While doing my clean ups I've tried to keep them as "64-bit" clean as possible so that we can make the compiler 'bi-arch' when we feel we need to (I might even give it a shot if I find the time.) Regarding the Linux kernel and bi-archs. Yes, it normally splits 32-bit and 64-bit targets, even if they belong to the same architecture. But that is due to limitations in Linux. IIRC, NetBSD does not do this. brgds, Johan Rydberg. On Tue, 9 Mar 2004, Matjaz Breskvar wrote: > Then I think the architecture in the tuple should be called "openrisc". > There is nothing that says that openrisc--gcc can't support OR32, OR64 > and OR16 at the same time. SPARC and MIPS compilers are often bi-arch. i would go with such patch as a cleanup, but only if there is no argument against it and if it's for the whole toolchain. the last thing we'd want is to have or32 in some tools and openrisc in others. That's what I'm doing. I'm cleaning up our GCC target (and doing some modifcations) so that it fits with CVS HEAD. So far I've cleaned up the tm.c and tm.h files (i.e., openrisc.c and openrisc.h), fixed the conditonal branch issues (l.sfCC+l.bX) and added support for l.mac instructions (I have to work a bit more on this, though. Right now using normal "l.mul" generates better code. I'll try to eliminate moves to and from the MACLO register as much as possible.) I will also take a look at the code size problem. as far as linux is concearned though you have seperate arch directories for 32 and 64 bits 'bi-archs'. While doing my clean ups I've tried to keep them as "64-bit" clean as possible so that we can make the compiler 'bi-arch' when we feel we need to (I might even give it a shot if I find the time.) Regarding the Linux kernel and bi-archs. Yes, it normally splits 32-bit and 64-bit targets, even if they belong to the same architecture. But that is due to limitations in Linux. IIRC, NetBSD does not do this. brgds, Johan Rydberg.

a few questions by Unknown on Mar 9, 2004			Not available!
[q] win to do so. Are there any implementations of OpenRISC which only has l.mac and not l.mul ?[/q] Probably not since for MAC you need a multiplier. For example for the OR1200, when you enable to implement the l.mac insn, you always have l.muc implemented (since l.mac uses the multiplier and if you have the multiplier why not to have l.mul implemented) regards, Damjan win to do so. Are there any implementations of OpenRISC which only has l.mac and not l.mul ? Probably not since for MAC you need a multiplier. For example for the OR1200, when you enable to implement the l.mac insn, you always have l.muc implemented (since l.mac uses the multiplier and if you have the multiplier why not to have l.mul implemented) regards, Damjan

a few questions by Unknown on Mar 9, 2004			Not available!
[q] well i'm not sure which one is really official. does anyone know of offical registry or something. anyway if you 'change' it to 92 let me know to fix it in uclinux & linux or they woun't work anymore. also all existing binaries will need to be recompiled...[/q] And don't forget the openrisc arch manual. It also says describes the ELF. Use whatever is in the manual. I hate to keep changing the manual. I think the manual uses Johan's number but not sure. regards, Damjan well i'm not sure which one is really official. does anyone know of offical registry or something. anyway if you 'change' it to 92 let me know to fix it in uclinux & linux or they woun't work anymore. also all existing binaries will need to be recompiled... And don't forget the openrisc arch manual. It also says describes the ELF. Use whatever is in the manual. I hate to keep changing the manual. I think the manual uses Johan's number but not sure. regards, Damjan

a few questions by Unknown on Mar 9, 2004			Not available!
"Damjan Lampret" <<A HREF="mailto:lampret@opencores.org">lampret@opencores.org</A>> wrote: : > added support for l.mac[i] : > instructions (I have to work a bit more on this, though. Right now : : Can you actually test if this works - I tried it in the past and never could : get it working. Of course. But I've only added support for l.mac to my "CVS HEAD" branch, so there may be other things broken. Is it best to run the testsuite in the simulator to verify this? I still have problems with that GCC generates too much code when it uses l.mac. I'll try to fix it so that it only uses it when there is a real win to do so. Are there any implementations of OpenRISC which only has l.mac and not l.mul ? Another issue. GCC 3.2.3 emits l.mul insn even if you run it with -msoft-mul. Is this the right behaviour, or just a bug? -- Johan Rydberg, Free Software Developer, Sweden <A HREF="http://rtmk.sf.net">http://rtmk.sf.net</A> \| <A HREF="http://www.nongnu.org/guss/">http://www.nongnu.org/guss/</A> Playing Incubus - Nice To Know You "Damjan Lampret" lampret@opencores.org> wrote: : > added support for l.mac : > instructions (I have to work a bit more on this, though. Right now : : Can you actually test if this works - I tried it in the past and never could : get it working. Of course. But I've only added support for l.mac to my "CVS HEAD" branch, so there may be other things broken. Is it best to run the testsuite in the simulator to verify this? I still have problems with that GCC generates too much code when it uses l.mac. I'll try to fix it so that it only uses it when there is a real win to do so. Are there any implementations of OpenRISC which only has l.mac and not l.mul ? Another issue. GCC 3.2.3 emits l.mul insn even if you run it with -msoft-mul. Is this the right behaviour, or just a bug? -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net \| http://www.nongnu.org/guss/ Playing Incubus - Nice To Know You

a few questions by Unknown on Mar 9, 2004			Not available!
"Damjan Lampret" <<A HREF="mailto:lampret@opencores.org">lampret@opencores.org</A>> wrote: : So the general idea is that you either use openrisc or : short OR. So openrisc32 or OPENRISC32 would be the same as OR32... This is pretty much the same as SPARC, but the omit the "32" since it is the default -> sparc vs sparc64. This seem to be the convention. FWIW I think we should stick with the convention and use openrisc for the 32-bit ISA's and openrisc64 for the 64-bit version (it should not be impossible to just use "openrisc" and specify -m64 to the compiler aswell. I'm not sure about binutils/GDB, though.) -- Johan Rydberg, Free Software Developer, Sweden <A HREF="http://rtmk.sf.net">http://rtmk.sf.net</A> \| <A HREF="http://www.nongnu.org/guss/">http://www.nongnu.org/guss/</A> Playing Incubus - Nice To Know You "Damjan Lampret" lampret@opencores.org> wrote: : So the general idea is that you either use openrisc or : short OR. So openrisc32 or OPENRISC32 would be the same as OR32... This is pretty much the same as SPARC, but the omit the "32" since it is the default -> sparc vs sparc64. This seem to be the convention. FWIW I think we should stick with the convention and use openrisc for the 32-bit ISA's and openrisc64 for the 64-bit version (it should not be impossible to just use "openrisc" and specify -m64 to the compiler aswell. I'm not sure about binutils/GDB, though.) -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net \| http://www.nongnu.org/guss/ Playing Incubus - Nice To Know You

a few questions by Unknown on Mar 9, 2004			Not available!
* Johan Rydberg (<A HREF="mailto:jrydberg@night.trouble.net">jrydberg@night.trouble.net</A>) wrote: [q] "Damjan Lampret" <<A HREF="mailto:lampret@opencores.org">lampret@opencores.org</A>> wrote: : > added support for l.mac[i] : > instructions (I have to work a bit more on this, though. Right now : : Can you actually test if this works - I tried it in the past and never could : get it working. Another issue. GCC 3.2.3 emits l.mul insn even if you run it with -msoft-mul. Is this the right behaviour, or just a bug? [/q] that would be a bug. regards, p. * Johan Rydberg (jrydberg@night.trouble.net) wrote: "Damjan Lampret" lampret@opencores.org> wrote: : > added support for l.mac : > instructions (I have to work a bit more on this, though. Right now : : Can you actually test if this works - I tried it in the past and never could : get it working. Another issue. GCC 3.2.3 emits l.mul insn even if you run it with -msoft-mul. Is this the right behaviour, or just a bug? that would be a bug. regards, p.

a few questions by Unknown on Mar 10, 2004			Not available!
Johan Rydberg <<A HREF="mailto:jrydberg@night.trouble.net">jrydberg@night.trouble.net</A>> wrote: : : So the general idea is that you either use openrisc or : : short OR. So openrisc32 or OPENRISC32 would be the same as OR32... : : This is pretty much the same as SPARC, but the omit the "32" since : it is the default -> sparc vs sparc64. This seem to be the convention. : FWIW I think we should stick with the convention and use openrisc Another issue is what to do with the sources that is already a part of the offical GNU binutils distribution. Right now there is my old port (openrisc-) and "your" port (or32-), side by side. When I did my port I registered a elf machine architecture value for OpenRISC. [q]From include/elf/common.h:[/q] #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor / A few lines below that: / (Deprecated) Temporary number for the OpenRISC processor. / #define EM_OR32 0x8472 Who made it deprecated, or was it already that when the port was contributed? I could make an effort to merge them (remove one of them, clear some issues and start using EM_OPENRISC.) and check out what needs to be done to support 64 bit, unless someone objects. Comments? -- Johan Rydberg, Free Software Developer, Sweden <A HREF="http://rtmk.sf.net">http://rtmk.sf.net</A> \| <A HREF="http://www.nongnu.org/guss/">http://www.nongnu.org/guss/</A> Playing Ratatat - Crips Johan Rydberg jrydberg@night.trouble.net> wrote: : : So the general idea is that you either use openrisc or : : short OR. So openrisc32 or OPENRISC32 would be the same as OR32... : : This is pretty much the same as SPARC, but the omit the "32" since : it is the default -> sparc vs sparc64. This seem to be the convention. : FWIW I think we should stick with the convention and use openrisc Another issue is what to do with the sources that is already a part of the offical GNU binutils distribution. Right now there is my old port (openrisc-) and "your" port (or32-), side by side. When I did my port I registered a elf machine architecture value for OpenRISC. From include/elf/common.h: #define EM_OPENRISC 92 / OpenRISC 32-bit embedded processor / A few lines below that: / (Deprecated) Temporary number for the OpenRISC processor. */ #define EM_OR32 0x8472 Who made it deprecated, or was it already that when the port was contributed? I could make an effort to merge them (remove one of them, clear some issues and start using EM_OPENRISC.) and check out what needs to be done to support 64 bit, unless someone objects. Comments? -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net \| http://www.nongnu.org/guss/ Playing Ratatat - Crips

a few questions by Unknown on Mar 10, 2004			Not available!
* Johan Rydberg (<A HREF="mailto:jrydberg@night.trouble.net">jrydberg@night.trouble.net</A>) wrote: [q] Johan Rydberg <<A HREF="mailto:jrydberg@night.trouble.net">jrydberg@night.trouble.net</A>> wrote: : : So the general idea is that you either use openrisc or : : short OR. So openrisc32 or OPENRISC32 would be the same as OR32... : : This is pretty much the same as SPARC, but the omit the "32" since : it is the default -> sparc vs sparc64. This seem to be the convention. : FWIW I think we should stick with the convention and use openrisc Another issue is what to do with the sources that is already a part of the offical GNU binutils distribution. Right now there is my old port (openrisc-) and "your" port (or32-), side by side. When I did my port I registered a elf machine architecture value for OpenRISC. [q]>From include/elf/common.h:[/q] #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor / A few lines below that: / (Deprecated) Temporary number for the OpenRISC processor. / #define EM_OR32 0x8472 Who made it deprecated, or was it already that when the port was contributed? I could make an effort to merge them (remove one of them, clear some issues and start using EM_OPENRISC.) and check out what needs to be done to support 64 bit, unless someone objects. Comments?[/q] well i'm not sure which one is really official. does anyone know of offical registry or something. anyway if you 'change' it to 92 let me know to fix it in uclinux & linux or they woun't work anymore. also all existing binaries will need to be recompiled... regards, p. Johan Rydberg (jrydberg@night.trouble.net) wrote: Johan Rydberg jrydberg@night.trouble.net> wrote: : : So the general idea is that you either use openrisc or : : short OR. So openrisc32 or OPENRISC32 would be the same as OR32... : : This is pretty much the same as SPARC, but the omit the "32" since : it is the default -> sparc vs sparc64. This seem to be the convention. : FWIW I think we should stick with the convention and use openrisc Another issue is what to do with the sources that is already a part of the offical GNU binutils distribution. Right now there is my old port (openrisc-) and "your" port (or32-), side by side. When I did my port I registered a elf machine architecture value for OpenRISC. >From include/elf/common.h: #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor / A few lines below that: / (Deprecated) Temporary number for the OpenRISC processor. */ #define EM_OR32 0x8472 Who made it deprecated, or was it already that when the port was contributed? I could make an effort to merge them (remove one of them, clear some issues and start using EM_OPENRISC.) and check out what needs to be done to support 64 bit, unless someone objects. Comments? well i'm not sure which one is really official. does anyone know of offical registry or something. anyway if you 'change' it to 92 let me know to fix it in uclinux & linux or they woun't work anymore. also all existing binaries will need to be recompiled... regards, p.

no use

no use

1/2

Next

Last

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