I'm in the process of bring the GNU tool chain up to the latest released versions: binutils 2.19.1, gcc 4.4.1 and GDB 6.8 (done already). I wish to rationalize the work so far, and seek comments for all users.

The work by various contributors over the years has led to confused naming. In particular the target architecture is variously known as "openrisc", "or1k" and "or32", with files carrying all these names in existence.

In addition all GNU tool chain targets are identified by a triplet

• cpu

• manufacturer

• kernel-operating_system

Historically OpenRISC has often omitted the manufacturer, and used target names such as openrisc-rtems, or32-uclinux and or32-elf

I propose rationalizing this as follows.

Target Triplet

For embedded systems the kernel-operating system component of the triplet is appropriately specified as the linkage format, in this case ELF.

Where the manufacturer is unclear, it is acceptable to use the string "unknown". However I think it would be better for promoting opensource to use "opencores".

Finally the cpu component need not be a specific part number, but can refer to a group of processors with a common instruction set architecture (hence the use of i386 and i686 for many PC linux targets). For this reason, rather than "or1200" (the specific implementation), I suggest "or32", meaning all 32-bit big-endian machines implementing the ORBIS instruction set. We can then add or32-little for the 32-bit little-endian machines. I've used this naming, a) because it is already commonly in use, b) big-endian is the default endianness on OpenRISC implementations to date, and c) it is consistent with the proposed naming for binutils below.

That then means the target triplet to be used is:

or32-opencores-elf

Binutils Structure

Binutils covers all the low level GNU tools, most importantly the assembler gas and the linker, ld. Modern ports of binutils specify the target architecture using CGEN, which automates much of the work in creating the assembler/disassembler. I shall use CGEN in the new OpenRISC port. Underlying all of binutils is the binary file description (BFD) library.

From a binutils perspective, the BFD has two concepts, the *architecture* and the *machine*. So for example we have the m68k and SPARC architectures and within these the m68000, m68008, m68010, m68020 ... and the sparclet, sparclite, sparc_v8plus, ... machines. Note in particular that the architectures may cover both 32- and 64-bit machines. Each architecture may then have one or two ELF loaders, thus elf32-sparc and elf64-sparc.

CGEN defines a hierarchy of machines:

architecture
-> cpu family
   -> machine
      -> model

The assembler is architecture specific, so will work for all CPU families, machines and models, although particular features may be turned off for particular families/machines/models. Simulators are tied to particular machines or models.

OpenRISC is too broad an idea to be an architecture (we can reasonably believe the OpenRISC 2000 would be radically different). I believe that our architecture is the "OpenRISC 1000" (abbreviate as or1k), that we have the OR32 base family, the OR32 big-endian family and the OR32 little-endian family. The big-endian family contains the or32 (big-endian) machine and the little-endian familyt contains the or32-little (little-endian) machine. The or1200 and or1200 v2 are models of the or32 machine.

On the basis of this, the BFD ELF handler should be elf32-or1k, not elf32-openrisc, nor elf32-or32.

Similarly the assembler support functions should be or1k-asm.c, or1k-dis.c, or1k-opc.h, or1k-desc.c, or1k-ibld.c, or1k-desc.h and or1k-opc.c, not the or32-xxx versions there. The assembler testsuite should be gas/or1k, not gas/or32.

BTW CGEN also allows definition of multiple instruction set architectures. Assemblers and simulators can enable/disable ISAs as desired. That's convenient for OpenRISC, which has the ORBIS32, ORBIS64, ORFPX32, ORFPX64 and ORVDX64 instruction sets. I believe the OR1200 only implements ORBIS32.

Feedback on these proposals much appreciated.

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

It seems to me a nice thing to standardize this and CGEN sounds as a nice framework to port GNU tools. Very good initiative.

I would only comment, that opencores as manufacturer could be abbreviated into: oc

I need the gc-sections function. Does the new porting support it?

Hi Anserine

I believe it will, since this functionality is a generic part of ld. I don't believe it has any dependency on the target specific porting.

ATB

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hi Anserine

I've investigated further, and changed my opinion on this. It does depend on target specific functionality being implemented.

I don't know whether this will be provided. What is the specific requirement you have for this?

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

I need more compact size of the object code on the embedded system. The gc-sections option can remove unused object code. The small object size means lower cost on the small system.

Hi Anserine,

I'm reusing a lot of the existing binutils code. If --gc-sections is supported there, it will probably be supported in the new port.

Otherwise it depends how much effort is involved.

ATB,

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

I think these naming conventions are fine; your rationale for choosing them makes sense to me.

(slight tangent:) I think the hard part will be to keep everyone using them as designed. To that end, I suggest documenting your naming convention (including the rationale behind it), and then putting a copy of that document in every conceivable place that someone might possibly look for this information. Then, the other hard part, keep every copy up to date. Because it's very easy to picture someone five years from now making a half-hearted search for this, failing to find it, and making up something else for his project. As soon as someone else sees it, it becomes a 'competing standard', and a general mess ensues.

Sorry if I'm preaching to the choir, but up-to-date documentation has historically been difficult to come by around here...a little work now can keep this particular wheel from being re-invented (poorly) in the future.

Hi Nathan,

You make very good points. I'm documenting throughout using Doxygen, and each source file explains the naming convention.

I'm also going to strip out the old OpenRISC/or32 code. Leaving that around, unused, will only add to the confusion.

ATB,

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

I also need the naked __attribute__ to remove the prolog/epilog of functions.

Hi Kuoping,

Would you record this in the bug tracker (www.opencores.org/openrisc,bugtracker). It's something that will need adding to GCC when I get that far.

Thanks for the suggestion.

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

will there be libstdc++ and or32-elf-g++ ?

Thank you

Hi hiwu

Eventually there will be. The work is being fitted in round my day job, so it may be some time. I have heard there is an experimental version of g++ for OR1K already, but I don't know where it is. Binutils already seems to have the hooks in to provide the necessary relocations.

ATB

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com