This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: packing/unpacking 4-octet longs


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]