Re: Ternary operator patch
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Ternary operator patch
- From: KHMan <keinhong@...>
- Date: 2010年9月21日 08:57:02 +0800
On 9/21/2010 8:29 AM, Ryota Hirose wrote:
Hello Lua Hackers,
2010年9月21日 KHMan wrote:
So, source line 1 was compiled to 7 lines binary, line 3 was 8
lines, line 5 was 9 lines.
Look closely, why are you counting the RETURN?
I'm sorry, it's my mistake. Last RETURN becomes from whole chunk,
not a single source line. Exactly, source line 1 was compiled to
7 lines, line 3 and 5 were 8 lines.
So this is a 'win'? Colour me unimpressed.
The difference between line 1 and 3, a ternary operator and
and/or, is little. and/or needs one more TEST line (And, this
TEST line is what I want to eliminate by a ternary operator...).
There would not be any noticeable performance difference in normal
programs. I think it's better to stick to a discussion on syntax
rather than tout a case of one or two instructions saved.
I doubt adding syntax here and there for these reasons is good
programming language design.
But the difference between line 1 and 5, a ternary operator and
if-statement, is big. With a ternary operator, a
compiler calculated left operand of assignment only once. But
with if-statement, the left operand must be compiled twice. When
the left operand is complex, this difference became bigger.
If by 'left operand' you mean the LHS of 'z'? I can't remember any
complex variations for assignment other than a list of identifiers.
But look, only one path is executed -- nothing is 'saved' during
execution. There would be negligible performance difference.
16 [5] GETGLOBAL 0 -2 ; a
17 [5] TEST 0 0 0
18 [5] JMP 3 ; to 22
19 [5] GETGLOBAL 0 -3 ; b
20 [5] SETGLOBAL 0 -6 ; z
21 [5] JMP 2 ; to 24
22 [5] GETGLOBAL 0 -4 ; c
23 [5] SETGLOBAL 0 -6 ; z
If I were using my VIC-20, then I would applaud such measures of
saving an instruction here and there. But with Lua, I don't think
these can be used as very good reasons in support of your proposed
syntax.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
- References:
- Re: Ternary operator patch, Henk Boom
- Re: Ternary operator patch, steve donovan
- Re: Ternary operator patch, Geoff Leyland
- Re: Ternary operator patch, steve donovan
- Re: Ternary operator patch, Miles Bader
- Re: Ternary operator patch, David Kastrup
- Re: Ternary operator patch, Miles Bader
- Re: Ternary operator patch, David Kastrup
- Re: Ternary operator patch, Jonathan Castello
- Re: Ternary operator patch, Roberto Ierusalimschy
- Re: Ternary operator patch, Enrico Tassi
- Re: Ternary operator patch, Doug Rogers
- Re: Ternary operator patch, Ryota Hirose
- Re: Ternary operator patch, Ryota Hirose
- Re: Ternary operator patch, Tom N Harris
- Re: Ternary operator patch, Ryota Hirose
- Re: Ternary operator patch, Tom N Harris
- Re: Ternary operator patch, Ryota Hirose
- Re: Ternary operator patch, KHMan
- Re: Ternary operator patch, Ryota Hirose