Mill Computing, Inc. Forums The Mill Tools Applications Threads/Coroutines

  • Author
    Posts
  • Russell Johnston
    Participant
    Post count: 9
    #737 |

    Just curious- how does state get saved for context switches? What happens with all the metadata on belt/scratch items? What about the call stack?

  • Art
    Participant
    Post count: 8

    This is discussed, at least briefly, here: http://millcomputing.com/topic/the-belt/. The description starts at slide 40, at 00:30:46 in the video.

    In short, the state is saved/restored by a hardware mechanism. All the metadata is saved/restored with it.

    The “call stack” on a Mill is not the same as on a conventional. On a Mill, data that is not part of programmer visible state (such as function or interrupt return address) is saved/restored by the spiller hardware, and if enough levels of interrupt and/or function call occur to push this data to main memory, it is pushed to a completely different memory block. Normally, except for debugging, this “saved state” region is protected from all access except by the spiller hardware. The programmer visible “call stack” (such as C automatic local function variables) on a Mill is in a memory privilege region containing only programmer visible variables.

    This same spiller hardware mechanism is used by the OS to change thread contexts. How something like Unix fork is handled is NYF, and I will defer to Ivan to explain that when it is.

    • Russell Johnston
      Participant
      Post count: 9

      Ah, okay. What are the performance implications of this method of context switching? It sounds like they could be pretty good- spilled lazily, etc. Iā€™m wondering specifically what it would mean for things like coroutines, continuations, etc. Or is that too closely related to fork()?

      • Ivan Godard
        Keymaster
        Post count: 689

        Everything is lazy and background, so performance is very good unless you do a deeply nested run of calls with lots of arguments and no work except the next nested call. “Very good” here means the usual one-cycle cost of a call.

        There is support for coroutines (though NYF) and non-resumeable continuations. Scheme-style repeatable continuations require a garbage collector, which is not what hardware does šŸ™‚

You must be logged in to reply to this topic.