public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* (BFD): Non-byte addressing possible?
@ 2000-07-14  7:21 Di Carlo Federico
  2000-07-14  8:11 ` gprof: bb counts John Levon
  2000-07-14 10:27 ` (BFD): Non-byte addressing possible? Ian Lance Taylor
  0 siblings, 2 replies; 3+ messages in thread
From: Di Carlo Federico @ 2000-07-14  7:21 UTC (permalink / raw)
  To: binutils

Hi there!

We are trying to port all binutils to our parallel-architecture machine.

This architecture demands non per-byte addressing.
In fact we have to provide address via a 32 bit bus referring 16 byte (a
word, in this machine) with an address.

For example if address 0x8000 is address 0x4000 for memory controller
then address 0x8001 is address 0x4010 . So subseguent addresses refers
to 128 different bits in memory.

As far as we discovered it's not possible to force binutils (just BFD
ELF support, we guess, due to relocs) to support this feature, so we
think we'll have to do very strange magic translation at reloc/link
time.

Are there any features we didn't see or any back-end already using such
an addressing we could study?

Thanks!

Federico Di Carlo


^ permalink raw reply	[flat|nested] 3+ messages in thread

* gprof: bb counts
  2000-07-14  7:21 (BFD): Non-byte addressing possible? Di Carlo Federico
@ 2000-07-14  8:11 ` John Levon
  2000-07-14 10:27 ` (BFD): Non-byte addressing possible? Ian Lance Taylor
  1 sibling, 0 replies; 3+ messages in thread
From: John Levon @ 2000-07-14  8:11 UTC (permalink / raw)
  To: binutils

Hi *

I have an application which generates counts (not necessarily
execution) against EIPs. Now I can export this data in gprof format.

The manual *seems* to imply that if I use an address that isn't
the start of a basic block, then gprof will find which basic block it is
in and use that as a count.

So I can produce some number of different addresses within a basic
block, each with a different count.

When these are execution counts, is gprof clever enough to collate these
and provide accurate execution counts against each instruction ?

I would very much like to avoid fiddling with basic blocks myself

thanks
john 

-- 
"I don't have any solution but I certainly admire the problem."
	- Ashleigh Brilliant

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: (BFD): Non-byte addressing possible?
  2000-07-14  7:21 (BFD): Non-byte addressing possible? Di Carlo Federico
  2000-07-14  8:11 ` gprof: bb counts John Levon
@ 2000-07-14 10:27 ` Ian Lance Taylor
  1 sibling, 0 replies; 3+ messages in thread
From: Ian Lance Taylor @ 2000-07-14 10:27 UTC (permalink / raw)
  To: dicarlo; +Cc: binutils

   Date: Fri, 14 Jul 2000 16:21:16 +0200
   From: Di Carlo Federico <dicarlo@apegate.roma1.infn.it>

   We are trying to port all binutils to our parallel-architecture machine.

   This architecture demands non per-byte addressing.
   In fact we have to provide address via a 32 bit bus referring 16 byte (a
   word, in this machine) with an address.

   For example if address 0x8000 is address 0x4000 for memory controller
   then address 0x8001 is address 0x4010 . So subseguent addresses refers
   to 128 different bits in memory.

   As far as we discovered it's not possible to force binutils (just BFD
   ELF support, we guess, due to relocs) to support this feature, so we
   think we'll have to do very strange magic translation at reloc/link
   time.

   Are there any features we didn't see or any back-end already using such
   an addressing we could study?

See the tic54x and the octets_per_byte code.  Perhaps it will help.

Ian

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-07-14 10:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-14  7:21 (BFD): Non-byte addressing possible? Di Carlo Federico
2000-07-14  8:11 ` gprof: bb counts John Levon
2000-07-14 10:27 ` (BFD): Non-byte addressing possible? Ian Lance Taylor

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