| MemoryBlock.longToBytes() has a silly behaviour [message #168328] |
Tue, 18 April 2006 11:13  |
Eclipse User |
|
|
|
While attempting to handle the output of memory reads, I found some
difficulties in rendering some non-standard memory sizes.
What I actually need, is to display the content of the memory in the
memory view, but I expect to view the memory not as a char but as a memory
word in 24 bits.
In other words, the -data-read-memory MI command will return "0x345678" at
adress 0x2000, "0x345678" at adress 0x2001 and so on...
At a first glance, I was convinced that the standard "Hex" memory
rendering was not able to cope with those strange memory formats, but I've
found something quite interesting in the CDT source:
In order to render the memory values, the MemoryBlock.longToBytes(long v)
method attempts to split a long value into bytes with such a cycle (for
big endian values, a similar one exists for little endian):
for (int i = 0; i < count; ++i) {
int shift = (count - i - 1) * count;
bytes[i] = (byte)((v >>> shift) & 0xFF);
}
where "count" is the number of bytes you actually need to fit the input
(long v).
as you may see, when count is three, that cycle firstly shifts by six
bits, and then by three!
I changed
int shift = (count - i - 1) * count;
into:
int shift = i * 8;
and now everything seems to work fine.
It's quite tricky, because, as long as your memory's bytesize is 1,
you'll never notice any fault (because of no shifts!).
Has anyone already run into such a problem?
Regards,
Giuseppe
|
|
|
| Re: MemoryBlock.longToBytes() has a silly behaviour [message #168352 is a reply to message #168328] |
Wed, 19 April 2006 02:04  |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
Please, submit a bug in Bugzilla.
"Giuseppe Montalto" <giuseppe.montalto@st.com> wrote in message
news:f0d99590dd6874d312ccc79dbca8e0ab$1@www.eclipse.org...
> While attempting to handle the output of memory reads, I found some
> difficulties in rendering some non-standard memory sizes.
>
> What I actually need, is to display the content of the memory in the
> memory view, but I expect to view the memory not as a char but as a memory
> word in 24 bits.
> In other words, the -data-read-memory MI command will return "0x345678" at
> adress 0x2000, "0x345678" at adress 0x2001 and so on...
>
> At a first glance, I was convinced that the standard "Hex" memory
> rendering was not able to cope with those strange memory formats, but I've
> found something quite interesting in the CDT source:
>
> In order to render the memory values, the MemoryBlock.longToBytes(long v)
> method attempts to split a long value into bytes with such a cycle (for
> big endian values, a similar one exists for little endian):
>
> for (int i = 0; i < count; ++i) {
> int shift = (count - i - 1) * count;
> bytes[i] = (byte)((v >>> shift) & 0xFF);
> }
>
> where "count" is the number of bytes you actually need to fit the input
> (long v).
>
> as you may see, when count is three, that cycle firstly shifts by six
> bits, and then by three!
>
> I changed int shift = (count - i - 1) * count;
> into:
> int shift = i * 8;
>
> and now everything seems to work fine.
> It's quite tricky, because, as long as your memory's bytesize is 1,
> you'll never notice any fault (because of no shifts!).
> Has anyone already run into such a problem?
>
> Regards,
> Giuseppe
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04203 seconds
Home