Re: Fwd: Compiler Guided Refactoring.

>
> a flow-graph can be generated from source, and in your case from the
> generated assembly code.


Good idea... I already have a wee ruby script that extracts the call graph
/ symbol reference graph from the disassembler listing. (I use it for
thread graph coloring / race detection and/or as a guide decomposing .c
files that have grown way too big.)


On Wed, Jul 10, 2013 at 4:07 PM, J Arrizza <[email protected]> wrote:

> John, I may be beating a dead horse here, but I'm going to throw it out
> there anyway.
>
> I remember vaguely from a comp-sci course that a flow-graph can be
> generated from source, and in your case from the generated assembly code.
> Comparing the before and after flow-graphs would give you a true/false as
> to functional equivalence of a refactoring operation. But I'm pretty sure
> that flow-graphs do not include timing.
>
> So here's the pitch: extend the concept of a flow-graph to tally the timi=
ng
> on the branches of the graph. Then the before/after comparison would give
> you both functional and timing equivalence. Sounds like a pain, but it
> might make a nice master's thesis.
>
> Not sure what exactly this would bring to the table, but it would --
> potentially -- allow some refactorings to occur that a strict diff of the
> before/after executables would not. From a practical perspective, you'd
> have to trust the theory and also the utility that generates the
> flow-graphs, of course.
>
> Bottom line: Is it worth the effort? no idea....
>
> John
>
> On Mon, Jul 8, 2013 at 3:54 PM, J Arrizza <[email protected]> wrote:
>
> > On Mon, Jul 8, 2013 at 3:02 PM, John Carter <[email protected]
> >wrote:
> >
> >> **
> >>
> >>
> >> > The key aspect to the Extract Method with no arguments and void retu=
rn
> >> > value (i.e. void-void extraction) is that it minimizes the risk of
> >> > introducing side-effects.
> >>
> >> That is what appeals to me most about it....
> >>
> >> However, it is steps a largish notch away from the idea... ie. Tweakin=
g
> >> the Declarations to Tighten the constraints enforced by the compiler.
> >>
> >> I see, so the code is that critical... You're looking for absolutely n=
o
> > change in the generated executable but still refactorings on the source=
.
> >
> >> ie. Your void-void is low risk, provided the person doing the
> refactoring
> >> doesn't,,,
> >> * accidentally reorder something,
> >> * drop a step,
> >> * or extract copypasta into a single method that isn't copypasta but
> >> copypasta and tiny easily missed tweak.
> >>
> >> :) copy and pasta, had it for supper last night.
> >
> > I wonder if there is any way of doing a reliable cross check, or a
> variant
> >> of this, or a way of injecting additional steps to increase safety.
> >>
> >> So clearly UTs are not available. What about Pair Programming? Or code
> > review after a small set of changes?
> > On the other hand, if the code is as critical as it seems to be, even
> > those won't guarantee no changes in the executable.
> >
> > Hmm. It might need an additional check, gcc will always inline somethin=
g
> >> like that so could diff the disassembly output.
> >>
> > Sure, it could be used in lieu of UTs:
> > - If the disassembly output matches, then all is well.
> > - If they don't match, then a quick review of the disassembly output an=
d
> > the source to see why the mismatch. A mismatch might still be acceptabl=
e,
> > right??
> >
> > On the bright side... you might find a compiler bug.
> >
> >
> >> On Sun, Jul 7, 2013 at 5:31 AM, J Arrizza <[email protected]> wrote:
> >>
> >> > The key aspect to the Extract Method with no arguments and void retu=
rn
> >> > value (i.e. void-void extraction) is that it minimizes the risk of
> >> > introducing side-effects.
> >> >
> >> > The conversion of the function parameters to consts is slightly
> >> different,
> >> > its purpose is to highlight the fact that the function won't
> introduce a
> >> > side-effect via those parameters.
> >>
> >> >
> >> > Further to this, one additional refactoring I've used is Rename
> >> Variable to
> >> > add a "g" prefix to all global variables. I personally don't like
> >> hungarian
> >> > notation but adding the "g" is a very useful exception to this rule.
> All
> >> > the globals show up clearly in the code.
> >> >
> >> > One other way to achieve this is to put all globals into a single
> struct
> >> > called "globals". Then all uses show up as "globals.some_variable"
> which
> >> > makes it very clear that there is a global side-effect in that part =
of
> >> the
> >> > code. But note the compiler may generate more code for this techniqu=
e.
> >> >
> >> > John
> >>
> >> >
> >> >
> >> >
> >> > On Thu, Jul 4, 2013 at 3:28 PM, J Arrizza <[email protected]> wrote=
:
> >> >
> >> > > On Thu, Jul 4, 2013 at 7:27 AM, Richard <[email protected]>
> >> wrote:
> >> > >
> >> > >> **
> >> > >>
> >> > >> n article <
> >> > >> CAEyOLyBfwH6uD6Z5RxBmmne4NA90cpF6N6LGacJPmRTSz7Enyg@mail.gmail.co=
m
> >,
> >>
> >> > >> J Arrizza <[email protected]> writes:
> >> > >>
> >> > >> > is. IMO the biggest bang for buck is the void-void extraction.
> >> > >>
> >> > >> This is Extract Method/Extract Function with no arguments
> >> > >>
> >> > > ... and void return value.
> >> > >
> >> > >> > The next best is the void-const extraction.
> >> > >>
> >> > >
> >> > >> This is Extract Method/Extract Function with arguments
> >> > >>
> >> > > ... and void return value and all the arguments are const.
> >> > >
> >> > >>
> >> > >> I think it's important to use the established names for well know=
n
> >> > >> refactorings for clear communication.
> >> > >>
> >> > > Absolutely.
> >> > >
> >> > >>
> >> > >>
> >> > >>
> >> > >> Start a New Topic<
> >> >
> >>
> http://groups.yahoo.com/group/refactoring/post;_ylc=3DX3oDMTJlazgzdWgyBF9=
TAzk3MzU5NzE0BGdycElkAzM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwNmdHIEc2xrA2=
50cGMEc3RpbWUDMTM3Mjk0ODA2Ng--
> >> >
> >> > Messages
> >> > >> in this topic<
> >> >
> >>
> http://groups.yahoo.com/group/refactoring/message/10661;_ylc=3DX3oDMTM2dT=
Y1ZDY3BF9TAzk3MzU5NzE0BGdycElkAzM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BG1zZ0lkA=
zEwNjY0BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTM3Mjk0ODA2NgR0cGNJZAMxMDY2MQ--
> >> > >(4)
> >> > >> Recent Activity:
> >> > >>
> >> > >>
> >> > >> Visit Your Group<
> >> >
> >>
> http://groups.yahoo.com/group/refactoring;_ylc=3DX3oDMTJlOW1ucG5jBF9TAzk3=
MzU5NzE0BGdycElkAzM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwN2dGwEc2xrA3ZnaHA=
Ec3RpbWUDMTM3Mjk0ODA2Ng--
> >> > >
> >> > >> [image: Yahoo! Groups]<
> >> >
> >>
> http://groups.yahoo.com/;_ylc=3DX3oDMTJkbWt0N2dqBF9TAzk3MzU5NzE0BGdycElkA=
zM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMzcyOTQ4=
MDY2
> >> > >
> >> > >> Switch to: Text-Only<
> >> > [email protected]
> >> ?subject=3DChange+Delivery+Format:+Traditional
> >> > >,
> >> > >> Daily Digest<
> >> > [email protected]?subject=3DEmail+Delivery:+Digest>=
=E2=80=A2
> >> > >> Unsubscribe <
> >> > [email protected]?subject=3DUnsubscribe>=E2=80=
=A2 Terms
> >> > >> of Use <http://docs.yahoo.com/info/terms/> =E2=80=A2 Send us Feed=
back
> >> > >> <
> >> > [email protected]
> >> ?subject=3DFeedback+on+the+redesigned+individual+mail+v1
> >> > >
> >> > >> .
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> >
> >> >
> >> > [Non-text portions of this message have been removed]
> >> >
> >> >
> >> >
> >> > ------------------------------------
> >> >
> >> > Yahoo! Groups Links
> >> >
> >> >
> >> >
> >> >
> >>
> >> --
> >> John Carter Phone : (64)(3) 358 6639
> >> Tait Electronics Fax : (64)(3) 359 4632
> >> PO Box 1645 Christchurch Email : [email protected]
> >> New Zealand
> >>
> >> --
> >>
> >> ------------------------------
> >> This email, including any attachments, is only for the intended
> >> recipient.
> >> It is subject to copyright, is confidential and may be the subject of
> >> legal
> >> or other privilege, none of which is waived or lost by reason of this
> >> transmission.
> >> If you are not an intended recipient, you may not use, disseminate,
> >> distribute or reproduce such email, any attachments, or any part
> thereof.
> >> If you have received a message in error, please notify the sender
> >> immediately and erase all copies of the message and any attachments.
> >> Unfortunately, we cannot warrant that the email has not been altered o=
r
> >> corrupted during transmission nor can we guarantee that any email or a=
ny
> >> attachments are free from computer viruses or other conditions which m=
ay
> >> damage or interfere with recipient data, hardware or software. The
> >> recipient relies upon its own procedures and assumes all risk of use a=
nd
> >> of
> >> opening any attachments.
> >> ------------------------------
> >>
> >>
> >> [Non-text portions of this message have been removed]
> >>
> >>
> >>
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--=20
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                       Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch       Email : [email protected]
New Zealand

--=20

------------------------------
This email, including any attachments, is only for the intended recipient.=
=20
It is subject to copyright, is confidential and may be the subject of legal=
=20
or other privilege, none of which is waived or lost by reason of this=20
transmission.
If you are not an intended recipient, you may not use, disseminate,=20
distribute or reproduce such email, any attachments, or any part thereof.=20
If you have received a message in error, please notify the sender=20
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or=20
corrupted during transmission nor can we guarantee that any email or any=20
attachments are free from computer viruses or other conditions which may=20
damage or interfere with recipient data, hardware or software. The=20
recipient relies upon its own procedures and assumes all risk of use and of=
=20
opening any attachments.
------------------------------


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected]=20
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/