Clarification on what a byte is in -data-*-memory-bytes ?

Clarification on what a byte is in -data-*-memory-bytes ?

[Andreas From]

Hi,

We're developing support for a target architecture where the smallest
addressable data type is 16-bit, i.e. the char type size is 16 bits, and 
we have

sizeof(char) = 1
sizeof(int)  = 1

The memory addresses are aligned on 16-bit boundaries and the second
octet of the contents of that memory is not addressable in itself.


In the -data-read-memory-bytes, we get a bit confused.  The "byte" is on 
our target system 16-bits, and we would like to clarify what a "byte" 
really should mean.

The COUNT and OFFSET are said to be in bytes, but does that mean that we 
would read in target bytes or in host bytes (i.e. octets) ?


Reading the old posts related to the introduction of the
-data-read-memory-bytes which this thread from June-Aug 2010

https://sourceware.org/ml/gdb-patches/2010-06/msg00571.html
https://sourceware.org/ml/gdb-patches/2010-07/msg00114.html
https://sourceware.org/ml/gdb-patches/2010-08/msg00140.html

it seems like the byte is an octet.


Also, offset and count interpreted as octets might raise questions on 
introducing a read-modify-write scheme for the first and last bytes when 
issuing the -data-write-memory-bytes command.

BR,
Andreas

Re: Clarification on what a byte is in -data-*-memory-bytes ?

[Andreas From]

(NOTE: I didn't see this previous mail reaching the GDB mailing list. 
Has there been some problem lately with lost messages or can there be 
some delay before mails hit the archives for some reason?)

On 14-01-31 07:35 PM, John Gilmore wrote:
>> We're developing support for a target architecture where the smallest
>> addressable data type is 16-bit, i.e. the char type size is 16 bits...
>
> I don't think GDB has ever been ported to a machine without 8-bit bytes.
> So some generalization would probably need to be added at the heart of GDB.
> This is not for the faint of heart.  It is complicated by the likelihood
> that you are cross-debugging (a machine with 16-bit addresses probably
> can't run GDB natively), so you'll be dealing with two byte sizes,
> the target's and the host's.
>
We have ported GDB to this architecture, and you're right, the target 
cannot run GDB natively and it needs a stub of its own. The separation 
into host bytes and target bytes internally on client side might not be 
trivial, but we have most things working related to such 16-bit issues.

> Is this a DSP?  Why did someone build a processor without byte
> addressing?  If you are intent on using an unusual processor, you
> might not get much leverage from our free tools; you might have to
> write your own tools from scratch.  Good luck!
>
Yes, the processing is on a multicore/DSP architecture. I don't know the 
history of the architecture that well to know the reasoning behind going 
for 16-bit. We are one of the very few along with some off the shelf 
commercial DSPs / architectures out there using something else than 
8-bit, e.g. TI's C54x family and OnSemi's Belasigna 250 (24-bit audio 
DSPs) and even the unlikely DCPU-16 (virtual HW for the computer 
terminals inside the Mojang game 0x10c that won't ever be released?!).

> 	John Gilmore
>
> PS: There are some free emulators that can deal with strange byte
> sizes and addressing (such as in emulating ancient computers).  See,
> for example, http://ibm1130.org/sim which emulates a machine with
> 16-bit addressing of 16-bit words.  See also:
> http://simh.trailing-edge.com/ I don't know of cross-debuggers for the
> code that runs inside these simulators, but maybe they exist.
>