Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Timothy Wall <twall@oculustech.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: packing/unpacking 4-octet longs
Date: Wed, 05 Dec 2001 10:20:00 -0000	[thread overview]
Message-ID: <3C0E6556.A5F9D5D6@oculustech.com> (raw)
In-Reply-To: <3C0E617F.7020506@cygnus.com>

See comments below.

Andrew Cagney wrote:

> > Andrew Cagney wrote:
> >
> >
> >>
> >> Regarding the hard case, when you say that the byte order switches at an
> >> odd address.  Is this an odd word address or an odd byte address?
> >>
> >
> >
> > In this case the word address is the same as the byte address.  One byte = 16
> > bits, i.e.
> > octets are not addressable.
> >
> > So if you read a long (two words) from address 0x1000, the DSP grabs the MSW from
> > 0x1000,
> > and the LSW from 0x1001.  If you read a long from address 0x2001, the DSP grabs
> > the MSW from
> > 0x2001, and the LSW from 0x2000.
> >
> > So in addition to ensuring that the data read by GDB for a long is aligned, I need
> > to swap words
> > if the original address wasn't aligned.
>
> (I'm trying to avoid using the word byte it is dangerous :-)

Yeah, octets and smallest addressable unit (technical definition of byte) are not the
same thing.

>
>
> So the architecture is really this hybrid 8bit/16bit thing where low
> bits of the address are used to imply an interpretation of the data.  Ulgh.

I doubt they thought that far.  They probably just made it easy to make the data
transfer
units always interpret the first word the same, and the addressing logic was easier to
make the second word
go back one address instead of forward one (just toggle the lo bit of the address to
get the second word).

>
>
> Can this be represented as another hybrid integer type - two 16 bit
> words unpacked in a very strange way?

That's certainly a possibility, maybe an xlong/xfloat (following TI's assembly notation
for indicating a long/float need not be aligned).  I'll have to look into that...

>
>
> The other (I'm not so sure about) possability is, since GDB must read in
> 16bit chunks, modify it to mimic the hardware and 8bit swap things on
> the way in/out.

Except that the swapping is only done on long value accesses (double-word access, as it
were).  If you otherwise sequentially read data, there is no swapping.

>
>
> On this, what will happen with an 8bit character.  Won't GDB need to
> read/modify/write such a value?
>
>         Andrew

Ain't got none of those on this target.  Characters are 16 bits.  I'm going to finally
ditch those sections that refuse TARGET_CHAR_BIT != 8.

For the most part, I'm leaving lengths as octet lengths and adjusting them to target
lengths if necessary at the last possible instant.  My remote server/stub will answer
1-octet requests with the LS octet of the character addressed, though this is not a
recommended request, nor are 1-octet write requests.

Thanks for the tips.

T.


  reply	other threads:[~2001-12-05 18:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-04  5:44 Timothy Wall
2001-12-05  8:26 ` Andrew Cagney
2001-12-05  8:46   ` Richard Earnshaw
2001-12-05 10:11     ` Lars Brinkhoff
2001-12-05 10:42     ` Andrew Cagney
2001-12-06  2:03       ` Richard Earnshaw
2001-12-05  9:31   ` Timothy Wall
2001-12-05 10:03     ` Andrew Cagney
2001-12-05 10:20       ` Timothy Wall [this message]
2001-12-05 10:49         ` Andrew Cagney

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=3C0E6556.A5F9D5D6@oculustech.com \
    --to=twall@oculustech.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.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