Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Icon > Re: Icon / Unic...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 3 of 3 Topic 143 of 189
Post > Topic >>

Re: Icon / Unicon and the C stack

by Steve Wampler <swampler@[EMAIL PROTECTED] > Jan 31, 2007 at 08:21 AM

Frank J. Lhota wrote:
> Now imagine that generators saved their state data in the block regions,

> instead of on the C stack. That is, imagine that the expression !"ABC"
would 
> allocate a block object that contains information indicating the last
value 
> generated, along with a method for generating the next generated value.
If 
> this scheme was implemented, would there be any need for the coswitch 
> function?

Probably not, but I suspect that you'd see a performance impact.

I think this approach would require that every tem****ary value be placed
into these block objects instead of on the C stack - since very expression
is potentially a generator or need to be saved in case of a co-expression
switch.  (To avoid doing this would take some *very* clever analysis to
determine when it's safe to leave values on the stack.  For example,
in:

   x := a*2 + f()

where do you compute and store the result of a*2?  It would have to go
into the block unless you can determine that f() is neither a generator
nor contains a co-expression activation - and since the value of f() can
change dynamically, it seems effectively impossible to do so.

The 'C' stack is traditionally used for tem****ary values because [he
claims]:

  a. allocating/deallocating storage for tem****ary values is very
    efficient for 'traditional' operations (procedure calls and
    non-generator expression evaluation
  b. most machines provide very efficient instructions for accessing
    values on the stack (relative addresses, etc.)

Switching to a block-based evaluation scheme may not be much worse (but
it would be at least a little worse) for (a) since deallocation would
fall out in the normal GC operation, but would almost certainly
be worse for (b) [he claims].

However, that still doesn't mean this shouldn't be looked at more!
Modern machines are so freaking fast that a little loss in performance
may be overwhelmed by a gain in functionality - and switching to a
block-based evaluation structure opens the doors to a number of
interesting ideas.  You're no longer so closely tied to the traditional
hierarchical control flow.  Parallel evaluation of co-expressions
becomes easier to implement, for example.  Computing stack traces
would be an interesting exercise (but very doable as long as one
knows to look for cycles).

This would be a good topic to involve the Unicon mailing list in!

-Steve
-- 
Steve Wampler -- swampler@[EMAIL PROTECTED]
 gods that smiled on your birth are now laughing out loud.
 




 3 Posts in Topic:
Icon / Unicon and the C stack
"Frank J. Lhota"  2007-01-30 20:55:08 
Re: Icon / Unicon and the C stack
gmt@[EMAIL PROTECTED] (G  2007-01-31 15:19:30 
Re: Icon / Unicon and the C stack
Steve Wampler <swample  2007-01-31 08:21:46 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Fri Jul 18 20:39:18 CDT 2008.