[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-debug-dev] Forcing edits to write in variable views
|
Title: Message
Hi
John,
What kind of
practical problems are you anticipating?
I can see there
maybe being a memory bloat problem if every register were given a fresh instance
of an IElementEditor, but I don't see any reason why all instances of my
register class can't share the same instance of the IElementEditor. I imagine
that's how the platform provides the default IElementEditor for registers
already.
What am I
missing?
Aside: Actually, AMI is one of those oddball
companies that isn't using the CDT. Until recently, assembly has been the only
language option for programming our chips and CDT didn't offer the kind of
assembly-level support that we needed at the time that we were making our
decision.
-Ken
Is it practical to do this on a per-register basis?
My guess is it isn't and that what we're really looking at is having CDT
provide a custom ICellModifier that would be used across the
entire Registers view. (Ken, I believe you guys are using CDT in your
debugger, right?)
John
At 07:54 AM 5/9/2007, Darin Wright
wrote:
Hi Ken,
So yes - in this case you need to provide your own
IElementEditor adapter for your register that provides a custom
implementation of ICellModifier allowing unchanged variables to be written.
To minimize code duplication you could subclass the provisional/internal
classes VariableEditor and DefaultVariableCellModifier.
Darin
Ken_Dyck@xxxxxxxx
Sent by:
platform-debug-dev-bounces@xxxxxxxxxxx
05/09/2007 06:38 AM
Please respond to
"Eclipse Platform Debug
component developers list."
<platform-debug-dev@xxxxxxxxxxx>
To
platform-debug-dev@xxxxxxxxxxx
cc
Subject
RE:
[platform-debug-dev] Forcing edits to write in variable views
Hi Darin,
>So, why do you want to be invoked to save changes, if there are
no changes?
Some of the registers on our
processors contain "sticky bits". These bits stay on until they are set to
1. The common example is an interrupt status register. The processor sets a
bit in the status register when an interrupt occurs and the interrupt
handler clears it by writing a high bit to it. The easiest way to zero-out
all the sticky bits, then, is to write the same value to the register that's
already in it. Our users sometimes want to do this in their debugging
environment.
There are also peripheral
control registers that have side effects when written. When a value is
written to one of these registers, the peripheral performs an action. If a
user wants the peripheral to perform an action several times, she might need
to write the same value to its control register several times.
There are obvious performance advantages to
ignoring unchanged values. I agree that it's the best default behaviour. I'd
just like to override it for some special cases when that default doesn't
quite fit.
--Ken
-----Original Message-----
From:
platform-debug-dev-bounces@xxxxxxxxxxx [
mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of
Darin_Wright@xxxxxxxxxx
Sent: Tuesday, May 08, 2007 10:58
AM
To: Eclipse Platform Debug component developers
list.
Subject: Re: [platform-debug-dev] Forcing edits to write in
variable views
Hi Ken,
We intentionally avoid saving any changes to the target if there
are no changes in the variable value editor. It's more efficient - if you're
tabbing/keying through variable values, making no changes then there's no
need to have the back end do anything.
So, why
do you want to be invoked to save changes, if there are no changes?
Darin Wright
Ken_Dyck@xxxxxxxx
Sent by:
platform-debug-dev-bounces@xxxxxxxxxxx
05/07/2007 10:35 AM
Please respond to
"Eclipse Platform Debug
component developers list."
<platform-debug-dev@xxxxxxxxxxx>
To
platform-debug-dev@xxxxxxxxxxx
cc
Subject
[platform-debug-dev]
Forcing edits to write in variable views
Hi,
I'm trying to coax the register view to write edited
values to their
registers even if the values haven't changed.
It
seems to me that the natural place to do this would be in
my
implementation of IVariableValueEditor.saveVariable() (supplied via
the
org.eclipse.debug.ui.variableValueEditors extension point) except
that
it is only called from DefaultVariableCellModifier.modify() when
the
value has changed.
It looks like the next best alternative is
to supply an IEditorAdapter
adapter for my IRegister class, implementing
all the associated plumbing
that goes along with that (ICellModifier, and
maybe a CellEditor). I can
see this resulting in a lot of duplication of
what's already in the
platform. Yuck.
Questions:
1. Would
it make any sense to change
DefaultVariableCellModifier.modify() so that
it checks whether the value
has changed as part of the default behaviour
that happens _after_
IVariableValueEditor.saveVariable() returns
false?
2. If not, are there any simpler ways to force edits to write
than by
providing an IEditorAdapter? What are
they?
Regards,
Ken
_______________________________________
Ken
Dyck
Senior Member of Technical Staff
Software Tools Group
AMI
Semiconductor Canada Company
Tel: +1.519.884.9696 ext 2277
Fax:
+1.519.884.0228
Email address: ken_dyck@xxxxxxxx
Internet: http://www.amis.com
AMI
Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This
electronic message contains information that may be confidential or
privileged. The information is intended for the use of the individual or
entity named above. If you are not the intended recipient, please be aware
that any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you received this electronic message in error,
please notify the sender and delete the copy you
received.
_______________________________________________
platform-debug-dev
mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
AMI Semiconductor - "Silicon Solutions for the Real
World"
NOTICE:
This electronic message contains information that may
be confidential or privileged. The information is intended for the use of
the individual or entity named above. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or use of the
contents of this information is prohibited. If you received this electronic
message in error, please notify the sender and delete the copy you
received.
_______________________________________________
platform-debug-dev
mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev
mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE:
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.