GOTO in Javascript

Discussion in 'Javascript' started by David Given, Jul 7, 2008.

  1. David Given

    David Given Guest

    I have a situation where I need to use GOTO in a Javascript program.

    No, I can't use break or continue. Yes, I really do know what I'm doing.
    What I've got is a huge mass of automatically generated code that
    contains thousands of clauses like this:

    label1:
    ...do something...
    if (condition)
    goto label3;
    else
    goto label9;

    This situation is exactly what GOTO is the ideal tool for. Except that
    Javascript doesn't have GOTO.

    One alternative is to use tail calls, so that each block would turn into
    a function like this:

    function label1()
    {
    ...do something...
    if (condition)
    return label3();
    else
    return label9();
    }

    Unfortunately, Javascript doesn't support tail calls either --- each
    function call adds another entry to the stack which means I only get a
    few thousand calls before everything grinds to a halt.

    The only other thing I can think of is to use a switch statement like this:

    while (true)
    {
    switch (label)
    {
    case 1:
    ...do something...
    if (condition)
    label = 3;
    else
    label = 9;
    break;
    }
    }

    However this is going to do horrible things to my performance due to
    having to keep reading and writing the label variable; also, I'm very
    dubious has to how well Javascript switch statements perform with very
    big numbers of entries (thousands, remember).

    Can anyone suggest anything else I could try?

    --
    ┌─── dg@cï½ï½—lï½ï½’k.cï½ï½ ───── http://www.cowlark.com ─────
    │ "I have always wished for my computer to be as easy to use as my
    │ telephone; my wish has come true because I can no longer figure out
    │ how to use my telephone." --- Bjarne Stroustrup
    David Given, Jul 7, 2008
    #1
    1. Advertising

  2. David Given <> writes:

    > I have a situation where I need to use GOTO in a Javascript program.


    [ ... ]

    > Unfortunately, Javascript doesn't support tail calls either --- each
    > function call adds another entry to the stack which means I only get a
    > few thousand calls before everything grinds to a halt.


    So, you're calling recursively? If not, there are plenty fairly simple
    solutions.

    > The only other thing I can think of is to use a switch statement like this:
    >
    > while (true)
    > {
    > switch (label)
    > {
    > case 1:
    > ...do something...
    > if (condition)
    > label = 3;
    > else
    > label = 9;
    > break;
    > }
    > }


    Actually, this doesn't look too bad at all.

    > However this is going to do horrible things to my performance due to
    > having to keep reading and writing the label variable; also, I'm very
    > dubious has to how well Javascript switch statements perform with very
    > big numbers of entries (thousands, remember).


    You're only writing the label variable once per iteration, and
    probably not reading it much more than once either. I haven't tried
    it, but I would be completely astonished if a simple variable
    assignment + read is going to make any appreciable slowdown.

    Due to the way switch/case is defined in JS (it's defined in terms of
    !==), I would guess it would perform fairly well regardless of the
    number of cases. AFAICS it would be comparable to:

    var label;
    var myswitch = {
    something: function() {
    // stuff;
    label = "somethingelse";
    },
    somethingelse: function() {
    // stuff;
    label = "something";
    }
    };
    while (true) {
    myswitch[label]();
    }

    Which can be pretty well optimized in theory at least (you can cache
    the hash code for strings, and numbers can provide their own).

    > Can anyone suggest anything else I could try?


    I suggest you run a few benchmarks first and profile some stuff before
    you discount your current strategy. Also: firebug has a fairly useful
    profiler, so check that out too; maybe the performance issues you're
    seeing aren't really due to the switch statement.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
    Joost Diepenmaat, Jul 7, 2008
    #2
    1. Advertising

  3. David Given wrote:
    > I have a situation where I need to use GOTO in a Javascript program.
    >
    > No, I can't use break or continue. Yes, I really do know what I'm doing.

    ^^^^^^^^^^^^^^^^
    There is a "not" missing.

    > What I've got is a huge mass of automatically generated code that

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > contains thousands of clauses like this:
    >
    > label1:
    > ...do something...
    > if (condition)
    > goto label3;
    > else
    > goto label9;


    See?

    > This situation is exactly what GOTO is the ideal tool for. Except that
    > Javascript doesn't have GOTO.


    BASIC's GOTO nonsense stopped being implemented in higher-level programming
    language which provide better ways to implement program logic. You are
    well-advised to learn them.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Jul 7, 2008
    #3
  4. David Given

    David Given Guest

    Joost Diepenmaat wrote:
    [...]
    > You're only writing the label variable once per iteration, and
    > probably not reading it much more than once either. I haven't tried
    > it, but I would be completely astonished if a simple variable
    > assignment + read is going to make any appreciable slowdown.
    >
    > Due to the way switch/case is defined in JS (it's defined in terms of
    > !==), I would guess it would perform fairly well regardless of the
    > number of cases.


    Do Javascript switches on simple integers turn into jump tables? I'd
    really rather not have to to do a dictionary lookup on each state
    change. In particular, given that most Javascript interpreters implement
    variables as entries in a scope-specific dictionary, this means we're
    theoretically getting *three* dictionary lookups per state change. I
    realise that modern interpreters will optimise at least some of this,
    but given the operation I'm trying to do is so utterly basic I still
    resent having to waste cycles.

    What I've got, you see, is a huge collection of states generated with
    code; control flow transfers from state to state arbitrarily and
    extremely frequently. Wasted cycles on state changes will directly
    impact performance in a very big way. Despite the goto-is-evil nonsense
    that you hear so much of (mostly from people who don't know what they're
    talking about), it really is the best tool for the job here...

    [...]
    > I suggest you run a few benchmarks first and profile some stuff before
    > you discount your current strategy. Also: firebug has a fairly useful
    > profiler, so check that out too; maybe the performance issues you're
    > seeing aren't really due to the switch statement.


    I'll admit that I haven't actually tried running code yet --- this is
    still speculative before I start work on the code generator (which is
    currently designed to emit code for a language that actually does have a
    GOTO).

    --
    ┌─── dg@cï½ï½—lï½ï½’k.cï½ï½ ───── http://www.cowlark.com ─────
    │ "I have always wished for my computer to be as easy to use as my
    │ telephone; my wish has come true because I can no longer figure out
    │ how to use my telephone." --- Bjarne Stroustrup
    David Given, Jul 7, 2008
    #4
  5. David Given wrote:
    > Joost Diepenmaat wrote:
    > [...]
    >> You're only writing the label variable once per iteration, and
    >> probably not reading it much more than once either. I haven't tried
    >> it, but I would be completely astonished if a simple variable
    >> assignment + read is going to make any appreciable slowdown.
    >>
    >> Due to the way switch/case is defined in JS (it's defined in terms of
    >> !==), I would guess it would perform fairly well regardless of the
    >> number of cases.

    >
    > Do Javascript switches on simple integers turn into jump tables?


    I beg your pardon?

    > I'd really rather not have to to do a dictionary lookup on each state
    > change. In particular, given that most Javascript interpreters implement
    > variables as entries in a scope-specific dictionary, this means we're
    > theoretically getting *three* dictionary lookups per state change.


    No, it does not. Expressions are evaluated first.

    > I realise that modern interpreters will optimise at least some of this,
    > but given the operation I'm trying to do is so utterly basic I still
    > resent having to waste cycles.


    ISTM you don't know what you are talking about. To begin with, you are
    repeating the usual half-wit nonsense about a single programming language
    where there are in fact several different implementations of ECMAScript,
    of which only one you could really know all this about.

    > What I've got, you see, is a huge collection of states generated with
    > code; control flow transfers from state to state arbitrarily and
    > extremely frequently. Wasted cycles on state changes will directly
    > impact performance in a very big way. Despite the goto-is-evil nonsense
    > that you hear so much of (mostly from people who don't know what they're
    > talking about), it really is the best tool for the job here...


    Yeah, well, see above.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Jul 8, 2008
    #5
  6. David Given <> writes:

    > Do Javascript switches on simple integers turn into jump tables? I'd
    > really rather not have to to do a dictionary lookup on each state
    > change.


    The difference between a jump table and a dictionary lookup isn't (or
    shouldn't be) all that large, especially given that everything else in
    JS is pretty slow anyway.

    > In particular, given that most Javascript interpreters implement
    > variables as entries in a scope-specific dictionary, this means we're
    > theoretically getting *three* dictionary lookups per state change.


    Not if the state variable is in the top-most scope. Which it will be
    in this case. Scopes chains are (probably) simple stacks.

    All this depends on the implementation of course.

    > I realise that modern interpreters will optimise at least some of
    > this, but given the operation I'm trying to do is so utterly basic I
    > still resent having to waste cycles.


    How much it matters is completely dependent on how much work you're
    doing in between state changes. If the work being done is trivial,
    then you may have to rethink your strategy.

    > What I've got, you see, is a huge collection of states generated with
    > code; control flow transfers from state to state arbitrarily and
    > extremely frequently. Wasted cycles on state changes will directly
    > impact performance in a very big way. Despite the goto-is-evil nonsense
    > that you hear so much of (mostly from people who don't know what they're
    > talking about), it really is the best tool for the job here...


    But maybe javascript isn't. :) Or maybe try to reduce the number of
    state changes, IOW *increase* the number of states - while you're
    generating code anyway.

    > [...]
    >> I suggest you run a few benchmarks first and profile some stuff before
    >> you discount your current strategy. Also: firebug has a fairly useful
    >> profiler, so check that out too; maybe the performance issues you're
    >> seeing aren't really due to the switch statement.

    >
    > I'll admit that I haven't actually tried running code yet --- this is
    > still speculative before I start work on the code generator (which is
    > currently designed to emit code for a language that actually does have a
    > GOTO).


    Well, since you're automatically generating code, it shouldn't be too
    hard to test a few different constructs at least.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
    Joost Diepenmaat, Jul 8, 2008
    #6
  7. David Given

    David Given Guest

    Joost Diepenmaat wrote:
    [...]
    >> In particular, given that most Javascript interpreters implement
    >> variables as entries in a scope-specific dictionary, this means we're
    >> theoretically getting *three* dictionary lookups per state change.

    >
    > Not if the state variable is in the top-most scope. Which it will be
    > in this case. Scopes chains are (probably) simple stacks.


    Ah, good, that'll save a fair bit of time. (The entire state machine
    will live in a single large function --- although I will have multiple
    state machines in different functions, they're all independent).

    > All this depends on the implementation of course.


    Indeed.

    [...]
    > How much it matters is completely dependent on how much work you're
    > doing in between state changes. If the work being done is trivial,
    > then you may have to rethink your strategy.


    Unfortunately the work *is* like to be trivial. Alas, what work is done
    and what states that are being emitted depend very much on the input
    material to the code generator, which I don't have any control over.

    [...]
    > Well, since you're automatically generating code, it shouldn't be too
    > hard to test a few different constructs at least.


    Indeed. I'll give the switch method a try and see how that works out. As
    you say, Javascript is fundamentally slow anyway...

    --
    ┌─── dg@cï½ï½—lï½ï½’k.cï½ï½ ───── http://www.cowlark.com ─────
    │ "I have always wished for my computer to be as easy to use as my
    │ telephone; my wish has come true because I can no longer figure out
    │ how to use my telephone." --- Bjarne Stroustrup
    David Given, Jul 8, 2008
    #7
  8. Thomas 'PointedEars' Lahn wrote:
    > David Given wrote:
    >> I realise that modern interpreters will optimise at least some of this,
    >> but given the operation I'm trying to do is so utterly basic I still
    >> resent having to waste cycles.

    >
    > ISTM you don't know what you are talking about. To begin with, you are
    > repeating the usual half-wit nonsense about a single programming language
    > where there are in fact several different implementations of ECMAScript,
    > of which only one you could really know all this about.


    Rather three, KJS has always been and Apple JavaScriptCore went open source,
    too. (Did I forget another one?)


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Jul 8, 2008
    #8
  9. David Given

    Tom de Neef Guest

    "David Given" <> schreef in bericht
    news:48729189$0$78075$...
    >I have a situation where I need to use GOTO in a Javascript program.
    >
    > No, I can't use break or continue. Yes, I really do know what I'm doing.
    > What I've got is a huge mass of automatically generated code that
    > contains thousands of clauses like this:
    >
    > label1:
    > ...do something...
    > if (condition)
    > goto label3;
    > else
    > goto label9;
    >


    Could you implement these code parts as functions and assign them to array
    elements?
    eg:

    var codeparts = []
    codeparts[1] = function ()
    { ...do something...
    if (condition) return 3 else return 9
    }

    codeparts[2] = function ()
    { ...do something...
    if (condition) return 7 else return 11
    }

    etc..

    var state = 1
    while (state) { state = codeparts[state] }

    Tom
    Tom de Neef, Jul 8, 2008
    #9
  10. David Given

    The Magpie Guest

    David Given wrote:
    > I have a situation where I need to use GOTO in a Javascript program.
    >

    I have been a professional programmer and analyst for more than thrity
    years. So far, I have never yet found a single case where I *had* to
    use a "goto". There are always alternatives.
    The Magpie, Jul 8, 2008
    #10
  11. David Given

    RoLo Guest

    On Jul 7, 5:58 pm, David Given <> wrote:
    > I have a situation where I need to use GOTO in a Javascript program.
    >
    > No, I can't use break or continue. Yes, I really do know what I'm doing.
    > What I've got is a huge mass of automatically generated code that
    > contains thousands of clauses like this:
    >
    > label1:
    > ...do something...
    > if (condition)
    > goto label3;
    > else
    > goto label9;
    >
    > This situation is exactly what GOTO is the ideal tool for. Except that
    > Javascript doesn't have GOTO.
    >
    > One alternative is to use tail calls, so that each block would turn into
    > a function like this:
    >
    > function label1()
    > {
    > ...do something...
    > if (condition)
    > return label3();
    > else
    > return label9();
    >
    > }
    >
    > Unfortunately, Javascript doesn't support tail calls either --- each
    > function call adds another entry to the stack which means I only get a
    > few thousand calls before everything grinds to a halt.
    >
    > The only other thing I can think of is to use a switch statement like this:
    >
    > while (true)
    > {
    > switch (label)
    > {
    > case 1:
    > ...do something...
    > if (condition)
    > label = 3;
    > else
    > label = 9;
    > break;
    > }
    >
    > }
    >
    > However this is going to do horrible things to my performance due to
    > having to keep reading and writing the label variable; also, I'm very
    > dubious has to how well Javascript switch statements perform with very
    > big numbers of entries (thousands, remember).
    >
    > Can anyone suggest anything else I could try?
    >
    > --
    > $B(#(!(!(!(B $B#d#g!w#c#o#w#l#a#r#k!%#c#o#m(B $B(!(!(!(!(!(Bhttp://www.cowlark.com$B(!(!(!(!(!(B
    > $B("(B "I have always wished for my computer to be as easy to use as my
    > $B("(B telephone; my wish has come true because I can no longer figure out
    > $B("(B how to use my telephone." --- Bjarne Stroustrup


    templates in javascript.
    RoLo, Jul 8, 2008
    #11
  12. David Given

    Evertjan. Guest

    The Magpie wrote on 08 jul 2008 in comp.lang.javascript:

    > David Given wrote:
    >> I have a situation where I need to use GOTO in a Javascript program.
    >>

    > I have been a professional programmer and analyst for more than thrity
    > years. So far, I have never yet found a single case where I *had* to
    > use a "goto". There are always alternatives.


    I am programming for 40 years now and remember it came as a blow to me when
    Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
    in Byte [1968] declared "goto" in Basic the worst word in programming,
    because it made thinking modular impossible.

    The word "modular" was not part of his typewritten accusation, but I am
    sure he mant that. I did not understand modular programming then, and even
    now I do not use all it's benefits, I suppose.

    A Case against the GO TO Statement typewritten original
    <http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF>
    html transcript:
    <http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html>

    Edsger Wybe Dijkstra
    <http://en.wikipedia.org/wiki/Edsger_Dijkstra>

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Jul 8, 2008
    #12
  13. David Given

    Tom de Neef Guest

    "Tom de Neef" <> wrote

    <snip>
    >
    > var state = 1
    > while (state) { state = codeparts[state] }
    >

    should be
    while (state) { state = codeparts[state]() }

    Tom
    Tom de Neef, Jul 9, 2008
    #13
  14. Evertjan. wrote:

    > The Magpie wrote on 08 jul 2008 in comp.lang.javascript:
    >> I have been a professional programmer and analyst for more than thrity
    >> years. So far, I have never yet found a single case where I *had* to
    >> use a "goto". There are always alternatives.

    >
    > I am programming for 40 years now and remember it came as a blow to me when
    > Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
    > in Byte [1968] declared "goto" in Basic the worst word in programming,
    > because it made thinking modular impossible.


    I can only present 10 years of professional experience, but I think
    this statement is too extreme. Modular thinking is still possible with
    GOTO; it all depends on the mindset of the programmer and the way he
    uses GOTO-commands. I also evolved from GOTO towards GOSUB (already
    the seeds for the later OO-approach), which allowed to make software
    programs much more complex, and still be able to maintain that
    complexity.

    And if you take into account the academic criteria to measure software
    quality[*], I think the benefits of OO are even clearer. On the other
    hand, I've always had the feeling that object oriented programming has
    never been able to fully realize what it had promised (IMHO the same
    for XML, javascript, XSL, ...). Procedurial code has its benefits too,
    and I think that this will not change.

    > The word "modular" was not part of his typewritten accusation, but I am
    > sure he mant that. I did not understand modular programming then, and even
    > now I do not use all it's benefits, I suppose.


    In my opinion, there is no such thing as fully modular programming.
    The core flow of any program is still procedurial, no matter to which
    extent object-oriented elements are present. IMHO every programming
    language can be put on a scale between procedurial and OO; it's not
    black or white, and, I think a lot depends of the programmer too.

    [*] "MATURE": Maintainable, Adaptable, Transparent, User-friendly,
    Reliable, Efficient.

    --
    Bart
    Bart Van der Donck, Jul 9, 2008
    #14
  15. Tom de Neef wrote:
    > "Tom de Neef" <> wrote
    > <snip>
    >> var state = 1
    >> while (state) { state = codeparts[state] }

    >
    > should be
    > while (state) { state = codeparts[state]() }


    TypeError: 9 is not a function.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Jul 9, 2008
    #15
  16. David Given

    Tom de Neef Guest

    "Thomas 'PointedEars' Lahn" <> wrote:
    >>> var state = 1
    >>> while (state) { state = codeparts[state] }

    >>
    >> should be
    >> while (state) { state = codeparts[state]() }

    >
    > TypeError: 9 is not a function.
    >
    >


    This seerms to work as intended:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <HTML><HEAD><TITLE>ArrayTest</TITLE>
    <script type="text/javascript">
    var codeparts = [];
    var arg = 1;
    codeparts[1] = function() {return (arg>3)?0:arg+1}
    codeparts[2] = function() {return 1+Math.floor(3*Math.random())}
    codeparts[3] = function() {return 3-Math.floor(4*Math.random())}

    function cycle()
    {
    var state = 1;
    while (state) { state = codeparts[state](); alert(state) }
    }
    </script>
    </head>
    <body onload=cycle()> </body>
    </html>

    Tom
    Tom de Neef, Jul 9, 2008
    #16
  17. Tom de Neef wrote:
    > "Thomas 'PointedEars' Lahn" <> wrote:
    >>>> var state = 1
    >>>> while (state) { state = codeparts[state] }
    >>> should be
    >>> while (state) { state = codeparts[state]() }

    >> TypeError: 9 is not a function.

    >
    > This seerms to work as intended: [...]


    It is not Valid markup, however I have misinterpreted your reusing `state'.

    I think it is evil[tm], although it works.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Jul 9, 2008
    #17
  18. David Given

    Evertjan. Guest

    Johannes Baagoe wrote on 09 jul 2008 in comp.lang.javascript:

    > Evertjan. :
    >
    >> I am programming for 40 years now and remember it came as a blow to me
    >> when Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
    >> in Byte [1968] declared "goto" in Basic the worst word in programming,
    >> because it made thinking modular impossible.

    >
    > Hardly in BASIC, since it is unlikely that Dijkstra even knew about
    > Kemeny's and Kurtz's experiments in 1968. FORTRAN and COBOL are more to
    > the point.
    >
    > And certainly not in BYTE, which started in 1975. Actually, Dijkstra's
    > article was published in the March 1968 Communications of the ACM.


    You should be right, memory serves me well, but was expensive at that time.

    Could it have been Scientific American,
    I remember expensive glossyness reading the 1968? article?

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Jul 9, 2008
    #18
  19. Johannes Baagoe wrote:
    > Evertjan. :
    >
    >> I am programming for 40 years now and remember it came as a blow to me
    >> when Edsger Wybe Dijkstra [1930-2002] in his famous or infamous article
    >> in Byte [1968] declared "goto" in Basic the worst word in programming,
    >> because it made thinking modular impossible.

    >
    > Hardly in BASIC, since it is unlikely that Dijkstra even knew about
    > Kemeny's and Kurtz's experiments in 1968. FORTRAN and COBOL are more to
    > the point.
    >
    > And certainly not in BYTE, which started in 1975. Actually, Dijkstra's
    > article was published in the March 1968 Communications of the ACM.


    And I was consciously avoiding GOTO in PL/I even before that. As soon as
    ALGOL introduced structured IF statements, the advantage was fairly obvious.

    I note, however, that the case under discussion is machine-generated
    code, and in this context, it should be noted that Ada includes GOTO
    with the specific justification that code generators might take
    advantage of it. (After all, machine code on every architecture I know
    of still uses Branch/Jump instructions.)
    --
    John W. Kennedy
    "There are those who argue that everything breaks even in this old
    dump of a world of ours. I suppose these ginks who argue that way hold
    that because the rich man gets ice in the summer and the poor man gets
    it in the winter things are breaking even for both. Maybe so, but I'll
    swear I can't see it that way."
    -- The last words of Bat Masterson
    John W Kennedy, Jul 9, 2008
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. youngsun park
    Replies:
    2
    Views:
    626
    David Pursley
    Nov 18, 2003
  2. David Jubinille

    Flash Goto's in Javascript

    David Jubinille, Oct 14, 2005, in forum: Javascript
    Replies:
    0
    Views:
    71
    David Jubinille
    Oct 14, 2005
  3. Replies:
    31
    Views:
    320
  4. Replies:
    2
    Views:
    113
    Randy Webb
    Mar 18, 2006
  5. MayBoy
    Replies:
    6
    Views:
    191
    Julian Turner
    Dec 14, 2006
Loading...

Share This Page