Re: Architectures and Machine Names

[Jeremy Bennett <jeremy dot bennett at embecosm dot com>]

On Mon, 2009-08-24 at 17:21 -0700, Doug Evans wrote:
> Jeremy Bennett wrote:
> > I'm updating the OpenRISC 1000 binutils port and CGEN specification and
> > need some advice on defining architecture and machine.

...

> > So it seems natural to define the CGEN architecture as or1k, with a
> > machine named or32 (supporting the core ISA) and a model named or1200.
> > All in a file named or1k.cpu.
> >   
> 
> Seems straightforward enough to me.
> 
> > Users build their binutils using --target=or32-opencores-elf. I have a
> > BFD architecture bfd_arch_or1k and a BFD machine bfd_mach_or32.
> >   
> 
> Having --target=or32-foo is ok of course, but OOC did you want to have 
> one set of tools support all variants instead?  E.g. have 
> --target=or1k-foo instead?  You could have both, and only support 
> or1k-foo later of course.  Just wondering.

I'm really covering myself, since I'm not sure that one set of tools
will be able to cover everything in future OpenRISC 1000 implementations
(e.g. a 64-bit little-endian variant supporting the vector
instructions).

> > However I am struggling to get binutils to accept the idea that the
> > machine name and architecture are different. CGEN will generate my
> > opcodes files using the architecture (or1k-) as prefix. However GAS will
> > set the prefix from the CPU (or32), not the CPU Type (or1k), so looks
> > for opcodes files with a or32- prefix.
> >   
> 
> This may just be a consequence of never having a port that did it this 
> way before, and we just need to spiff up things a bit.  I.e. see above.  
> Looking through src/opcodes/Makefile.am, I see all cgen ports passing 
> the same text for arch= and prefix= to run-cgen.
> 
> OTOH, let's make sure you *want* to do it this way (i.e. have 
> --target=or32-foo instead of --target=or1k-foo).  [Assuming I'm 
> understanding the issue correctly, that's not a given. :-)]

A good question to consider now - thanks for all your input.

> [And for my own education, does this mean the openrisc target is going away?
> e.g. grep for openrisc in src/*/configure.in]

openrisc was never the right name for the target. OpenRISC is a generic
name for the open source processors being developed at OpenCores. So far
we have only the OpenRISC 1000 architecture family (32/64-bit,
big/little endian, integer, FP and vector ops). However there  has
always been a vision that there could in future be OpenRISC 2000, 3000
projects, with radically different architecture.

Over the years people have tried to clarify this in various ways - or1k
as a target for OpenRISC 1000, or or32, for the 32-bit versions. So we
end up with some tools using openrisc, some using or32 and some using
or1k.

To add to the confusion, OpenCores has changed over the last 10 years,
and the people now working on the project have changed, with little
continuity, and inadequate documentation of design decisions.

I'm trying to tidy this up. So far there are several 32-bit
implementations of the OpenRISC 1000 architecture: the OR1200 and
OR1200v2 from OpenCores, the BA12, BA14 and BA22 from Beyond Semi and
others elsewhere. I think these are all big-endian, but there are
reportedly some little-endian variants out there.

Ideally I'd like all the tools to work for all the targets, with just
flags to specify which variant (a bit like the Motorola 68k tools do).
However in case this isn't possible, I've suggested allowing the target
variants to be specified (or32 for big-endian 32-bit architectures,
since big-endian is the hardware default).

> > I have tried overriding this in configure.in for gas by setting the
> > prefix to match the CPU type (or1k), and binutils will build. However
> > the ELF images created by the assembler use the machine name (or32) as
> > the architecture, but the disassembler checks that the file matches the
> > architecture (or1k). Thus objdump -d will not recognize files created by
> > the assembler.
> 
> I'm not clear on what "use the machine name (or32) as the architecture" 
> means.  Can you give details?  E.g. example output from objdump -f or 
> some such? [objdump -f output mightn't be sufficient, all the details 
> you can provide will help]
> 
> The setting of architecture and machine name in the ELF files is mostly 
> a gas/bfd thing (IIRC).  I'm not sure how cgen comes into play here.

Agreed. I've realized the mistake is mine. It is the printable name
field in the bfd_arch_info structure, which I had mistakenly thought was
just the machine name field.

If I end up with multiple CPU types (not just or32) within the or1k
architecture, then I'll have multiple bfd_arch_info structures, one for
each bfd_mach. In this sense a BFD machine corresponds to the CPU in
CGEN - which is exactly what the documentation says:-)

objdump -d was refusing to disassemble the images I'd assembled with
gas, but that problem has now gone away. I'm not quite sure why, since I
don't think it was the textual name that was affecting it. Now objdump
just crashes :-) But at least that's a bug I can start working on.

> > I'd appreciate advice on how to resolve this. Most of the OpenRISC 1000
> > is common to all implementations, so it makes sense to have a single
> > "or1k" set of tools. However the user also needs to specify which CPU
> > within the "or1k" set, to allow variations to happen.  
> 
> Typically (for some definition of "typically" :-)) users have one set of 
> tools that handles all machine variants and they specify either in the 
> assembler file, or in parameters passed to gas, which machine  variant 
> they are assembling for.  No claim is made that this definition of 
> "typically" is, umm, typical. :-)
> 
> btw, if one were go with --target=or32-foo, and I'm not saying it's a 
> bad route to go, I'd pass the machine name to the -m option to cgen so 
> that only that machine's description is kept (and all others are 
> discarded).  I see src/opcodes/cgen.sh currently passes "all" for -m, 
> we'd want to make that a parameter.  Since it's always been "all", 
> getting this to work may involve a bit of hacking.  Getting the 
> architecture/machine data right in the ELF file should be straightforward.

Your comments have been very helpful. You've given me lots of ideas to
think about

> Can you send me a patch or tarball or some such for me to play with?

Certainly. Bzipped patch against binutils 2.19.1 attached. It's over
100k, so I hope the mailing list accepts it.

It's work in progress - it just builds, I'm only starting to test it
now. I used the CGEN from CVS tagged 1.1.

Thanks for your advice.


Jeremy

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

Attachment: or1k-binutils-patch-26-aug-09.bz2
Description: application/bzip