[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] word addressed memory?
|
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.
