public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@sebabeach.org>
To: jeremy.bennett@embecosm.com
Cc: cgen@sourceware.org
Subject: Re: Architectures and Machine Names
Date: Tue, 25 Aug 2009 00:21:00 -0000	[thread overview]
Message-ID: <4A932E72.7010503@sebabeach.org> (raw)
In-Reply-To: <1250877079.10529.224.camel@thomas>

Jeremy Bennett wrote:
> I'm updating the OpenRISC 1000 binutils port and CGEN specification and
> need some advice on defining architecture and machine.
>
> Over the years there has been some confusion over naming with the
> OpenRISC project. The OpenRISC 1000 is an architecture permitting
> various implementations (32-bit, 64-bit, big-endian, little-endian).
> Within this architecture there is a core instruction set (either 32 or
> 64-bit), and supplementary instruction sets for floating point and
> vector operations.
>
> Currently there is one 32-bit big-endian implementation, the OpenRISC
> 1200 supporting the core 32-bit instruction set
>
> 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.

> 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. :-)]

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

> 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.

> Unfortunately I cannot find an example to follow within binutils of an
> architecture like this. The SuperH processors are specified with CGEN
> (sh.cpu), but not built with CGEN. All the CGEN targets in configure.in
> with using_cgen=yes have the same name for both architecture and
> machine.
>
> 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.
>
> Many thanks,
>
>
> Jeremy
>
>   

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.

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


  reply	other threads:[~2009-08-25  0:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-21 17:51 Jeremy Bennett
2009-08-25  0:21 ` Doug Evans [this message]
2009-08-26 17:29   ` Jeremy Bennett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A932E72.7010503@sebabeach.org \
    --to=dje@sebabeach.org \
    --cc=cgen@sourceware.org \
    --cc=jeremy.bennett@embecosm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).