Hi Michael,
Yes, I agree. This does look like the best approach.
As the first step, I have added declarations for AddressableUnitSize
and DefaultWordSize properties in the Memory service context.
Changing the Memory view is a bit complicated - that code is not part
of TCF project. I'll look into it. Suggestions are welcome.
Thanks,
Eugene
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Michael.Rentschler@xxxxxxxxxxxxx
Sent: Wednesday, February 11, 2015 8:24 AM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] word addressed memory?
Hi Eugene,
I would suggest to support any size of "smallest addressable memory
units", at least any value that is a power of 2 (e.g. 1, 2, 4, 8, 16,
...).
We can put this value inside the properties of a memory context to
stay backward compatible, or extend the MemoryContext interface
by an additional getter method, e.g. "getAddressableUnitSize". If this
information is not available, we can default to a unit size of 1 byte,
as it is today. I would also like to add some property like
"getDefaultWordSize" to be used as the default memory view word
representation.
It would be the best to keep all other methods as is (using
Byte-addressing) and just use the unit size for rendering purposes.
Of course, the TCF back-end has to translate the addresses then. But I
think this can be accepted for some exotic targets.
The client (e.g. the memory view) should only access multiples of the
unit size and the Byte-address must be aligned to this unit size, when
calling set/get/fill operations on a memory. This must be done, since
the back-end may return different results if it has to read a memory
unit multiple times.
Multiple address spaces should be already supported by the service.
The service is able to provide multiple children where each has its
own
context, name and properties. We only have to extend the TCF Memory
View in Eclipse to show the different memories and let us
switch between each other.
Regards,
Michael
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eugene Tarassov
Sent: Dienstag, 10. Februar 2015 18:35
To: TCF Development
Subject: Re: [tcf-dev] word addressed memory?
Hi Michael,
We can start adding support for word addresses.
I would need a target that can be used to validate such changes.
Perhaps, a TCF back-end that simulates exotic memory architecture.
I wonder if something like that is already available in open source.
Or, could you publish some code that can used for that?
Regards,
Eugene
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Michael.Rentschler@xxxxxxxxxxxxx
Sent: Tuesday, February 10, 2015 2:54 AM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] word addressed memory?
Hi Conny, Eugene,
we have the same issue with our targets. Some of the memories are
Word- or even Quad-Word-addressed. Our solution was to translate
addresses and sizes to Byte-wise values. This works very well, but may
confuse the users a bit. The users need to calculate the Byte-address
on their own if they need to look up a given Word-address from the
targets datasheet.
Another problem we faced is the missing support for multiple address
spaces inside the memory view. We run a Harvard Architecture
(different code and data address space) and our targets provide
peripheral buffers that must also be viewable through the memory view.
We came across this limitation by mapping the memories to a single
address space. An index inside the upper address bits let the users
differentiate between the memories. Works, but is not very nice.
Is there a global interest in extending the TCF memory service and the
TCF memory view plugin to support non-conform memory structures on
targets?
Regards,
Michael
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eugene Tarassov
Sent: Montag, 9. Februar 2015 19:31
To: TCF Development
Subject: Re: [tcf-dev] word addressed memory?
Hi Conny,
If you are OK with presenting byte addresses and sizes to the user, it
should be relatively easy to do the translation in your implementation
of context.h in the agent. However, you will also need to do the
translation in the symbol reader. That part looks a bit more
challenging. Good thing is such approach should not require any
changes in the Eclipse plugins.
Regards,
Eugene
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Konrad Anheim
Sent: Monday, February 09, 2015 1:52 AM
To: Tcf Dev
Subject: [tcf-dev] word addressed memory?
Hi,
The specific CPU core (for which I using TCF) supports only word
addressing (16 bits) of memory, not byte addressing as "regular" CPUs.
I understand that this is not supported out of the box in TCF, however
I would like to get your advice what would need to be changed (in the
agent and Eclipse) to make this work. Since all the infrastructure is
byte based, I believe that I might go away with some smart word
address to byte address and vice versa translations.
My specific questions are:
*) Where should I put such address translations in the code? Are there
any hooks already available?
*) The Eclipse memory view would need to be configured or replaced at
all? What is the best way doing this?
To make things even worse, I'm not permitted to patch any existing
Eclipse/CDT plugins (agent is free to modify), however any code on top
of the existing plugins is OK.
Cheers,
Conny
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you
are not the intended recipient, do not read, copy, or forward this
email message or any attachments. Delete this email message and any
attachments immediately.
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you
are not the intended recipient, do not read, copy, or forward this
email message or any attachments. Delete this email message and any
attachments immediately.
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you
are not the intended recipient, do not read, copy, or forward this
email message or any attachments. Delete this email message and any
attachments immediately.
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev
