On 27/08/07, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 8/27/07, Igor Stasenko <siguctua at gmail.com> wrote:
> >
> > I'm not pushing idea that cascade stands vs pipe. They both can be
> > quite useful, i'm just pointing you out that current implementation of
> > sequencing operators do not take in account that result is not used
> > and must be dropped. And that stinks.
>
> The issue is you can't always *know* if the result will be used or
> not.  When you generator byte codes for a method the variable storing
> on the method goes *there*.  Some callers of the method will use it,
> some wont.
>
This is not an issue with proper implementation.

> > Yes it is. I can't consider pushing value on stack just for being
> > popped after method returns as useful operation.
> > Its simply waste.
>
> It's flexible.  To do anything else is going to require some pretty
> big changes/complexity to the current system.

A complexity of implementation is expedient if it serves to increase
performance and efficiency.

>
> > Not at all. for statements like:
> > a someMessage.
> > you don't need a result, its dropped.
>
> How exactly is it dropped?  #someMessage will have op codes to return
> what ever it returns.  It has to because it can't know what callers
> expect.
>
> > And this can be easily detected. If you look at parse tree, a
> > statement which beginning from send node (not return node and not
> > assignment node) can be considered as send without need a result,
> > because its simply dropped at the end.
>
> It's easily detected in the caller, but then it's too late.  Unless
> you want to somehow dynamically change called methods byte codes
> depending on what the caller expects.
>
> > Unmeasurably?
> > Ok, simple example, a bytecode of Collection class>>with:with
> >
> > 13 <70> self
> > 14 <CC> send: new
> > 15 <88> dup
> > 16 <10> pushTemp: 0
> > 17 <E0> send: add:
> > 18 <87> pop
> > 19 <88> dup
> > 20 <11> pushTemp: 1
> > 21 <E0> send: add:
> > 22 <87> pop
> > 23 <D1> send: yourself
> > 24 <7C> returnTop
> >
> > now compare it to (suppose we having sendNoRet bytecode):
> >
> > 13 <70> self
> > 14 <CC> send: new
> > 15 <88> dup
> > 16 <10> pushTemp: 0
> > 17 <E0> sendNoRet: add:
> > 19 <88> dup
> > 20 <11> pushTemp: 1
> > 21 <E0> sendNoRet: add:
> > 23 <D1> send: yourself
> > 24 <7C> returnTop
> >
> > for each send in cascade you saving at least two operations: push
> > result and corresponding pop. Also, you saving a bytecode size in
> > method.
> > Are you still thinking that this is 'unmeasureable'?
> > Do you want me to write a 'measurer' tool which will parse all current
> > methods in squeak and shows a percentage of sends which result is not
> > used?
>
> No, I'm not really interested to be honest.  This is a small fish in a
> big pond full of things that need to be fixed.  For me much more may
> be gained by switching away from a stack based VM altogether (though
> I'm not far in my research on it yet :).
>

Yes, maybe you right, it's a small fish, you can say same for any
bytecode in bytecode implemented language. And from what you choose
and how you combine them depends an overall performance of your
language implementation.


-- 
Best regards,
Igor Stasenko AKA sig.